| ||||||||||
| 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. > > 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 |
