[FFmpeg-user] apple-friendly timestamps with -c copy
jazzman at misalpina.net
Tue Dec 22 08:00:15 CET 2015
On 12/21/2015 3:19 PM, Claudiu Rad wrote:
> On 12/20/2015 2:55 AM, Laine Lee wrote:
>> On 12/18/15, 12:41 PM, "ffmpeg-user on behalf of Claudiu Rad"
>> <ffmpeg-user-bounces at ffmpeg.org on behalf of jazzman at misalpina.net>
>>> anyone? i really need to find a solution without re-encoding the whole
>> I worked around this issue by using Remux 1.3.1 in OS X, available
>> from MacUpdate. When I saw a similar issue in Mencoder output, I
>> discovered that "-lavfopts format=mp4” appeared to solve it, but even
>> with an ffmpeg equivalent, it would mean re-encoding, of course.
> so just remuxing without reencoding? this would confirm that the issue
> is fixable by only fiddling around with the timestamps as i suspected.
> ffmpeg by default also automatically fixes this if i just reencode,
> probably because it knows to properly decode the input and then
> regenerates timestamps.
> it's a pity though that timestamps / frame order in ffmpeg cannot be
> easily controlled without reencoding. after all, this is not actual
> media content, just metadata (although mandatory for playback).
> maybe a bitstream filter would to the trick?
i also filled a bug at apple in the meantime and got back an interesting
/"Please know that our engineering team has determined that this issue
behaves as intended based on the information provided./
/The movie clearly has b-frames and requires frame reordering, but it
lacks a ‘ctts’ (also known as the Composition Offsets table) in the
header. So, we play back the frames in the order which they were decoded./
/This is clearly a malformed mp4, since it lacks the required
Composition Offset table. Other players may play back the movie without
regard for this movie header information, but we strictly adhere to the
timing information they provide - not doing so will cause us to
disregard what may be intentional updates to this header data./
/If you can, you have authored this content with your own tools you
should update your tools to correctly add this composition offset
information. Otherwise, if you know what tools were used to author the
media, you should report this issue so that they can cease creating
so this gets interesting as due to the lack of CTTS, they strictly
adhere to decoding order, unlike ffmpeg and others, thus, the playback
why isn't ffmpeg regenerating this table when transcoding if it doesn't
in this case i see two possible ways of going further:
- somehow regenerate CTTS (anyone has any ideas? maybe converting to
some other container formats?)
- somehow force frame reordering, although not very sure this would fix
the issue in this particular case. still, i do believe it's possible
because my current setup takes input from the same encoder and without
reencoding the output has nice monotonically increasing timestamps. i
still have to figure out who does this in the processing chain
More information about the ffmpeg-user