On Thu, Nov 22, 2018 at 07:18:04PM +0200, Jan Ekström wrote: > On Thu, Nov 22, 2018 at 4:17 AM Michael Niedermayer > <mich...@niedermayer.cc> wrote: > > > > On Wed, Nov 21, 2018 at 03:58:47PM +0000, Derek Buitenhuis wrote: > > > Any FLV file, not necessarily valid, but in extremely common use for live > > > or archived live purposes, may output discontinuous timestamps. As it > > > currently > > > is, only files produced by NGINX's RTMP module will be marked as > > > supporting > > > discontinuous timestamps, which is obviously untrue, and the fix was only > > > ever put in place for a single bug report / file. The FLV demuxer, however > > > will happily ingest any FLV, and output discontinuous timestamps, > > > regardless > > > of whether this "live" demuxer is used, making the current set of flags > > > untrue. > > > > > > Add the flag to the main demuxer, as this is how it *actually* works. > > > Lying to > > > downstream API users about a demuxer's behavior is not OK. > > > > > > Also set AVFMT_NOBINSEARCH, as this should be true given discontinuous > > > timetsamps. > > > > > > Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com> > > > --- > > > libavformat/flvdec.c | 14 ++++---------- > > > 1 file changed, 4 insertions(+), 10 deletions(-) > > > > the specification says this: > > "Timestamp UI24 Time in milliseconds at which the data in this tag > > applies. This is relative to the first tag in the FLV file, > > which always has a timestamp of 0. > > " > > So flv does not seem to allow discontinuities. Any tool writing files with > > discontinuities would be faulty > > How do you separate FLV files that came from RTMP originally (be it > live or VOD) from files that were "just files"? > > Additionally, wasn't FLV with a time base of 1000 and a 32bit (signed > in "file" format and unsigned in RTMP (?!?!)) time stamp. See > 4d3dd167dfdfa2f36724f5613f05f46e3477c0d1 . > > I think I'm trying to sit down and note that FLV is a colossal mess > for everyone at this point. >
> > > > declaring files which have no discontinuities as having some would > > result in worse performing seeking in some cases. Both slower and or less > > accurate. Also flv IIRC allows gaps in tracks like no packets where there is > > silence. This may interfere with discontinuities as it looks > > like a discontinuity. > > Yes, timestamps jumping is valid and I don't see this being similar to > discontinuities. The fact that ffmpeg.c doesn't like intra-stream > timestamp jumps in case this flag is set is orthogonal to this > specific thing IMHO. a simple example: 0,1,2,3,4,403,404,405 these are a files timestamps, is this a discontinuity or a gap of silence? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
