H.264 Is Magic (2016)(sidbala.com)
sidbala.com
H.264 Is Magic (2016)
https://sidbala.com/h-264-is-magic/
199 comments
Well sure, but the hardware encode and decode isn’t completely widespread yet. I’ve been patiently waiting for what has felt like an eternity. From the developer perspective everyone needs to have access to it or I’m just sitting on my hands waiting for the capabilities to trickle down to the majority of users. Hopefully more users will purchase hardware if it features AV1 encode/decode. They need a logo that says “AV1 inside” or something. So, for example only the iPhone 15 pro offers hardware decode so far in the iPhone lineup.
You inevitably have to do multiple encodes. An H.264 encode as the "plays anywhere" option and an AV1 encode as the "less bandwidth or better image quality at the same bandwidth" option.
YouTube does H.264, VP9, and AV1 video encodes with AAC and Opus audio encodes.
This video for example has encodes of all those options: https://www.youtube.com/watch?v=ArmDp-zijuc
You can watch it in multiple resolutions and formats from 4K in AV1 down to 144p in H.264.
YouTube does H.264, VP9, and AV1 video encodes with AAC and Opus audio encodes.
This video for example has encodes of all those options: https://www.youtube.com/watch?v=ArmDp-zijuc
You can watch it in multiple resolutions and formats from 4K in AV1 down to 144p in H.264.
This only happens because they're using Cisco's license. H.264 is not "plays anywhere".
By your definition then nothing would be "plays anywhere". H.264 is about the closest you can get. And depending on Profiles it is about to become patent free where license will no longer be required.
Get a cheap Intel ARC A310 card. I have one in my workstation along side my AMD GPU purely for streaming/encoding. It works great.
Then the issue kind of becomes software support. For example, something like Handbrake will gladly use AV1, but Kdenlive will refuse to acknowledge that it exists (at least for hardware encode, last I checked; that said, they still mark NVENC as experimental).
Also, OBS handles AV1 nicely, but you can’t stream to a site like Twitch because they only support H264 outside of specific experiments.
That said, Arc GPUs are nice, I have an A580 and while the drivers aren’t as mature as Nvidia or AMD, I got it for a pretty good price and they’re gradually patching things out.
Also, OBS handles AV1 nicely, but you can’t stream to a site like Twitch because they only support H264 outside of specific experiments.
That said, Arc GPUs are nice, I have an A580 and while the drivers aren’t as mature as Nvidia or AMD, I got it for a pretty good price and they’re gradually patching things out.
That only works if you actually own a desktop though. It's too bad they don't have some ultra tiny SD card sized accelerator addon system or something for laptops
> AV1 is more magic with better licensing.
AV1 is bloody awful to encode in software.
I was recording videos of lectures (a slowly moving person against a whiteboard with thin sharp lines on it, in a questionably well-lit room) and needed to encode them to smallish 720p files to be posted somewhere (ended up uploading them to the Internet Archive). This is not something that x264’s default encoding profiles do well on, but with a day or two of fiddling with the settings I had something I could run on my 2014-era iGPU-only laptop the night after the lecture and have the result up the next day.
By contrast, libaom promised me something like a week of rendering time for the three hours of video. Perhaps this could be brought down (my x264 fiddling got me veryslow-comparable results several times faster), but the defaults were so bad I couldn’t afford to experiment. (This was some four years ago. Things have probably gotten better since then, but I don’t expect miracles.)
AV1 is bloody awful to encode in software.
I was recording videos of lectures (a slowly moving person against a whiteboard with thin sharp lines on it, in a questionably well-lit room) and needed to encode them to smallish 720p files to be posted somewhere (ended up uploading them to the Internet Archive). This is not something that x264’s default encoding profiles do well on, but with a day or two of fiddling with the settings I had something I could run on my 2014-era iGPU-only laptop the night after the lecture and have the result up the next day.
By contrast, libaom promised me something like a week of rendering time for the three hours of video. Perhaps this could be brought down (my x264 fiddling got me veryslow-comparable results several times faster), but the defaults were so bad I couldn’t afford to experiment. (This was some four years ago. Things have probably gotten better since then, but I don’t expect miracles.)
Not at all my experience, 673 movies and counting. I encode at around 10 to 13x with my 12900K using svt-av1.
My command:
ffmpeg.exe -i file.mp4 -r 23.976 -vf scale=1280:720 -c:v libsvtav1 -pix_fmt yuv420p10le -crf 30 -preset 10 -g 600 -c:a libopus -b:a 96k -ac 2 -c:s copy -map 0 out.mp4
Try it.
My command:
ffmpeg.exe -i file.mp4 -r 23.976 -vf scale=1280:720 -c:v libsvtav1 -pix_fmt yuv420p10le -crf 30 -preset 10 -g 600 -c:a libopus -b:a 96k -ac 2 -c:s copy -map 0 out.mp4
Try it.
while the lectures in they were encoding would definitely look fine with these settings, I have to question your baseline for quality if you’re watching full Hollywood movies encoded at CRF 30.
I'm watching these on my second monitor when I play guitar.
Isn’t that the recommended starting point for AV1? What’s an appropriate high quality starting point?
there isn’t an easy answer, as it’s always going to be dependent on the source you’re encoding from. That said, in my experience anything higher than CRF 25 on AV1 is noticeably compressed, even to a layman. I mostly work in 1080 and occasionally 2160, though.
i can’t remember the last project i worked on in native 720 (probably circa 2009?) and even now 720 is only part of my output pipeline if specifically requested by the client.
i can’t remember the last project i worked on in native 720 (probably circa 2009?) and even now 720 is only part of my output pipeline if specifically requested by the client.
> -crf 30
That would do it.
That would do it.
SVT-AV1 is a much faster AV1 encoder: https://gitlab.com/AOMediaCodec/SVT-AV1/
> libaom promised me
The reference AOM was never a practically useful encoder even 4 years ago.
> I couldn’t afford to experiment
Pity as you'd discover a better encoder...
The reference AOM was never a practically useful encoder even 4 years ago.
> I couldn’t afford to experiment
Pity as you'd discover a better encoder...
In an 8-bit colorspace, h.264/5 suffer from virtually no block artifacts. AV1 can't get rid of them without upping to 10-bit. Not that it's necessarily a problem.
The real problem with AV1 is how darn computationally intensive it is to compress.
The real problem with AV1 is how darn computationally intensive it is to compress.
> In an 8-bit colorspace, h.264/5 suffer from virtually no block artifacts. AV1 can't get rid of them without upping to 10-bit. Not that it's necessarily a problem.
H.264 gets enough of a compression boost from 10-bit math that you should be using it anyway.
I don't know if this affects H.265
> The real problem with AV1 is how darn computationally intensive it is to compress.
How are you measuring that?
It's true that SVT-AV1 is slower than x264 at preset 6 or below. And it's slower than x265 at preset 3 or below. But those aren't the presets you use if you want to be fast.
SVT-AV1 can match the quality of x264 veryslow while running at the speed of x264 veryfast.
It can match the quality of x265 veryslow while running at the speed of x265 medium.
It can match the quality of x265 medium while running at the speed of x265 ultrafast.
https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Co...
H.264 gets enough of a compression boost from 10-bit math that you should be using it anyway.
I don't know if this affects H.265
> The real problem with AV1 is how darn computationally intensive it is to compress.
How are you measuring that?
It's true that SVT-AV1 is slower than x264 at preset 6 or below. And it's slower than x265 at preset 3 or below. But those aren't the presets you use if you want to be fast.
SVT-AV1 can match the quality of x264 veryslow while running at the speed of x264 veryfast.
It can match the quality of x265 veryslow while running at the speed of x265 medium.
It can match the quality of x265 medium while running at the speed of x265 ultrafast.
https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Co...
> how darn computationally intensive it is to compress.
which i think is fine, as most decompression is on user side, but compression is on server side (and mostly only ever done once!).
which i think is fine, as most decompression is on user side, but compression is on server side (and mostly only ever done once!).
> which i think is fine, as most decompression is on user side, but compression is on server side (and mostly only ever done once!).
This is 100% use case dependent.
For Netflix, compression is only done once and decompression happens a ridiculous amount of times.
For YouTube, popular channels are similar to Netflix; but they suffer from a very very long tail of videos which only get watched a handful of times.
For chat applications, videos may get watched only once by the recipient.
For video conferencing, videos get compressed once (on the client's machine even, so ideally using hardware encoding), then decompressed once per recipient. This use-case also has the issue that every client needs to decode every other client's video stream, so you better send video in a format which every client can quickly decode (ideally using hardware decoding).
Notice how "slow compression is fine because decompressing happens much more frequently" is only true for the Netflix use-case and the popular YouTube channels use-case. For everything else, slow compression is a problem.
(Luckily, at least according to others here, AV1 isn't necessarily slow to encode, it's just the reference implementation that's slow and there are software implementations which match the speed of x264. I haven't verified this though)
This is 100% use case dependent.
For Netflix, compression is only done once and decompression happens a ridiculous amount of times.
For YouTube, popular channels are similar to Netflix; but they suffer from a very very long tail of videos which only get watched a handful of times.
For chat applications, videos may get watched only once by the recipient.
For video conferencing, videos get compressed once (on the client's machine even, so ideally using hardware encoding), then decompressed once per recipient. This use-case also has the issue that every client needs to decode every other client's video stream, so you better send video in a format which every client can quickly decode (ideally using hardware decoding).
Notice how "slow compression is fine because decompressing happens much more frequently" is only true for the Netflix use-case and the popular YouTube channels use-case. For everything else, slow compression is a problem.
(Luckily, at least according to others here, AV1 isn't necessarily slow to encode, it's just the reference implementation that's slow and there are software implementations which match the speed of x264. I haven't verified this though)
VP8, VP9, and AV1 are all wonderful and unencumbered. However, as awful as the licensing of H.264 is, it does yield reasonable quality even on hardware that is over a decade old.
It is true that for many purposes we can offload encoding onto servers. However, as someone that frequently deals with live video streaming, AV1 is still out of reach on most hardware I am on and VP9 has only been viable for less than a decade. Yes, VP9 and AV1 are superior in terms of quality, but it is truly remarkable that H.264 runs as well as it does and I wish we had a similar unencumbered lightweight/portable codec (VP8 in my experience is about as heavy as VP9 and offers about the same quality as H.264).
At least for audio we now have Opus and Flac (plus MP3 having had its vile patents expire), so hopefully video is the last frontier and VP9 and AV1 will become the standard over this decade.
It is true that for many purposes we can offload encoding onto servers. However, as someone that frequently deals with live video streaming, AV1 is still out of reach on most hardware I am on and VP9 has only been viable for less than a decade. Yes, VP9 and AV1 are superior in terms of quality, but it is truly remarkable that H.264 runs as well as it does and I wish we had a similar unencumbered lightweight/portable codec (VP8 in my experience is about as heavy as VP9 and offers about the same quality as H.264).
At least for audio we now have Opus and Flac (plus MP3 having had its vile patents expire), so hopefully video is the last frontier and VP9 and AV1 will become the standard over this decade.
In many ways I'd agree. Its more economical to compress once on the server and send over the internet as small as possible. Compression is both a science and a dark art to me.....yet I recognize that the more you compress data the more CPU usage is needed to decompress that data.
> Most of the video I see on YouTube these days is in VP9 or AV1. Occasionally some video is still H.264.
can't shake the feeling that most videos at 720p took a hard hit to quality within the last years (or my eyes are getting better)
any deep dives on the topic appreciated
can't shake the feeling that most videos at 720p took a hard hit to quality within the last years (or my eyes are getting better)
any deep dives on the topic appreciated
I've compressed tens of thousands of videos in recent years and critically looked at the results.
My gut feeling is that implementations of hardware acceleration are just simply not as good as software implementations, the cause perhaps relating to localised resource constraints in hardware when recursing deeper or somesuch.
The algorithms are the same, the chip versions are more resource constrained as the stack goes deeper if you will.
Hardware compressors are much much faster, no doubt, by an order of magnitude and more .. but software compressors left to run slow, with two passes, just produce a much better result.
Standard hardware compressor settings tend to leave moire patterns when the camera pans outside a chain link fence onto a player inside a court (for example), or leaves a blocky halo around the significant figure point of interest moving in an otherwise stillish scene - it's subltle small things that grate when you see them.
The root cause of perceived downgrade in quality is bulk pushing of high quality originals through hardware accelerated compression in order to save time and reduce cost when generating lower bitrate versions to stream.
My gut feeling is that implementations of hardware acceleration are just simply not as good as software implementations, the cause perhaps relating to localised resource constraints in hardware when recursing deeper or somesuch.
The algorithms are the same, the chip versions are more resource constrained as the stack goes deeper if you will.
Hardware compressors are much much faster, no doubt, by an order of magnitude and more .. but software compressors left to run slow, with two passes, just produce a much better result.
Standard hardware compressor settings tend to leave moire patterns when the camera pans outside a chain link fence onto a player inside a court (for example), or leaves a blocky halo around the significant figure point of interest moving in an otherwise stillish scene - it's subltle small things that grate when you see them.
The root cause of perceived downgrade in quality is bulk pushing of high quality originals through hardware accelerated compression in order to save time and reduce cost when generating lower bitrate versions to stream.
Absolutely. Software encoders are constantly pushing the envelope in terms of quality, and they have tuneable knobs to allow you to pick the speed vs quality trade off.
Hardware encoders are much more restrictive. They will target a maximum resolution and frame rate, realtime encoding a possibly low latency as requirement.
The standards define the bitstream, but is lots of scope for cheating to allow for simpler hardware implementation. You could skip motion prediction and use simple quantisation, it would just contribute to the residual entropy that needs to be encoded. Then, you can use inefficient implementations of the entropy encoders. The end result is something that can be interpreted as a valid bitstream but threw out all the algorithmic tricks to give you high quality compressed video.
I think specifically in terms of YouTube, it’s not a hardware encoding issue but it’s a purposeful optimisation for storage and bandwidth.
Hardware encoders are much more restrictive. They will target a maximum resolution and frame rate, realtime encoding a possibly low latency as requirement.
The standards define the bitstream, but is lots of scope for cheating to allow for simpler hardware implementation. You could skip motion prediction and use simple quantisation, it would just contribute to the residual entropy that needs to be encoded. Then, you can use inefficient implementations of the entropy encoders. The end result is something that can be interpreted as a valid bitstream but threw out all the algorithmic tricks to give you high quality compressed video.
I think specifically in terms of YouTube, it’s not a hardware encoding issue but it’s a purposeful optimisation for storage and bandwidth.
There are tradeoffs. IIRC Netflix uses software encoders and they work pretty hard to squeeze the maximum quality for a given bitrate. Makes sense for their use case. OTOH, for like video calls, certain kinds of archiving, in general cases with few or no views, it makes sense to use hardware encoding even if it means compromised image quality.
Sure, there are many use cases and Netflix generally has streams with high quality and few artifacts.
Real time video communications are going to go for fast low bitrates and that's more or less expected.
In other cases where encoders have no real time constraint, eg pirate torrents and youtube alternate versions, there are multiple tiers of quality - for a given resolution (say 720p) and bit rate rate | file size the offerings can be split by time spent encoding, quick and shitty to slow and few visible quirks.
Real time video communications are going to go for fast low bitrates and that's more or less expected.
In other cases where encoders have no real time constraint, eg pirate torrents and youtube alternate versions, there are multiple tiers of quality - for a given resolution (say 720p) and bit rate rate | file size the offerings can be split by time spent encoding, quick and shitty to slow and few visible quirks.
I don't have a deep dive, but I can confirm youtube has made things worse. I came across a copy of 『the TV show』 that I downloaded in 2009. 720p, H.264, 2460kbps. Looking again a couple weeks ago, it was 720p, VP9, 1300kbps. VP9 is more efficient but at half the bitrate it looks much worse.
Poking more, there's an AV1 version that's a little less bad at about the same bitrate, but it's still significantly worse than the old encode. There's also a new version of H.264 that's 2/3 the size of the old one. It's about as bad as the VP9 version but the artifacts focus on different parts of the image.
You'd think after 15 years of storage prices dropping, bandwidth prices cratering, and screens getting bigger, youtube might decide to maintain bitrates and let new codecs increase the quality of videos. Or split the difference between quality and savings. But nah, worse.
Poking more, there's an AV1 version that's a little less bad at about the same bitrate, but it's still significantly worse than the old encode. There's also a new version of H.264 that's 2/3 the size of the old one. It's about as bad as the VP9 version but the artifacts focus on different parts of the image.
You'd think after 15 years of storage prices dropping, bandwidth prices cratering, and screens getting bigger, youtube might decide to maintain bitrates and let new codecs increase the quality of videos. Or split the difference between quality and savings. But nah, worse.
It doesn't make much sense to compare 720p to 720p like that. What matters is the bitrate. So the better question is - does youtube offer better quality video at a given bitrate constraint now in comparison to the past?
I am comparing the maximum quality available. I don't much care that today's 1300kbps video looks better than 2009's 1300kbps video. I care that they used to offer higher quality, and now they don't. I am not bitrate-limited, or at least my bitrate limit is higher than youtube would ever consider going.
What matters is the bitrate, and they're being overly stingy on bitrate.
What matters is the bitrate, and they're being overly stingy on bitrate.
Ok, this wasn't clear to me. Perhaps it was a video with too few views and thus not considered worth spending storage on? I mean, popular videos on youtube have up to 4K and pretty high bitrate.
It has 2.6 million views.
But the source was 720p, and youtube's bandwidth tiers are tied directly to resolution and most of them are stingy.
But the source was 720p, and youtube's bandwidth tiers are tied directly to resolution and most of them are stingy.
seems more like gog/yt shifted bitrate/resolution downwards because pleps demand 4k, and now the "High Definition" version that was good enough for cinemas looks like crap.
During the pandemic everyone was online. There wasn’t enough bandwidth. So all major platforms slashed bitrates. YouTube, Netflix, Zoom.
afaik this was done by a modification to the quality-selection algo, not the videos themselfs
Is this why "Auto" on YouTube never gives me the highest quality option?
I thought it was well known that YouTube cut bitrates during the pandemic? In any case, I think you're quite right, I only watch YouTube in 720p and some videos seem comparable to stuff I downloaded from Kazaa back in the day. It's ok, though. I don't pay for YouTube and I think it's good for them to offer higher quality options for a charge rather than hound every single viewer for payment.
probably different things, seem my other comment itt
AV1 doesn't have the fast encode/decode speed that H.264 has.
Do you have numbers for that?
I don't have a comparison for decode speed, but software encoding of AV1 is able to match the performance of x264 veryfast while looking vastly better.
I don't have a comparison for decode speed, but software encoding of AV1 is able to match the performance of x264 veryfast while looking vastly better.
Related:
H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - March 2022 (219 comments)
H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - May 2019 (180 comments)
H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - May 2018 (1 comment)
H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - Nov 2016 (219 comments)
H.264 is Magic (2016) - https://news.ycombinator.com/item?id=30710574 - March 2022 (219 comments)
H.264 is magic (2016) - https://news.ycombinator.com/item?id=19997813 - May 2019 (180 comments)
H.264 is Magic – a technical walkthrough - https://news.ycombinator.com/item?id=17101627 - May 2018 (1 comment)
H.264 is Magic - https://news.ycombinator.com/item?id=12871403 - Nov 2016 (219 comments)
8 years after that article was written, many of the patents on H.264 are actually approaching expiry soon (i.e. within a year or two):
https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
This is not surprising, given that the first version of the H.264 standard was published in 2003 and patents are usually valid for 20 years.
Its predecessors, H.263 and MPEG-4 ASP, have already patent-expired and are in public domain.
https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
This is not surprising, given that the first version of the H.264 standard was published in 2003 and patents are usually valid for 20 years.
Its predecessors, H.263 and MPEG-4 ASP, have already patent-expired and are in public domain.
I bet that the successor algorithms will be implemented everywhere in hardware, and we're stuck with the patent problem once again.
Well OK, but what about H.265? It's one louder, isn't it?
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding
I do a lot of video compression for hobby projects, and I stick with h264 for the most part because h265 encoding requires far too much extra compute relative to the space savings. I can spend an hour compressing a file down to 1gb with h264, or I can spend 12 hours compressing the same file to 850mb with h265. Depending on the use-case, I might still need the h264 version anyway since it's far more widely supported by clients. If I had a data center worth of compute to throw at encoding, or I were running a streaming service where the extra 150mb per video started to add up, then I'd definitely on-board with h265 but it's really hard to justify for a lot of practical use-cases.
> I stick with h264 for the most part because h265 encoding requires far too much extra compute relative to the space savings. I can spend an hour compressing a file down to 1gb with h264, or I can spend 12 hours compressing the same file to 850mb with h265.
FWIW, as someone who is a complete layman on this topic but has spent much of the past 6 months converting age-old videos to h265...
i have a pi5 where i queue up old videos into a RAM disk, it converts them to h265, and moves them back to the machine which uploaded them. It can take up to 2 days to compress any given video (depending mostly on the input format - old AVIs tend to compress in a few hours), but the space savings is _much_ higher than what you're reporting. The average size of my h265-encodes is anywhere from 1/3rd to 1/2 of the original, and 1/4th of the original is not terribly uncommon. That said: the input formats vary wildly, with possibly only a minority fraction being h264.
i've tried the same thing using a pi4 but it needs roughly 4-5x as long as the pi5. An 8-core intel-based laptop can do it in some 25% of the time of the pi5 but pulls a lot more electricity while doing so. So my otherwise idle pi5 gets the assignment.
My Firefly collection (14 tv episodes plus the movie) dropped from 8gb to 2.1gb. My Bob Ross collection (141 videos) went from 38gb to 7.4gb. 128 Futurama episodes/movies was cut from roughly 50gb to 21gb.
i was once asked why i didn't choose AV1 and the answer is simple: when i googled along the lines of "how to get the best video compression with ffmpeg" the most common answer was h265. Whether that's correct or not, i can't say, but it works for me and i've freed up the better part of a terabyte of space with it.
FWIW, as someone who is a complete layman on this topic but has spent much of the past 6 months converting age-old videos to h265...
i have a pi5 where i queue up old videos into a RAM disk, it converts them to h265, and moves them back to the machine which uploaded them. It can take up to 2 days to compress any given video (depending mostly on the input format - old AVIs tend to compress in a few hours), but the space savings is _much_ higher than what you're reporting. The average size of my h265-encodes is anywhere from 1/3rd to 1/2 of the original, and 1/4th of the original is not terribly uncommon. That said: the input formats vary wildly, with possibly only a minority fraction being h264.
i've tried the same thing using a pi4 but it needs roughly 4-5x as long as the pi5. An 8-core intel-based laptop can do it in some 25% of the time of the pi5 but pulls a lot more electricity while doing so. So my otherwise idle pi5 gets the assignment.
My Firefly collection (14 tv episodes plus the movie) dropped from 8gb to 2.1gb. My Bob Ross collection (141 videos) went from 38gb to 7.4gb. 128 Futurama episodes/movies was cut from roughly 50gb to 21gb.
i was once asked why i didn't choose AV1 and the answer is simple: when i googled along the lines of "how to get the best video compression with ffmpeg" the most common answer was h265. Whether that's correct or not, i can't say, but it works for me and i've freed up the better part of a terabyte of space with it.
Interesting, your numbers look to be quite a bit better than the 30% improvement I've heard is the standard rule of thumb for how much improvement to expect with h.265, and on average for me it's been closer to 20%. I think h.265 starts to show much more meaningful improvements as you start using lower bitrates, and the specific type of media probably matters a bit as well.
I do most of my encoding on an i9-13900k. I've also noticed that h.265 seems to be quite a bit more likely to trigger the smt related crashes in ffmpeg, which makes it a pain when I've queued up a lot of things to encode over night.
I do most of my encoding on an i9-13900k. I've also noticed that h.265 seems to be quite a bit more likely to trigger the smt related crashes in ffmpeg, which makes it a pain when I've queued up a lot of things to encode over night.
What about when you’re recording (say your iPhone / android / standalone camera) - are you choosing h264 or h265 (or something else like an intra-frame only codec for easier editing).
Most of what I do is working with pre-recorded video, but for projects where I'm doing recording I tend to use h.264 since I don't have a lot of devices that support h.265 anyway, and picking one format with broad compatibility is generally more important to me than the efficiency gains I'd get using h.265 when I could.
Is GPU accelerated encoding not an option?
I haven't actually done the comparison myself, but the common refrain is that the quality of the video suffers when you use GPU accelerated encoding. That's not a tradeoff I want to make, so I've just stuck with CPU encoding.
Wait, why does GPU encoding affect the output quality? Is that common in transcoding stuff?
>why does GPU encoding affect the output quality
Every single encoder, regardless or hardware or software will output different output quality. Video Encoding is a lossy encoding, not lossless like ZIP or RAR. That is the same with Audio that is why people test different audio encoder. It seems more people knows this about Audio than Video. At least on HN.
GPU encoding quality has always been lower quality than Software. Primary because they trade off quality for speed. It is good enough once you hit certain bitrate, but at low bitrate where absolutely encoding efficiency is required Hardware Encoding just dont compare to software. Even with Software you could have multiple encoder with different results. It is not like H.266 / HEVC only has x266 as encoder, example Netflix uses BEAMR. And Broadcasting TV station uses other encoder that better suits their needs.
And it is one reason why I dislike all these AV1 discussion, whenever people said it is slow they said use SVT-AV1, well yes SVT-AV1 is faster but dont produce the best AV1 quality encode. So what is the point. It is like every time these discussions about AV1 AOM supporters will just move the goal post.
Every single encoder, regardless or hardware or software will output different output quality. Video Encoding is a lossy encoding, not lossless like ZIP or RAR. That is the same with Audio that is why people test different audio encoder. It seems more people knows this about Audio than Video. At least on HN.
GPU encoding quality has always been lower quality than Software. Primary because they trade off quality for speed. It is good enough once you hit certain bitrate, but at low bitrate where absolutely encoding efficiency is required Hardware Encoding just dont compare to software. Even with Software you could have multiple encoder with different results. It is not like H.266 / HEVC only has x266 as encoder, example Netflix uses BEAMR. And Broadcasting TV station uses other encoder that better suits their needs.
And it is one reason why I dislike all these AV1 discussion, whenever people said it is slow they said use SVT-AV1, well yes SVT-AV1 is faster but dont produce the best AV1 quality encode. So what is the point. It is like every time these discussions about AV1 AOM supporters will just move the goal post.
Do you blanketly refuse to encode with h.264 or h.265? Because they're always worse than the best AV1 encode too.
If you only use h.266 and you're willing to wait extreme amounts of time to encode, then that's valid, but understand that you're an outlier. Most people don't have that much time to spend on encoding.
If you only use h.266 and you're willing to wait extreme amounts of time to encode, then that's valid, but understand that you're an outlier. Most people don't have that much time to spend on encoding.
You don't need to find the best possible encoding. SVT-AV1 can encode as fast as x264, keeping the same visual quality to human eyes while reducing bit rate by 50%.
If you want to retain visual quality, you always have an option to use higher bit rate.
If you want to retain visual quality, you always have an option to use higher bit rate.
If we assume that to be true (VMAF and SSIM aren’t the whole picture), just keep in mind that’s only true at particular speeds, bitrates, and types of content.
What I should say is, please show me an AV1 encoder that can beat x264 in quality at a source-transparent encode of a 4K or 1080p Blu-ray film, if given ~3GB per hour of content and the encode had to run in at least 3x the runtime. I’d start using it! It may be there as of recently, it’s been a year or two since I looked.
This is a usecase where AV1 encoders and even x265 have had trouble.
What I should say is, please show me an AV1 encoder that can beat x264 in quality at a source-transparent encode of a 4K or 1080p Blu-ray film, if given ~3GB per hour of content and the encode had to run in at least 3x the runtime. I’d start using it! It may be there as of recently, it’s been a year or two since I looked.
This is a usecase where AV1 encoders and even x265 have had trouble.
Why does GPU need to trade off quality for speed? GPU is faster than CPU, that is the whole point of GPU encoding, isnt it?
Does it mean just that nVidia and AMD engineers done a poor job when implementing those encoders?
Does it mean just that nVidia and AMD engineers done a poor job when implementing those encoders?
No. Decoding is a job mostly done by specialized hardware - the shader units are used sometimes, before a fully fixed function implementation is ready. Encoding in particular doesn’t map well to GPUs. They can do it, using varying degrees of fixed function and shader cores, and it’s nice to isolate that load from the CPU, but they implement fewer of the analysis, prediction, and psychovisual optimization tricks that x264 and x265 use, and less of the optional features of the format. They often can beat software at specific, fast speeds with lower power consumption, but the trade-off is being inflexible and unuseful for making encodes that are transparent to the source.
I mean the thing with something like SVT-AV1 is, even if it doesn’t give you the best efficiency encode, does it do a more efficient encode than your alternatives in a reasonable timeframe.
GPU video encoding is pretty much always optimised for real-time encoding, meaning that it can't run certain optimisations as it would increase the time to encode.
Compare x264 veryfast and veryslow presets. There is a quality difference at the same bitrate.
Additionally, GPU encoders don't have as many psychovisual options as CPU encoders as they would need to be included in the hardware and adding extra options to CPU encoders is much faster, easier and cheaper.
You could build a non-realtime GPU encoder, but there is not much point.
Compare x264 veryfast and veryslow presets. There is a quality difference at the same bitrate.
Additionally, GPU encoders don't have as many psychovisual options as CPU encoders as they would need to be included in the hardware and adding extra options to CPU encoders is much faster, easier and cheaper.
You could build a non-realtime GPU encoder, but there is not much point.
There two types of GPU acceleration: acceleration by a hardware codec bolted on a GPU, and actual GPU computational acceleration. the latter is not widely used but probably is not n gonna have any difference in terms of quality, and provides only modest acceleration.
I really like HEVC/h265. It's pretty much on par with VP9. but licensing trouble has made it difficult to get adopted everywhere even now. VVC/h266 seems to be having the same issues; AV1 is pretty much just as good and already seeing much more adoption.
What’s the tldr of the licensing problems?
I’ve started reading this article which list the various H.26x proposals - https://en.m.wikipedia.org/wiki/Video_Coding_Experts_Group
Seems like the group that comes with these is eventually part of the UN ? https://en.m.wikipedia.org/wiki/International_Telecommunicat...
Is it because they come with the codecs “jointly” with the MPEG organization, which is for profit? If the group is part of a standards organization that’s part of the UN, I feel like they should come up with non-patent-encumbered “recommendations”.
I’ve started reading this article which list the various H.26x proposals - https://en.m.wikipedia.org/wiki/Video_Coding_Experts_Group
Seems like the group that comes with these is eventually part of the UN ? https://en.m.wikipedia.org/wiki/International_Telecommunicat...
Is it because they come with the codecs “jointly” with the MPEG organization, which is for profit? If the group is part of a standards organization that’s part of the UN, I feel like they should come up with non-patent-encumbered “recommendations”.
> What’s the tldr of the licensing problems?
There are multiple patent pools for H.265 wanting to be paid licensing fees (MPEG LA, HEVC Advance, Velos Media). HEVC Advance and Velos Media even want content distribution licensing fees.
And there are patent holders not in any pool who also want to be paid (Technicolor, Motorola, Nokia, etc.).
It's a mess.
There are multiple patent pools for H.265 wanting to be paid licensing fees (MPEG LA, HEVC Advance, Velos Media). HEVC Advance and Velos Media even want content distribution licensing fees.
And there are patent holders not in any pool who also want to be paid (Technicolor, Motorola, Nokia, etc.).
It's a mess.
>HEVC Advance and Velos Media even want content distribution licensing fees.
That is not correct. Unless you meant they once "suggested" to ask for content distribution licensing.
That is not correct. Unless you meant they once "suggested" to ask for content distribution licensing.
It's correct. It's category 4: https://accessadvance.com/topic-what-do-we-license/
Content distribution licensing fees implies and refers to streaming and broadcasting.
Physical Media has always been a seperate and its own category.
Physical Media has always been a seperate and its own category.
No, it doesn't. You were wrong. Just accept that and be happy.
Ok, I will bite
>>HEVC Advance and Velos Media even want content distribution licensing fees.
1. Are Broadcasting and Streaming "content distribution"?
2. Do HEVC Advance and Velos Media currently, or has ever charges for Broadcasting and Streaming?
And to quote: You were wrong. Just accept that and be happy.
>>HEVC Advance and Velos Media even want content distribution licensing fees.
1. Are Broadcasting and Streaming "content distribution"?
2. Do HEVC Advance and Velos Media currently, or has ever charges for Broadcasting and Streaming?
And to quote: You were wrong. Just accept that and be happy.
There's nothing to bite. You've been wrong before. You'll be wrong again.
LOL, You didn't even bother answering the question. I will let others be the judge. But it is rather obvious from your other reply about your knowledge on video codec.
Have a nice day.
Have a nice day.
Look, your claim is that selling movies on discs is not content distribution. But it clearly is.
You're just wrong. Don't worry about it.
You're just wrong. Don't worry about it.
iPhone, DJI, Cameras etc all use H.265 or RAW.
It's really like H.264 all over again where everyone claims the patent pools make a big difference but only on the periphery.
It's really like H.264 all over again where everyone claims the patent pools make a big difference but only on the periphery.
"Cameras all use H.265", curious , what cameras are you referring to?
While some cameras do support it, it's much more common to use ProRes, DNxHD/DNxHR or h264 in all-intra mode (as e.g. in XAVC-I and XAVC-S-I).
h265, or long-GOP codecs in general, are only really used for long talking head shots or lectures.
While some cameras do support it, it's much more common to use ProRes, DNxHD/DNxHR or h264 in all-intra mode (as e.g. in XAVC-I and XAVC-S-I).
h265, or long-GOP codecs in general, are only really used for long talking head shots or lectures.
How does being long-GOP affect the decision? (genuine question)
“Everyone” meaning the vocal minority of HN users trying to maintain the purity of their Gentoo installs.
Hey, someone needs to protect our precious binary fluids.
I've always felt like H.264 hit a great sweet spot of complexity vs compression. Newer codecs compress better, but they're increasingly complex in a nonlinear way.
Doesn't every state of the art codec do that, including H.264 versus previous?
Also I haven't seen charts of decode difficulty, but as far as encoding goes, codecs a generation more advanced can crush H.264 at any particular level of effort. The even newer codecs can probably get there too with more encoder work. https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Co...
Also I haven't seen charts of decode difficulty, but as far as encoding goes, codecs a generation more advanced can crush H.264 at any particular level of effort. The even newer codecs can probably get there too with more encoder work. https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Co...
Generally yes, but I wasn't only talking about compute costs. Mentally grokking H.264's features and inner workings is a lot easier than newer, better codecs.
H.264 will probably never die, especially once all the patents expire in a few years.
H.262 has a long future too. New DVDs and OTA broadcasts (at least for ATSC 1.0) will probably end at some point, but the discs won't go away for a long time, even if disc players are less and less popular.
…you mean MPEG2?
H.262 == MPEG-2 Part 2 Video == ISO/IEC 13818-2. Video codecs are fun because multiple standards bodies publish their own version of the same codec. The ITU-T publishes the H.26x specs, and ISO/IEC publish the other xxxxx-x specs.
Pesonally I like the ITU-T because you can get the specs for free from them. ISO/IEC demand $242 for a copy of ISO/IEC 23008-2 (also known as MPEG-H Part 2 or HEVC). But ITU-T will give you H.265's spec (which is the same codec as ISO/IEC 23008-2) for free: https://www.itu.int/rec/T-REC-H.265
Pesonally I like the ITU-T because you can get the specs for free from them. ISO/IEC demand $242 for a copy of ISO/IEC 23008-2 (also known as MPEG-H Part 2 or HEVC). But ITU-T will give you H.265's spec (which is the same codec as ISO/IEC 23008-2) for free: https://www.itu.int/rec/T-REC-H.265
This is true, but I think I settled on either VP8 or VP9 because it's already widely supported, and it's part of webm, so people will maintain support just for backwards compatibility.
When do they expire?
According to https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M..., probably September 2027.
There are an additional two patents on that list that expire in 2028 and 2030, but it's not clear if they apply. So probably November 2030 at the latest.
There are an additional two patents on that list that expire in 2028 and 2030, but it's not clear if they apply. So probably November 2030 at the latest.
It also benefits from the extremely optimized encoder x264, which has many easily approachable tunings and speed/compression presets.
I’m not sure I’d trust x265 to preserve film grain better than x264 —tune film unless I gave x265 much, much more time as well as pretty similar bitrate.
I’m not sure I’d trust x265 to preserve film grain better than x264 —tune film unless I gave x265 much, much more time as well as pretty similar bitrate.
x265 has a specific "--tune grain" mode specifically for video with a lot of film grain.
Apologies, I did miss that. However it seems to still underperform.
See this thread, screenshots on the first page.
http://forum.doom9.net/showthread.php?p=1947856#post1947856
I was remembering from this a couple years ago, but focused on the parameters shown and missed that they were derived from --tune grain.
See this thread, screenshots on the first page.
http://forum.doom9.net/showthread.php?p=1947856#post1947856
I was remembering from this a couple years ago, but focused on the parameters shown and missed that they were derived from --tune grain.
But with hardware acceleration for both encoding and decoding of HEVC it feels like less of a problem IMO.
Video piracy is pretty much all in HEVC
Uhh, not in my experience. Its extremely difficult to find h265 sources for a large majority of content. Its basically a meme where if you tell people you want to try and get h265 by default, they talk down to you like "why would you do that".
From https://trash-guides.info/Misc/x265-4k/
> Something like 95% of video files are x264 and have much better direct play support.
From https://trash-guides.info/Misc/x265-4k/
> Something like 95% of video files are x264 and have much better direct play support.
That info seems a little out of date. The utility of h.265 at resolutions below 1080p can be questionable, but everything these days is 1080p or 4k.
Hardware support has also been ubiquitous for a while now. iPhones have had it since 2016. I usually "move on" to the next codec for my encodes once I run out of hardware that doesn't support it, and that happened for me with h.265 in 2019. My iPad, laptop, and Shield TV are still holding me back from bothering with AV1. Though with how slow it is, I might stick with h.265 anyways.
Hardware support has also been ubiquitous for a while now. iPhones have had it since 2016. I usually "move on" to the next codec for my encodes once I run out of hardware that doesn't support it, and that happened for me with h.265 in 2019. My iPad, laptop, and Shield TV are still holding me back from bothering with AV1. Though with how slow it is, I might stick with h.265 anyways.
The guide isnt saying 95% of source content is h264. Its saying 95% of files you would download when pirating are h264. The scene, by and large, is transcoding h265 4k to h264 720/1080. The 4k h265 is available but its considered the 'premium' option.
The scene maybe, but outside of the scene and into general uploads I'd say it's more like 80% h265.
Most 1080p encodes I see on pirate bay are h.265 these days.
But frankly, most of what "the scene" produces it trash. I gave up on waiting for proper blu-rays for the remaining seasons of Bojack Horseman and pirated them a few weeks ago, and all the options were compromised. The best visual quality came from a set that was h.265 encoded with a reasonable average bitrate, yet the quality still did not reflect the bitrate at all, with obvious artifacting in fades and scenes with lots of motion. I usually get much better results at only slightly larger file sizes with my own blu-ray rips.
I'm pretty sure the key difference is that I go for a variable bitrate with a constant quality, whereas most scene groups want to hit an arbitrary file size for every episode regardless of whether or not that is feasible for the content. Every episode in this set is almost exactly 266 MB, whereas similar shows that I rip will vary anywhere from 200 to 350 MB per episode.
But frankly, most of what "the scene" produces it trash. I gave up on waiting for proper blu-rays for the remaining seasons of Bojack Horseman and pirated them a few weeks ago, and all the options were compromised. The best visual quality came from a set that was h.265 encoded with a reasonable average bitrate, yet the quality still did not reflect the bitrate at all, with obvious artifacting in fades and scenes with lots of motion. I usually get much better results at only slightly larger file sizes with my own blu-ray rips.
I'm pretty sure the key difference is that I go for a variable bitrate with a constant quality, whereas most scene groups want to hit an arbitrary file size for every episode regardless of whether or not that is feasible for the content. Every episode in this set is almost exactly 266 MB, whereas similar shows that I rip will vary anywhere from 200 to 350 MB per episode.
Yeah, tv shows are tough. I should caveat that I'm talking mostly about movies. I find a _lot_ more 265 content for tv shows. I also am generally on usenet rather than torrenting.
That makes sense, a 20-40% space savings means a lot more for 6 seasons of TV than it does for one 2-hour movie.
> Hardware support has also been ubiquitous for a while now.
With how limited browser support for h265 is, I always have to encode an h264 version anyway.
At that point I just encode a 720p h264, a 1080p h264, and a 4K HDR AV1 encode of all media I store.
With how limited browser support for h265 is, I always have to encode an h264 version anyway.
At that point I just encode a 720p h264, a 1080p h264, and a 4K HDR AV1 encode of all media I store.
That's on the browser vendors.
Google added HEVC support to Chrome in 104. It relies on decoders exposed by the host OS, negating the need to license a software decoder.
There's no reason Firefox couldn't do the same.
EDIT: Apparently, similar support showed up in nightly Firefox builds late last year, hidden behind `media.wmf.hevc.enabled`
Google added HEVC support to Chrome in 104. It relies on decoders exposed by the host OS, negating the need to license a software decoder.
There's no reason Firefox couldn't do the same.
EDIT: Apparently, similar support showed up in nightly Firefox builds late last year, hidden behind `media.wmf.hevc.enabled`
> There's no reason Firefox couldn't do the same.
> It relies on decoders exposed by the host OS, negating the need to license a software decoder.
Windows requires you to pay (!) to get access to h265 decoding. Someone needs to license the decoder at some point, and that means you'll have to pay for it one way or the other.
> It relies on decoders exposed by the host OS, negating the need to license a software decoder.
Windows requires you to pay (!) to get access to h265 decoding. Someone needs to license the decoder at some point, and that means you'll have to pay for it one way or the other.
But the GPU vendors already provide this directly (Nvidia, Intel, and AMD). It can absolutely be done at no extra cost to the user. There are also open source software decoders that can be installed and play nice with WMF.
> But the GPU vendors already provide this directly (Nvidia, Intel, and AMD). It can absolutely be done at no extra cost to the user. There are also open source software decoders that can be installed and play nice with WMF.
Somehow I doubt that Nouveau or the in-kernel AMDGPU have paid the license fee for HEVC decoding, or that it works well with WMF...
Somehow I doubt that Nouveau or the in-kernel AMDGPU have paid the license fee for HEVC decoding, or that it works well with WMF...
We're just whittling down to a smaller and smaller subset of users. 99.9% of users shouldn't be made to go without just because 0.1% of users can't have it.
Though even then, ffmpeg is open source and decodes hevc just fine. I get why browser vendors would not want to bundle ffmpeg, but that shouldn't stop them from leveraging it if the user already has it installed.
Though even then, ffmpeg is open source and decodes hevc just fine. I get why browser vendors would not want to bundle ffmpeg, but that shouldn't stop them from leveraging it if the user already has it installed.
> Uhh, not in my experience. Its extremely difficult to find h265 sources for a large majority of content.
Sounds like you need some new sources. For now content I generally see x264 and x265 for just about everything. 264 isn't going anywhere because many older design set top boxes (including those still running Kodi on Pi3s) don't have hardware decode support, but 265 has become the default for 4K (which older kit doesn't support anyway) with 1080 & 720 being commonly available in both.
Admittedly some of the 265 encodes are recompressions of larger 264 sources and sometimes bad settings in either encode (including just choosing an already overly crunched source) show through, but that isn't common enough to be problematical (my usual complaint is that encodes like that strip subs, though that is useful: avoiding 265 encodes with no subs avoids the other issues mostly too).
Few are going back and making 265 encodes for older sources, so that may be an issue you've faced, but if that content has a new BR release or other re-release (like when B5 got a slightly remastered version on one of the streamers) then you'll get both formats in the common resolutions.
Sounds like you need some new sources. For now content I generally see x264 and x265 for just about everything. 264 isn't going anywhere because many older design set top boxes (including those still running Kodi on Pi3s) don't have hardware decode support, but 265 has become the default for 4K (which older kit doesn't support anyway) with 1080 & 720 being commonly available in both.
Admittedly some of the 265 encodes are recompressions of larger 264 sources and sometimes bad settings in either encode (including just choosing an already overly crunched source) show through, but that isn't common enough to be problematical (my usual complaint is that encodes like that strip subs, though that is useful: avoiding 265 encodes with no subs avoids the other issues mostly too).
Few are going back and making 265 encodes for older sources, so that may be an issue you've faced, but if that content has a new BR release or other re-release (like when B5 got a slightly remastered version on one of the streamers) then you'll get both formats in the common resolutions.
That's not my experience at all.
I mean I've gone all 4K/HDR a number of years ago, and all streaming 4K and disc 4K is HEVC. So all the piracy content is WEB-DLs or UHD disc rips of that and it is often not re-converted, but even if it it tey still use HEVC.
H.264 is a fine codec, but it doesn't support HDR and also really starts to show its weakness in efficiency at 4K resolution. At 1080p SDR it fairs much better vs HEVC.
I mean I've gone all 4K/HDR a number of years ago, and all streaming 4K and disc 4K is HEVC. So all the piracy content is WEB-DLs or UHD disc rips of that and it is often not re-converted, but even if it it tey still use HEVC.
H.264 is a fine codec, but it doesn't support HDR and also really starts to show its weakness in efficiency at 4K resolution. At 1080p SDR it fairs much better vs HEVC.
I think the big switch will happen once most people have TV's that can do 10bit color and true HDR. H264 can definitely do 10 bit but I'm not sure how well it handles higher dynamic range content (or if it even can) but H265 definitely can.
I feel like the switch from AVC (h.264) to HEVC (h.265) has already happened. It's used in 4k blu rays, most premium streaming services, and hardware support has been ubiquitous for at least 6 years.
Not really. Only 4k content and anime seems to use HEVC/h265. Anything lower resolution has stuck to h264 for the time being.
But anything made in the last few or more years is 4K now and everything I watch is 4K, so all I find is HEVC stuff for everything.
Sure, if you are going to go get an older show that's pre 4K/HDR or a movie that isn't on UHD disc yet, then it will be H.264 of course.
But if you primarily watch newly made 4K/HDR content, it's all been HEVC for years now.
Sure, if you are going to go get an older show that's pre 4K/HDR or a movie that isn't on UHD disc yet, then it will be H.264 of course.
But if you primarily watch newly made 4K/HDR content, it's all been HEVC for years now.
Again, depends on your source content. Obviously 4k/HDR is H265. Plenty of shows are still 1080p source though even today. Not the 'flagship' shiny ones, but there's a lot more 1080p max source content. And for those, the proper format is H264, and still is what is released today.
FWIW IIRC yts.mx began offering H.265 on standard resolution films about a year or two back.
Yeah, and most people consider stuff off yts to be of poor quality. Encodes are bad and do not meet standards.
MPEG 5 EVC Baseline, arguably the improved / refined version of H.264, actually compress better while having the same complexity, Both in terms of mental model and computational cost.
Somewhat unfortunate that never became anything.
Somewhat unfortunate that never became anything.
Twitch...
I just had DiVX vs Xvid flashbacks
> Well OK, but what about H.265? It's one louder, isn't it?
I had some old, gigantic, video footage (in a variety of old, inefficient, formats at a super high quality).
So I did some testing and, well, ended up re-encoding/transcoding everything to H.265. It makes for much smaller files than H.264. The standard is also ten years younger than H.264 (2013 for H.265 vs 2003 for H.264).
I had some old, gigantic, video footage (in a variety of old, inefficient, formats at a super high quality).
So I did some testing and, well, ended up re-encoding/transcoding everything to H.265. It makes for much smaller files than H.264. The standard is also ten years younger than H.264 (2013 for H.265 vs 2003 for H.264).
Years ago I was photographing a party in silicon valley (had just graduated college and was taking any job I could get). I take a nice photo of a couple and the wife looks at me and says " You know my husband invented H264? Do you know what that is?".
Ended up having a long conversation with the husband (the engineer) and he hinted many times that they were working currently on something even better. Years later now of course we have H265. Everytime I play something in H264 or H265 I think of that moment and how much work that guy and his colleagues must have put into coding such a widely used codec (and how proud his wife was!)
Ended up having a long conversation with the husband (the engineer) and he hinted many times that they were working currently on something even better. Years later now of course we have H265. Everytime I play something in H264 or H265 I think of that moment and how much work that guy and his colleagues must have put into coding such a widely used codec (and how proud his wife was!)
She should say "helped to invent". Video codec standard development is most definitely a group effort.
You worked on MPEG?
Yes, from 1993 until I retired in 2011. I worked at C-Cube Microsystems and LSI Logic.
In 1993-1994 at C-Cube, I helped develop the first real-time MPEG-1 encoder. The rest of the team was busy developing the 704x480 resolution encoder for the roll-out of DirecTV, so I ended up taking sole responsibility for the MPEG-1 product and brought it to market. It's thought that this encoder authored much of the content for China VCD.
One notable thing I remember was watching the OJ Simpson chase on a test DirecTV receiver in the C-Cube lab (the same day that DirecTV went live).
Here's a picture of the C-Cube chip. It took 12 of these running in parallel to encode 704x480 MPEG-2.
https://www.w6rz.net/cl4010.png
In 1993-1994 at C-Cube, I helped develop the first real-time MPEG-1 encoder. The rest of the team was busy developing the 704x480 resolution encoder for the roll-out of DirecTV, so I ended up taking sole responsibility for the MPEG-1 product and brought it to market. It's thought that this encoder authored much of the content for China VCD.
One notable thing I remember was watching the OJ Simpson chase on a test DirecTV receiver in the C-Cube lab (the same day that DirecTV went live).
Here's a picture of the C-Cube chip. It took 12 of these running in parallel to encode 704x480 MPEG-2.
https://www.w6rz.net/cl4010.png
That’s really cool, thanks for sharing!
What about VVC (H.266)?
https://en.wikipedia.org/wiki/Versatile_Video_Coding
https://en.wikipedia.org/wiki/Versatile_Video_Coding
VVC has a lot of the same issues that plagued HEVC adoption. There really isn't much reason to not use AV1 if you want the best codec currently.
VVC is a generational improvement in compression ratio over AV1, which might make it the best for a lot of applications. Too bad it will probably languish in patent licensing hell.
> VVC is a generational improvement in compression ratio over AV1
That's probably true, but do you know where I could find a comparison that shows a variety of speed settings for both codecs? And ideally discusses how fast VVC is expected to encode once everything is more finalized.
It's easy enough to run everything at default speed but then the results are almost meaningless.
That's probably true, but do you know where I could find a comparison that shows a variety of speed settings for both codecs? And ideally discusses how fast VVC is expected to encode once everything is more finalized.
It's easy enough to run everything at default speed but then the results are almost meaningless.
It's always really slow at the start, but once hardware acceleration happens it becomes much less of a problem.
Or if you are just an end user consuming streaming video content, then you only care that your player can decode it which I don't think will be any sort of problem if things play out like they did for HEVC vs VP9.
If all the streaming services choose VVC over AV1, then all the player companies will put hardware decoders in their SoC.
Or if you are just an end user consuming streaming video content, then you only care that your player can decode it which I don't think will be any sort of problem if things play out like they did for HEVC vs VP9.
If all the streaming services choose VVC over AV1, then all the player companies will put hardware decoders in their SoC.
Well people definitely had complaints about HEVC compared to H.264 and VP9, but it seems that HEVC did perfectly fine.
I deal with a lot of video and HEVC is by and far the most used codec that I see.
I am not sure why AV1 vs VVC will go any differently.
Just like HEVC was about a generation better than VP9, VVC is about a generation better than AV1.
I guess it depends on what streaming companies choose. Since they all chose HEVC, all the cheap player chips in TVs and boxes and sticks all have HEVC hardware decode. Even though YouTube chose VP9, it didn't really seem to make a difference in the grand scheme of things.
YouTube chose AV1 of course, but if all the streaming companies go VVC, well then I think it will proliferate similarly to HEVC.
I deal with a lot of video and HEVC is by and far the most used codec that I see.
I am not sure why AV1 vs VVC will go any differently.
Just like HEVC was about a generation better than VP9, VVC is about a generation better than AV1.
I guess it depends on what streaming companies choose. Since they all chose HEVC, all the cheap player chips in TVs and boxes and sticks all have HEVC hardware decode. Even though YouTube chose VP9, it didn't really seem to make a difference in the grand scheme of things.
YouTube chose AV1 of course, but if all the streaming companies go VVC, well then I think it will proliferate similarly to HEVC.
Unless you need hardware acceleration. I’ve managed to implement live h265 encode and decode with Directx12 on Windows on Intel and Nvidia, but the driver crashes on AMD and they seem uninterested in fixing it, so there I have to fallback to h264.
Well, it’s two louder, obviously.
Best in terms of compression efficiency. Although x266 has been delayed by 6 months and counting.
But it is currently being used in India and China already. So its usage is much bigger than a lot of people would imagine.
But it is currently being used in India and China already. So its usage is much bigger than a lot of people would imagine.
Have you experimented with it much? First I am hearing of it
HEVC and AV1 is twice more magic. It keep the same quality to human eyes while reducing the bitrate by 50%.
HEVC is patent encumbered. Users who use old hardware don't have hardware decoder. So both requires more time to be adopted.
HEVC is patent encumbered. Users who use old hardware don't have hardware decoder. So both requires more time to be adopted.
Maybe I need to change some options, but I find whatever encoder I get when I ask ffmpeg to encode h265 takes a very long time. Then decoding 4k h265 is very slow on most of my PCs.
It sure gets the file size down though.
It sure gets the file size down though.
> Suppose you have some strange coin - you've tossed it 10 times, and every time it lands on heads. How would you describe this information to someone? You wouldn't say HHHHHHHHH. You would just say "10 tosses, all heads" - bam! You've just compressed some data!
There appears to be some lossy compression on that string of "H"s.
There appears to be some lossy compression on that string of "H"s.
Also, it's not really compression because "10 tosses, all heads" is more characters.
Try saying each of those though.
They're just jokingly noting that the string of H's is only 9 letters long, not 10.
Yeah I get it, but it's ten utterances vs four.
I remember when h264 appeared.
At that time, I was obsessed with mplayer and would download and build the latest releases on a regular basis. The first time I got an h264 file, mplayer wouldn’t read it so I had to get the dev version and build it.
It worked, and I realized two things : the quality was incredible, and my athlon 1800+ couldn’t cope with it. Subsequent mplayer versions ( or libavcodec ?) vastly improved performance, but I still remember that day.
At that time, I was obsessed with mplayer and would download and build the latest releases on a regular basis. The first time I got an h264 file, mplayer wouldn’t read it so I had to get the dev version and build it.
It worked, and I realized two things : the quality was incredible, and my athlon 1800+ couldn’t cope with it. Subsequent mplayer versions ( or libavcodec ?) vastly improved performance, but I still remember that day.
Yep. Same here. Man, I have not used mplayer in a very long time. But, it was the bee's knees.
I used to work for a company that was developing some video based products. And this other company in Vegas sold our bosses a "revolutionary video codec" and a player. We had to sign NDAs to use it.
I used it and observed that it worked like mplayer. Too much like it. 5 more minutes of investigation and the jig was up. Our execs who paid a lot of money to the Vegas company had an egg on their face.
It is shockingly easy to scam non-tech decisions makers in the tech field. They are too worried about being left behind. Smart ones will pull in a "good" engineer for evaluation. Dunning Kruger subjects will line up with their wallets out.
I used to work for a company that was developing some video based products. And this other company in Vegas sold our bosses a "revolutionary video codec" and a player. We had to sign NDAs to use it.
I used it and observed that it worked like mplayer. Too much like it. 5 more minutes of investigation and the jig was up. Our execs who paid a lot of money to the Vegas company had an egg on their face.
It is shockingly easy to scam non-tech decisions makers in the tech field. They are too worried about being left behind. Smart ones will pull in a "good" engineer for evaluation. Dunning Kruger subjects will line up with their wallets out.
Story time.
Back in 1999, I was leaving a startup that had been acquired, but I didn't want to stick around. I had been doing in mpeg encoding; this is relevant later.
One of the companies I interviewed with had come up with a new video compression scheme. They were very tight lipped but after signing NDA paperwork, they showed me some short clips they had encoded/decoded via a non-realtime software codec. I was interviewing to create an ASIC version of the algorithm. Even seeing just a minute or two of their codec output, I guessed what they were doing. I suggested that their examples were playing to the strengths of their algorithm and suggested some scenarios that would be more challenging. I also described what I thought they were doing. They neither confirmed nor denied, but they had me come back for a second round.
In the second round I talked with the founders, a husband/wife CEO/CTO (IIRC) team. That is when I learned their plan wasn't to sell ASICs, but they wanted to keep their codec secret and instead create DSL-based cable network using the ASICs for video distribution. I said something like, it sounds like you have invented a better carburetor and instead of selling carburetors you are planning on building a car factory to compete with GM. It was cheeky, and they didn't take it well.
Getting to the point of how this story relates to H.264, their claim was: conventional compression has reached the limit, and so their codec would allow them to do something nobody else can do: send high-def video over DSL lines. I replied: I think compressors will continue to get better, and even if not, higher speed internet service will eventually come to houses and remove the particular threshhold they think only they can cross. Oh, no, they replied, physics dictates the speed bits can be sent on a wire and we are at that limit.
I didn't get (and didn't want) a job offer. The company did get some VC money but folded a few years later, much more efficient codecs were developed by others, and 2 Mbps internet connections were not a limit. I'm sure the actual algorithm (which I describe later at a high level) had a lot of clever math and algorithmic muscle to make it work -- they weren't stupid technically, just stupid from a business sense.
This retelling makes me sound like a smug know-it-all, but it is one of two times in my life where I looked at something and in seconds figured out their secret sauce. There are far more examples where I am an idiot.
What was their algorithm? They never confirmed it, but based on silhouette artifacts, it seemed pretty clear what they were doing. MPEG (like jpeg) works by compressing images in small blocks (8x8, 16x16, and a few others). That limits how much spatial redundancy can be used to compress the image, but it also limits the computational costs of finding that redundancy. Their codec was similar to what Microsoft had proposed for their Talisman graphics architecture in the late 90s.
From what I could tell, they would analyze a sequence of frames and rather than segmenting the image into fixed blocks like mpeg, they would find regions with semi-arbitrary boundaries that were structurally coherent -- eg, if the scene was a tennis match, they could tell that the background was pretty "rigid" -- if a pixel appeared to move (the camera panned) then the nearby pixels were highly likely to make the same spatial transformation. Although each player changed frame to frame, that blob had some kind of correlation in lighting and position. Once identified, they would isolate a given region and compress that image using whatever (probably similar to jpeg). In subsequent frames they'd analyze the affine (or perhaps more general) transformation from a region from one frame to the next, then encode that transformation via a few parameters. That would be the basis of the next frame prediction, and if done well, not many bits need to be sent to fix up the misprediction errors.
Back in 1999, I was leaving a startup that had been acquired, but I didn't want to stick around. I had been doing in mpeg encoding; this is relevant later.
One of the companies I interviewed with had come up with a new video compression scheme. They were very tight lipped but after signing NDA paperwork, they showed me some short clips they had encoded/decoded via a non-realtime software codec. I was interviewing to create an ASIC version of the algorithm. Even seeing just a minute or two of their codec output, I guessed what they were doing. I suggested that their examples were playing to the strengths of their algorithm and suggested some scenarios that would be more challenging. I also described what I thought they were doing. They neither confirmed nor denied, but they had me come back for a second round.
In the second round I talked with the founders, a husband/wife CEO/CTO (IIRC) team. That is when I learned their plan wasn't to sell ASICs, but they wanted to keep their codec secret and instead create DSL-based cable network using the ASICs for video distribution. I said something like, it sounds like you have invented a better carburetor and instead of selling carburetors you are planning on building a car factory to compete with GM. It was cheeky, and they didn't take it well.
Getting to the point of how this story relates to H.264, their claim was: conventional compression has reached the limit, and so their codec would allow them to do something nobody else can do: send high-def video over DSL lines. I replied: I think compressors will continue to get better, and even if not, higher speed internet service will eventually come to houses and remove the particular threshhold they think only they can cross. Oh, no, they replied, physics dictates the speed bits can be sent on a wire and we are at that limit.
I didn't get (and didn't want) a job offer. The company did get some VC money but folded a few years later, much more efficient codecs were developed by others, and 2 Mbps internet connections were not a limit. I'm sure the actual algorithm (which I describe later at a high level) had a lot of clever math and algorithmic muscle to make it work -- they weren't stupid technically, just stupid from a business sense.
This retelling makes me sound like a smug know-it-all, but it is one of two times in my life where I looked at something and in seconds figured out their secret sauce. There are far more examples where I am an idiot.
What was their algorithm? They never confirmed it, but based on silhouette artifacts, it seemed pretty clear what they were doing. MPEG (like jpeg) works by compressing images in small blocks (8x8, 16x16, and a few others). That limits how much spatial redundancy can be used to compress the image, but it also limits the computational costs of finding that redundancy. Their codec was similar to what Microsoft had proposed for their Talisman graphics architecture in the late 90s.
From what I could tell, they would analyze a sequence of frames and rather than segmenting the image into fixed blocks like mpeg, they would find regions with semi-arbitrary boundaries that were structurally coherent -- eg, if the scene was a tennis match, they could tell that the background was pretty "rigid" -- if a pixel appeared to move (the camera panned) then the nearby pixels were highly likely to make the same spatial transformation. Although each player changed frame to frame, that blob had some kind of correlation in lighting and position. Once identified, they would isolate a given region and compress that image using whatever (probably similar to jpeg). In subsequent frames they'd analyze the affine (or perhaps more general) transformation from a region from one frame to the next, then encode that transformation via a few parameters. That would be the basis of the next frame prediction, and if done well, not many bits need to be sent to fix up the misprediction errors.
I couldn't remember the name of the company, nor the founders, but google found it for me:
https://www.zdnet.com/article/high-hopes-for-video-compressi...
It says they raised $32M from VCs, came out of stealth mode in 2002. I was unable to find what happened after that.
https://www.zdnet.com/article/high-hopes-for-video-compressi...
It says they raised $32M from VCs, came out of stealth mode in 2002. I was unable to find what happened after that.
I'm always amused when I read an article from years ago that uses perfectly-fine-but-quaint terminology:
> ...that hope to deliver broadcast quality programming over the Internet--the holy grail for nascent video-on-demand (VOD) services
What year did we all suddenly stop using the term "video-on-demand" and start saying "streaming"? I don't remember it happening, but obviously it did.
Well at least "broadcast quality" still means the same thing. An ancient antenna on my roof can still kick Youtube's ass when it comes to clarity and resolution.
> ...that hope to deliver broadcast quality programming over the Internet--the holy grail for nascent video-on-demand (VOD) services
What year did we all suddenly stop using the term "video-on-demand" and start saying "streaming"? I don't remember it happening, but obviously it did.
Well at least "broadcast quality" still means the same thing. An ancient antenna on my roof can still kick Youtube's ass when it comes to clarity and resolution.
> What year did we all suddenly stop using the term "video-on-demand" and start saying "streaming"?
"VOD" is still used pretty frequently in some contexts to distinguish between live and prerecorded video. It's common parlance on Twitch, for example.
> An ancient antenna on my roof can still kick Youtube's ass when it comes to clarity and resolution.
How so? ATSC is MPEG-2 at an absolute maximum of ~18 Mbps - and most broadcasters cut it down much lower than that to add subchannels. It doesn't support 1080p60 video at all, only 1080p30 or 720p60. Youtube routinely uses higher resolutions and bitrates, as well as newer codecs (H.264 at the oldest).
"VOD" is still used pretty frequently in some contexts to distinguish between live and prerecorded video. It's common parlance on Twitch, for example.
> An ancient antenna on my roof can still kick Youtube's ass when it comes to clarity and resolution.
How so? ATSC is MPEG-2 at an absolute maximum of ~18 Mbps - and most broadcasters cut it down much lower than that to add subchannels. It doesn't support 1080p60 video at all, only 1080p30 or 720p60. Youtube routinely uses higher resolutions and bitrates, as well as newer codecs (H.264 at the oldest).
The grandparent poster may be talking about ATSC 3.0 which has been rolling out for a while. H.265 at a reported 28-36Mbps is nothing to sneeze at!
YouTube recommends encoding master files for 1080p30 at 8 Mbps.
BluRay tends to encode 1080p30 at 50 Mbps
ATSC using 18 Mbps for 1080p30 is quite a lot in comparison.
BluRay tends to encode 1080p30 at 50 Mbps
ATSC using 18 Mbps for 1080p30 is quite a lot in comparison.
Sounds like they are doing drugs now
https://www.verseon.com
https://www.verseon.com
> they weren't stupid technically, just stupid from a business sense
I wouldn’t call them “stupid technically”, but assuming that there was a hard limit to codec efficiency and to internet bandwidth would at least make them technically naive in my opinion.
I wouldn’t call them “stupid technically”, but assuming that there was a hard limit to codec efficiency and to internet bandwidth would at least make them technically naive in my opinion.
These stories are a big part of what I love in HN. Thank you.
Thx for telling
This is very cool but the use of the terms "Information Entropy" together as if they were a separate thing is maybe the furthest that any "ATM-machine"-type phrase has rustled my jimmies.
It is a cool article, just, wowzers, what a phrase.
It is a cool article, just, wowzers, what a phrase.
To be fair I think information entropy is more self descriptive than Shannon entropy
Corporate has asked you to find the differences between these two pictures.
They're two names which references the same concept, but Shannon entropy is not the only type of entropy. I mean maybe everything really is just Shannon entropy if you look deep enough and have a sufficiently powerful model of physics but we're not there today.
I'm meaning the term "information entropy". Both of those words are generally used interchangeably to mean the same thing (to include the different forms of entropy, as I understand it. :')))) ) <3 :'))))
Oh, no I was talking about ex https://en.m.wikipedia.org/wiki/Entropy_(classical_thermodyn...
There's other kinds of 'entropy' that have distinct lineages and contexts than 'information entropy', but information is kind of the basis for everything physically so if you squint a bit you can make any non-information entropy look like information entropy
There's other kinds of 'entropy' that have distinct lineages and contexts than 'information entropy', but information is kind of the basis for everything physically so if you squint a bit you can make any non-information entropy look like information entropy
Yes that's where the term came from. They're (effectively) the same thing as I understand it.
I mean, it's obviously not relevant here, but technically there is also heat entropy, isn't there? It's not always information.
in 02016 it was patented magic in many countries. now the patents have all expired, or will in a few months, since the standard was released in august 02004 after a year of public standardization work, patents only last 20 years from filing, and you can't file a patent on something that's already public (except that, in the usa, there's a one-year grace period if you're the one that published it). if there are any exceptions, i'd be very interested to hear of them
userbinator points at https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264..., but most of the patents there have a precedence date after the h.264 standard was finalized, and therefore can't be necessary to implement h.264 itself (unless the argument is that, at the time it was standardized, it was not known to be implementable, a rather implausible argument)
what's surprising is that the last 20 years have produced a few things that are arguably a little better, but nothing that's much better, at least according to my tests of the implementations in ffmpeg
it seems likely that its guaranteed patent-free status will entrench it as the standard codec for the foreseeable future, for better or worse. av1 has slightly better visual quality at the same bandwidth, but is much slower (possibly this is fixable by a darktangent), but it's vulnerable to patents filed by criminals as late as 02018
userbinator points at https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H.264..., but most of the patents there have a precedence date after the h.264 standard was finalized, and therefore can't be necessary to implement h.264 itself (unless the argument is that, at the time it was standardized, it was not known to be implementable, a rather implausible argument)
what's surprising is that the last 20 years have produced a few things that are arguably a little better, but nothing that's much better, at least according to my tests of the implementations in ffmpeg
it seems likely that its guaranteed patent-free status will entrench it as the standard codec for the foreseeable future, for better or worse. av1 has slightly better visual quality at the same bandwidth, but is much slower (possibly this is fixable by a darktangent), but it's vulnerable to patents filed by criminals as late as 02018
but it's vulnerable to patents filed by criminals as late as 02018
Ah, if we get through year 2038 we get latent free AV1!
Ah, if we get through year 2038 we get latent free AV1!
why do you put an extra zero in front of the year?
He’s a time traveler from 38056
Because he's a true believer in the Long Now religion. But not enough of a true believer that he uses six or seven digits ;-)
Also, he uses that (and no capital letters) as a "bozo filter" - anyone who replies about that rather than the substance of the comment, he defines as someone he doesn't want to talk to anyway.
Personally, I think it's rather an obnoxious move. He's deliberately derailing discussion about the content, and he has decent content. But he insists on playing this game instead of just talking about the substance.
Also, he uses that (and no capital letters) as a "bozo filter" - anyone who replies about that rather than the substance of the comment, he defines as someone he doesn't want to talk to anyway.
Personally, I think it's rather an obnoxious move. He's deliberately derailing discussion about the content, and he has decent content. But he insists on playing this game instead of just talking about the substance.
it's a little bit like wearing a mohawk or a short skirt. a certain kind of people reveal what kind of people they are by harassing the mohawk-wearer and blaming the target for it. nobody is going to read this thread and be dumb enough to say, 'oh, yes, clearly, the person who was derailing discussion about the patent status of h.264 and the future of video codecs, in order to advocate the far more important topic of proper capitalization, was someone other than animalmuppet'
(i recommend you knock it off)
but yeah, the main benefit is that it gets people to read about the long now foundation
(i recommend you knock it off)
but yeah, the main benefit is that it gets people to read about the long now foundation
1. Fine. You didn't derail the discussion; you just deliberately opened a tempting door for it to be derailed. As a "bozo filter". Is that better?
2. The person who derailed the conversation was 293984j29384.
3. It's AnimalMuppet, not animalmuppet.
4. Why do I care? I think about that scene in Chariots Of Fire where the track coach is talking to a sprinter, and explaining that is starting steps are too far apart. As he explains what it's like, he says "It knocks you back" and slaps him lightly in the face. The runner rocks back slightly. "Knocks you back" and slaps him lightly. He does this four times. Then he says, "You see?"
That's what you're doing to your readers with your dates and your lack of proper capitalization. Sure, they can read it. But it costs them a small amount of unnecessary effort to parse it. Does it matter? As the track coach said, "I can get you another two yards." Two yards isn't much, in a 100 yard race, but it's enough to matter. (And posts are read more often than they are written. It's a small matter for each reader, but if 10 people read it, or 100, it adds up.)
Look, if you want to do that in a blog, that's fine. You do you. I won't care. But I care about HN, and I care about you making it a worse experience for people. I wish you would stop doing so.
2. The person who derailed the conversation was 293984j29384.
3. It's AnimalMuppet, not animalmuppet.
4. Why do I care? I think about that scene in Chariots Of Fire where the track coach is talking to a sprinter, and explaining that is starting steps are too far apart. As he explains what it's like, he says "It knocks you back" and slaps him lightly in the face. The runner rocks back slightly. "Knocks you back" and slaps him lightly. He does this four times. Then he says, "You see?"
That's what you're doing to your readers with your dates and your lack of proper capitalization. Sure, they can read it. But it costs them a small amount of unnecessary effort to parse it. Does it matter? As the track coach said, "I can get you another two yards." Two yards isn't much, in a 100 yard race, but it's enough to matter. (And posts are read more often than they are written. It's a small matter for each reader, but if 10 people read it, or 100, it adds up.)
Look, if you want to do that in a blog, that's fine. You do you. I won't care. But I care about HN, and I care about you making it a worse experience for people. I wish you would stop doing so.
so much projection
293984j29384 asked a perfectly reasonable question; they are blameless. you're the one who chose to start heckling the people who are actually talking about interesting things, attempting to harass them into formatting their comments more to your personal liking. that's what makes hn a worse experience for people
and if you think you're enforcing some kind of community standards by doing so, i have bad news for you
293984j29384 asked a perfectly reasonable question; they are blameless. you're the one who chose to start heckling the people who are actually talking about interesting things, attempting to harass them into formatting their comments more to your personal liking. that's what makes hn a worse experience for people
and if you think you're enforcing some kind of community standards by doing so, i have bad news for you
Yep, 02016 = 1038
> Because you've asked the decoder to jump to some arbitrary frame, the decoder has to redo all the calculations - starting from the nearest I-frames and adding up the motion vector deltas to the frame you're on - and this is computationally expensive, and hence the brief pause.
That was 2016. Today, it's because Youtube knows you're on Firefox.
That was 2016. Today, it's because Youtube knows you're on Firefox.
My favorite part of these codecs is how the discrete cosine transform plays so well together with quantization, zig-zag scanning and entropy coding.
The core of any lossy visual compressor is approximately the same theme. Those I-frames are essentially jpegs.
The core of any lossy visual compressor is approximately the same theme. Those I-frames are essentially jpegs.
Lossy compression is possible in PNG to a certain degree. This is the "same PNG", but 94 kB instead of 1015 kB:
1015 kB: https://sidbala.com/content/images/2016/11/outputFrame.png
94 kB: https://www.photopea.com/keynote.png
1015 kB: https://sidbala.com/content/images/2016/11/outputFrame.png
94 kB: https://www.photopea.com/keynote.png
(What's happening here is a reduction of the color count: https://en.wikipedia.org/wiki/Color_quantization)
Thats not PNG being lossy, the image was preprocessed to lose information by reducing color count before being compressed with PNG.
That is what a "lossy compression" means. Instead of encoding the original image, you look for a similar image, that can be losslessly encoded into a smaller file.
In PNG, you look for an image with 100 - 200 colors (so that colors repeat more often) and losslessly encode it with DEFLATE.
In JPG, you look for an image with with a reduced description through DCT, and losslessly encode it with Huffmann trees.
In PNG, you look for an image with 100 - 200 colors (so that colors repeat more often) and losslessly encode it with DEFLATE.
In JPG, you look for an image with with a reduced description through DCT, and losslessly encode it with Huffmann trees.
No thats image preprocessing to lose information before compression. JPG would be smaller if color count was reduced as well.
If color quantization using a specific algorithm was part of PNG you could say its lossy compression, its not, PNG is not lossy compression by any definition. Your specific image processing pipeline might be lossy, based on various tools you ran the image through or equipment used to capture, PNG is not.
If color quantization using a specific algorithm was part of PNG you could say its lossy compression, its not, PNG is not lossy compression by any definition. Your specific image processing pipeline might be lossy, based on various tools you ran the image through or equipment used to capture, PNG is not.
V-Nova has developed a very interesting video compression algorithm, now in use at some major media companies [0]. It is software but it will also be built-in in certain hardware for Smart TVs, etc.
Disclosure: I'm an investor.
[0]: https://www.v-nova.com/
Disclosure: I'm an investor.
[0]: https://www.v-nova.com/
>>V-Nova’s 1000 patents: not size that matters, but how you use it
Oh no, not again....
Oh no, not again....
One of my surprises when I started to investigate video encoders was that, because the details in a scene comes at the high frequency, you can drop the bandwith requirements on the fly, by just not sending the details for a frame.
I think VVC is even better, MXPlayer streaming already has shows streaming in VVC in India! I dont know how they're doing it but its live. VVC is supposedly 20-30% more efficient than av1
To nitpick, comparing with PNG is misleading, because it's comparing a lossless format with lossy. a JPEG would be around the same size has H.264.
Lossy compression is possible in PNG to a certain degree. This is the "same PNG", but 94 kB instead of 1015 kB:
1015 kB: https://sidbala.com/content/images/2016/11/outputFrame.png
94 kB: https://www.photopea.com/keynote.png
1015 kB: https://sidbala.com/content/images/2016/11/outputFrame.png
94 kB: https://www.photopea.com/keynote.png
PNG is not lossy, your example uses a preprocessor to quantize colors before being compressed with PNG.
PNG loss no information from the image being fed to it, the loss was done before creating a simpler image.
PNG loss no information from the image being fed to it, the loss was done before creating a simpler image.
I know that the "lossines" is not included in PNG encoders, as it is in JPG / WEBP encoders. But the idea is the same: if you are ready to "accept some loss" (by reducing the number of colors in this case), you can get a much smaller PNG file.
You can get a smaller uncompressed bitmap by reducing color count too reducing bits per pixel, that does not mean bmp is a lossy compression scheme. Color quantization will reduce the final size of the image in nearly all image formats jpg/webp would benefit as well.
You could have an artist or AI render the picture as a cartoon and png will highly compress it more than the original that does not mean PNG is a lossy compression scheme.
You could take a photo with a low resolution camera and it will be smaller than a higher resolution one after PNG compression, again nothing to do with PNG.
It is no surprise simpler images with less information compress better with lossless formats than more complex ones.
Your example implies that the PNG format itself has a lossy mode, when instead its just the way the image is preprocessed which has no limit on techniques that can lose information to make the image smaller independent of the codec.
You could have an artist or AI render the picture as a cartoon and png will highly compress it more than the original that does not mean PNG is a lossy compression scheme.
You could take a photo with a low resolution camera and it will be smaller than a higher resolution one after PNG compression, again nothing to do with PNG.
It is no surprise simpler images with less information compress better with lossless formats than more complex ones.
Your example implies that the PNG format itself has a lossy mode, when instead its just the way the image is preprocessed which has no limit on techniques that can lose information to make the image smaller independent of the codec.
You can have a PNG and JPG versoin of the original image without no loss, and the files would be about the same size.
You can have a PNG and JPG version of the original image, with the same loss - "average error per pixel", and the files would be about the same size.
I know there is no lossy compression described in a PNG standard. But there exist programs which produce tiny PNG files with a loss. So comparing an MP4 encoder with a bult-in loss to a PNG encoder without any built-in loss is not fair. They should have made the MP4 encoder encode the video in a lossless way, just like they did with PNG.
You can have a PNG and JPG version of the original image, with the same loss - "average error per pixel", and the files would be about the same size.
I know there is no lossy compression described in a PNG standard. But there exist programs which produce tiny PNG files with a loss. So comparing an MP4 encoder with a bult-in loss to a PNG encoder without any built-in loss is not fair. They should have made the MP4 encoder encode the video in a lossless way, just like they did with PNG.
it's not misleading, but leading - to the concept of lossy compression
Yeah that jumped out at me as well. It's a really unfair comparison.
It's not supposed to be a "fair" comparison, it's just an observation. You already understand where the difference comes from. The article goes into some detail to explain it to a person who doesn't.
The actual point of that example isn't even about lossy vs lossless anyway, it's about how 300 frames can take up nearly the space as one frame (interframe compression).
The actual point of that example isn't even about lossy vs lossless anyway, it's about how 300 frames can take up nearly the space as one frame (interframe compression).
If it's magic, it's spells have been greatly disenchanted. It's like gandolf.
For their use case Meta is gradually getting to a baseline of VP9 and AV1 streams for their video streaming: https://www.streamingmedia.com/Producer/Articles/Editorial/F...
And AV1 for video calls: https://engineering.fb.com/2024/03/20/video-engineering/mobi...
Microsoft is starting to use AV1 in Teams. AV1 has video coding tools that are particularly useful for screen sharing: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/...
Most of the video I see on YouTube these days is in VP9 or AV1. Occasionally some video is still H.264.
H.264 will still be around for quite some time, but AV1 looks set to become the new baseline for internet video.