From: "Brendan Bolles" Received: from spike.lmi.net ([66.117.140.17] verified) by media-motion.tv (CommuniGate Pro SMTP 4.2.10) with ESMTP id 5564725 for AE-List@media-motion.tv; Thu, 04 Sep 2014 19:53:21 +0200 Received: from [192.168.1.13] (c-73-167-88-176.hsd1.ma.comcast.net [73.167.88.176]) by spike.lmi.net (Postfix) with ESMTP id DFC19154067 for ; Thu, 4 Sep 2014 10:53:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) Subject: Re: [AE] Compression issues article In-Reply-To: Date: Thu, 4 Sep 2014 13:53:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8ECEF5B9-3CA7-4834-B0CF-BD5FFED64AEB@fnordware.com> References: To: "After Effects Mail List" X-Mailer: Apple Mail (2.1085) On Sep 4, 2014, at 1:35 PM, Robert Kjettrup wrote: > Doesnt an encoder need to full decode the file and get an RGB image = before re-encoding it again? That is what i was thinking and caused the = colorshift i was seeing, that FFmpeg did a "wrong" YUV -> RGB = conversion. Maybe it is possible to keep it in keep it in YUV space = without the color conversion, it should be when i think about it. >=20 > It has been a while since i tested this, and some things might have = been improved with newer versions of FFmpeg. But i did test Uncompressed = YUV, ProRes HQ and DNxHD 185, and they are all in YUV 4:2:2 and all = showed colorshifts. FFmpeg wouldnt read DNxHD 444 or ProRes 444 so i = couln't check those, but it might be able to now, dont know. > I think DNxHD444 is RGB, but ProRes444 is still YUV??? So it could be = interesting to test those again if they are read now. H.264 (and WebM) are almost always 4:2:0 YUV, so FFmpeg should be able = to transport 4:2:0 directly to them. If you have 4:2:2, there will be = conversion, which might mean going through RGB. When it's called "ProRes444", that implies to me that it is YUV. But = that's OK, pretty much every lossy compression is. But then the next = question is if codecs provide a way to directly access the YUV, or if = they are using YUV internally and always convert to RGB. Another issue is that there are actually two YUVs, one for Rec601 and = one for Rec709. Working with WebM, it's become clear that it expects to = use the old 601 conversion, but for most TV applications you expect 709. = WebM is meant for viewing on a computer or phone, so I guess it's OK = that it sticks with 601, but this seems to be like an easy place to = introduce a color shift. Brendan