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.

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.

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

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

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.

The real problem with AV1 is how darn computationally intensive it is to compress.

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

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)

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.

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

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.

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.

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.

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.

What matters is the bitrate, and they're being overly stingy on bitrate.

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.

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.

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.

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.

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 want to retain visual quality, you always have an option to use higher bit rate.

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

That is not correct. Unless you meant they once "suggested" to ask for content distribution licensing.

Physical Media has always been a seperate and its own category.

Have a nice day.

1. No where did I make the claim selling movies on discs is not content distribution. It is however NOT ALL content distribution, which is what you implied. And Physical Media licensing has been is own category since MPEG2 as used in DVD.

2. You claim of content distribution does not include Streaming and Broadcasting. Which has been the debate of the HEVC / H,266 licensing programme during its early stage of IP Negotiation terms. If you dont know H.265's history on patent terms then my suggestion is that you read up on it. As it is often the FUD pointed towards H.265. And you are, knowing or not, repeating it.

3. >You're just wrong. Don't worry about it.

This is HN. Not Reddit. If you dont know something, ask. Stop pretending you know something that you dont.

There is no uncertainty or doubt. The licensing of H.265 is well understood to be terrible.

You yourself are the perfect demonstration of this. You plainly don't know the terms of the licensing for all the different patent pools and individual licensors, and you've contradicted yourself multiple times in this thread. Let's review:

1. First you claimed there were no content distribution fees. That's false.

2. Next you claimed that "content distribution" only refers to streaming and broadcasting. That's false.

3. Then you claimed that "content distribution" does indeed include selling movies on discs. That's true and it means we're back at Claim 1.

Watching you flail about trying to save face is pretty funny, but more importantly it is the clear demonstration that you don't understand the terms of H.265 licensing which is, of course, why the licensing is so terrible.

One of the reasons AV1 is more usable is because its licensing is simpler, clearer, and more straightforward. You've proven that.

The specific was not about Physical media. The specific was that All content distribution requires fees. Physical media was not even specified in the original context.

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.

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

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.

From https://trash-guides.info/Misc/x265-4k/

> Something like 95% of video files are x264 and have much better direct play support.

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.

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.

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.

Somewhat unfortunate that never became anything.

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

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!)

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

But it is currently being used in India and China already. So its usage is much bigger than a lot of people would imagine.

HEVC is patent encumbered. Users who use old hardware don't have hardware decoder. So both requires more time to be adopted.

It sure gets the file size down though.

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.

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.

There appears to be some lossy compression on that string of "H"s.

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.

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

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

BluRay tends to encode 1080p30 at 50 Mbps

ATSC using 18 Mbps for 1080p30 is quite a lot in comparison.

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.

It is a cool article, just, wowzers, what a phrase.

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

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.

(i recommend you knock it off)

but yeah, the main benefit is that it gets people to read about the long now foundation

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.

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

The core of any lossy visual compressor is approximately the same theme. Those I-frames are essentially jpegs.

That was 2016. Today, it's because Youtube knows you're on Firefox.

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.

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.

PNG loss no information from the image being fed to it, the loss was done before creating a simpler image.

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.

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