[FFmpeg-user] apple-friendly timestamps with -c copy

[Claudiu Rad]

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> 
>> wrote:
>>
>>> 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 
answer:
/
/
/"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 
invalid content."/

so this gets interesting as due to the lack of CTTS, they strictly 
adhere to decoding order, unlike ffmpeg and others, thus, the playback 
issue.
why isn't ffmpeg regenerating this table when transcoding if it doesn't 
exist?

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

-- 
Claudiu