How does a compressed 4K video still look so good?

[Edan Maus]

I did some paper napkin math and found that a raw 1hr 4k video would be over 5TB in size if it is in 24 bit true RGB.  If u have 16:9 aspect ratio, that would be 24.883MB per image. 60fps playback would be 1492.98MB per second which would mean over 5TB for an hour video. Netflix claims about 7GB per hour of streaming so how can it look even close with that little of the data being used? That is not something your average device could uncompress very easily much less in an instant to stream a video.

[whispous]

 

[Kilrah]

On 9/21/2021 at 9:11 AM, Edan Maus said:

That is not something your average device could uncompress very easily much less in an instant to stream a video.

Of course it is, been done for decades now. 

[Lord Szechenyi]

On 9/21/2021 at 9:11 AM, Edan Maus said:

Netflix claims about 7GB per hour of streaming

I could be wrong but i think most people don't stream Netflix in 4k.

 

Also, 1080p is now so heavily compressed that 4K is the "new" old 1080p

[Edan Maus]

On 9/23/2021 at 5:29 AM, Kilrah said:

Of course it is, been done for decades now. 

We have done decompression for decades, but not from what we stream to RAW afaik bc that would take some serious juice to do on the fly. We have some smart ways to compress stuff so that it can be unpacked quicker, but idk if we are there yet on lots of devices. If raw 4k video is about 20MB per frame (that's average) than at 30fps playback you would have to decompress 600MB of video per second. That's a lot to do instantly even for good PC's. Couldn't imagine a smart tv or firstick doing that. There has to be some kind of missing information right? Looks good regardless though. I have a 10900k and just decompressing a 1GB zip still takes 2 or 3 seconds.

[Helpful Tech Witch]

1 hour ago, Edan Maus said:

We have done decompression for decades, but not from what we stream to RAW afaik bc that would take some serious juice to do on the fly. We have some smart ways to compress stuff so that it can be unpacked quicker, but idk if we are there yet on lots of devices. If raw 4k video is about 20MB per frame (that's average) than at 30fps playback you would have to decompress 600MB of video per second. That's a lot to do instantly even for good PC's. Couldn't imagine a smart tv or firstick doing that. There has to be some kind of missing information right? Looks good regardless though. I have a 10900k and just decompressing a 1GB zip still takes 2 or 3 seconds.

Well, your data assumes 24bit color?

well, it’s going to be a third of that, 1.5tb (ish) per hour for uncompressed 4k 8 but color. 

Cinema is a 24fps, not 60, so multiply by .4. Now you have 2/3tb per hour.

that’s what uncompressed 4k movies would be per hour. 2/3tb, NOT 5tb.

Though movies are actually 4096x2160, so call it .75tb/hour for uncompressed

thats 200MB/s, which your pc should be able to handle. Plus you can probably optimize the decompress if you know what file type your decompressing.

[LAwLz]

25 minutes ago, HelpfulTechWizard said:

Well, your data assumes 24bit color?

well, it’s going to be a third of that, 1.5tb (ish) per hour for uncompressed 4k 8 but color. 

Cinema is a 24fps, not 60, so multiply by .4. Now you have 2/3tb per hour.

that’s what uncompressed 4k movies would be per hour. 2/3tb, NOT 5tb.

Though movies are actually 4096x2160, so call it .75tb/hour for uncompressed

thats 200MB/s, which your pc should be able to handle. Plus you can probably optimize the decompress if you know what file type your decompressing.

Your math is way off.

His calculation doesn't assume 24 bit color depth, it assumes 8 bit color depth, but per color channel.

When you see something say "8 bit color depth", it actually means 24 bits of color info (if it's an RGB value). 8 bits for red, 8 bits for green and 8 bits for blue. 8+8+8=24.

Uncompressed video is massive and unwieldy, so barely anyone uses it. 

 

Completely uncompressed RGB video would be (horizontal resolution)*(vertical resolution)*(color depth * 3)*(frame rate) = bits per second.

 

So a 1280x720 video, with 8 bit color depth at 24 FPS would be 1280x720*24*24=530841600

530841600 bits = 530Mbps.

 

Half a gigabit for a 720p video with standard color bit depth and 24 FPS.

 

 

On 9/21/2021 at 9:11 AM, Edan Maus said:

Netflix claims about 7GB per hour of streaming so how can it look even close with that little of the data being used? That is not something your average device could uncompress very easily much less in an instant to stream a video.

OP, the FAP video posted above should give you a decent basic understanding of video compression.

If you're wondering how it can still give so good despite us removing like 92% of the original data? It's because raw video is extremely inefficient in how it stores the data, and we really don't need that much data to get a good looking image. Why store the RGB values of each individual pixel if the entire screen is just completely black? Why store a 1 second completely black screen as 30 individual frames, when we could store them as "repeat this frame 30 times"?

 

Want more details than that? 

Here is a great video from Xiph about audio and video that covers the basics in a far more detailed way. The part about digital video starts at 15:58:

 

If you want to know about the specifics for a certain video codec, then the AV1 specifications are completely open for anyone to read and implement. AV1 is a very complicated codec though, so it might not be a good way to start.

https://aomediacodec.github.io/av1-spec/av1-spec.pdf

[wanderingfool2]

1 hour ago, Edan Maus said:

We have done decompression for decades, but not from what we stream to RAW afaik bc that would take some serious juice to do on the fly. We have some smart ways to compress stuff so that it can be unpacked quicker, but idk if we are there yet on lots of devices. If raw 4k video is about 20MB per frame (that's average) than at 30fps playback you would have to decompress 600MB of video per second. That's a lot to do instantly even for good PC's. Couldn't imagine a smart tv or firstick doing that. There has to be some kind of missing information right? Looks good regardless though. I have a 10900k and just decompressing a 1GB zip still takes 2 or 3 seconds.

It's good to remember that modern devices has specific decoders for certain media formats...so a few million transistors can do a lot of work.

 

A smaller example being YUV 4:2:0 sub sampling (actually most things are stored as YUV, then converted to RGB later)...but lets say going from RGB to YUV.  You can look it up, but it's essentially 3 multiplies and 2 adds (plus rounding).  So that's like 6 operations, or 18 when considering the UV components.  What Sub-sampling does is essentially toss out 3/4 of the UV data...essentially meaning YUV 4:2:0, which instantly cuts the total need by 50%.  https://en.wikipedia.org/wiki/Chroma_subsampling

 

In terms of processing power, you are doing this all in parallel...but lets say you have a chip that runs at 16mHz, and lets say they designed multiplication and addition to be about 2 IPC.  That means you could do 8 mill adds/mult per second (and that's just for one bit, no parallel).  So it's quite trivial to do YUV to RGB conversion with even a decent amount of logic gates running at like 16 mHz.

 

Then you get to DCT compression...which essentially exploits that any given 8x8 grid will likely have very similar colored pixels...this actually is decently computationally expensive, in the order of O(nlogn)...but I mean even in worst case scenario you are looking at 64 calculations per channel...but again we have the horse power now and days to create custom chips that just burn through those kinds of calculations like nothing.

 

The thing to remember is that video compression is highly parallel.  zip files aren't nearly as parallel, they require the previous decompressed data to keep decompressing.  With images, you can essentially break things down into segments (like in JPEG's case an 8x8 grid for DCT)....which very naively saying means you could break it down into 129600 parallel calculations to decompress the image...which again would be quite easy to make a custom chip to do so.

[Kilrah]

5 hours ago, Edan Maus said:

We have done decompression for decades, but not from what we stream to RAW afaik

Of course. Even your average phone can take 4K 60fps highly compressed video and turn it into "raw" RGB pixels to show on your screen.

 

5 hours ago, Edan Maus said:

that would take some serious juice to do on the fly

All devices nowadays have dedicated hardware of which the sole job is decoding/encoding video hundreds of times faster than a CPU could for that reason. 

[LAwLz]

38 minutes ago, Kilrah said:

Of course. Even your average phone can take 4K 60fps highly compressed video and turn it into "raw" RGB pixels to show on your screen.

That's clearly not what OP is talking about. He is talking about the video files themselves and the processing to display those, not what is being displayed on the screen.

Besides, calling the data in the output buffer "raw" is extremely misleading. Might as well call a 128Kbps MP3 "raw audio" in that case. When talking about raw formats people mean little or no processing of the file, and stored in a simple manner. Like BMP which stores each RGB value for each pixel in the image. Or WAV which stores the audio as LPCM. Data in the output buffer is not "raw". 

[8tg]

You can compress a lot without losing all that much noticeable detail without a metaphorical fine toothed comb.

Look into uncompressed high resolution audio. DSD512 can be easily 1-2gb per song. You can take that file and bring it down to 50-100mb as a 48khz flac. And depending on what you’re listening to and with, you might only notice very small differences.

Even further make that flac a 320kbps MP3 and you’re looking at some more noticeable differences between the original DSD file, but at a mere 10-15mb in size.

 

Compression is surprisingly smart.

[Helly]

It just so happens i am currently recording footage from my PS5 in 4k60fps 10bit. Not really needed as the game is running in 30fps so i should really stop that but w/e. I am using MagicYUV with the 4:2:0 10bit option. This is lossless recording. I record in bits of roughly 30mins. Depending on whats happening in the scene the parts are anywhere from 620GB to 665GB at the moment. So if we're talking 1 hour of footage that is only 1.2 to 1.3TB. Nowhere near the 5TB mentioned before.

 

From experience i can tell you right now that NOTHING from ANY streaming service (or bluray for that matter) is anything more then 4:2:0. Why? Because i have recorded a game in 4:2:2 and compressed it using x265 with the 4:2:2 intact and it brought my old I7 5960x to its knees. And not only the CPU but the GPU as well. It played back fine without stutters but both the CPU and GPU were at almost 100% usage (my HTPC with R5 2400G was unable to play it in any watchable way). The same footage converted to 4:2:0 has almost no usage for either of them. My current PC has less trouble playing it back (~30% usage for both depending on whats happening), but its still to much for something that makes no visual difference.

 

So if you're going to have anything more then 4:2:0 it will only be for editing purposes and never for viewing, and for editing you're gonna need a beast of a machine to watch it back without stutters.

 

Just thought i'd give some numbers based on experience

[LAwLz]

9 hours ago, Helly said:

It just so happens i am currently recording footage from my PS5 in 4k60fps 10bit. Not really needed as the game is running in 30fps so i should really stop that but w/e. I am using MagicYUV with the 4:2:0 10bit option. This is lossless recording. I record in bits of roughly 30mins. Depending on whats happening in the scene the parts are anywhere from 620GB to 665GB at the moment. So if we're talking 1 hour of footage that is only 1.2 to 1.3TB. Nowhere near the 5TB mentioned before.

That's because your file is compressed, while OP is talking about uncompressed video. 

 

9 hours ago, Helly said:

From experience i can tell you right now that NOTHING from ANY streaming service (or bluray for that matter) is anything more then 4:2:0. Why? Because i have recorded a game in 4:2:2 and compressed it using x265 with the 4:2:2 intact and it brought my old I7 5960x to its knees. And not only the CPU but the GPU as well. It played back fine without stutters but both the CPU and GPU were at almost 100% usage (my HTPC with R5 2400G was unable to play it in any watchable way). The same footage converted to 4:2:0 has almost no usage for either of them. My current PC has less trouble playing it back (~30% usage for both depending on whats happening), but its still to much for something that makes no visual difference.

I don't think it was the 4:2:2 chroma subsampling that made your CPU have to work so much. It was probably your settings in x265, and it would have happened at other subsampling settings as well. 

The fact that both your CPU and GPU was used tells me that something is suboptimal with your setup. You shouldn't mix CPU and GPU with either encoding or decoding. Hell, even when you're encoding on the GPU you should only be hitting the media engine, not the actual shader cores. 

 

 

10 hours ago, Helly said:

So if you're going to have anything more then 4:2:0 it will only be for editing purposes and never for viewing, and for editing you're gonna need a beast of a machine to watch it back without stutters.

I don't think 4:2:0 means what you think it means. OP is talking about compression, not subsampling. Subsampling is not really the type of compression OP is talking about when he says "raw video". A video can be in a "raw format" and still be 4:2:0 for example, or 4:4:4.

[wanderingfool2]

17 hours ago, Helly said:

It just so happens i am currently recording footage from my PS5 in 4k60fps 10bit. Not really needed as the game is running in 30fps so i should really stop that but w/e. I am using MagicYUV with the 4:2:0 10bit option. This is lossless recording. I record in bits of roughly 30mins. Depending on whats happening in the scene the parts are anywhere from 620GB to 665GB at the moment. So if we're talking 1 hour of footage that is only 1.2 to 1.3TB. Nowhere near the 5TB mentioned before.

I'm sorry but you have been conned by marketing.  4:2:0 sub sampling is in no way shape or form lossless recording (or even loss less compression).  You literally are cutting away 75% of the color data (which produces 50% less file size).

 

17 hours ago, Helly said:

From experience i can tell you right now that NOTHING from ANY streaming service (or bluray for that matter) is anything more then 4:2:0. Why? Because i have recorded a game in 4:2:2 and compressed it using x265 with the 4:2:2 intact and it brought my old I7 5960x to its knees. And not only the CPU but the GPU as well. It played back fine without stutters but both the CPU and GPU were at almost 100% usage (my HTPC with R5 2400G was unable to play it in any watchable way). The same footage converted to 4:2:0 has almost no usage for either of them. My current PC has less trouble playing it back (~30% usage for both depending on whats happening), but its still to much for something that makes no visual difference.

Encoding is generally much much harder than decoding, as you need to calculate the optimal motion vectors for each 8x8 grid (as well as other stuff).

 

Honestly, I think you need to look at your setup.  My 8 year old HTPC can easily play back my 4:4:4 h.264 files I created (and it doesn't even have a video card)..I do find it funny NVideo NVENC supports 4:4:4 h264 but not NVDEC.  Albeit I am talking about 1080p, but most modern hardware has accelerators for that.

 

A simple reason why streaming services would tend to 4:2:0 is because it automatically offers pretty much 50% reduction in size (and the human eye, especially at 4k resolutions will likely not spot it unless it's like text on the screen or a high contrast environment without motion).  The other reason being that it means a lot less mastering time.  Going from 4:4:4 to 4:2:0 means you have also 50% less data to run compression on (finding MV's and such is so much quicker)

[LAwLz]

1 hour ago, wanderingfool2 said:

I'm sorry but you have been conned by marketing.  4:2:0 sub sampling is in no way shape or form lossless recording (or even loss less compression).  You literally are cutting away 75% of the color data (which produces 50% less file size).

I don't think he has been conned by marketing. MagicYUV is a lossless codec. But it seems like he don't understand the technical details and thinks it is lossless because it uses 4:2:0, or something.

 

Also, I don't think it is a good idea to say things like "chroma subsampling is compression" because we are mixing resolution with data compression.

 

If I take a picture with my phone, and then removed the red channel in Photoshop and save it as a PNG, would you say the compression was lossy? Since it is saved as a PNG, it still has a lossless compression. Sure I removed one of the color channels, but that's not the same as "compressing", right?

Same deal here. Chroma subsampling is lowering the resolution of the image. That's not the same as compressing the actual data of the image using something like JPEG's DCT.

[Helly]

8 hours ago, LAwLz said:

I don't think it was the 4:2:2 chroma subsampling that made your CPU have to work so much. It was probably your settings in x265, and it would have happened at other subsampling settings as well. 

The fact that both your CPU and GPU was used tells me that something is suboptimal with your setup. You shouldn't mix CPU and GPU with either encoding or decoding. Hell, even when you're encoding on the GPU you should only be hitting the media engine, not the actual shader cores.

 

55 minutes ago, wanderingfool2 said:

Honestly, I think you need to look at your setup.  My 8 year old HTPC can easily play back my 4:4:4 h.264 files I created (and it doesn't even have a video card)..I do find it funny NVideo NVENC supports 4:4:4 h264 but not NVDEC.  Albeit I am talking about 1080p, but most modern hardware has accelerators for that.

Honestly i think you both missed the part where i said the same file in 420 has next to no use for both cpu and gpu. And to be clear here, it is not a differently encoded file. The encoding profile was the same for both files. They just got presented a frame with different subsamplings.

 

and to clear things up a bit, i remembered the usage wrong of the 422 file. The CPU was over 50% the whole time hitting 70%+ regularly, the GPU was at 25%. Going back to 0% to 1% when playing 420.

 

1 hour ago, wanderingfool2 said:

I'm sorry but you have been conned by marketing.  4:2:0 sub sampling is in no way shape or form lossless recording (or even loss less compression).  You literally are cutting away 75% of the color data (which produces 50% less file size)

I'm sorry but that is a very reckless assumption to make.... can also be completely wrong, so be careful with what you assume. If i am presented a 4:2:0 signal and i record it in 4:2:0, how am i throwing away 75% of the color data? Why record or encode something that isn't there, and remember, everything videowise you watch on a daily basis is 4:2:0.

 

But enough hijacking of the topic. Sorry to throw it off. Just thought i'd give at least some numbers of close to raw video files that at least made some sense to be created and used. As using RAW video is pointless and useless, certainly for a service like netflix. They can fit multiple seasons of multiple tv-shows, encoded in every selectable format, in the size of a single episode in RAW video format. Not to mention they'd have to encode the video everytime anyone starts a stream....

[wanderingfool2]

23 minutes ago, LAwLz said:

Also, I don't think it is a good idea to say things like "chroma subsampling is compression" because we are mixing resolution with data compression.

Actually it is by definition a compression technique when talking about the RGB space.  When I was learning about the implementation of jpg images at school, it was even taught as a lossy compression technique used by jpg.

 

34 minutes ago, LAwLz said:

If I take a picture with my phone, and then removed the red channel in Photoshop and save it as a PNG, would you say the compression was lossy? Since it is saved as a PNG, it still has a lossless compression. Sure I removed one of the color channels, but that's not the same as "compressing", right?

Same deal here. Chroma subsampling is lowering the resolution of the image. That's not the same as compressing the actual data of the image using something like JPEG's DCT.

If you removed the red channel, and only saved the GB channels then yea, I would consider that a type of compression (not a good one, but it's still compression).  The quantization done on the DCT is the lossy part (it's just lumped in with DCT because it makes little sense running DCT without quantizing).

 

It's similar to music compression.  Using a FT to translate into frequencies, even before the quantization you remove some frequencies (like if you have a high peak at one frequency and one bin over you have a peak half the size, you remove that bin because the human ear will likely not hear that).  Effectively you are removing frequencies from that don't matter.  The thing is any technique used to reduce the overall data size should be considered as compression.

 

22 minutes ago, Helly said:

The CPU was over 50% the whole time hitting 70%+ regularly, the GPU was at 25%. Going back to 0% to 1% when playing 420.

That's more likely due to not having hardware that has dedicated decoders.  The reason why you see 0% to 1% with 4:2:0 is likely because it doesn't report the decoder % (if you go to task manager, you could actually see it)

 

46 minutes ago, Helly said:

I'm sorry but that is a very reckless assumption to make.... can also be completely wrong, so be careful with what you assume. If i am presented a 4:2:0 signal and i record it in 4:2:0, how am i throwing away 75% of the color data? Why record or encode something that isn't there, and remember, everything videowise you watch on a daily basis is 4:2:0.

I can re-encode a jpg image at no loss of data...that doesn't make the jpg standard lossless.  As I've said before, 4:2:0 is used quite commonly because you get a 50% reduction, and especially with 4k most people won't notice it unless being told what to look for.  YUV space is inherently 4:4:4, and TV shows while stored in 4:2:0 was shot on cameras that utilize RGB sensors, that would have it in YUV space (even if briefly), and sampled to 4:2:0.  You ultimately have a type of lossy compression happening here...which leads me back to, effectively 75% of data has been thrown out in a 4:2:0 setting.

[LAwLz]

9 minutes ago, Helly said:

Honestly i think you both missed the part where i said the same file in 420 has next to no use for both cpu and gpu.

I didn't miss it. I just ignored it because it sounds like you're doing something incorrect. Maybe I'm just being dumb, but it sounds like you're very confused and don't quite understand what you're talking about.

 

14 minutes ago, Helly said:

And to be clear here, it is not a differently encoded file. The encoding profile was the same for both files.

I am not following you here.

Before you said that you encoded them differently and as a result you got very different performance on your different devices. Now you say you encoded them with the same profile? In that case you should not have gotten different decoding performance. The source file does not matter at all once the file has been transcoded.

A 4:2:0 HEVC file is just as easy/difficult to decode regardless of whether or not the source file (before the transcode) was 4:4:4 or 4:2:0.

 

The fact that the 4:4:4 file takes longer to encode is just because it has more information in it. Then there is also varying degrees of optimization for the different profiles, as well as potential hardware support that can play an even bigger role in how well it performs.

 

23 minutes ago, Helly said:

and to clear things up a bit, i remembered the usage wrong of the 422 file. The CPU was over 50% the whole time hitting 70%+ regularly, the GPU was at 25%. Going back to 0% to 1% when playing 420.

Again, that's super weird and indicates an issue in your setup.

Video decoding is either done on the CPU, or the GPU. Very rarely are both used at the same time (and even then it's usually not a good idea). If your computer supports hardware accelerated decoding then neither your CPU nor your GPU should be stressed. If it doesn't support HWA decoding then it should almost entirely be your CPU. The fact that it's both is strange.

There might be some CPU and GPU load regardless of HWA but that depends on what type of post-processing you're doing (upscaling, motion smoothing, de-interlacing, anti-ringing, etc) but those should be fairly constant regardless of the codec (since they are applied after decoding is done).

 

I'd like for you to describe in more detail what happened, because it feels like both me and wanderingfool might not fully understand your explanation of what you did and what results you got.

[LAwLz]

3 minutes ago, wanderingfool2 said:

Actually it is by definition a compression technique when talking about the RGB space.  When I was learning about the implementation of jpg images at school, it was even taught as a lossy compression technique used by jpg.

It's a type of compression, but it's not the same type of compression people talk about when they talk about let's say HEVC. It's a different thing and should not be mixed in. Flopping around between chroma subsampling and other compression types will just be confusing and lead to misunderstanding.

 

 

4 minutes ago, wanderingfool2 said:

If you removed the red channel, and only saved the GB channels then yea, I would consider that a type of compression (not a good one, but it's still compression). 

Yes, but would you say the image was lossily compressed? I would not say it is, because the compression (PNG) didn't remove any information. It was instead like I made a new image and did lossless compression on that.

If we start lumping all types of data removal regardless of where they take place in the chain and label all of them as "compression" then we could basically never say anything is lossless. A camera capturing in RAW? Still lossy compression, because the sensor does not have a resolution high enough to capture all the details in the world.

It just becomes silly, and we need to make definitions and cutoffs for those definitions. Chroma subsampling is not viewed as the same category as a video format like HEVC. You could call both of them "compression", but if you are talking about both video formats and chroma subsampling in the same post then it's best to stick to using "compression" for only one of the two. Using the same word to describe two different categories of things is just begging for misunderstandings.

We are definingly arguing semantics here, but I think that it will be clearer for everyone involved if you refrain from calling chroma subsampling "compression" if you are also going to talk about data compression video formats.

 

 

 

 

 

12 minutes ago, wanderingfool2 said:

I can re-encode a jpg image at no loss of data...that doesn't make the jpg standard lossless.

If the re-encode didn't remove any visual data then it would actually be lossless. That's how the term lossless is used.

Here is a quote from the JPEG working group regarding JPEG XL:

Quote

Existing JPEG files can be losslessly transcoded to JPEG XL, significantly reducing their size.

When talking about transcoding, the terms lossy and lossless are always only talking about the relation of the input and output file, not the entire production chain.

 

If I take a JPEG picture with my phone and then save that as a PNG, the file is losslessly compressed (PNG). PNG does not become "lossy compression" just because the input file used lossy compression. It is still classified as lossless because the output file looks identical to the input file.

[wanderingfool2]

7 minutes ago, LAwLz said:

We are definingly arguing semantics here, but I think that it will be clearer for everyone involved if you refrain from calling chroma subsampling "compression" if you are also going to talk about data compression video formats.

I think it's important to note it as an compression element.  As it's a low cost way of reducing a file size by half, while requiring very little computational power (relative to other solutions).

 

13 minutes ago, LAwLz said:

A camera capturing in RAW? Still lossy compression, because the sensor does not have a resolution high enough to capture all the details in the world.

Fun fact, this actually was a discussion in my class.  The general rule, taught by the prof, was that once in the digital world that raw data would be considered to be considered as the baseline...ie when it enters the RGB data is generated.

 

16 minutes ago, LAwLz said:

Chroma subsampling is not viewed as the same category as a video format like HEVC

Oh yea, I totally agree with this.  It's a different type of thing.

 

20 minutes ago, LAwLz said:

When talking about transcoding, the terms lossy and lossless are always only talking about the relation of the input and output file, not the entire production chain.

 

If I take a JPEG picture with my phone and then save that as a PNG, the file is losslessly compressed (PNG). PNG does not become "lossy compression" just because the input file used lossy compression. It is still classified as lossless because the output file looks identical to the input file.

That's sort of what I am saying though.  Ultimately we can discuss whether or not YUV 4:2:0 should be called compression or not, but having the term "lossless" around I think causes more confusion...as can be seen by the thought that a (YUV 4:2:0 "lossless recording" numbers were equivalent to "24 bit RGB" as mentioned by the OP).

 

Call me cynical, but I've met too many people who use lossless transcoding as a justification that a file is lossless.  Without the understanding that it's still a lossy compression.

 

 

[Helly]

34 minutes ago, wanderingfool2 said:

That's more likely due to not having hardware that has dedicated decoders.  The reason why you see 0% to 1% with 4:2:0 is likely because it doesn't report the decoder % (if you go to task manager, you could actually see it)

The numbers i gave you came from task manager....

 

32 minutes ago, LAwLz said:

I didn't miss it. I just ignored it because it sounds like you're doing something incorrect. Maybe I'm just being dumb, but it sounds like you're very confused and don't quite understand what you're talking about.

The only one very confused here is you. Maybe same file in 420 was confusing and wrong description for it? The same recording encoded to 420 is probably better then. I never said i was an expert at compression techniques. Everything i said is based on just recording and encoding those recordings and observing what my pc does when playing back the encoded file. It is very obvious to me that neither of you have ever even watch a file encoded in 422 or 444 (why would you? No one really does it and you won't notice the difference). If you did you would see the higher CPU and GPU use. My current 5950x and 6900XT does the same. Lower usage then the 5960x/vega64 but definitely higher usage then the 420 file.

 

And to be clear here, i have no idea why the usage is so much higher. I found it weird when it happened and had no idea it would be a thing, but it is. If i had to guess then i would say that the decoders are optimized for 420 because nothing is really encoded in anything more... so why bother?

 

37 minutes ago, LAwLz said:

I am not following you here.

Before you said that you encoded them differently and as a result you got very different performance on your different devices. Now you say you encoded them with the same profile? In that case you should not have gotten different decoding performance. The source file does not matter at all once the file has been transcoded.

A 4:2:0 HEVC file is just as easy/difficult to decode regardless of whether or not the source file (before the transcode) was 4:4:4 or 4:2:0.

of course you're not following, you don't do a lot of encoding do you? I never said i encoded them with a different profile. The only thing i said was 1 file was 422 and the other was 420. If you did ever encode anything you would know that the codec would just use the same subsampling as the original source does. It encodes with the sampling it gets. Unless maybe you can set it to specifically change it but i've never done that.

In short, all i said was that 1 file was 422 and the other 420. That was all that changed between the two. You and wanderingfool wrongfully assumed i used a different profile. All i did to encode the files was change the way the decoder of the recording presents the frames to the encoder. (using avisynth function ConvertToYUV420)

[wanderingfool2]

4 minutes ago, Helly said:

The numbers i gave you came from task manager....

Task manager doesn't show all the % always.  An example being using nvenc my GPU % doesn't show too much but clicking on it will show 50% video encoding process.  Task manager isn't exactly the best either at reporting usages I find.

 

9 minutes ago, Helly said:

It is very obvious to me that neither of you have ever even watch a file encoded in 422 or 444 (why would you? No one really does it and you won't notice the difference). If you did you would see the higher CPU and GPU use. My current 5950x and 6900XT does the same. Lower usage then the 5960x/vega64 but definitely higher usage then the 420 file.

You are wrong there.  I find 4:2:0 can be distracting when there is a lot of text at 1080p resolution.  Solution, taking the 4k signal, and saving it as a 1080p 4:4:4.  My theatre room has a 12 foot screen, with a 1080p projector...4:2:0 artifacts with text can become quite apparent.

 

Again, the theoretical application of 4:2:0 vs 4:4:4 for any given resolution would be 2x the amount of processing.  If you want to see what it really is like though, just disable hardware acceleration in VLC, load up a file with 4:2:0 then 4:4:4 and witness it yourself.

[Helly]

5 minutes ago, wanderingfool2 said:

You are wrong there.  I find 4:2:0 can be distracting when there is a lot of text at 1080p resolution.  Solution, taking the 4k signal, and saving it as a 1080p 4:4:4.  My theatre room has a 12 foot screen, with a 1080p projector...4:2:0 artifacts with text can become quite apparent.

No idea what you're trying to say here.... a GPU output has nothing to do with the file being played. Or are you saying you can just convert them and add the missing data back in somehow? How does that even work? What are you even watching that has so much text? Feels more like you have something wrong with YOUR setup...

 

8 minutes ago, wanderingfool2 said:

Again, the theoretical application of 4:2:0 vs 4:4:4 for any given resolution would be 2x the amount of processing.

So a file encoded in 422 requires more processing power then 1 encoded in 420. Thank you for making this entire discussion pointless and me needlessly explaining what i did when you could have just said that....

[LAwLz]

1 hour ago, Helly said:

The only one very confused here is you. Maybe same file in 420 was confusing and wrong description for it? The same recording encoded to 420 is probably better then. I never said i was an expert at compression techniques. Everything i said is based on just recording and encoding those recordings and observing what my pc does when playing back the encoded file. It is very obvious to me that neither of you have ever even watch a file encoded in 422 or 444 (why would you? No one really does it and you won't notice the difference). If you did you would see the higher CPU and GPU use. My current 5950x and 6900XT does the same. Lower usage then the 5960x/vega64 but definitely higher usage then the 420 file.

Okay so you had a 4:4:4 file and then transcoded that to one 4:2:0 file and one 4:4:4 file?

 

 

 

1 hour ago, Helly said:

And to be clear here, i have no idea why the usage is so much higher. I found it weird when it happened and had no idea it would be a thing, but it is. If i had to guess then i would say that the decoders are optimized for 420 because nothing is really encoded in anything more... so why bother?

I don't think it's weird that it uses more resources. I mean, it's pretty obvious that it should use more resources, it's more information to process.

What I find weird is that both your CPU and GPU is used, to a pretty high degree. That's weird. 

 

1 hour ago, Helly said:

of course you're not following, you don't do a lot of encoding do you?

I do actually.

 

1 hour ago, Helly said:

I never said i encoded them with a different profile. The only thing i said was 1 file was 422 and the other was 420.

That would be a different profile...

For example if we're talking about HEVC, then for example the Main 12 profile is often 4:2:0 while the profile for 4:4:4 is called Main 4:4:4. Maybe you're getting profile confused with preset? 

 

1 hour ago, Helly said:

If you did ever encode anything you would know that the codec would just use the same subsampling as the original source does. It encodes with the sampling it gets. Unless maybe you can set it to specifically change it but i've never done that.

No it doesn't. Maybe that's the default with the encoder you're using, but it is by no means a rule that has to be followed. In for example x264 you can set the output to be whatever chroma subsampling you want, regardless of what the input is.

Just set it to --profile high444 and you will get 4:4:4 chroma subsampling in your output file.

Not sure which encoder you are using but it is very likely that it does not automatically use the same subsampling as the original. It might just be that they aligned for you by accident.

Edit: I was wrong on this point. It seems like the encoders do follow the source subsampling automatically. At least x264 and x265 do.

[Helly]

6 minutes ago, LAwLz said:

That would be a different profile...

For example if we're talking about HEVC, then for example the Main 12 profile is often 4:2:0 while the profile for 4:4:4 is called Main 4:4:4. Maybe you're getting profile confused with preset?

haha, yeah that might be it. It is very confusing. I've been using MeGUI for years. For x264 you can set a profile (i set it to high). for x265 its called preset... which i set to medium... or is that something else entirely? Yeah seems like it, as you can set a profile with extra parameters. I didn't set the profile there. So its the default one. Can't really find which is the default, i'm guessing main.

So i guess i'll rephrase yet again. I used the same encoding settings for both versions of the file. All i changed between them was converting to 420 before presenting it to the encoder with avisynth.

This will be my last response... not really interested anymore, and completely irrelevant to the original question.