On Wed, Nov 16, 2011 at 09:22:02AM +0100, Johan Andersson wrote: > On Tue, Nov 15, 2011 at 11:06:48PM -0800, [email protected] wrote: > > From: Mike Melanson <[email protected]> > > > > http://samples.mplayerhq.hu/V-codecs/CVID/bad_cinepak_frame_size.mov > > > > This fix works around another work around which handles a different type > > of odd Cinepak data. > > > > Thanks to Matthew Hoops (clone2727 - gmail.com) for the sample and fix. > > --- > > libavcodec/cinepak.c | 5 +++-- > > 1 files changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c > > index c5d47be..2eca87e 100644 > > --- a/libavcodec/cinepak.c > > +++ b/libavcodec/cinepak.c > > @@ -330,12 +330,13 @@ static int cinepak_decode (CinepakContext *s) > > > > /* if this is the first frame, check for deviant Sega FILM data */ > > if (s->sega_film_skip_bytes == -1) { > > - if (encoded_buf_size != s->size) { > > + if (encoded_buf_size != s->size && (s->size % encoded_buf_size) != > > 0) { > > /* If the encoded frame size differs from the frame size as > > indicated > > * by the container file, this data likely comes from a Sega > > FILM/CPK file. > > * If the frame header is followed by the bytes FE 00 00 06 00 > > 00 then > > * this is probably one of the two known files that have 6 > > extra bytes > > - * after the frame header. Else, assume 2 extra bytes. */ > > + * after the frame header. Else, assume 2 extra bytes. The > > container size > > + * size also cannot be a multiple of the encoded size. */ > > "The container size size also cannot be a multiple of the encoded size" > one size to much?
That's when several Cinepak frames are stuffed together _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
