VideoHelp Forum
+ Reply to Thread
Page 2 of 3
FirstFirst 1 2 3 LastLast
Results 31 to 60 of 68
Thread
  1. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Originally Posted by sneaker View Post
    Every time you encode with a lossy codec you suffer additional loss.
    Perhaps slightly off-topic, but some weeks ago I read a test where someone re-encoded an AAC audio file 100 times. One HUNDRED times. You'd expect the result to be completely garbled, but no. There was practically no difference at all (objectively or subjectively).

    Analog degradation is much more understandable but I've often wondered about this in digital media. I have some (very limited) knowledge of audio codecs and I can see how in theory it would be simple: the encoder would instantly notice that the signal has already been compressed. It would not attempt to remove the "redundant" parts. It couldn't since they are no longer there, there's nothing left to remove! So at least in the case of encoding to the same codec, the result could plausibly even be identical .

    Unfortunately I know next to nothing about video codecs (especially the modern, impossibly complex ones) so I don't know to what extent the same principle would apply. A similar test for video would be interesting.
    Quote Quote  
  2. So looking at those two examples, amount of data they carry, its hard to believe, you'd get smaller encoding size for second example, YUV444P10 and having similar quality out. Not necessarily same CRF as sneaker says. The entropy (chaos in data) would be much higher than in my example in real world scenario.
    Quote Quote  
  3. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Originally Posted by _Al_ View Post
    But that is only because of the choice to use a bicubic interpolation, right? Meaning changing the colorspace alone (in this case) would not in itself cause any change at all. Correct?
    Changing subsampling alone, means to resize chroma for sure. To do it physically to a plane, there is no difference doing it between Y or U or V, resize is resize.
    So there is a change. Bicubic interpolates using certain alghorithms, like Bilinear, like Lanczos etc. But not Point resize.
    ...
    so you definitely resize two planes even if not apparent on screen
    Wait, you lost me there. I was talking about not doing any resizing at all, but only changing the colorspace. If I have a 1280x720 pixel frame in YUV420p8 and I convert it to YUV444P10, how would the Y plane change size, first of all? (even if the U and V did)
    Quote Quote  
  4. 8bit to 10bit changes value alone. If having Y value for pixel is 25, then 10bit value would be 25x2x2 = 100

    YUV420P8 to YUV444P10 does not change dimension of Y, just value. When I said resize is a resize I ment chroma resize is the same as Y resize. You might tend to think that chroma resize is something else than Y resize (only if width and height of video is changed). But mathematically it is the same.

    Changing subsampling is unrelated to bit depth
    Click image for larger version

Name:	39523785660_ed4b725d9f_b.jpg
Views:	76
Size:	52.1 KB
ID:	50745
    Last edited by _Al_; 2nd Nov 2019 at 13:59.
    Quote Quote  
  5. Originally Posted by non-vol View Post
    Originally Posted by jagabo View Post
    Each time the chroma is downsampled and upsampled you get more blurring and/or artifacts. That is why you try to avoid multiple conversions.
    Hmm... downsampling I get, but why would upsampling be a problem? Let's say yuv420p to yuv444p10 if we need to be specific. What kind of "blurring" would occur?
    "multiple times" implies more than one

    You're said you were interested in the effect of subsampling chroma "multiple" times. yuv420p => yuv444p10le is 1 time. yuv420p => yuv444p10le => yuv420p is "1 time, round trip", or "2 times total" .




    Originally Posted by non-vol View Post
    But that is only because of the choice to use a bicubic interpolation, right? Meaning changing the colorspace alone (in this case) would not in itself cause any change at all. Correct?
    It depends on what you're asking exactly. Any non reversible manipulation should technically give you lower quality (because it's a deviation from the "original"). The exception is higher bit depths (in most cases)


    10 bit vs 8 bit is something I admit I don't really understand at all, what comes to "compression efficiency". The 420 vs 444 case was explained as the encoder simply having much better methods for discarding "unneeded" information compared to chroma subsampling (which is the simplest and stupidest compression method). That does make sense. Whatever the encoder (x265) does, it seems to even be SO good at it that I can encode a yuv420p8 source to yuv444p10, x265 crf 20, and it will still be smaller than the source AND smaller than doing the exact same encode without changing the colorspace.

    One of your observations was "smaller" filesizes with yuv444p compared to yuv420p (from a yuv420p source) - but that was using "crf" encoding. The quality is actually lower per bitrate(filesize) if you measured it with something like ssim or psnr and plotted against bitrates.

    Note that "crf" isn't a measure of "quality", it's just a rate control method. yes, there is an inverse relationship (lower values yield larger filesizes, higher quality), but that's it. It's widely "abused" as a quality indicator. You can't compare between different settings, different pixel formats - this is what sneaker was alluding to.



    10bit encoding from 8bit source is beneficial in most situations, especially in terms of banding. The evidence for this is very clear. The exception is very low bitrate scenarios. The gains are mainly from higher precision

    4:4:4 - not from a 4:2:0 source . It will always be slightly worse at a given bitrate (less efficient) if using default scaling (ffmpeg uses bicubic by default if you don't specify sws flags) . Because of the rounding errors and interpolation introduced . You're supposed to measure against the original source, and original pixel format. ie. how close is it to the "original". That means scaling up to 4:4:4 for the encode, and back down to 4:2:0 for the test. Again, how you up and downscale can change everything.

    Or you can choose to frame the test slightly differently; Given original source, convert it and each encode to 8bit RGB using a standardized method and compare in RGB (because that's what you will be "seeing"). At what bitrate can you achieve "x" quality from the 4:2:0 vs. 4:4:4 encode, and plot the rd curves. It will still be higher for the 4:2:0 at a given bitrate using metrics

    Upscaling to 4:4:4 might be beneficial when your viewing target has a known low quality chroma upsampling algorithm. It does it poorly. By upscaling to 4:4:4 you "force" a certain algorithm to be used for the scaling



    Another reason you might not want to upsample to 444 is compatibility. Hardware decoders, TV's . 10bit420 HEVC is widely supported now in hardware, but 444 is not - only software decode. Another reason is speed - takes longer to process, encode

    10bit however is beneficial in most circumstances, especially with banding issues. It's slightly more efficient too , except at very low bitrate scenarios. You can make a valid case for 10bit420 from a 8bit420 source, especially for HEVC because support in hardware. No case can be made for scaling to 444, unless it's some known specific situation where the scaling is known to be bad
    Quote Quote  
  6. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Originally Posted by _Al_ View Post
    So looking at those two examples, amount of data they carry, its hard to believe, you'd get smaller encoding size for second example, YUV444P10 and having similar quality out. Not necessarily same CRF as sneaker says. The entropy (chaos in data) would be much higher than in my example in real world scenario.
    I have no idea why or how 444 encodes can be of similar size and similar (subjective) quality compared to 420 ones. I've read many times that subsampling results in such HUGE bandwidth savings that this shouldn't be possible (and the difference between those encodes should be EASILY visible). On the other hand, like I said, I've also read that an x264 or x265 encoder has other compression methods that are MORE efficient than chroma subsampling. I don't know.

    I just figured out how to compute SSIM and PSNR metrics, but I don't know how to interpret them.

    Code:
    [Parsed_ssim_0 @ 0000021c12daa040] SSIM Y:0.631191 (4.331986) U:0.967972 (14.944716) V:0.971511 (15.453282) All:0.856892 (8.443347)
    [Parsed_psnr_1 @ 0000021c114983c0] PSNR y:16.185592 u:32.825807 v:31.457493 average:20.739209 min:15.861137 max:39.032183
    This is comparing a 2 minute clip, the original (h264, yuv420p) against an x265, yuv444p10 encode. The x265 is slightly smaller in size. Would those metrics suggest there's a huge quality difference between them? Because I can't see it. Maybe with a side-by-side comparison, but I don't have anything I could do that with right now.
    Quote Quote  
  7. Higher values are better for PSNR and SSIM. You're mixing up bit depth with chroma subsampling. I suggest you test each one individually to determine the effect. (10bit vs 8bit, 444 vs. 420). Otherwise you don't know what is causing what. You test each one against the original.

    10bit vs. 8bit is proven, both in theory and practice - many tests show this - and you can "SEE" the results quite easily, especially in terms of banding along gradients . (The exception is very low bitrate cases, where the efficiency gained does not offset the cost of storing additional bits)
    eg
    https://forum.videohelp.com/threads/394569-I-there-any-benefit-to-encoding-to-10-bits#post2562122

    444 from a 420 source will always be worse in general at a given bitrate (not just x264,x265 - for any encoder, any format). There is no savings because of higher precision unlike 10bit. There is only additional cost - it takes more bits to encode larger dimensions. Think of it as upscaling a photo. Is there any benefit in terms of compression? No it will almost always be worse (if we exclude some extreme methods like "AI" or GAN based) . 420=>444 is analogous to upscaling, but only the U,V planes.
    Last edited by poisondeathray; 2nd Nov 2019 at 15:47.
    Quote Quote  
  8. Originally Posted by non-vol View Post
    Code:
    [Parsed_ssim_0 @ 0000021c12daa040] SSIM Y:0.631191 (4.331986) U:0.967972 (14.944716) V:0.971511 (15.453282) All:0.856892 (8.443347)
    [Parsed_psnr_1 @ 0000021c114983c0] PSNR y:16.185592 u:32.825807 v:31.457493 average:20.739209 min:15.861137 max:39.032183
    This is comparing a 2 minute clip, the original (h264, yuv420p) against an x265, yuv444p10 encode. The x265 is slightly smaller in size. Would those metrics suggest there's a huge quality difference between them? Because I can't see it. Maybe with a side-by-side comparison, but I don't have anything I could do that with right now.
    Those values suggest an error in the calculation. An average PSNR of 20 or PSNR Y of 16 is incredibly low quality, something lower than VHS quality.

    Possibly you are not using frame accurate parsing, or some jitter in the timecodes between the containers. Essentially you're not comparing frame accurately (different frames are being compared)
    Quote Quote  
  9. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Higher than what? As far as I can tell, for SSIM the maximum should be 1.0, which could never be reached with a lossy encoder.
    I'm doing another encode in 420p10 right now so I can measure the difference that way.

    One concern is re-encoding the encoded files sometime in the future. One typical case for me is that the source file is h264 at some stupidly high bitrate (20 Mbps or so) and I can't keep such large files around indefinitely. Also some of them are interlaced. You might already see the problem. I can encode them with x265 to reduce the size, but what if I need to get them back to h264 for viewing elsewhere for instance?
    Quote Quote  
  10. Originally Posted by non-vol View Post
    Higher than what? As far as I can tell, for SSIM the maximum should be 1.0, which could never be reached with a lossy encoder.
    I'm doing another encode in 420p10 right now so I can measure the difference that way.

    One concern is re-encoding the encoded files sometime in the future. One typical case for me is that the source file is h264 at some stupidly high bitrate (20 Mbps or so) and I can't keep such large files around indefinitely. Also some of them are interlaced. You might already see the problem. I can encode them with x265 to reduce the size, but what if I need to get them back to h264 for viewing elsewhere for instance?
    Or why not just get another HDD ? Storage is pretty cheap these days

    I would use x264 if you need interlace. Proper MBAFF support. HEVC interlace support is buggy and limited. Some decoder chips don't support it

    But a SSIM of 0.63 is like something lower than VHS quality. Certainly not at -crf 20 for either libx264 or libx265 . That suggests more like error in measurement, not frame accurate. You'd expect in the range 0.96-0.99 depending on source complexity
    Quote Quote  
  11. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    found the error
    Last edited by non-vol; 2nd Nov 2019 at 16:21.
    Quote Quote  
  12. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    It was indeed some kind of container problem I suppose, the clips were not lining up or something.

    Here are the proper numbers for reference vs. x265 yuv420p8:

    Code:
    [Parsed_ssim_0 @ 000001b4949a7640] SSIM Y:0.988331 (19.329804) U:0.989394 (19.744495) V:0.992721 (21.378997) All:0.989240 (19.681894)
    [Parsed_psnr_1 @ 000001b492e283c0] PSNR y:44.900170 u:48.915998 v:50.432808 average:45.982578 min:38.750805 max:51.053030
    And here for reference vs. x265 yuv444p8

    Code:
    [Parsed_ssim_0 @ 000001b341c083c0] SSIM Y:0.988191 (19.277990) U:0.990706 (20.318033) V:0.993373 (21.786793) All:0.990757 (20.341790)
    [Parsed_psnr_1 @ 000001b343435d00] PSNR y:44.855089 u:48.661029 v:50.050397 average:47.274500 min:41.187819 max:51.490182
    The 444 file is slightly smaller. I still can't see anything indicating it being worse than the 420 encode, subjectively or objectively. How is that possible?
    Quote Quote  
  13. You wouldn't expect to "see" major differences at crf 20 unless there was a major issue with the upsampling, or the conversion to RGB (for display) , at least not on "normal" content. It might be visible on test patterns

    A certain level of "quality" is achieved at the native pixel format at a lower bitrate, compare to upscaling and downscaling the chroma. That's the idea behind "compression efficiency". At what CRF resulting in what bitrate would upscaling to yuv444p be required to reach the same level of quality. Upscaling to 444 should always be worse (again, ignoring the extreme methods).



    The lower "average" and large "min" deviation for the PSNR yuv420p8 suggests an error somewhere, either in the encode or measurement, mismatched frames or timecodes

    What were your command lines ? Technically , a comparison to the source should be comparing at the source pixel format (you're comparing against the source). So yuv444p should be downsampled to the source yuv420p .

    You should expect PSNR and SSIM U and V to drop significantly, and Y only drop a little bit for yuv444p at a given bitrate. All measures should drop. If you were to plot serial CRF encodes and their bitrates on the x-axis, and the SSIM or PSNR on the y-axis, you will get the rd plot or trendline . That is the "penalty" incurred for upscaling (at least in terms of PNSR or SSIM, they aren't necessarily the best measures of "similarity")
    Quote Quote  
  14. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Originally Posted by poisondeathray View Post
    You wouldn't expect to "see" major differences at crf 20 unless there was a major issue with the upsampling, or the conversion to RGB (for display) , at least not on "normal" content. It might be visible on test patterns

    A certain level of "quality" is achieved at the native pixel format at a lower bitrate, compare to upscaling and downscaling the chroma. That's the idea behind "compression efficiency". At what CRF resulting in what bitrate would upscaling to yuv444p be required to reach the same level of quality. Upscaling to 444 should always be worse (again, ignoring the extreme methods).
    Yes, I keep reading that it should be worse. I keep reading that it should be MUCH worse. But it isn't.
    Quote Quote  
  15. Originally Posted by non-vol View Post
    Originally Posted by poisondeathray View Post
    You wouldn't expect to "see" major differences at crf 20 unless there was a major issue with the upsampling, or the conversion to RGB (for display) , at least not on "normal" content. It might be visible on test patterns

    A certain level of "quality" is achieved at the native pixel format at a lower bitrate, compare to upscaling and downscaling the chroma. That's the idea behind "compression efficiency". At what CRF resulting in what bitrate would upscaling to yuv444p be required to reach the same level of quality. Upscaling to 444 should always be worse (again, ignoring the extreme methods).
    Yes, I keep reading that it should be worse. I keep reading that it should be MUCH worse. But it isn't.
    Starting from yuv420p8 source , upscaling to yuv444p8 shouldn't be that much worse, maybe a few % .

    But it's slower to encode, potential compatibility issues (HW decoders, devices) , always lower quality (in general, if we ignore the extreme methods) . So no benefit. Absolutely no reason to even consider it. All negatives, no positives.
    Quote Quote  
  16. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Originally Posted by poisondeathray View Post
    Originally Posted by non-vol View Post
    Originally Posted by poisondeathray View Post
    You wouldn't expect to "see" major differences at crf 20 unless there was a major issue with the upsampling, or the conversion to RGB (for display) , at least not on "normal" content. It might be visible on test patterns

    A certain level of "quality" is achieved at the native pixel format at a lower bitrate, compare to upscaling and downscaling the chroma. That's the idea behind "compression efficiency". At what CRF resulting in what bitrate would upscaling to yuv444p be required to reach the same level of quality. Upscaling to 444 should always be worse (again, ignoring the extreme methods).
    Yes, I keep reading that it should be worse. I keep reading that it should be MUCH worse. But it isn't.
    Starting from yuv420p8 source , upscaling to yuv444p8 shouldn't be that much worse, maybe a few % .

    But it's slower to encode, potential compatibility issues (HW decoders, devices) , always lower quality (in general, if we ignore the extreme methods) . So no benefit. Absolutely no reason to even consider it. All negatives, no positives.
    Oh. Ok. I've lost track of what we're actually talking about here now.

    If you'd like me to clarify it, I'm not advocating any particular colorspace or encoding scheme for any particular use case. I don't know why I would, I don't know them nearly well enough.

    This thread has become a little too convoluted for it's own good. I think I missed a post or two on the last page as well. Let's see if I can get back on track.
    Quote Quote  
  17. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Originally Posted by poisondeathray View Post
    Originally Posted by non-vol View Post
    ...

    One concern is re-encoding the encoded files sometime in the future. One typical case for me is that the source file is h264 at some stupidly high bitrate (20 Mbps or so) and I can't keep such large files around indefinitely. Also some of them are interlaced. You might already see the problem. I can encode them with x265 to reduce the size, but what if I need to get them back to h264 for viewing elsewhere for instance?
    Or why not just get another HDD ? Storage is pretty cheap these days
    You're right that storage is "pretty cheap", but there are other considerations. I already have more than 5 hard drives, I wouldn't really want MORE of them.
    Mostly the problem is in that new stuff comes in much too fast. For example, my smartphone records video at 17 Mbps. I could have looked through 200 hours of footage and deciding, right at that moment, which ones I'd want to keep. But instead, I figured I could just re-encode them, save an ENORMOUS amount of space and look through them (the re-encodes) later. The quality loss here is probably a non-issue, the source quality probably doesn't warrant even a quarter of that 17 Mbps. It's a compromise.

    Also while "storage", such as a cheap portable hard drive is... cheap, something reliable like a mirrored RAID system of the same capacity costs a LOT more. But that's where you'd want to store the files you don't want to be easily lost or corrupted.
    Quote Quote  
  18. Originally Posted by non-vol View Post

    Oh. Ok. I've lost track of what we're actually talking about here now.

    If you'd like me to clarify it, I'm not advocating any particular colorspace or encoding scheme for any particular use case. I don't know why I would, I don't know them nearly well enough.

    This thread has become a little too convoluted for it's own good. I think I missed a post or two on the last page as well. Let's see if I can get back on track.



    I'll summarize:

    As a general rule ,

    1) stay in the same color model (YUV), same color subsampling (if starting with 4:2:0, stay with 4:2:0) .

    2) The only benefit to changing anything is potentially 10bit vs. 8bit . You can actually "see" the difference, and the benefits are measureable as well. The exception is very low bitrate scenarios, where it can be worse

    3) It doesn't make sense to lose 5-8% compression efficiency (it might be more for some types of content), when you're trying to save HDD space. As a general rule, "normal" upscaling (that's what you're doing , upscaling the chroma by going 4:2:0 => 4:4:4) does not help. It just requires more bitrate for certain level of quality . At the same filesize, all Y, U, V will be lower in quality. Not only that, it's slower to encode (you have to resize the U,V planes), and you reduce compatibility

    4) A common mistake is equating "CRF" to a certain level of quality. CRF is just a rate control. You can can't compare between different settings, chroma samplings, bit depths.
    Quote Quote  
  19. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Originally Posted by poisondeathray View Post
    ...

    3) It doesn't make sense to lose 5-8% compression efficiency (it might be more for some types of content), when you're trying to save HDD space. As a general rule, "normal" upscaling (that's what you're doing , upscaling the chroma by going 4:2:0 => 4:4:4) does not help. It just requires more bitrate for certain level of quality . At the same filesize, all Y, U, V will be lower in quality. Not only that, it's slower to encode (you have to resize the U,V planes), and you reduce compatibility
    Of course not! I am in no way deliberately doing the upscaling at all. Most of the encodes I've done in the past year have been yuv420p (the default) or yuv420p10 (*) . But I have made no claims about ANY pixel format being better or worse than any other one. I must repeat and stress this.
    There is more to discuss but we need to make sure we're not misunderstanding each other too much, as currently it seems oddly like we were on opposite sides of some argument and I don't see why.

    4) A common mistake is equating "CRF" to a certain level of quality. CRF is just a rate control. You can can't compare between different settings, chroma samplings, bit depths.
    I do NOT think CRF is any sort of absolute indicator of quality, and I haven't said so at any point.

    I've judged quality by simply looking at the videos, comparing PSNR and SSIM numbers, comparing bitrates/file sizes. CRF has nothing to do with this.

    (*) I've read, elsewhere on the Internet, that a 420p8 to 420p10 conversion can "improve compression efficiency".
    Completely separate from this, I've ALSO read a claim involving compression efficiency with or without chroma subsampling.
    Last edited by non-vol; 3rd Nov 2019 at 11:09.
    Quote Quote  
  20. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Just quickly, I can tell you where I read that compression efficiency claim: http://forum.doom9.org/archive/index.php/t-167428.html

    "... lowering chroma resolution is a very inefficient way of saving bits on chroma. ..." . I've read that more than once, either there or on another forum.

    All this does is explain to me why there is nothing particularly odd with encodes being both of similar size AND similar quality, even if the chroma is artificially upsampled for no reason.
    Quote Quote  
  21. Originally Posted by non-vol View Post
    Just quickly, I can tell you where I read that compression efficiency claim: http://forum.doom9.org/archive/index.php/t-167428.html

    "... lowering chroma resolution is a very inefficient way of saving bits on chroma. ..." . I've read that more than once, either there or on another forum.

    All this does is explain to me why there is nothing particularly odd with encodes being both of similar size AND similar quality, even if the chroma is artificially upsampled for no reason.


    You can start another thread on that, but the 4:2:0 "debate" has been settled decades ago. It's why it's so commonly still today.

    If you're starting with 4:2:0 , absolutely nobody would recommend upscaling the chroma. 4:2:0 literally means that information has been dropped. You can't make something from nothing (if we ignore the extreme methods) . But the penalty you incur from upscaling is less than the savings you gain from downscaling from true 4:4:4 . In the latter, you are dropping real details , real data. The underlying premise is human vision is not as sensitive to color information, and it's true. Subsampling chroma is actually a very good way of obtaining bitrate savings, for most types of content

    Very little content is "true" 4:4:4 (as in 4:4:4 worth of valid information) . You can generate it with CG, high end cameras and "raw" recordings, film scans. Even still photo cameras with 30-40 mega pixels in jpg mode are typically subsampled 4:2:2. But live action distribution formats typically require an oversampled source . eg. if you had UHD BD if you downscale the Y to 1080p, then it's "fake" 4:4:4 at 1080p but it can closely approximates "true" 4:4:4 depending on the source chroma condition

    If you're starting with true 4:4:4, as in 4:4:4 worth of actual content, then that's a different discussion. Today you can encode and view 4:4:4. Even modern browsers, webm support it. Very good for razor sharp graphics, logos . If you had thin colored text, it would be clear instead of blurry.

    If you want to see an old demo (2015), download this zip in the 1st post, unzip, and open index.html with a browser . The "compatibility" issue is reduced in some ways, because almost everyone has a web browser
    https://forum.videohelp.com/threads/371183-VP9-webm-1-4-officially-supports-YUV444-now

    But that is content dependent. How often do you have thin text , or watch test patterns, or have true 4:4:4 content? - almost never.

    But even today, for live action (normal video, movies) , you can barely tell the difference under normal viewing conditions between true 4:4:4 and 4:2:0 . For typical usage, live action content 4:2:0 is still a good bandwidth compromise today. That's why it's still the dominant delivery format, even in 2019, and probably will be for the next decade at least. Chroma subsampling is one thing the engineers got right so many years ago
    Quote Quote  
  22. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    I only skimmed that last post, but frankly I don't know what point you are arguing exactly. Are we supposed to have a disagreement over something?

    In my last post, all I did was refer to another discussion, where it was mentioned that besides subsampling, there are other methods of compressing the color information (and those methods could be equally or even more efficient).

    I agree, for example, that for 1920x1080 or higher resolution content (particularly live action movies, nature scenes etc.), 420 chroma subsampling is just fine. But that was never a point of contention here!
    Quote Quote  
  23. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Anyway, in an attempt to "get back on track"... forget the subsampling for a moment. I understand what subsampling is, why it's used and all that. However, I have NO IDEA how x265 (with ffmpeg) works. It's a black box. All I ever actually see is the source, as RGB -- and the result, also as RGB.

    The point, or question, was supposed to be more in the direction of what the x265 encoder itself actually does. If I encode from an h264 source to x265 and then back to h264, will there be
    specific kinds of color artifacts resulting from some particular stage of that process? Do these two codecs handle color very differently from each other?
    Quote Quote  
  24. Originally Posted by non-vol View Post
    Anyway, in an attempt to "get back on track"... forget the subsampling for a moment. I understand what subsampling is, why it's used and all that. However, I have NO IDEA how x265 (with ffmpeg) works. It's a black box. All I ever actually see is the source, as RGB -- and the result, also as RGB.

    The point, or question, was supposed to be more in the direction of what the x265 encoder itself actually does. If I encode from an h264 source to x265 and then back to h264, will there be
    specific kinds of color artifacts resulting from some particular stage of that process? Do these two codecs handle color very differently from each other?
    There should no RGB involved in x264 4:2:0 to x265 4:2:0. You can pass YUV 4:2:0 (usually as YV12) directly. Same with x265 to x264. Losses will only be from compression -- loss of detail, DCT ringing artifacts, etc.
    Quote Quote  
  25. Originally Posted by non-vol View Post
    Anyway, in an attempt to "get back on track"... forget the subsampling for a moment. I understand what subsampling is, why it's used and all that. However, I have NO IDEA how x265 (with ffmpeg) works. It's a black box. All I ever actually see is the source, as RGB -- and the result, also as RGB.

    The point, or question, was supposed to be more in the direction of what the x265 encoder itself actually does. If I encode from an h264 source to x265 and then back to h264, will there be
    specific kinds of color artifacts resulting from some particular stage of that process? Do these two codecs handle color very differently from each other?
    So you know , that if you are going from YUV420 to YUV444 you are actually resizing? Two planes out of tree. Doubling their resolution. And if going from 8bit to 10 bit you also increase plane values, assigning 2bytes (0-1023) for a value instead of just one byte (0-255) for a value.

    If you have enough bitrates for encoder, meaning you do not starve them and picture would not start to break up, colors will stay the same. If encoder changed colors it would not be tolerated. Sure, there should not be something messed up in the process - before feeding video to encoder (matrix is different in Vapoursynth,Avisynth, ffmpeg etc., decoder problems) or in the process of getting visual of those YUV values, again wrong matrix is presumed, wrong range during preview, something wrong with RGB conversion like you use Lanczos for that RGB conversion, personally I use Point resize for RGB conversion on screen.
    Actually, if someone knows where to use Point and when to rather use other resize method would be appropriated. For upscale Point, for downscale bilinear? To see colors that are closest to original, no enhancing sort of. YUV to RGB for preview only.

    Sure you never see exact colors if previewing YUV. Pixel values are converted and changed to RGB 8bit value for preview, but the difference would not be visible. Maybe some testing , computer generated images, but not real life videos. If you see RGB 191,0,1 instead of 190,0,0 you would not notice at all in real life scenario. The best to see those differences is using those common testing images. How that RGB preview value changes a bit, but nothing serious to be caught by our brain in real life situation.
    If using Vapoursynth's VSEdit (or Avisynth I guess as well) , you can always see those thru YUV values as well, if interested. Or you can use your scripts to pull those values out of video. With Vapoutsynth you can have a function that returns YUV values, if giving pixel coordinates, frame number and video, it is actually not that difficult at all.
    Last edited by _Al_; 3rd Nov 2019 at 20:58.
    Quote Quote  
  26. You can always view the Y, U, and V planes directly in a tool like AviSynth:

    Code:
    WhateverSource()
    StackHorizontal(GreyScale(), StackVertical(UtoY(), VtoY()))
    Image
    [Attachment 50753 - Click to enlarge]


    Y on the left, U at the top right, V at the bottom right. Color frame:

    Image
    [Attachment 50754 - Click to enlarge]
    Quote Quote  
  27. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Originally Posted by jagabo View Post
    Originally Posted by non-vol View Post
    ... h264 source to x265 and then back to h264, will there be
    specific kinds of color artifacts resulting from some particular stage of that process? Do these two codecs handle color very differently from each other?
    ... Losses will only be from compression -- loss of detail, DCT ringing artifacts, etc.
    Yes, this is the interesting stuff. What loss of detail happens and why? What is DCT? What is "ringing"?
    Quote Quote  
  28. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Originally Posted by _Al_ View Post
    So you know , that if you are going from YUV420 to YUV444 you are actually resizing?
    Yes.

    Two planes out of tree. Doubling their resolution. And if going from 8bit to 10 bit you also increase plane values, assigning 2bytes (0-1023) for a value instead of just one byte (0-255) for a value.
    Why would 2 bytes be used for 10 bit values?
    Quote Quote  
  29. Member
    Join Date
    Nov 2019
    Location
    Europe
    Search PM
    Thanks. Although I was more trying to point out that while chroma subsampling and colorspace conversions have been explained in excruciating and excessive detail, with several example pictures and diagrams... the "actual compression" has not.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!