<p>How do you know file is 2:09:42 long?</p>

<p>From ffmpeg documention:</p>

<blockquote>
  <p><strong>Get duration by decoding</strong><br>
  You can also use <code>ffmpeg</code> to get the duration by fully decoding the file. The null muxer is used so no output file is created. Refer to <code>time=</code> in the last line of the console output. In this example the input has a duration of 00:57:28.87. </p>
</blockquote>

<pre><code>$ ffmpeg -i input.webm -f null -
...
frame=206723 fps=1390 q=-0.0 Lsize=N/A time=00:57:28.87 bitrate=N/A speed=23.2x
</code></pre>

<blockquote>
  <ul>
  <li>This method will report the correct duration in case the methods using ffprobe are incorrect or missing due to corrupt, truncated, or damaged files. </li>
  <li>The command may take some time depending on the input file duration and decoding complexity. </li>
  </ul>
</blockquote>

<p>So it seems that your file timings are <em>"incorrect or missing due to corrupt, truncated, or damaged files."</em><br>
Hence your ffprobe report contains wrong duration.
Your remux <em>"did not change anything"</em> because you did not encode the file: <code>-codec copy</code></p>

<p>2nd line of your report shows: <em>"Duration: N/A, bitrate: N/A"</em> which is another indication of damaged file.
Further in the report, you'll notice <em>"Estimating duration from bitrate, this may be inaccurate"</em></p>

<p>Try this:</p>

<pre><code>ffmpeg -i input.mp4 -c:v libx264 x.mp4
</code></pre>

<p>With a very good computer, this should be done in about 2 hrs. 
Enjoy.</p>

CC BY-SA 4.0
2020-02-20T15:27:25.103Z
`-c:v libx264` may be omitted as it is the default codec for the mp4 container
MarianD
CC BY-SA 4.0
2020-02-20T16:02:17.483Z
"How do you know file is 2:09:42 long?" => GSpot shows this duration and it corresponds to the length of the visible movie. I really would like to avoid recoding the file. I have now recoded the aac stream to MP3. It really is 7 hours long. The audio is repeated multiple times. No idea why. So I guess I can just trim that stream? Is that appropriate?
boot4life
CC BY-SA 4.0
2020-02-21T12:50:00.180Z
How did you encode the aac stream to MP3? Try `ffmpeg -i "input.mp4" out.mp3`. VLC doesn't seem to report the correct timestamps of some aac files. When playing the file, it will report how much of the audio has been played, but won't show the correct amount of time left. If you play the video in VLC, it should finish in 2:09:42.
Try Audacity to extract audio from video file, or `ffmpeg -i "input.mp4" -vn -acodec copy audio.aac`. Audacity will report the correct time for the extracted audio file, but VLC won't. However, both should play the entire audio in 2:09:42.
Zimba
CC BY-SA 4.0
2020-02-22T11:02:34.730Z
I have used DbPowerAmp to transcode the file. The new MP3 file is playable and seekable for the full 7 hours. Could it be that the AAC stream is simply 7 hours long and the video duration is therefore correctly reported? Maybe I just need to cut off the superfluous AAC data. I suspect at this point that some accident happened when this MP4 file was created (it wasn't created by me).
boot4life
CC BY-SA 4.0
2020-02-27T14:05:53.917Z
Can you send me a link to the file?
Zimba
CC BY-SA 4.0
2020-02-20T08:49:36.657Z
2020-02-20T09:39:56.647Z
2020-02-20T09:39:56.647Z
Zimba
<p>I've got an MP4 file that is actually 2:09:42 long. But when playing it in VLC player it is being shown as 7:13:45 long. I'm trying to fix this file.</p>

<p>I remuxed it using <code>ffmpeg -i input.mp4 -codec copy output.mp4</code> which did not change anything.</p>

<p><code>ffprobe</code> reports:</p>

<pre><code>Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 1
    compatible_brands: isomavc1
    creation_time   : 2012-12-12T09:35:27.000000Z
  Duration: 07:13:45.09, start: 0.000000, bitrate: 578 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x800
[SAR 1:1 DAR 12:5], 1618 kb/s, 23.98 fps, 23.98 tbr, 96k tbn, 47.95 tbc (default
)
    Metadata:
      creation_time   : 2012-12-12T09:35:27.000000Z
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, flt
p, 92 kb/s (default)
    Metadata:
      creation_time   : 2012-12-12T09:36:27.000000Z
      handler_name    : GPAC ISO Audio Handler
</code></pre>

<p>I demuxed the file and tried to recombine the streams. Here, this is shown:</p>

<pre><code>Input #0, h264, from 'x.h264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x800 [SAR 1:1 DAR
 12:5], 23.98 fps, 23.98 tbr, 1200k tbn, 47.95 tbc
[aac @ 000000000328a8c0] Estimating duration from bitrate, this may be inaccurat
e
Input #1, aac, from 'x.aac':
  Duration: 07:14:19.51, bitrate: 94 kb/s
    Stream #1:0: Audio: aac (LC), 48000 Hz, stereo, fltp, 94 kb/s
Output #0, mp4, to 'x.mp4':
  Metadata:
    encoder         : Lavf58.38.101
    Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1
920x800 [SAR 1:1 DAR 12:5], q=2-31, 23.98 fps, 23.98 tbr, 1200k tbn, 1200k tbc
    Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 94
 kb/s
Stream mapping:
  Stream #0:0 -&gt; #0:0 (copy)
  Stream #1:0 -&gt; #0:1 (copy)
</code></pre>

<p>Here, the wrong duration is shown for the aac stream. Does this mean that the aac stream has wrong time information?</p>

<p>When I play the aac file VLC player shows 7 hours duration. When I play the h264 file no duration is shown.</p>

<p>I then tried to remux specifying <code>-t 2:09:42</code>. This makes VLC player display the correct duration. The movie plays normally and appears complete. But the file size dropped from 1.8 GB to 1.6 GB which makes me suspect that I somehow lost data.</p>

<p>How can I fix this file?</p>

<p>Update: I have now recoded the aac stream to MP3. It really is 7 hours long. The audio is repeated multiple times. No idea why. So I guess I can just trim that stream? Is that appropriate?</p>

CC BY-SA 4.0
2020-02-20T16:04:00.870Z
Update: I have now recoded the aac stream to MP3. It really is 7 hours long. The audio is repeated multiple times. No idea why. So I guess I can just trim that stream? Is that appropriate?
boot4life
<ffmpeg><mp4>
AAC stream in MP4 file has wrong duration. How to fix?
boot4life
# AAC stream in MP4 file has wrong duration. How to fix?

(Asked by: username_0 on 2020-02-19)

I've got an MP4 file that is actually 2:09:42 long. But when playing it in VLC player it is being shown as 7:13:45 long. I'm trying to fix this file.
I remuxed it using ffmpeg -i input.mp4 -codec copy output.mp4 which did not change anything.
ffprobe reports:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 1
    compatible_brands: isomavc1
    creation_time   : 2012-12-12T09:35:27.000000Z
  Duration: 07:13:45.09, start: 0.000000, bitrate: 578 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x800
[SAR 1:1 DAR 12:5], 1618 kb/s, 23.98 fps, 23.98 tbr, 96k tbn, 47.95 tbc (default
)
    Metadata:
      creation_time   : 2012-12-12T09:35:27.000000Z
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, flt
p, 92 kb/s (default)
    Metadata:
      creation_time   : 2012-12-12T09:36:27.000000Z
      handler_name    : GPAC ISO Audio Handler

I demuxed the file and tried to recombine the streams. Here, this is shown:
Input #0, h264, from 'x.h264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x800 [SAR 1:1 DAR
 12:5], 23.98 fps, 23.98 tbr, 1200k tbn, 47.95 tbc
[aac @ 000000000328a8c0] Estimating duration from bitrate, this may be inaccurat
e
Input #1, aac, from 'x.aac':
  Duration: 07:14:19.51, bitrate: 94 kb/s
    Stream #1:0: Audio: aac (LC), 48000 Hz, stereo, fltp, 94 kb/s
Output #0, mp4, to 'x.mp4':
  Metadata:
    encoder         : Lavf58.38.101
    Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1
920x800 [SAR 1:1 DAR 12:5], q=2-31, 23.98 fps, 23.98 tbr, 1200k tbn, 1200k tbc
    Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 94
 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #1:0 -> #0:1 (copy)

Here, the wrong duration is shown for the aac stream. Does this mean that the aac stream has wrong time information?
When I play the aac file VLC player shows 7 hours duration. When I play the h264 file no duration is shown.
I then tried to remux specifying -t 2:09:42. This makes VLC player display the correct duration. The movie plays normally and appears complete. But the file size dropped from 1.8 GB to 1.6 GB which makes me suspect that I somehow lost data.
How can I fix this file?
Update: I have now recoded the aac stream to MP3. It really is 7 hours long. The audio is repeated multiple times. No idea why. So I guess I can just trim that stream? Is that appropriate?

**Tags:** ffmpeg, mp4

> **Comments:**
> **username_0**: Update: I have now recoded the aac stream to MP3. It really is 7 hours long. The audio is repeated multiple times. No idea why. So I guess I can just trim that stream? Is that appropriate?  

---

## 1 answers

### Answer by username_1 on 2020-02-20. Score: 1

How do you know file is 2:09:42 long?
From ffmpeg documention:

Get duration by decoding
  You can also use ffmpeg to get the duration by fully decoding the file. The null muxer is used so no output file is created. Refer to time= in the last line of the console output. In this example the input has a duration of 00:57:28.87. 

$ ffmpeg -i input.webm -f null -
...
frame=206723 fps=1390 q=-0.0 Lsize=N/A time=00:57:28.87 bitrate=N/A speed=23.2x



This method will report the correct duration in case the methods using ffprobe are incorrect or missing due to corrupt, truncated, or damaged files. 
The command may take some time depending on the input file duration and decoding complexity. 


So it seems that your file timings are "incorrect or missing due to corrupt, truncated, or damaged files."
Hence your ffprobe report contains wrong duration.
Your remux "did not change anything" because you did not encode the file: -codec copy
2nd line of your report shows: "Duration: N/A, bitrate: N/A" which is another indication of damaged file.
Further in the report, you'll notice "Estimating duration from bitrate, this may be inaccurate"
Try this:
ffmpeg -i input.mp4 -c:v libx264 x.mp4

With a very good computer, this should be done in about 2 hrs. 
Enjoy.

> **Comments:**
> **username_2**: `-c:v libx264` may be omitted as it is the default codec for the mp4 container  
> **username_0**: "How do you know file is 2:09:42 long?" => GSpot shows this duration and it corresponds to the length of the visible movie. I really would like to avoid recoding the file. I have now recoded the aac stream to MP3. It really is 7 hours long. The audio is repeated multiple times. No idea why. So I guess I can just trim that stream? Is that appropriate?  
> **username_1**: How did you encode the aac stream to MP3? Try `ffmpeg -i "input.mp4" out.mp3`. VLC doesn't seem to report the correct timestamps of some aac files. When playing the file, it will report how much of the audio has been played, but won't show the correct amount of time left. If you play the video in VLC, it should finish in 2:09:42. Try Audacity to extract audio from video file, or `ffmpeg -i "input.mp4" -vn -acodec copy audio.aac`. Audacity will report the correct time for the extracted audio file, but VLC won't. However, both should play the entire audio in 2:09:42.  
> **username_0**: I have used DbPowerAmp to transcode the file. The new MP3 file is playable and seekable for the full 7 hours. Could it be that the AAC stream is simply 7 hours long and the video duration is therefore correctly reported? Maybe I just need to cut off the superfluous AAC data. I suspect at this point that some accident happened when this MP4 file was created (it wasn't created by me).  
> **username_1**: Can you send me a link to the file?  

---

