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"
<[email protected] on behalf of [email protected]>
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
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
