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. > > Can these files with discontinuities be detected somehow from the headers? > If so then the probe function could be changed so they get the discontinuity > flag while valid files do not have the disadvantages from having it set > Not that I know, unless FLV dumped from RTMP somehow magically has some special identifier. I have not noticed any so far. Jan _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
