[FFmpeg-devel] [PATCH] interprete bits_per_raw_sample==0 as »use default bit depth«

Michael Niedermayer michaelni
Mon Aug 31 21:23:24 CEST 2009

On Mon, Aug 31, 2009 at 09:07:56PM +0200, Lars T?uber wrote:
> Hi Michael,
> On Mon, 31 Aug 2009 13:33:45 +0200 Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Mon, Aug 31, 2009 at 08:11:18AM +0200, Lars T?uber wrote:
> > > Hi,
> > > 
> > > with this patch the standard bit depth is taken for all the colorspaces used in ffv1 when bits_per_raw_sample==0.
> > 
> > you move code around and change it at the same time, this makes a
> > review hard, also you explain what you change but not why
> ok, let me try to explain the patch.
> when using
> ffmpeg ... -pix_fmt yuv4xxple ... 
> the source file is decoded and put into YUV-planes. But avctx->bits_per_raw_sample is not necessarily set to the needed/correct value.
> In my testcase it is simply not set and that's why: avctx->bits_per_raw_sample==0 !
> Because ffv1 needs it to be set to the count of msb used the patch sets it to the correct value of 16 as for all YUV4xxP16 colorspaces when not set.
> This is done with just inserting this line before the test of it's value:
> +        avctx->bits_per_raw_sample = avctx->bits_per_raw_sample ? avctx->bits_per_raw_sample : 16;
>         if(avctx->bits_per_raw_sample <=8){
>             av_log(avctx, AV_LOG_ERROR, "bits_per_raw_sample invalid\n");
>             return -1;
>         }
> Unfortunately the value is checked before this part at the initialization of s->quant_table[.][.] .
> That's why I moved this colorspace check just before the quant_table init.
> Additionally I check against it being greater than 16 just to be sure.
> What do you think about it?

i think bits_per_raw_sample should be set correctly not code be adapted to
handle incorrect values

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- 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/20090831/7b23336c/attachment.pgp>

More information about the ffmpeg-devel mailing list