x266 VVC Encoder

[kurkosdr]

We've been complaining a lot about YouTube and the fact that videos are low bitrate, 8bit only and full of banding, but at least you can upload up to 8K 60p there and if you upload HLG or PQ it will be preserved and passed through to supported devices (while showing a puny LUT conversion on SDR ones). I mean, this is at least something.(

Wait, 8-bit HLG is something that's actually done in the wild? Does it mean we could get HLG on TV channels in Europe? Here in Europe, I doubt we 'll get more than 2-3 UHD channels per country, considering some countries are still trying to fully get out of Mpeg2 SD and that UHD requires double the bitrate compared to HD (even when H.265 is used). So, if someone could work HLG into 8-bit to retrofit all those HD H.264 channels with HLG, that would be great.

Also, how does the signalling work so the decoder won't decode it as SDR in YouTube? Is it at the stream level or at the container level?

[FranceBB]

Wait, 8-bit HLG is something that's actually done in the wild?

Only by Sony cameras like the Sony A7 III as it's technically not compliant.
TL;DR you cannot go on air in 8bit in UHD.



Does it mean we could get HLG on TV channels in Europe?


There are already UHD channels in Europe.
For instance, at Sky we've been airing in UHD BT2020 SDR in H.265 4:2:0 25 Mbit/s 10bit planar since 2015 and in UHD BT2020 HDR HLG 4:2:0 25 Mbit/s 10bit planar since 2018. And not just Sports, but also Cinema (so movies).




Here in Europe, I doubt we 'll get more than 2-3 UHD channels per country


The problem ain't UHD, the problem is the fact that Hotbird is overcrowded and bitrate is expensive as f...





considering some countries are still trying to fully get out of Mpeg2 SD


This is an issue everywhere...
If I get a content, I have to encode an SD version, a FULL HD version and a UHD version as we have the same channels on air with 3 different codecs and 3 different resolutions.
This is a huge waste of bitrate.
My biggest satisfaction would be to see all the SD channels shut down one day, 'cause this is a problem for lots and lots of broadcasters...


if someone could work HLG into 8-bit to retrofit all those HD H.264 channels with HLG, that would be great.


Not gonna happen, not with H.264, not in 8bit, not in HLG.
That's just Sony's poor hardware trying to squeeze the best out of it with 8bit Full Range HLG in H.264.


Also, how does the signalling work so the decoder won't decode it as SDR in YouTube? Is it at the stream level or at the container level?

In linear channels?
The encoded stream is correctly flagged as arib-std-b67 and with the color matrix BT2020. Those channels are backwards compatible with BT2020 SDR TVs.

[benwaggoner]

If I may add, the majority of websites have historically avoided patented formats that come with "content fees" so they won't have to pay said "content fees" for every picture or video they distribute (which can be a problem considering how thin per-content profit margins are for web content available as free-to-view/ad-supported). It's the reason why there was almost no web content encoded in JPEG2000, Mpeg2 or Mpeg4 ASP in the past. Websites just used good old JPEG for pictures and for video they used Cinepak (and after that WMV or Quicktime, often both in order to effortlessly serve both Windows and Mac).
Cinepak got used because it was the first universal video codec. There weren't any content fees for any good codecs on Mac/PC back then.
J2K required much more compute for relatively minor efficiency improvements over JPEG.
Neither MPEG-2 or MPEG-4 ASP were quality-competitive against the best streaming codecs of their era.
MPEG-4 ASP decode became pretty universal pretty quickly. I wrote a DV Magazine article about using it as a universal codec for Robert X. Cringley's web site back in the late 90's.

One certainly can argue that IP concerns about J2K, MPEG-2, and MP4ASP slowed down development that prevented competitive implementations from emerging. But I can't think of any format that was abandoned due to distribution licensing concerns. Encoder licensing concerns arguably killed VP6 for Flash, with YouTube skipping straight from H.263 to H.264.

In addition, browser vendors that offer their browsers as free downloads (such as Mozilla and Google) avoid patented codecs so they won't have to pay a "decoder fee" with every download. Sure, they could use the system codecs where available, but the "where available" part causes an inconsistent experience. Also, blocking system codecs is a form of "gatekeeping" to keep patented codecs out of the web so they won't have to be dragged into paying "decoder fees" later.
Chrome and Firefox do "pass to system decoder" perfectly well for H.264. What I spoke of was their explicitly disabling HEVC support to prop up less technically competitive alternatives for ideological reasons. Which has largely meant H.264 and very little HDR on the desktop.

If you think about it, H.264 was the exception to the rule, the only ISO video compression standard to be widely used in the web. Firstly because it blew everything out of the water at the time in terms of efficiency, secondly because it had hardware acceleration in almost every computer (if not full, at least assisted) back when full software decoding was still an issue on low-powered PCs, and thirdly because it was imposed on browser vendors by the proprietary Adobe Flash plugin (which meant browser vendors couldn't "gatekeep" it out of their browsers).
H.264 become the dominant web codec well before HW decoding became universal. That's why x264 has --tune fastdecode. The MPEG design process prioritizes low decoder complexity increases versus efficiency gains, which helped a lot. Early H.264 on the web was all Baseline profile, and SW decode was a pretty reasonable lift. After a few years of Moore's Law, Main and High profiles became viable. Sure MP4-ASP and WMV3 were somewhat faster per-pixel, but only somewhat, so the efficiency gains of H.264 made the difference. Still, a well-tuned VC1 AP was well matched with H.264 Baseline in the mid aughts. x264 was really H.264's killer feature. It's hard to beat the development power of hundreds of quality and speed obsessed piracy groups around the world working with lots of different kinds of content. Once --cutree was introduced and VC1 encoder development largely ceased (~2009?) x264 pulled farther and farther away.

None of these conditions apply today. Someone needs to break it to H.265 and H.266 patent holders that they aren't getting the kind of windfall they did from H.264 patents. This includes Apple.
It really depends by market. HEVC, H.264, and MPEG-2 all made patent holders buckets of money (MPEG-2 most of all). Not that much premium content is played in browsers on Mac/Windows. TV and phone companies, cable companies, etc are very comfortable with paying additional codec licensing fees in return for a very high standard of interoperability and 2x better compression efficiency. VVC clearly has the compression efficiency improvements vital to those industries, and a "good enough" licensing regime will be successful, even if it isn't suitable for non-DRM web content.

For all the "HEVC is dead!" claims, a huge amount of content is watched in HEVC with hardware decoders, including nearly all HDR premium content.

[Blue_MiSfit]

For all the "HEVC is dead!" claims, a huge amount of content is watched in HEVC with hardware decoders, including nearly all HDR premium content.

QFT.

Lots of UHD streaming happening from premium services in the last 6 years like Netflix, Disney+, Amazon Prime, Hulu, iTunes, VUDU, Movies Anywhere etc. The common thread? HEVC :)

[kurkosdr]

Cinepak got used because it was the first universal video codec. There weren't any content fees for any good codecs on Mac/PC back then.
J2K required much more compute for relatively minor efficiency improvements over JPEG.
Neither MPEG-2 or MPEG-4 ASP were quality-competitive against the best streaming codecs of their era.
MPEG-4 ASP decode became pretty universal pretty quickly. I wrote a DV Magazine article about using it as a universal codec for Robert X. Cringley's web site back in the late 90's.

One certainly can argue that IP concerns about J2K, MPEG-2, and MP4ASP slowed down development that prevented competitive implementations from emerging. But I can't think of any format that was abandoned due to distribution licensing concerns. Encoder licensing concerns arguably killed VP6 for Flash, with YouTube skipping straight from H.263 to H.264.
Ok, I agree that the situation with JPEG2000 and MPEG-2 is murky, but MPEG-4 ASP failed due to licensing concerns. Windows XP didn't provide codecs for it to avoid a "decoder fee", browsers didn't provide codecs for it for the same reason, websites didn't touch it due to the dreaded "content fee" (https://blog.chiariglione.org/the-impact-of-mpeg-standards/) and used WMV and QT instead. I haven't seen a single video on the web (from a non-pirate page) that used MPEG-4 ASP. Pirates used it because, when you are distributing unauthorized copies of the latest Disney movie, content fees are the least of your worries as far as legality is concerned.

BTW I can think of a format that was abandoned due to distribution licensing concerns: H.264, which was abandoned from YouTube, the biggest online video platform. And HEVC, which was abandoned from YouTube before it even got adopted. Yes, "content fees" matter to platforms like YouTube. And "decoder fees" matter for browser vendors. Netflix also avoids streaming H.264 or HEVC if they can stream AV1.


Chrome and Firefox do "pass to system decoder" perfectly well for H.264.
Yes, they do pass H.264 to system decoder because they also provide an H.264 decoder, so there is no inconsistency (at least for Chrome).

What I spoke of was their explicitly disabling HEVC support to prop up less technically competitive alternatives for ideological reasons.
To which I say: Thank you Mozilla and Google! I don't want to pay for the HEVC patent thicket every time I download a browser (or indirectly every time I watch a free video), not when a good-enough alternative exists. Nor do I want to have family and relatives asking me about codec packs and where to find them. Also, we can't count on Google to subsidize the HEVC patent thicket payments for Chrome like they do for H.264. It's just silly from a financial perspective. AV1 is good-enough. Thanks to all the patents that expired during the last 20 years, we don't need MPEG anymore in order to have an open video format that allows for decent encoders. That's why the patent holders behind HEVC have a sad (https://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/).


Which has largely meant H.264 and very little HDR on the desktop.

AV1 supports 10-bit and HDR.


For all the "HEVC is dead!" claims, a huge amount of content is watched in HEVC with hardware decoders, including nearly all HDR premium content.
Good for them, considering they are charging for every piece of content they show. The web is just fine with AV1 and doesn't have to pay any "content fee" or "decoder fee". Thank you Google and Mozilla for making it happen.

[lvqcl]

h.264, which was abandoned from youtube
wdym?

[lvqcl]

(Why did the forum software change all text to lowercase in my previous post?)

[kurkosdr]

H.264, which was abandoned from YouTube.

wdym?

YouTube is all VP9 and AV1 nowadays, with VP8 for backwards compatibility. You can probably get YouTube to serve a 720p H.264 stream as a "last resort" extreme backward compatibility stream, but I don't know if they even do that anymore.

In the past, YouTube was all H.264 for 720p and 1080p.

[benwaggoner]

BTW I can think of a format that was abandoned due to distribution licensing concerns: H.264, which was abandoned from YouTube, the biggest online video platform. And HEVC, which was abandoned from YouTube before it even got adopted. Yes, "content fees" matter to platforms like YouTube. And "decoder fees" matter for browser vendors. Netflix also avoids streaming H.264 or HEVC if they can stream AV1.
YouTube still serves tons of H.264. That's all that Apple devices get, IIRC, among others. It has been deemphasized, but certainly not abandoned. H.264 is likely to remain the only universally supported bitstream in browsers & hardware decoders for 5+ more years.

HEVC is pretty much universally supported in current HW decoders, although there are people still using older devices without it, particularly for things like TVs with slower refresh cycles. I'm not aware of anyone shipping a mobile devices without HW HEVC support for several years now.

Yes, they do pass H.264 to system decoder because they also provide an H.264 decoder, so there is no inconsistency (at least for Chrome).
In our ABR multi-codec world, "consistency" hasn't been a big factor for a long time. It's pretty rare someone watches an imbedded .mp4 these days.

To which I say: Thank you Mozilla and Google! I don't want to pay for the HEVC patent thicket every time I download a browser (or indirectly every time I watch a free video), not when a good-enough alternative exists. Nor do I want to have family and relatives asking me about codec packs and where to find them. Also, we can't count on Google to subsidize the HEVC patent thicket payments for Chrome like they do for H.264. It's just silly from a financial perspective. AV1 is good-enough. Thanks to all the patents that expired during the last 20 years, we don't need MPEG anymore in order to have an open video format that allows for decent encoders. That's why the patent holders behind HEVC have a sad (https://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/).
There would be no cost to Google or Mozilla to support passthrough to HEVC decode. I don't know there would be any distribution fee at all. That does reiterate the problems with HEVC licensing - it's not like there's a single source of truth to figure out what you have to pay for doing what, and what you don't have to pay for at all. For H.264, MPEG-LA had a nice PowerPoint summary available to the public.

Oh, there are certainly costs to not supporting HEVC. Bandwidth consumption has been higher than needed for a given quality for years now. Browser and PC HDR is years behind where it could have been. 4K on PC is years behind where it could have been.

Software decoders are fine for short-form user-generated content. But they don't have the DRM robustness for premium 4K or HDR content, which is why that's almost entirely viewed on other kinds of devices that have HW decoders. SW decoders also eat more power, and there are absolutely devices that could have played a 2 hour movie in HW HEVC that will run out of battery before hitting 2 hours in SW AV1.

Globally, the aggerate impact of all those computers burning watts to decode software codecs on YouTube despite HW decoders being available has been ballparked as several MW.

AV1 supports 10-bit and HDR.
Nominally. But 10-bit decode is still materially slower/more power hungry than 8-bit in current mainstream released browsers. And what's your favorite AV1 encoder well-tuned for HDR-10 encoding using the PQ EOTF? I've not found any that are actually competitive with HEVC encoders form three years ago, let alone state of the art.

Good for them, considering they are charging for every piece of content they show. The web is just fine with AV1 and doesn't have to pay any "content fee" or "decoder fee". Thank you Google and Mozilla for making it happen.
The web is highly diverse. And viewership of streaming services in browsers has been dropping rapidly year-on-year. A big reason why Netflix et al have been pushing people to use apps over browsers is that they can HEVC, HDR, DD+ audio, and other media technologies they can't from a browser.

[kurkosdr]

YouTube still serves tons of H.264. That's all that Apple devices get, IIRC, among others. It has been deemphasized, but certainly not abandoned. H.264 is likely to remain the only universally supported bitstream in browsers & hardware decoders for 5+ more years.
Even Apple has begrudgingly started supporting VP9 on newer devices. So, for YouTube, H.264 is indeed a "last resort" compatibility stream wherever VP8, VP9 or AV1 cannot be used. Funny what happens when the biggest online video provider (aka YouTube) says "sorry Apple, I will not pay content fees towards your HEVC patent thicket and I will use an alternative standard instead". Did I say "thank you Google" already?

All Apple achieves by refusing to support AV1 is making their product offerings a bit worse. Their problem not ours.


HEVC is pretty much universally supported in current HW decoders, although there are people still using older devices without it, particularly for things like TVs with slower refresh cycles. I'm not aware of anyone shipping a mobile devices without HW HEVC support for several years now.

(and)

Oh, there are certainly costs to not supporting HEVC. Bandwidth consumption has been higher than needed for a given quality for years now. Browser and PC HDR is years behind where it could have been. 4K on PC is years behind where it could have been.

Software decoders are fine for short-form user-generated content. But they don't have the DRM robustness for premium 4K or HDR content, which is why that's almost entirely viewed on other kinds of devices that have HW decoders. SW decoders also eat more power, and there are absolutely devices that could have played a 2 hour movie in HW HEVC that will run out of battery before hitting 2 hours in SW AV1.

Globally, the aggerate impact of all those computers burning watts to decode software codecs on YouTube despite HW decoders being available has been ballparked as several MW.

All of them temporary problems now that VP9 and AV1 have wide industry support and ship on new devices. Also, the aggregate MWs are a red herring: the watt impact per person is small. I don't see why any of this stuff justifies paying content fees for the next two decades just to have video on the world wide web. Premium services can do whatever they want. These services charge for the content, so they can presumably pay the content fees (though Netflix streams AV1 wherever possible, since AV1 achieves at least bitrate parity with HEVC and has no content fees, which means the economics work in favour of AV1). I want the ability to have video on YouTube (or a site some startup has made) without the website having to pay to the HEVC patent thicket (or the H.264 patent thicket) any content fees. Or me having to pay to download the browser. Or having to care about "system codecs". Which brings me to...


In our ABR multi-codec world, "consistency" hasn't been a big factor for a long time. It's pretty rare someone watches an imbedded .mp4 these days.

(and)

There would be no cost to Google or Mozilla to support passthrough to HEVC decode.
There is a cost in that users of the browser will have to deal with system codecs, which for most users is rarely fun (videos that work on one computer won't work on another, on the same browser and version, try explain that to people!). That's what I mean by "consistency". The product (browser) won't be consistent across computers. It's the reason Chrome was forced to implement H.264 despite H.264 system codecs being a thing. And you know services from Apple will exclusively use HEVC just to force every browser to implement it, so they can the collect those sweet fees. In contrast, anyone can ship a browser with a software VP8, VP9 and AV1 decoder without any fees and have videos work on every computer the browser runs on.


Nominally. But 10-bit decode is still materially slower/more power hungry than 8-bit in current mainstream released browsers. And what's your favorite AV1 encoder well-tuned for HDR-10 encoding using the PQ EOTF? I've not found any that are actually competitive with HEVC encoders form three years ago, let alone state of the art.
If you want perfectly-tuned HDR for your 90" OLED 8K StratoDef TV then download the app and pay for the content. On the web, the ability to implement standards without paying fees (and the resulting consistency from not having to pay fees) is valued more than perfectly-tuned HDR (or DD+ for that matter). The web can do just fine with "good enough" AV1 HDR10+ and HLG. It already does.


The web is highly diverse. And viewership of streaming services in browsers has been dropping rapidly year-on-year. A big reason why Netflix et al have been pushing people to use apps over browsers is that they can HEVC, HDR, DD+ audio, and other media technologies they can't from a browser.

At this point, it's impossible for the web to keep premium services happy. You give them Widevine (so they supposedly won't move to apps), they ask for more DRM. If you give them that, then they'll ask for HEVC. And then for something else.

So, why bother? Just let those premium services have their apps and deliver a more plain service on the web.


I don't know there would be any distribution fee at all.

Hmm, let me see... There are content fees for Mpeg 4 ASP, there are content fees for H.264 (no, I don't care if it was waived for a small number of years as part of a promotion), but somehow, magically, there is even a snowball's chance in hell there won't be content fees for HEVC, despite the patent owners having gotten more aggressive to the point the can't even form a common patent pool anymore... Why does the web need this mess? To satisfy some people complaining about HDR tuning? Nah, just give those people AV1 HDR10+ or HLG and tell them to bugger off.


That does reiterate the problems with HEVC licensing - it's not like there's a single source of truth to figure out what you have to pay for doing what, and what you don't have to pay for at all. For H.264, MPEG-LA had a nice PowerPoint summary available to the public.

Again, why does the web need this mess? How is it compatible with the open nature of web standards? It's not.

[kurkosdr]

Only by Sony cameras like the Sony A7 III as it's technically not compliant.
TL;DR you cannot go on air in 8bit in UHD.
I had a second look at HLG3 footage, and indeed it looks as flat as S-log, so most SDR viewers probably won't be able to stomach it if you were to feed it to a broadcast H.264 stream. So even if you could software-upgrade HDR TVs to recognise HLG3 somehow, it's still out of the question due to how bad it looks on SDR displays.

I guess most H.264 HD channels will do tone-mapped content (from HDR) and call it a day. Which means the handling of tone-mapped content will be a big differentiator for consumer HDR TVs for the years to come, much like the quality of upscaling and denoising of mpeg2 SD channels was a big differentiator for early consumer HD TVs (and still is in some countries like the UK, which has 12 HD channels and several dozen Mpeg2 SD ones, all of them at crappy bitrates).


There are already UHD channels in Europe.
For instance, at Sky we've been airing in UHD BT2020 SDR in H.265 4:2:0 25 Mbit/s 10bit planar since 2015 and in UHD BT2020 HDR HLG 4:2:0 25 Mbit/s 10bit planar since 2018. And not just Sports, but also Cinema (so movies).

The problem ain't UHD, the problem is the fact that Hotbird is overcrowded and bitrate is expensive as f...


Terrestrial is the big problem IMO. Many of us in the EU and UK live in rented apartments and cannot drill holes through walls and mount satellite dishes outside.

A terrestrial DVB-T2 mux can fit a grand total of 3 UHD channels. Indeed, any countries doing UHD trials are broadcasting just 2-3 UHD channels on one mux, and I doubt they will manage to free up more than one mux due to the 4G and 5G spectrum releases (and terminating H.264 is out of the question considering some countries are still facing resistance when trying to terminate mpeg2). So, I disagree, UHD bitrate requirements are very much a problem. The terrestrial broadcasting world should have waited for VVC so they can at least get 6 UHD channels per mux. If you though HD was a failure on terrestrial, wait and see how UHD will do.

[LigH]

(Why did the forum software change all text to lowercase in my previous post?)

Because "everything in uppercase" is treated as yelling and rude. It doesn't care about acronyms. There is no "intelligent software"... :cool:

[FranceBB]

I guess most H.264 HD channels will do tone-mapped content (from HDR) and call it a day.

I wish, but no...
I mean "no" to a certain extent. As long as a broadcaster is also a producer, anything can be done (for instance for sports contents, tonemapping HLG to BT709 SDR can be done on the fly without any issues), but try to do that on a movie and it's gonna be a digital rights madness 'cause some Hollywood companies DO NOT want you to tonemap on the fly. For instance, when they send us HDR PQ stuff and we convert them to HLG according to the maxCll info they provide, they always want to test our conversion methods via agreed test patters etc, but most of them will never sign an agreement for on-the-fly HDR PQ or HDR HLG to BT709 SDR tonemapping.
(It would be cool, but it ain't gonna happen 'till the Hollywood guys will change their minds :( )



(and still is in some countries like the UK, which has 12 HD channels and several dozen Mpeg2 SD ones, all of them at crappy bitrates).

Eheheheh as long as you watch itv, channel 4 etc, but if you watch Sky, that's gonna be a UHD H.265 HDR HLG 10bit stream re-encoded and dithered down from an internal 12bit DNxHQX (so 800 Mbit/s) mezzanine file, so the quality is there ;)



Terrestrial is the big problem IMO. Many of us in the EU and UK live in rented apartments and cannot drill holes through walls and mount satellite dishes outside.


Right! We're slowly but surely shifting towards internet tv, though, for anyone who can't mount a satellite dish and has a decent enough connection. Sky Glass is just an example, along with the new Sky Q Mini decoder.

OMG I sound like a salesman now xD



A terrestrial DVB-T2 mux can fit a grand total of 3 UHD channels. Indeed, any countries doing UHD trials are broadcasting just 2-3 UHD channels on one mux, and I doubt they will manage to free up more than one mux due to the 4G and 5G spectrum releases (and terminating H.264 is out of the question considering some countries are still facing resistance when trying to terminate mpeg2). So, I disagree, UHD bitrate requirements are very much a problem. The terrestrial broadcasting world should have waited for VVC so they can at least get 6 UHD channels per mux. If you though HD was a failure on terrestrial, wait and see how UHD will do.

Sorry, we've been talking past each other, I clearly meant satellite and... well... satellite-wise the UK has Astra 2E/2F/2G all dedicated to its channels, so it's easier to handle there. In Europe, every EU nation (and some non-eu ones) airs on Hotbird 13E. Can you imagine how overcrowded it is?


About terrestrial, I gotta be fair: I have no clue as I've never been interested...

[lvqcl]

YouTube is all VP9 and AV1 nowadays, with VP8 for backwards compatibility. You can probably get YouTube to serve a 720p H.264 stream as a "last resort" extreme backward compatibility stream, but I don't know if they even do that anymore.

Well, it's really not true. It's VP8 that doesn't exist anymore on YouTube, and every video has h.264 versions. Many live streams are h.264 only, like that -
format code extension resolution note
91 mp4 256x144 269k , avc1.4d400c, 30.0fps, mp4a.40.5
92 mp4 426x240 507k , avc1.4d4015, 30.0fps, mp4a.40.5
93 mp4 640x360 962k , avc1.4d401e, 30.0fps, mp4a.40.2
94 mp4 854x480 1282k , avc1.4d401f, 30.0fps, mp4a.40.2
300 mp4 1280x720 2922k , avc1.4d4020, 60.0fps, mp4a.40.2
301 mp4 1920x1080 5552k , avc1.4d402a, 60.0fps, mp4a.40.2 (best)




There would be no cost to Google or Mozilla to support passthrough to HEVC decode.
AFAIK HEVC decode in Edge Chromium is still broken --

https://techcommunity.microsoft.com/t5/discussions/hevc-video-decoding-broken-with-b-frames/m-p/2077247
https://answers.microsoft.com/en-us/windows/forum/all/hevc-video-has-stuttered-playback/56d047c1-dd76-4dc3-8544-58ec09133984
https://techcommunity.microsoft.com/t5/discussions/hevc-main-10-video-playback-is-heavily-stuttering/m-p/1959752

-- and Microsoft doesn't care much.

[birdie]

YouTube is all VP9 and AV1 nowadays, with VP8 for backwards compatibility. You can probably get YouTube to serve a 720p H.264 stream as a "last resort" extreme backward compatibility stream, but I don't know if they even do that anymore.

In the past, YouTube was all H.264 for 720p and 1080p.

This is not the case, 1080p H264 is still there for all new videos:

youtube-dl -F 'https://www.youtube.com/watch?v=zcI6SFiK_yk'
[youtube] zcI6SFiK_yk: Downloading webpage
[info] Available formats for zcI6SFiK_yk:
format code extension resolution note
249 webm audio only tiny 41k , webm_dash container, opus @ 41k (48000Hz), 759.27KiB
250 webm audio only tiny 54k , webm_dash container, opus @ 54k (48000Hz), 991.55KiB
251 webm audio only tiny 107k , webm_dash container, opus @107k (48000Hz), 1.92MiB
140 m4a audio only tiny 129k , m4a_dash container, mp4a.40.2@129k (44100Hz), 2.32MiB
160 mp4 256x144 144p 35k , mp4_dash container, avc1.4d400c@ 35k, 24fps, video only, 650.61KiB
394 mp4 256x144 144p 57k , mp4_dash container, av01.0.00M.08@ 57k, 24fps, video only, 1.02MiB
278 webm 256x144 144p 71k , webm_dash container, vp9@ 71k, 24fps, video only, 1.28MiB
133 mp4 426x240 240p 57k , mp4_dash container, avc1.4d4015@ 57k, 24fps, video only, 1.02MiB
395 mp4 426x240 240p 72k , mp4_dash container, av01.0.00M.08@ 72k, 24fps, video only, 1.30MiB
242 webm 426x240 240p 78k , webm_dash container, vp9@ 78k, 24fps, video only, 1.40MiB
134 mp4 640x360 360p 97k , mp4_dash container, avc1.4d401e@ 97k, 24fps, video only, 1.75MiB
396 mp4 640x360 360p 132k , mp4_dash container, av01.0.01M.08@ 132k, 24fps, video only, 2.37MiB
243 webm 640x360 360p 135k , webm_dash container, vp9@ 135k, 24fps, video only, 2.43MiB
135 mp4 854x480 480p 150k , mp4_dash container, avc1.4d401e@ 150k, 24fps, video only, 2.70MiB
244 webm 854x480 480p 209k , webm_dash container, vp9@ 209k, 24fps, video only, 3.76MiB
397 mp4 854x480 480p 233k , mp4_dash container, av01.0.04M.08@ 233k, 24fps, video only, 4.18MiB
136 mp4 1280x720 720p 275k , mp4_dash container, avc1.4d401f@ 275k, 24fps, video only, 4.94MiB
247 webm 1280x720 720p 319k , webm_dash container, vp9@ 319k, 24fps, video only, 5.73MiB
398 mp4 1280x720 720p 464k , mp4_dash container, av01.0.05M.08@ 464k, 24fps, video only, 8.32MiB
399 mp4 1920x1080 1080p 947k , mp4_dash container, av01.0.08M.08@ 947k, 24fps, video only, 16.96MiB
248 webm 1920x1080 1080p 1065k , webm_dash container, vp9@1065k, 24fps, video only, 19.08MiB
137 mp4 1920x1080 1080p 1227k , mp4_dash container, avc1.640028@1227k, 24fps, video only, 21.98MiB
18 mp4 640x360 360p 383k , avc1.42001E, 24fps, mp4a.40.2 (44100Hz), 6.87MiB
22 mp4 1280x720 720p 404k , avc1.64001F, 24fps, mp4a.40.2 (44100Hz) (best)

This is a three days old clip.

[benwaggoner]

This thread is about x266, not VVC in general. Let's move discussion about VVC in general to that thread.

[MoSal]

OMG I sound like a salesman now xD



Don't worry. No one here is going to fall for it before all HFR content
is properly encoded and an HFR option is provided (e.g. Football Highlights) ;)

Nothing in life bugs me more than an official source giving a video/live stream more than enough bitrate, but dropping half the frames for no good reason whatsoever. Yet for some reason, that seems to be the norm online, and doing it right is the exception.

[benwaggoner]

Don't worry. No one here is going to fall for it before all HFR content
is properly encoded and an HFR option is provided (e.g. Football Highlights) ;)

Nothing in life bugs me more than an official source giving a video/live stream more than enough bitrate, but dropping half the frames for no good reason whatsoever. Yet for some reason, that seems to be the norm online, and doing it right is the exception.
Please move discussion of VVC in general to the HEVC successor: Versatile Video Coding (https://forum.doom9.org/showthread.php?t=174940) thread.

This thread is specifically for discussions of the (unreleased!) x266 VVC encoder.

[ksec]

I think kurkosdr replies generally summarise everything that is annoying with Alliance for Open Media and their supporters. ( to say the least )

AV1 is not patent free, it is royalty free. There is a big difference between the two. The FUD on content fees and myth of patent free is still here, 2022. Fascinating world of misinformation being spread.

I would love to see a truly patent free codec, or if they could just take out the 10ish patent on EVC baseline profile. But AV1 is not a patent free codec.

H264 is not dead. Not in anyway shape of form, doesn't matter how you slice it.

Video Codec is not only used on the Web. And the web does not equal to all YouTube.

Apple is not even the largest beneficial, or even 10% of HEVC or VVC patent fee structure.

Because of these ideology over actual technical and market reality, we end up having browser vendor supporting AVIF and refuse to support JPEGXL. Which is also royalty free and open standard. And a technically better image codec on the web.

Alliance for Open Media have its place and purpose. I just wish they work on AV2 asap and learn from all the experience they had with AV1. But at least AV1 hardware decoder is finally coming. Three years behind their original schedule.

Finally this is a x266 thread. I wish we have new forum features where I could give a thumbs up like those QFT replies above.

I am already looking at beyond VVC with ECM. ~50% bitrate reduction compared to VVC Reference Encoder.

[FranceBB]

Finally this is a x266 thread.


I hope we're gonna have the new forum section soon-ish.
Like end of 2022 with all the H.266 VVC related topics moved there?


I wish we have new forum features where I could give a thumbs up

Trust me, you don't wanna have "likes" and "reactions" in a forum. Doom9 has been nearly identical for years, basically since 2001 Link (https://web.archive.org/web/20011128063251/http://forum.doom9.org/) and I sort of like the way it is with its "retro" look.


I am already looking at beyond VVC with ECM. ~50% bitrate reduction compared to VVC Reference Encoder.

Playing against the reference encoder is easy, try against VVEnc by Fraunhofer which is the closest thing we have to a real encoder. I might make more experiments with VVEnc (or indeed when x266 will come out), but I don't have time, I never have time to do the stuff I like... :(

[rwill]

I would love to see a truly patent free codec, or if they could just take out the 10ish patent on EVC baseline profile.


Wasn't the goal of the EVC Baseline profile to use no patented tools and techniques at all ? I think it was designed this way. Source please that it uses technology where active patents still apply ?

[ksec]

Wasn't the goal of the EVC Baseline profile to use no patented tools and techniques at all ? I think it was designed this way. Source please that it uses technology where active patents still apply ?

https://en.wikipedia.org/wiki/Essential_Video_Coding

The base consist of tools that were made public more than 20 years ago or for which a Type 1 declaration is received. Type 1, or option 1, means "royalty-free", in the nomenclature used in ISO documents.

The baseline has a few tools with patent that has yet to be expired but are granted the usage for free. Basically EVC baseline is royalty free or soon to be patent free.

[benwaggoner]

EVC baseline is technically promising in offering royalty free that is quite a bit better than H.264 at much lower complexity/cost than AV1 (or even VP9). And the optional tool design should make higher profiles a lot more resilient against submarine patents and such. Haven't heard too much about practical implementations lately, although Covid obscures lots of things trade shows used to reveal.

[FranceBB]

But at least AV1 hardware decoder is finally coming. Three years behind their original schedule.

I was looking into this this afternoon out of curiosity. Looks like NVIDIA introduced it only from the GeForce RTX 3050 Ti / RTX 3050 onwards, so:

- RTX 3050
- RTX 3050 Ti
- RTX 3060
- RTX 3060 Ti
- RTX 3070
- RTX 3070 Ti
- RTX 3080
- RTX 3090

and it's 4:2:0 only and 8bit/10bit but no 12bit.

On the bright side, H.265 is finally seeing some love for 4:4:4 as well, in fact 8bit, 10bit, 12bit 4:4:4 H.265 is hardware decoded. :D
This is indeed good and I'd love to see 4:2:2 and 4:4:4 be supported at high bit depth for other codecs as well (like H.264).

This might be slightly off topic, but one of the things I'm having hard time to decode is Motion JPEG2000 Intra Class 4:4:4 12bit XYZ BT2020 SDR in UHD and Motion JPEG2000 Intra Class RGB 12bit HDR PQ which movie studios seem to love. It's making my 20c/40th Xeon suffer and I can't still see it decoded in real time... :(
I'm sure the studios are using an hardware playback port to decode this (like we do with Omneon for MPEG-2 and Versio for H.264) but there must be another way, surely.
Also, I think that the reason why it's so hard to decode is that it's actually using the Wavelet Transform which is applied to the whole picture at once (so it can't be parallelized) instead of the DCT applied to blocks and macroblocks of different sizes like we have in MPEG codecs (but I might be wrong).

[ksec]

This might be slightly off topic, but one of the things I'm having hard time to decode is Motion JPEG2000 Intra Class 4:4:4 12bit XYZ BT2020 SDR in UHD and Motion JPEG2000 Intra Class RGB 12bit HDR PQ which movie studios seem to love. It's making my 20c/40th Xeon suffer and I can't still see it decoded in real time...

I dont know of any decent open source solution to Motion JPEG 2000. All of them are commercial software. I do know Nvidia has a nvJPEP2000 library on CUDA, but I have never played around with it.

[Blue_MiSfit]

libopenjpeg is pretty good :)

But we're getting off topic!

[Emulgator]

....but one of the things I'm having hard time to decode is Motion JPEG2000 Intra Class 4:4:4 12bit XYZ BT2020 SDR in UHD and Motion JPEG2000 Intra Class RGB 12bit HDR PQ which movie studios seem to love. It's making my 20c/40th Xeon suffer and I can't still see it decoded in real time...
I'm sure the studios are using an hardware playback port to decode this (like we do with Omneon for MPEG-2 and Versio for H.264) but there must be another way, surely.
Software: Kakadu et al., Hardware: Barco Silex et al.

[rwill]

Kakadu is much faster than OpenJPEG for me.

[benwaggoner]

At the time (before I was involved in SMPTE) I figured that J2K was used for digital cinema in large part to make it that much harder for pirates to be able to play them on PCs ;).

[ksec]

at the time (before i was involved in smpte) i figured that j2k was used for digital cinema in large part to make it that much harder for pirates to be able to play them on pcs ;).

rofl.

[LigH]

Security via obscurity...

[Balling]

At the time (before I was involved in SMPTE) I figured that J2K was used for digital cinema in large part to make it that much harder for pirates to be able to play them on PCs ;).

There were no such leaks. Only some masters in ProRes.

[Balling]

BTW, funny that you mention it https://docs.nvidia.com/cuda/nvjpeg2000/userguide.html

[benwaggoner]

There were no such leaks. Only some masters in ProRes.
Yeah there was sure a lot of belt and suspenders in security for DCI. I'm sure they would have been cracked eventually hadn't much more useful formats like ProRes HQ come out. And which have a lot more threat vectors.

[Dann0245]

https://multicorewareinc.com/news/meet-multicoreware-at-nab2022-in-las-vegas/

https://i.slow.pics/CBLiD4hX.png

[nevcairiel]

They have been listing x266 for convention schedules going back 6 months or so (going back to IBC 2021 in November), nevertheless more information has not really been made public in all that time.

[rwill]

https://multicorewareinc.com/news/meet-multicoreware-at-nab2022-in-las-vegas/


I read between the lines and it tells me a lot about the state x266 is in.

[FranceBB]

Ah, so more info and hopefully we're gonna have a date about when it's gonna be officially released.
I look forward to toss VVEnc and integrate x266 'cause so far I've had to work around the VVEnc limitations.

[BuccoBruce]

I'm hoping MCW working on this means VVC won't face as much of an uphill battle with functional rate control or single threaded performance as VP9/AV1 did. Anyone know what their demo at NAB was like?


AFAIK HEVC decode in Edge Chromium is still broken --

https://techcommunity.microsoft.com/t5/discussions/hevc-video-decoding-broken-with-b-frames/m-p/2077247
https://answers.microsoft.com/en-us/windows/forum/all/hevc-video-has-stuttered-playback/56d047c1-dd76-4dc3-8544-58ec09133984
https://techcommunity.microsoft.com/t5/discussions/hevc-main-10-video-playback-is-heavily-stuttering/m-p/1959752

-- and Microsoft doesn't care much.

That was a side effect of a regression in their HEVC Extension, downgrading it fixed it as soon as the bug was introduced in 2020. I'd know, I still have Microsoft.HEVCVideoExtension_1.0.31823.0_x64__8wekyb3d8bbwe.appx on my NAS for any machines that I forgot to disable Store updates for it on! It does finally work fine now, they did something to either the extension itself or Edge in March (likely both) and finally fixed it, nearly two years later. I wonder if they've actually paid out to HEVC Advance / MPEG LA for all the free HEVC Video Extensions from Device Manufacturer downloads out there.

You used to be able to build Chromium itself using a modified ffmpeg build that could play anything (including HEVC) but the old methods you can find online no longer work.

At the time (before I was involved in SMPTE) I figured that J2K was used for digital cinema in large part to make it that much harder for pirates to be able to play them on PCs ;).

:D

[LigH]

HEVC issues do not belong to this thread... per se. But you are probably right, making a mistake once does not guarantee it won't happen twice, in the area of media technology.

In the meantime, before x266 gets available, uvg266 (https://forum.doom9.org/showthread.php?t=184093) is about to get useable. When anyone has the time and knowledge to make MABS support it, let's test it together...

[rwill]

Any news?

And does anyone know if x266 will have a deep psycho-visual pipeline? Modern encoders seem to put their focus there.

[Jamaika]

https://www.videoaktiv.de/2022110436675/news/markt/mainconcept-vvc/h.266-freie-betaphase-zum-hevc-nachfolger-gestartet.html
Anyone tested? Worth the sin? What hardware for the new codec?

[LigH]

I doubt that x266 will be made by Fraunhofer, Jamaika... wrong thread for that link.

[birdie]

Updates on x266 (https://forum.doom9.org/showthread.php?p=1982204#post1982204).

[DTL]

And does anyone know if x266 will have a deep psycho-visual pipeline? Modern encoders seem to put their focus there.

I hope at some stage they will finally actively integrate noise reduction to reuse motion search data in both noise reduction and encoding stages. As I currently know only AV1 of modern enough codecs have more or less good progress to 'temporal noise reduction' with some not very few number of frames used.

[benwaggoner]

I hope at some stage they will finally actively integrate noise reduction to reuse motion search data in both noise reduction and encoding stages. As I currently know only AV1 of modern enough codecs have more or less good progress to 'temporal noise reduction' with some not very few number of frames used.
Do you mean FGS or something else?

FGS is really an out-of-band process, not a codec feature per se. An encoder just gets the degrained source and grain reconstruction metadata to include. Which is a perfectly rational approach; grain removal is hard, complex, and advancing quickly. There's lots of benefit in grain removal not being normative, and just having the reconstruction be normative.

[birdie]

The last webinar questions have been answered (http://bit.ly/3EB0Hdk).

I'm a little bit dumbfounded because seemingly some questions have been misunderstood, some others have very basic and uninformative answers.

[PatchWorKs]

For those who are interested in, latest FastFilx beta added x266 support (through VVCEasy (https://github.com/MartinEesmaa/VVCEasy)):
https://github.com/cdgriffith/FastFlix/releases/tag/5.2.0b3

[FranceBB]

Unlikely given that x266 hasn't been released yet for public availability and it's not even available to Multicoreware's partners right now.
Looks like they added VVDec and VVEnc by Fraunhofer, which is still an H.266 Decoder and Encoder, but done by a different company.

Different projects, same goals.

[rwill]

Looks like they added VVDec and VVEnc by Fraunhofer, which is still an H.266 Decoder and Encoder, but done by a different company.

Fraunhofer is not a company but an registered association.