[FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

Jan Ekström jeebjp at gmail.com
Thu Nov 22 19:18:04 EET 2018

On Thu, Nov 22, 2018 at 4:17 AM Michael Niedermayer
<michael at 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.buitenhuis at 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.


More information about the ffmpeg-devel mailing list