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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
