Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On Thu, Jan 17, 2019 at 09:45:04PM +, Derek Buitenhuis wrote: > On 15/01/2019 21:24, Michael Niedermayer wrote: > > Heres a better patch which may work with seeking as long as there are only > > 2 files concatenated > > > > i think completely discarding the parts after the concatenation would cause > > user complaints and they would have a point, if the data is in there we > > should be able to recover it for muxing it in a better file at least > > No strong opinion. You can push. will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On 15/01/2019 21:24, Michael Niedermayer wrote: > Heres a better patch which may work with seeking as long as there are only > 2 files concatenated > > i think completely discarding the parts after the concatenation would cause > user complaints and they would have a point, if the data is in there we > should be able to recover it for muxing it in a better file at least No strong opinion. You can push. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On Thu, Jan 03, 2019 at 04:21:37PM +, Derek Buitenhuis wrote:
> On 03/01/2019 01:33, Michael Niedermayer wrote:
> > The file looks like 2 files concatenated, even with FLV main header between
> > them.
>
> Yes, they all seem to be. I was under the impression FLV didn't have a header
> to
> check against like this. Seems I was wrong.
>
> > the patch below should make this work with sequential demuxing assuming the
> > 2 files dont change streams somehow with the normal demuxer.
> >
> > not sure this is the best way to do it ...
>
> [...]
>
> > also trying a random other flv related tool, FLVTool2 1.0.6 does not seem to
> > demux the 2nd file of the 2 correctly. Which makes me suspect more that the
> > file is invalid. Not that this would fundamentally change anything
>
> Some do, some don't. Classic multimedia.
>
> I would also be OK with a patch that simply stops demuxing like many programs
> seem to do, instead of outputting the packets. Up to you which you prefer; I
> have
> no strong opinion between the two.
>
> > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> > index 4b9f46902b..c9423da31c 100644
> > --- a/libavformat/flvdec.c
> > +++ b/libavformat/flvdec.c
>
> [...]
>
> > static int probe(AVProbeData *p, int live)
> > @@ -917,6 +919,17 @@ static int resync(AVFormatContext *s)
> > flv->resync_buffer[j ] =
> > flv->resync_buffer[j1] = avio_r8(s->pb);
> >
> > +if (i >= 8) {
> > +uint8_t *d = flv->resync_buffer + j1 - 8;
> > +if (d[0] == 'F' &&
> > +d[1] == 'L' &&
> > +d[2] == 'V' &&
> > +d[3] < 5 && d[5] == 0) {
> > +av_log(s, AV_LOG_WARNING, "Concatenated FLV detected,
> > might fail to demux, decode and seek %Ld\n", flv->last_ts);
> > +flv->time_offset = flv->last_ts + 1;
> > +}
> > +}
>
> How does this affect seeking? That is, is it safe? If it beaks seeking,
> it may be better to not output the concatenated packets at all.
Heres a better patch which may work with seeking as long as there are only
2 files concatenated
i think completely discarding the parts after the concatenation would cause
user complaints and they would have a point, if the data is in there we
should be able to recover it for muxing it in a better file at least
commit 41db08743da8a624c35d138130379aa1a46d3a53 (HEAD -> master)
Author: Michael Niedermayer
Date: Thu Jan 3 01:08:31 2019 +0100
avformat/flvdec: Try to support some concatenated flv files
Fixes: discont.flv
Signed-off-by: Michael Niedermayer
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 4b9f46902b..80bbc5cfeb 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -72,6 +72,9 @@ typedef struct FLVContext {
int64_t *keyframe_filepositions;
int missing_streams;
AVRational framerate;
+int64_t last_ts;
+int64_t time_offset;
+int64_t time_pos;
} FLVContext;
static int probe(AVProbeData *p, int live)
@@ -917,6 +920,18 @@ static int resync(AVFormatContext *s)
flv->resync_buffer[j ] =
flv->resync_buffer[j1] = avio_r8(s->pb);
+if (i >= 8 && pos) {
+uint8_t *d = flv->resync_buffer + j1 - 8;
+if (d[0] == 'F' &&
+d[1] == 'L' &&
+d[2] == 'V' &&
+d[3] < 5 && d[5] == 0) {
+av_log(s, AV_LOG_WARNING, "Concatenated FLV detected, might
fail to demux, decode and seek %Ld\n", flv->last_ts);
+flv->time_offset = flv->last_ts + 1;
+flv->time_pos= avio_tell(s->pb);
+}
+}
+
if (i > 22) {
unsigned lsize2 = AV_RB32(flv->resync_buffer + j1 - 4);
if (lsize2 >= 11 && lsize2 + 8LL < FFMIN(i, RESYNC_BUFFER_SIZE)) {
@@ -1072,6 +1087,10 @@ skip:
}
av_log(s, AV_LOG_TRACE, "%d %X %d \n", stream_type, flags,
st->discard);
+if (flv->time_pos <= pos) {
+dts += flv->time_offset;
+}
+
if ((s->pb->seekable & AVIO_SEEKABLE_NORMAL) &&
((flags & FLV_VIDEO_FRAMETYPE_MASK) == FLV_FRAME_KEY ||
stream_type == FLV_STREAM_TYPE_AUDIO))
@@ -1282,6 +1301,10 @@ leave:
}
}
}
+
+if (ret >= 0)
+flv->last_ts = pkt->dts;
+
return ret;
}
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Never trust a computer, one day, it may think you are the virus. -- Compn
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On 03/01/2019 01:33, Michael Niedermayer wrote:
> The file looks like 2 files concatenated, even with FLV main header between
> them.
Yes, they all seem to be. I was under the impression FLV didn't have a header to
check against like this. Seems I was wrong.
> the patch below should make this work with sequential demuxing assuming the
> 2 files dont change streams somehow with the normal demuxer.
>
> not sure this is the best way to do it ...
[...]
> also trying a random other flv related tool, FLVTool2 1.0.6 does not seem to
> demux the 2nd file of the 2 correctly. Which makes me suspect more that the
> file is invalid. Not that this would fundamentally change anything
Some do, some don't. Classic multimedia.
I would also be OK with a patch that simply stops demuxing like many programs
seem to do, instead of outputting the packets. Up to you which you prefer; I
have
no strong opinion between the two.
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 4b9f46902b..c9423da31c 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
[...]
> static int probe(AVProbeData *p, int live)
> @@ -917,6 +919,17 @@ static int resync(AVFormatContext *s)
> flv->resync_buffer[j ] =
> flv->resync_buffer[j1] = avio_r8(s->pb);
>
> +if (i >= 8) {
> +uint8_t *d = flv->resync_buffer + j1 - 8;
> +if (d[0] == 'F' &&
> +d[1] == 'L' &&
> +d[2] == 'V' &&
> +d[3] < 5 && d[5] == 0) {
> +av_log(s, AV_LOG_WARNING, "Concatenated FLV detected, might
> fail to demux, decode and seek %Ld\n", flv->last_ts);
> +flv->time_offset = flv->last_ts + 1;
> +}
> +}
How does this affect seeking? That is, is it safe? If it beaks seeking,
it may be better to not output the concatenated packets at all.
Cheers,
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On Mon, Nov 26, 2018 at 01:51:25PM +, Derek Buitenhuis wrote:
> On 23/11/2018 02:16, Michael Niedermayer wrote:
> > do we have some sample flv files that require this patchset / that have
> > discontinuites.
>
> I have many. I've mailed you one privately, while I work on getting a public
> one.
>
> > another thing i just realize now, why is this discontinuity issues coming up
> > now? flv support is very old. This should be a long standing issue
>
> Probably not many codebases check the DISCONT flag. I only just added proper
> discontinuity handling to some codebases this year, and that's why *I*
> noticed.
> Chances are most people use the ffmpeg cli which seems to handle stuff
> differently,
> and doesn't necessarily care about the flag. In my case, I only try to 'fix'
> discontinuities if they appear to be in a format that allows them, during
> indexing.
>
> I could add a workaround specific to FLV, or some threshold stuff, but I'd
> prefer
> that demuxers which may output discontinuous timestamps say they do.
The file looks like 2 files concatenated, even with FLV main header between
them.
the patch below should make this work with sequential demuxing assuming the
2 files dont change streams somehow with the normal demuxer.
not sure this is the best way to do it ...
also trying a random other flv related tool, FLVTool2 1.0.6 does not seem to
demux the 2nd file of the 2 correctly. Which makes me suspect more that the
file is invalid. Not that this would fundamentally change anything
thx
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 4b9f46902b..c9423da31c 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -72,6 +72,8 @@ typedef struct FLVContext {
int64_t *keyframe_filepositions;
int missing_streams;
AVRational framerate;
+int64_t last_ts;
+int64_t time_offset;
} FLVContext;
static int probe(AVProbeData *p, int live)
@@ -917,6 +919,17 @@ static int resync(AVFormatContext *s)
flv->resync_buffer[j ] =
flv->resync_buffer[j1] = avio_r8(s->pb);
+if (i >= 8) {
+uint8_t *d = flv->resync_buffer + j1 - 8;
+if (d[0] == 'F' &&
+d[1] == 'L' &&
+d[2] == 'V' &&
+d[3] < 5 && d[5] == 0) {
+av_log(s, AV_LOG_WARNING, "Concatenated FLV detected, might
fail to demux, decode and seek %Ld\n", flv->last_ts);
+flv->time_offset = flv->last_ts + 1;
+}
+}
+
if (i > 22) {
unsigned lsize2 = AV_RB32(flv->resync_buffer + j1 - 4);
if (lsize2 >= 11 && lsize2 + 8LL < FFMIN(i, RESYNC_BUFFER_SIZE)) {
@@ -1238,8 +1251,8 @@ retry_duration:
ret = av_get_packet(s->pb, pkt, size);
if (ret < 0)
return ret;
-pkt->dts = dts;
-pkt->pts = pts == AV_NOPTS_VALUE ? dts : pts;
+pkt->dts = dts + flv->time_offset;
+pkt->pts = (pts == AV_NOPTS_VALUE ? dts : pts) +flv->time_offset ;
pkt->stream_index = st->index;
pkt->pos = pos;
if (flv->new_extradata[stream_type]) {
@@ -1282,6 +1295,10 @@ leave:
}
}
}
+
+if (ret >= 0)
+flv->last_ts = pkt->dts;
+
return ret;
}
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On 24/12/2018 16:42, Derek Buitenhuis wrote: > Ping. Is there a decision on eitehr what to do or to ignore this? > > I'll update my downstream code with an FLV edge case if need be. Ping. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On 26/11/2018 13:51, Derek Buitenhuis wrote: > On 23/11/2018 02:16, Michael Niedermayer wrote: >> do we have some sample flv files that require this patchset / that have >> discontinuites. > > I have many. I've mailed you one privately, while I work on getting a public > one. > >> another thing i just realize now, why is this discontinuity issues coming up >> now? flv support is very old. This should be a long standing issue > > Probably not many codebases check the DISCONT flag. I only just added proper > discontinuity handling to some codebases this year, and that's why *I* > noticed. > Chances are most people use the ffmpeg cli which seems to handle stuff > differently, > and doesn't necessarily care about the flag. In my case, I only try to 'fix' > discontinuities if they appear to be in a format that allows them, during > indexing. > > I could add a workaround specific to FLV, or some threshold stuff, but I'd > prefer > that demuxers which may output discontinuous timestamps say they do. Ping. Is there a decision on eitehr what to do or to ignore this? I'll update my downstream code with an FLV edge case if need be. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On 23/11/2018 02:16, Michael Niedermayer wrote: > do we have some sample flv files that require this patchset / that have > discontinuites. I have many. I've mailed you one privately, while I work on getting a public one. > another thing i just realize now, why is this discontinuity issues coming up > now? flv support is very old. This should be a long standing issue Probably not many codebases check the DISCONT flag. I only just added proper discontinuity handling to some codebases this year, and that's why *I* noticed. Chances are most people use the ffmpeg cli which seems to handle stuff differently, and doesn't necessarily care about the flag. In my case, I only try to 'fix' discontinuities if they appear to be in a format that allows them, during indexing. I could add a workaround specific to FLV, or some threshold stuff, but I'd prefer that demuxers which may output discontinuous timestamps say they do. Cheers, - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On Thu, Nov 22, 2018 at 10:27:18AM +, Derek Buitenhuis wrote: > On 22/11/2018 02:16, Michael Niedermayer wrote: > > 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 > > I know they're not valid, however in the real world, tons and tons of these > files > exists, since this is how live FLV is done quite often. > > > 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. > > I agree, but then how do you propose we handle FLVs that do have > discontinuites? > Currently the demuxer just outputs the discontinuiting (negative or positive), > and it breaks, since codebases expect that demuxers which do this will be > properly > marked with the DISCONT flag. > > > 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 > > As far as I am aware, no, they cannot be detected by header. FLV is crappy > like that. do we have some sample flv files that require this patchset / that have discontinuites. another thing i just realize now, why is this discontinuity issues coming up now? flv support is very old. This should be a long standing issue thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
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 > wrote: > > > > On Wed, Nov 21, 2018 at 03:58:47PM +, 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 > > > --- > > > 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
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On Thu, Nov 22, 2018 at 4:17 AM Michael Niedermayer wrote: > > On Wed, Nov 21, 2018 at 03:58:47PM +, 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 > > --- > > 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
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On 22/11/2018 12:55, Carl Eugen Hoyos wrote: > Only the downstreams that expect invalid files, no? It's the generic way to handle containers which can have discontinuous timestamps. Nothing to do with expecting invalid files. Cheers, - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
2018-11-22 11:27 GMT+01:00, Derek Buitenhuis : > Every downstream codebase that cares could force the 'live_flv' > demuxer for all FLVs, but this seems ugly and needlessly special cased. Only the downstreams that expect invalid files, no? No opinion here about the patch, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On 22/11/2018 02:16, Michael Niedermayer wrote: > 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 I know they're not valid, however in the real world, tons and tons of these files exists, since this is how live FLV is done quite often. > 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. I agree, but then how do you propose we handle FLVs that do have discontinuites? Currently the demuxer just outputs the discontinuiting (negative or positive), and it breaks, since codebases expect that demuxers which do this will be properly marked with the DISCONT flag. > 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 As far as I am aware, no, they cannot be detected by header. FLV is crappy like that. Every downstream codebase that cares could force the 'live_flv' demuxer for all FLVs, but this seems ugly and needlessly special cased. I am open to better solutions... - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On Wed, Nov 21, 2018 at 03:58:47PM +, 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 > --- > 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 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. 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 Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
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
---
libavformat/flvdec.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 4b9f46902b..032e466bab 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -74,7 +74,7 @@ typedef struct FLVContext {
AVRational framerate;
} FLVContext;
-static int probe(AVProbeData *p, int live)
+static int flv_probe(AVProbeData *p)
{
const uint8_t *d = p->buf;
unsigned offset = AV_RB32(d + 5);
@@ -85,22 +85,15 @@ static int probe(AVProbeData *p, int live)
d[3] < 5 && d[5] == 0 &&
offset + 100 < p->buf_size &&
offset > 8) {
-int is_live = !memcmp(d + offset + 40, "NGINX RTMP", 10);
-if (live == is_live)
-return AVPROBE_SCORE_MAX;
+return AVPROBE_SCORE_MAX;
}
return 0;
}
-static int flv_probe(AVProbeData *p)
-{
-return probe(p, 0);
-}
-
static int live_flv_probe(AVProbeData *p)
{
-return probe(p, 1);
+return 0;
}
static void add_keyframes_index(AVFormatContext *s)
@@ -1321,6 +1314,7 @@ AVInputFormat ff_flv_demuxer = {
.read_close = flv_read_close,
.extensions = "flv",
.priv_class = _class,
+.flags = AVFMT_TS_DISCONT | AVFMT_NOBINSEARCH,
};
static const AVClass live_flv_class = {
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
