Hi, On Sat, Apr 23, 2011 at 3:42 AM, Kostya Shishkov <[email protected]> wrote: > Official AVI specification says that stream header in case of video contains > BITMAPINFO, which is equal to BITMAPINFOHEADER and optional palette. Currently > lavf AVI demuxer thinks otherwise which produces garbage on codecs that have > both palette and extradata (luckily, there are not so many such codecs). > > An example of such file is: > http://samples.multimedia.cx/V-codecs/KMVC/baseball1.avi > (IIRC, MSS1 or MSS2 also had such situation but they are still not supported > by lavc). > > As a side note, passing palette in extradata as it's been done previously is > not quite correct since proper _extra_ data is surplus bytes in > BITMAPINFOHEADER, not including palette. > > --- > libavformat/avidec.c | 12 ++++++++---- > 1 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/libavformat/avidec.c b/libavformat/avidec.c > index 43d72ce..a9ff688 100644 > --- a/libavformat/avidec.c > +++ b/libavformat/avidec.c > @@ -590,12 +590,16 @@ static int avi_read_header(AVFormatContext *s, > AVFormatParameters *ap) > /* This code assumes that extradata contains only > palette. */ > /* This is true for all paletted codecs implemented in > Libav. */ > if (st->codec->extradata_size && > (st->codec->bits_per_coded_sample <= 8)) { > + int pal_size = (1 << > st->codec->bits_per_coded_sample) << 2; > + const uint8_t *pal_src; > + > + pal_size = FFMIN(pal_size, > st->codec->extradata_size); > + pal_src = st->codec->extradata + > st->codec->extradata_size - pal_size; > #if HAVE_BIGENDIAN > - for (i = 0; i < FFMIN(st->codec->extradata_size, > AVPALETTE_SIZE)/4; i++) > - ast->pal[i] = > av_bswap32(((uint32_t*)st->codec->extradata)[i]); > + for (i = 0; i < pal_size/4; i++) > + ast->pal[i] = > av_bswap32(((uint32_t*)pal_src)[i]); > #else > - memcpy(ast->pal, st->codec->extradata, > - FFMIN(st->codec->extradata_size, > AVPALETTE_SIZE)); > + memcpy(ast->pal, pal_src, pal_size); > #endif
Does this fix an actual issue (would be nice to mention)? Patch OK... Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
