On Mon, Oct 13, 2014 at 12:36:30PM +0200, Michael Niedermayer wrote:
> On Mon, Oct 13, 2014 at 08:54:31AM +0300, Mika Raento wrote:
> > On 11 October 2014 23:02, Michael Niedermayer <michae...@gmx.at> wrote:
> > > On Sat, Oct 11, 2014 at 08:38:14PM +0300, Mika Raento wrote:
> > >> On 11 October 2014 20:20, Michael Niedermayer <michae...@gmx.at> wrote:
> > >> > 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 ?
> > >>
> > >> I can share a file privately (copyrighted). I do not have a reduced
> > >> test case. Let me know if you think that's helpful.
> > >
> > > dunno, might be usefull
> > >
> > >
> > >>
> > >> The files come from a commercial packager that is getting
> > >> discontinuous input from a commercial transcoder. My understanding is
> > >> that, the timestamp issue comes from the packager, rather than the
> > >> transcoder. The underlying software in the packager is Code-shop's
> > >> Unified Streaming, but it's been fed from proprietary software.
> > >>
> > >> This is what ffprobe says, it's not very specific:
> > >>
> > >> (multiprofile-streamers)mikie@universe:~/devel/multiprofile-streamers$
> > >> ffprobe -i ../multiprofile-fixer/hls-disco/50603088.ismv
> > >> ffprobe version N-66765-g67d95df Copyright (c) 2007-2014 the FFmpeg
> > >> developers
> > >> built on Oct 11 2014 18:42:41 with Apple LLVM version 6.0
> > >> (clang-600.0.51) (based on LLVM 3.5svn)
> > >> configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD
> > >> --enable-shared --enable-pthreads --enable-gpl --enable-version3
> > >> --enable-nonfree --enable-hardcoded-tables --enable-avresample
> > >> --enable-vda --cc=clang --host-cflags= --host-ldflags=
> > >> --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid
> > >> --enable-debug --disable-stripping --enable-libass
> > >> libavutil 54. 10.100 / 54. 10.100
> > >> libavcodec 56. 4.101 / 56. 4.101
> > >> libavformat 56. 9.100 / 56. 9.100
> > >> libavdevice 56. 1.100 / 56. 1.100
> > >> libavfilter 5. 1.103 / 5. 1.103
> > >> libavresample 2. 1. 0 / 2. 1. 0
> > >> libswscale 3. 1.100 / 3. 1.100
> > >> libswresample 1. 1.100 / 1. 1.100
> > >> libpostproc 53. 1.100 / 53. 1.100
> > >> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
> > >> '../multiprofile-fixer/hls-disco/50603088.ismv':
> > >> Metadata:
> > >> major_brand : isom
> > >> minor_version : 1
> > >> compatible_brands: isomiso2
> > >> Duration: 02:17:00.14, start: 0.000000, bitrate: 4411 kb/s
> > >> Stream #0:0(mul): Audio: aac (mp4a / 0x6134706D), 48000 Hz,
> > >> stereo, fltp, 124 kb/s (default)
> > >> Metadata:
> > >> handler_name : Sound Handler
> > >> Stream #0:1(mul): Audio: aac (mp4a / 0x6134706D), 48000 Hz,
> > >> stereo, fltp, 29 kb/s (default)
> > >> Metadata:
> > >> handler_name : Sound Handler
> > >> Stream #0:2(und): Video: h264 (Main) (avc1 / 0x31637661),
> > >> yuv420p(tv, bt470bg), 480x270 [SAR 1:1 DAR 16:9], 597 kb/s, 25 fps, 25
> > >> tbr, 10000k tbn, 50 tbc (default)
> > >> Metadata:
> > >> handler_name : Video Handler
> > >> encoder : AVC Coding
> > >> Stream #0:3(und): Video: h264 (Main) (avc1 / 0x31637661),
> > >> yuv420p(tv, bt470bg), 640x360 [SAR 1:1 DAR 16:9], 1195 kb/s, 25 fps,
> > >> 25 tbr, 10000k tbn, 50 tbc (default)
> > >> Metadata:
> > >> handler_name : Video Handler
> > >> encoder : AVC Coding
> > >> Stream #0:4(und): Video: h264 (High) (avc1 / 0x31637661),
> > >> yuv420p(tv, bt470bg), 768x432 [SAR 1:1 DAR 16:9], 2487 kb/s, 25 fps,
> > >> 25 tbr, 10000k tbn, 50 tbc (default)
> > >> Metadata:
> > >> handler_name : Video Handler
> > >> encoder : AVC Coding
> > >>
> > >>
> > >> >
> > >> > 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.
> > >>
> > >> From the differences between the packagers and the different
> > >> interpretations of the spec, I'm not very eager to attempt
> > >> autodetection.
> > >>
> > >> Consider ffmpeg: we'll at some point change the fragmentation code to
> > >> use pts. Whether that'll be visible in the file metadata is unclear.
> > >
> > > LIBAVFORMAT_IDENT will change as the version will change
> >
> >
> > I know we aren't exactly ecstatic about this change, but from my POV I
> > don't see a way to make it better: I am not working on a new version,
> > and would like to get this committed. Obviously, if committers
> > disagree I will try to address any issues they have.
>
> hmm, patch appliedpatchset posted which implements autodetection [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
