[FFmpeg-devel] [PATCH] mov.c: allow reading fragment start dts/pts from fragmented mp4

[Michael Niedermayer]

On Sat, Oct 11, 2014 at 06:43:48PM +0300, Mika Raento wrote:
> This introduces a new option to the mov demuxer: -use_mfra_for
> (pts|dts). When it's given and moofs and a MFRA are present, the MFRA's
> TFRAs are read for fragment start times.
> 
> Unfortunately some programs that produce fragmented mp4s use the TFRA
> time field for dts and some for pts. There is no realistic way to detect
> which is the case, hence the responsibility is punted onto the user.
> This also means that no behavioural change is enabled by default - you
> must pass either dts or pts for anything to happen.
> 
> Without this change, timestamps for some discontinuous fragmented mp4 are
> wrong, and cause audio/video desync and are not usable for generating
> HLS.
> ---
[...]
> @@ -3943,6 +4111,15 @@ static const AVOption options[] = {
>          0, 1, AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_DECODING_PARAM},
>      {"ignore_editlist", "", offsetof(MOVContext, ignore_editlist), FF_OPT_TYPE_INT, {.i64 = 0},
>          0, 1, AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_DECODING_PARAM},
> +    {"use_mfra_for",
> +        "use mfra for fragment timestamps",
> +        offsetof(MOVContext, use_mfra_for), FF_OPT_TYPE_INT, {.i64 = 0},
> +        0, FF_MOV_FLAG_MFRA_PTS, AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_DECODING_PARAM,
> +        "use_mfra_for"},

maybe a FF_MOV_FLAG_MFRA_AUTO which is set by default could be used to
guess based on some encoder/muxer identification what to do.

do the files which need this option have something that idenifies
them? like in metadata, compatible brands or other?
and can you share a file/testcase which needs this patch ?

Also ISO/IEC 14496-12:2008(E) seems to say this:
    This box provides only a hint as to where random access points are; the movie fragments themselves are
    definitive. It is recommended that readers take care in both locating and using this box as modifications to the
    file after it was created may render either the pointers, or the declaration of random access points, incorrect.

so if i understand it correctly, using these boxes requires some care
like maybe checking for some brand or muxer/encoder which makes further
gurantees about their validity.

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141011/85d1a512/attachment.asc>