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
