[FFmpeg-devel] [PATCH] Revert "avformat/flvdec: Check that sizes match and resync if not"

[wm4]

On Fri, 2 Oct 2015 02:22:48 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Fri, Oct 02, 2015 at 12:36:24AM +0200, wm4 wrote:
> > On Fri, 2 Oct 2015 00:06:24 +0200
> > Michael Niedermayer <michaelni at gmx.at> wrote:
> > 
> > > On Thu, Oct 01, 2015 at 11:33:27PM +0200, wm4 wrote:
> > > > On Thu, 1 Oct 2015 21:08:39 +0000 (UTC)
> > > > Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> > > > 
> > > > > wm4 <nfxjfg <at> googlemail.com> writes:
> > > > > 
> > > > > > This reverts commit cbbd906be6150be38dfc14b6bc67dcac8da8aea4.
> > > > > > 
> > > > > > It broke rtmp fatally, at least some cases of it.
> > > > > 
> > > > > You don't want to share some of them with us?
> > > > 
> > > > This is a bit hard, because it's some site accessed through youtube-dl
> > > > (youtube-dl extracts the current URL, encryption keys etc. - just
> > > > handling out an URL won't do). I haven't tested yet if this happens
> > > > with all rtmp URLs.
> > > 
> > > can you provide uncut ffmpeg output from the failure? it should contain
> > > information about the resync/mismatches even if the URLs&keys cannot
> > > be used.
> > 
> > I didn't use ffmpeg, and although it would have been possible, it's
> > complicated to extract and set all these rtmpe extra parameters.
> > 
> > > also what generated the rtmp stream that fails?
> > 
> 
> > I have no idea. But the flv stream is of course produced by
> > libavformat. I've dumped part of this stream: https://0x0.st/z0e.flv
> 
> do these invalid flv files exist elsewhere or is this the only one?

I don't know, but before the commit I pointed out, it could just play
such files, and now it can't. Does that mean the new code is less
robust? It's also conceivable that these files got into the wild
because someone recorded the byte stream ffmpeg outputs for rtmpe, but
I don't know if anyone did that.

Up to you to decide this.