[FFmpeg-devel] [PATCH] avoid crashes if input stream size changes without using -r

[Michael Niedermayer]

On Mon, Jul 06, 2009 at 10:57:26AM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On Mon, Jul 06, 2009 at 10:28:38AM +0100, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> > On Mon, Jul 06, 2009 at 05:30:56AM +0200, Michael Niedermayer wrote:
> >> >> On Sun, Jul 05, 2009 at 01:45:45PM +0200, Reimar D?ffinger wrote:
> >> >> > I don't know why, but currently FFmpeg only checks for an input stream
> >> >> > size change when it is using resizing.
> >> >> 
> >> >> id guess, the idea might have been to allow size changes on the encoder
> >> >> side too when supported (trivial for intra only codecs)
> >> >
> >> > The code for that isn't there though (rawenc with the current code could
> >> > already handle that fine), FFmpeg never gives the encoder the slightest
> >> > hint that the resolution changed (avctx width/height stay at the
> >> > original values)...
> >> 
> >> Then we should fix that.
> >
> > That would mean at the same time fixing all encoders to handle it or
> > there will still be crashes.
> 
> CODEC_CAP_*

yes, a CODEC_CAP_SIZE_CHANGE or some better name could be added and the
common code in lavc could maybe try to detect unexcpected size changes
and thus prevent crashes&sec holes for codecs not supporting it

also it could be used in decoders too catching changed w/h from demuxers


> 
> > Also, while the raw "encoder" can handle size changes, the result won't
> > be usable in most containers (which containers that handle raw can
> > handle mid-stream size changes in it?).

mov can handle it in theory, not sure how many players would handle it though
and iam not sure if we should support generating such streams ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090706/a114c1ba/attachment.pgp>