Re: [libav-devel] [RFC] pixfmt: support more yuva formats
On 10/14/2012 11:36 PM, Ronald S. Bultje wrote: > Well yes, can we first sort out this stuff without nut? I mean, I Sure! > 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. I tried yuv420p10le yuv420p9le and yuv420p16le, only 16 works for me here. I'll try to have a clean from some far commit so I can bisect when it broke. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] pixfmt: support more yuva formats
Hi, On Sun, Oct 14, 2012 at 2:12 PM, Luca Barbato wrote: > On 10/14/2012 10:43 PM, Ronald S. Bultje wrote: >> Hi, >> >> On Sun, Oct 14, 2012 at 1:39 PM, Luca Barbato 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 wrote: > Hi, > > On Sat, Oct 13, 2012 at 11:13 PM, Ronald S. Bultje > wrote: >> Hi, >> >> On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato >> 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
Re: [libav-devel] [RFC] pixfmt: support more yuva formats
On 10/14/2012 10:43 PM, Ronald S. Bultje wrote: > Hi, > > On Sun, Oct 14, 2012 at 1:39 PM, Luca Barbato 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 >>> wrote: Hi, On Sat, Oct 13, 2012 at 11:13 PM, Ronald S. Bultje wrote: > Hi, > > On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato 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). lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] pixfmt: support more yuva formats
Hi, On Sun, Oct 14, 2012 at 1:39 PM, Luca Barbato 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 >> wrote: >>> Hi, >>> >>> On Sat, Oct 13, 2012 at 11:13 PM, Ronald S. Bultje >>> wrote: Hi, On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato 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? Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] pixfmt: support more yuva formats
On 10/14/2012 09:54 PM, Ronald S. Bultje wrote: > Hi, > > On Sun, Oct 14, 2012 at 12:53 PM, Ronald S. Bultje wrote: >> Hi, >> >> On Sat, Oct 13, 2012 at 11:13 PM, Ronald S. Bultje >> wrote: >>> Hi, >>> >>> On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato 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 ^^; 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. And that reminds me that I could enjoy having color+ir and bayer+ir formats and those are used =) lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] pixfmt: support more yuva formats
Hi, On Sun, Oct 14, 2012 at 12:53 PM, Ronald S. Bultje wrote: > Hi, > > On Sat, Oct 13, 2012 at 11:13 PM, Ronald S. Bultje wrote: >> Hi, >> >> On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato 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. Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] pixfmt: support more yuva formats
Hi, On Sat, Oct 13, 2012 at 11:13 PM, Ronald S. Bultje wrote: > Hi, > > On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato 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. Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] pixfmt: support more yuva formats
On 10/14/2012 08:13 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato 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.
libswscale/swscale_unscaled.c:if ((srcFormat == AV_PIX_FMT_YUV420P
|| srcFormat == AV_PIX_FMT_YUVA420P) &&
libswscale/swscale_unscaled.c: srcFormat == AV_PIX_FMT_YUVA420P)
&& isAnyRGB(dstFormat) &&
libswscale/swscale_unscaled.c:(dstFormat == AV_PIX_FMT_YUV420P
|| dstFormat == AV_PIX_FMT_YUVA420P) &&
libswscale/swscale_unscaled.c:(dstFormat == AV_PIX_FMT_YUV420P
|| dstFormat == AV_PIX_FMT_YUVA420P) &&
libswscale/swscale_unscaled.c:if (srcFormat ==
AV_PIX_FMT_YUV420P || srcFormat == AV_PIX_FMT_YUVA420P) {
libswscale/swscale_unscaled.c: (dstFormat == AV_PIX_FMT_YUV420P ||
dstFormat == AV_PIX_FMT_YUVA420P))
libswscale/swscale_unscaled.c: (dstFormat == AV_PIX_FMT_YUV420P ||
dstFormat == AV_PIX_FMT_YUVA420P))
libswscale/swscale_unscaled.c:(srcFormat == AV_PIX_FMT_YUVA420P
&& dstFormat == AV_PIX_FMT_YUV420P) ||
libswscale/swscale_unscaled.c:(srcFormat == AV_PIX_FMT_YUV420P
&& dstFormat == AV_PIX_FMT_YUVA420P) ||
All of those seem to just consider yuva420 as yuv420
libswscale/x86/yuv2rgb.c:c->srcFormat != AV_PIX_FMT_YUVA420P)
libswscale/x86/yuv2rgb.c:if (c->srcFormat ==
AV_PIX_FMT_YUVA420P) {
libswscale/x86/yuv2rgb.c:if (c->srcFormat ==
AV_PIX_FMT_YUVA420P) {
libswscale/yuv2rgb.c:if (CONFIG_SWSCALE_ALPHA && c->srcFormat ==
AV_PIX_FMT_YUVA420P)
libswscale/yuv2rgb.c:if (CONFIG_SWSCALE_ALPHA && c->srcFormat ==
AV_PIX_FMT_YUVA420P)
And this is about yuva -> any not any -> yuva
What is strange is that building with clang+asan makes the problem
disappear...
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] pixfmt: support more yuva formats
Hi, On Sat, Oct 13, 2012 at 11:06 PM, Luca Barbato 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. Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [RFC] pixfmt: support more yuva formats
---
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.
libavcodec/raw.c| 19 +
libavformat/nut.c | 28 +++
libavutil/pixdesc.c | 234
libavutil/pixfmt.h | 28 +++
libswscale/utils.c | 18
5 files changed, 327 insertions(+)
diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index 6f0c923..4ccc6cc 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -124,6 +124,25 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
{ AV_PIX_FMT_YUVA420P,MKTAG('Y', '4', 11 , 8 ) },
{ AV_PIX_FMT_Y400A, MKTAG('Y', '2', 0 , 8 ) },
+{ AV_PIX_FMT_YUVA420P9LE, MKTAG('Y', '4', 11 , 9 ) },
+{ AV_PIX_FMT_YUVA420P9BE, MKTAG( 9 , 11 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA422P9LE, MKTAG('Y', '4', 10 , 9 ) },
+{ AV_PIX_FMT_YUVA422P9BE, MKTAG( 9 , 10 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA444P9LE, MKTAG('Y', '4', 0 , 9 ) },
+{ AV_PIX_FMT_YUVA444P9BE, MKTAG( 9 , 0 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA420P10LE, MKTAG('Y', '4', 11 , 10 ) },
+{ AV_PIX_FMT_YUVA420P10BE, MKTAG(10 , 11 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA422P10LE, MKTAG('Y', '4', 10 , 10 ) },
+{ AV_PIX_FMT_YUVA422P10BE, MKTAG(10 , 10 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA444P10LE, MKTAG('Y', '4', 0 , 10 ) },
+{ AV_PIX_FMT_YUVA444P10BE, MKTAG(10 , 0 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA420P16LE, MKTAG('Y', '4', 11 , 16 ) },
+{ AV_PIX_FMT_YUVA420P16BE, MKTAG(16 , 11 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA422P16LE, MKTAG('Y', '4', 10 , 16 ) },
+{ AV_PIX_FMT_YUVA422P16BE, MKTAG(16 , 10 , '4', 'Y') },
+{ AV_PIX_FMT_YUVA444P16LE, MKTAG('Y', '4', 0 , 16 ) },
+{ AV_PIX_FMT_YUVA444P16BE, MKTAG(16 , 0 , '4', 'Y') },
+
/* quicktime */
{ AV_PIX_FMT_UYVY422, MKTAG('2', 'v', 'u', 'y') },
{ AV_PIX_FMT_UYVY422, MKTAG('2', 'V', 'u', 'y') },
diff --git a/libavformat/nut.c b/libavformat/nut.c
index e367d1c..e3129aa 100644
--- a/libavformat/nut.c
+++ b/libavformat/nut.c
@@ -87,6 +87,34 @@ const AVCodecTag ff_nut_video_tags[] = {
{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 0 , '3', 'Y') },
{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 11 , 8 ) },
{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '2', 0 , 8 ) },
+
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '1', 0 , 9 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG( 9 , 0 , '1', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 11 , 9 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG( 9 , 11 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 10 , 9 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG( 9 , 10 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 0 , 9 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG( 9 , 0 , '4', 'Y') },
+
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '1', 0 , 10 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(10 , 0 , '1', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 11 , 10 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(10 , 11 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 10 , 10 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(10 , 10 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 0 , 10 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(10 , 0 , '4', 'Y') },
+
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '1', 0 , 16 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 0 , '1', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 11 , 16 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 11 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 10 , 16 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 10 , '4', 'Y') },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('Y', '4', 0 , 16 ) },
+{ AV_CODEC_ID_RAWVIDEO, MKTAG(16 , 0 , '4', 'Y') },
+
{ AV_CODEC_ID_NONE, 0 }
};
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index b8cfabd..bc446b1 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -558,6 +558,240 @@ const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
},
.flags = PIX_FMT_PLANAR,
},
+[AV_PIX_FMT_YUVA420P9BE] = {
+.name = "yuva420p9be",
+.nb_components = 4,
+.log2_chroma_w = 1,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 1, 1, 0, 8 },/* Y */
+{ 1, 1, 1, 0, 8 },/* U */
+{ 2, 1, 1, 0, 8 },/* V */
+{ 3, 1, 1, 0, 8 },/* A */
+},
+.flags = PIX_FMT_BE | PIX_FMT_PLANAR,
+},
+[AV_PIX_FMT_YUVA420P9LE] = {
+.name = "yuva420p9le",
+.nb_components = 4,
+.log2_chroma_w = 1,
+.log2_chroma_h = 1,
+.comp = {
+{ 0, 1, 1, 0, 8 },/* Y */
+{ 1, 1, 1, 0, 8 },/* U */
+{ 2, 1, 1, 0, 8 },/* V */
+{ 3, 1, 1, 0, 8 },
