user8060: I have a video that is stored in the YUV 4:2:0 colour space. Assuming I used a lossless video codec but set the output colour space to YUV 4:2:0, would this still be a lossless encode or would I have to use a 4:4:4 colour space to make the encode lossless?

user4169: Probably no loss, but there is more to it than just YUV420. You can need to make sure the same ITU-R Recommendation is used (BT.601, BT.708 or maybe even 2020) In addition make sure the same color ranges is used (0-255 vs 16-235)

user9105: A lossless codec that can read/write yuv 4:2:0 samples is logically like zip for the bytes of video data.  You get literally identical (same md5 hash, byte-for-byte identical) output back after decompressing.  That is the definition of lossless.
See my answer to https://superuser.com/questions/347433/how-to-create-an-uncompressed-avi-from-a-series-of-1000s-of-png-images-using-ff/864520#864520 for an example of compressing and then verifying losslessness with ffmpeg.
We all know converting between RGB and YUV is lossy, but even upsampling the chroma and then downsampling again is not necessarily lossless.  Here's a post in a discussion about the lossyness of storing 4:2:0 video by upsampling to 4:2:2 for huffyuv.  Depending on the upsampling algorithm, downsampling again might round differently in the last bit.  (jagabo on that forum knows what he's talking about, not everyone else does.)
So use libx264 -qp 0 -preset ultrafast, or utvideo for lossless tmp files, if you don't have a raid array of scratch space for uncompressed temporary files.  They both support all relevant pixel formats (rgb, 444, 422, and 420), and are fast.  IDK about higher bit-depth support in utvideo, but x264 does support it.

8060: <p>I have a video that is stored in the YUV 4:2:0 colour space. Assuming I used a lossless video codec but set the output colour space to YUV 4:2:0, would this still be a lossless encode or would I have to use a 4:4:4 colour space to make the encode lossless?</p>
 4169: <p>Probably no loss, but there is more to it than just YUV420. You can need to make sure the same ITU-R Recommendation is used (BT.601, BT.708 or maybe even 2020) In addition make sure the same color ranges is used (0-255 vs 16-235)</p>
 9105: <p>A lossless codec that can read/write yuv 4:2:0 samples is logically like zip for the bytes of video data.  You get literally identical (same md5 hash, byte-for-byte identical) output back after decompressing.  That is the definition of lossless.</p>

<p>See my answer to <a href="https://superuser.com/questions/347433/how-to-create-an-uncompressed-avi-from-a-series-of-1000s-of-png-images-using-ff/864520#864520">https://superuser.com/questions/347433/how-to-create-an-uncompressed-avi-from-a-series-of-1000s-of-png-images-using-ff/864520#864520</a> for an example of compressing and then verifying losslessness with ffmpeg.</p>

<p>We all know converting between RGB and YUV is lossy, but even upsampling the chroma and then downsampling again is not necessarily lossless.  <a href="http://forum.videohelp.com/threads/318382-Lagarith-or-x264-lossless?s=e30331c6a8beff0a6fe69b460f6388cb&amp;p=1972486&amp;viewfull=1#post1972486" rel="nofollow noreferrer">Here's a post</a> in a discussion about the lossyness of storing 4:2:0 video by upsampling to 4:2:2 for huffyuv.  Depending on the upsampling algorithm, downsampling again might round differently in the last bit.  (jagabo on that forum knows what he's talking about, not everyone else does.)</p>

<p>So use <code>libx264 -qp 0 -preset ultrafast</code>, or <code>utvideo</code> for lossless tmp files, if you don't have a raid array of scratch space for uncompressed temporary files.  They both support all relevant pixel formats (rgb, 444, 422, and 420), and are fast.  IDK about higher bit-depth support in utvideo, but x264 does support it.</p>
