[FFmpeg-devel] [PATCH] mov.c: read fragment start dts from fragmented mp4

[Mika Raento]

Right. Will definitely take a look.

I wouldn't mind help turning that into a fate testcase. I've been
struggling with writing fate tests. At least for somebody like me,
having more coverage in the fate tests would help enormously, as I
definitely do not have the required expertise to know what may break
with my changes (and I'm thankful for the reviews that try to fix that
problem).

    Mika

On 9 October 2014 22:49, Michael Niedermayer <michaelni at gmx.at> wrote:
> 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 times.
>> >
>> > 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
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>