[FFmpeg-devel] [PATCH] mov.c: read fragment start dts from fragmented mp4
mikie at iki.fi
Fri Oct 10 06:38:05 CEST 2014
On 9 October 2014 23:37, Yusuke Nakamura <muken.the.vfrmaniac at gmail.com> wrote:
> 2014-10-10 4:49 GMT+09:00 Michael Niedermayer <michaelni at gmx.at>:
>> On Thu, Oct 09, 2014 at 09:44:43PM +0200, Michael Niedermayer wrote:
>> > On Thu, Oct 09, 2014 at 06:57:59PM +0300, Mika Raento wrote:
>> > > If present, an MFRA box and its TFRAs are read for fragment start
>> > >
>> > > Without this change, timestamps for discontinuous fragmented mp4 are
>> > > wrong, and cause audio/video desync and are not usable for generating
>> > > HLS.
>> > > ---
>> > > libavformat/isom.h | 15 ++++++
>> > > libavformat/mov.c | 140
>> > > 2 files changed, 155 insertions(+)
>> > this seems to break some files
>> > for example a file generated with the following 2 commands:
>> > ffmpeg -i matrixbench_mpeg2.mpg -t 10 in.mp4
>> > l-smash/cli/remuxer -i in.mp4 --fragment 1 -o test.mp4
>> > ive not investigated why this doesnt work
>> maybe above was unclear, so to clarify before someone is confused
>> test.mp4 from above plays with ffplay before te patch but not really
>> aferwards. The 2 commads are just to create such file
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>> Good people do not need laws to tell them to act responsibly, while bad
>> people will find a way around the laws. -- Plato
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
> The 'time' field in the tfra box is defined in presentation timeline, not
> composition or decode timeline.
> Therefore, generally, the value of 'time' can't be used for DTS directly as
> long as following 14496-12.
> Maybe some derivatives of ISO Base Media file format define differently,
> but the spec of ISO Base Media file format defines 'time' as the
> presentation time of the sync sample.
> Presentation times are composition times after the application of any edit
> list for the track.
> I have also some samples which use the 'time' as DTS of sync sample.
> Historically, the term 'presentation time' was not defined clearly before
> 14496-12:2012, this fact possibly may have brought about such inconsistency.
Hm. So my changes aren't correct if there is an edit list? Because
AFAICT without edit lists mov.c sets pkt->pts = pkt->dts.
Would you mind explaining how edit lists and fragment times are
supposed to work together?
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel