#5448: aac: wrong calculation of duration
-------------------------------------+-------------------------------------
Reporter: ami_stuff | Owner: (none)
Type: defect | Status: open
Priority: minor | Component: avformat
Version: git-master | Resolution:
Keywords: aac | Blocked By:
regression |
Blocking: | Reproduced by developer: 1
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by RutD0g):
Bottom line:
{{{
ffmpeg -i audio.aac[.adts]/video.ts -c copy audio.m4a/video.mp4
}}}
The workaround solution is to use a different container. I have found
success muxing AAC audio into MP4/M4A. No need to recode, just -c copy.
Replying to [comment:3 Jozef Chutka]:
> Hi everyone, considering this error exists for 6 years, is there any
recent work ongoing? Or should be aac format in ffmpeg considered
unstable?
The best I've been able to figure out is that it's not a bug, it's a
limitation of the container represented by the .AAC extension.
Adding to the confusion is that the .AAC file extension, unlike MP4/M4A,
MKV/MKA, etc., is NOT representing a container of the same or similar
name.
As someone said elsewhere (I can't remember where) "AAC is a codec, not a
container."
File extension .AAC is just a synonym for .ADTS, the audio version of .TS
for video. These are transport stream containers.
I'm unclear why, but TS containers do not include the type of time data
that other containers include. At least in the .AAC and .TS files I've
dealt with.
I first encountered this because some media players are error prone when
playing .TS videos. Some players can't play them at all, others play but
you can't FF or RW. They are also prone to go on "forever", like a 2 hour
video that stretches to 8 hours.
Recently working with audio files, I noticed my .AAC audio files were
displaying inaccurate times. They play fine, but usually the time estimate
(see below) is a little low. When the progress bar hits the "end" it just
keeps playing, right up to the time that I originally expected
Using ffprobe on an .AAC audio file returns the following:
{{{
[aac @ 00000186079e0100] Estimating duration from bitrate, this may be
inaccurate
}}}
And a sample .TS video file has a time related error as well:
{{{
[mpegts @ 000001298c210100] start time for stream 2 is not set in
estimate_timings_from_pts
}}}
Most media players figure it out and play the media. And Windows OS also
estimates the "length" property in Explorer, but at least with audio files
the estimates are always a bit off.
The workaround solution is to use a different container. I have found
success muxing AAC audio (no need to recode, just -c copy) into MP4/M4A.
According to [https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio this
TRAC guide], you can also use MKV/MKA, FLV/F4V, and RMVB, but I haven't
tested any of those.
The workaround solution is to use a different container. I have found
success muxing AAC audio into MP4/M4A. No need to recode, just -c copy.
{{{
ffmpeg -i audio.aac[.adts]/video.ts -c copy audio.m4a/video.mp4
}}}
And ffprobe on these .mp4/.m4a files don't produce any messages about
time.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/5448#comment:4>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac
To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".
