Hi, On Sun, Oct 14, 2012 at 2:12 PM, Luca Barbato <lu_z...@gentoo.org> wrote: > On 10/14/2012 10:43 PM, Ronald S. Bultje wrote: >> Hi, >> >> On Sun, Oct 14, 2012 at 1:39 PM, Luca Barbato <lu_z...@gentoo.org> wrote: >>> On 10/14/2012 09:54 PM, Ronald S. Bultje wrote: >>>> Hi, >>>> >>>> On Sun, Oct 14, 2012 at 12:53 PM, Ronald S. Bultje <rsbul...@gmail.com> >>>> wrote: >>>>> Hi, >>>>> >>>>> On Sat, Oct 13, 2012 at 11:13 PM, Ronald S. Bultje <rsbul...@gmail.com> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato <lu_z...@gentoo.org> >>>>>> wrote: >>>>>>> --- >>>>>>> >>>>>>> Here an initial patch to support many yuva, apparently either I botched >>>>>>> adding them (since I did lots of cut and paste) or they manage the >>>>>>> expose some >>>>>>> flaws in swscale. valgrind manages to spot something and might be nice >>>>>>> if >>>>>>> other people try this and see if the values for the fate-lavfi change >>>>>>> after >>>>>>> each round. >>>>>> >>>>>> If this is what I think it is, search for YUVA420P in swscale and >>>>>> replace it with a generic alpha check. >>>>> >>>>> Oh I see now. >>>>> >>>>> swscale.c:661 >>>>> if (isPlanar(dstFormat) && isALPHA(dstFormat) && !alpPixBuf) >>>>> fillPlane(dst[3], dstStride[3], dstW, dstY - lastDstY, lastDstY, >>>>> 255); >>>>> This only works for 8bit. For 9bit, you need a word fill with a value >>>>> of (1 << numbits) - 1. >>>> >>>> Which actually leads to a question: does any of this exist in the real >>>> world? I've never, ever, ever seen an image with non-8bpc alpha >>>> planes. I hate to invent stuff that has no utility but does carry >>>> implementation burden. >>> >>> You asked me to add those ^^; >> >> Uhm, ok, maybe I meant something else? I mean, there really isn't much >> use for 9-15bpp alpha channels as far as I know. 8bpp is obvious and I >> can sort of see 16bpp being useful (although I don't think I've ever >> seen it used). >> >>> BTW while I was investigating I noticed >>> all the previous 9 and 10 formats look strange, if you have time we >>> could have a look. >> >> Can you elaborate? > > try this command > > ./avconv -v quiet -nostats -y -cpuflags all -i ./tests/vsynth1/%02d.pgm > -vcodec rawvideo -pix_fmt yuv420p10 -f nut - | ./avplay - > > You will see it blue tinted while it should be gray. > > (you might need to apply my yet to be reviewed patch to fix nut with > rawvideo).
Well yes, can we first sort out this stuff without nut? I mean, I really don't have much reason to trust nut at this moment. When you test a typical conversion (convert that thing to nut without colorspace conversion, and then ./avplay -vf format=yuv420p10le), it works, so the colorspace conversion itself is correct. Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
