x266 VVC Encoder

[rwill]

Anyway, the GPL obligates them to provide source code if they release, so the only way for them to avoid releasing source code is to avoid releasing at all, basically abandon the whole project. I don't think they will do that considering the effort they've already put in.

What makes you think they have to adhere to the GPL?

[kurkosdr]

What makes you think they have to adhere to the GPL?
All the VideoLan code that's inside. VideoLan has given them "selling exceptions" for the binaries (which allows them to distribute the binaries under a license different than the GPL), but they have to release the source code under the GPL.

[benwaggoner]

Maybe you should start a Go-Fund-Me to support their development effort. I mean Duke Nukem Forever took a while too. BTW anyone got news of Star Citizen?
I think Star Citizen is more of an example of how little can be completed despite huge developer funding!

[rwill]

All the VideoLan code that's inside. VideoLan has given them "selling exceptions" for the binaries (which allows them to distribute the binaries under a license different than the GPL), but they have to release the source code under the GPL.

I think you are mistaken.

Multicoreware is distributing x265 under a different License to their paying customers so their customers do not have to release their products under the GPL. Multicoreware paid of the x264 people for that or customers of Multicoreware have to deal with x264's commercial arm. I see no reason for Multicoreware to distribute binaries under a different license as x265 its source is available openly. Customers of Multicoreware can compile and link to it mostly freely and can keep their stuff to themself.

And I wonder where you got the information from that there is VideoLan code inside of x266. Do you have access to x266's source code? The x264 code x265 is based on has not been state of the art for a long time.
From my perspective it would be one of the first things I would replace - from a business and development perspective.

[rwill]

I think Star Citizen is more of an example of how little can be completed despite huge developer funding!

Well they completed lots of development progress videos. And Starships for this hangar thing...

This is what Star Citizen is all about right?

[kurkosdr]

I think you are mistaken.

Multicoreware is distributing x265 under a different License to their paying customers so their customers do not have to release their products under the GPL. Multicoreware paid of the x264 people for that or customers of Multicoreware have to deal with x264's commercial arm.
That's what "selling exceptions" is. A compiled binary of x265 that is distributed under a different license than the GPL (for a price) so it can be integrated into a product without the product being bound by the GPL. It can be done if you have the copyright to the entire x265, which VideoLan and MulticoreWare do. Basically a form of dual-licensing.

More info here:
https://www.fsf.org/blogs/rms/selling-exceptions
(warning: some FSF lecturing, but generally a good rundown of what it is about)

[kurkosdr]

And I wonder where you got the information from that there is VideoLan code inside of x266. Do you have access to x266's source code? The x264 code x265 is based on has not been state of the art for a long time.
From my perspective it would be one of the first things I would replace - from a business and development perspective.
Good point, but we haven't any indication they are starting from scratch either. Big rewrites tend to cost more than expected, take more time than expected, and not be better than a targeted refactoring, so there is a good chance they'll keep the existing VideoLan code inside

[kurkosdr]

I think he pulled that one out of his rear as you cannot decode EVC Main Profile streams with a EVC Baseline decoder.
First things first: You don't gain anything by being a rude twat, nor are you contributing anything to the forum. Also, I don't care what pretend indignation you're going to use as "justification" for being a rude twat.

Secondly, according to Wikipedia, EVC Main Profile "consists of a royalty-free subset (baseline) and individually switchable enhancements". Also, "each of the 21 payable (aka non-Baseline) tools can be individually turned off and, when necessary, replaced by a corresponding cost-free baseline profile tool. This structure makes it easy to fall back to a smaller set of tools in the future, if, for example, licensing complications occur around a specific tool, without breaking compatibility with already deployed decoders.". This means an EVC baseline decoder can decode EVC Main with a quality hit, right? Haven't played with an EVC encoder because I haven't found a compelling reason to, but again, the ability to have the payable tools be switchable and replaceable by cost-free aka baseline tools is the big sell of EVC.

[rwill]

I contributed by calling you out. What are you contributing to the forum by spreading misinformation about EVC?

[kurkosdr]

I contributed by calling you out. What are you contributing to the forum by spreading misinformation about EVC?
You could've said "this person made a mistake". People make honest mistakes, you know. Nobody needs a jerk who treats another person's mistake as an opportunity to be a rude twat.

Also, I still don't understand what ISO means by "individually switchable enhancements", I thought it meant that a Baseline decoder can play Main.

[rwill]

You could've said "this person made a mistake". People make honest mistakes, you know. Nobody needs a jerk who treats another person's mistake as an opportunity to be a rude twat.

I see this somewhat differently.

In my opinion, if there is something we do not need, its people that pretend they contribute facts but have themself no idea what they are talking/writing about and are thus generating unfounded rumors. And Indeed when I look around the Internet there are a lot of these people. There are people lurking this forum looking for information regarding video compression. They shouldn't have to fact check everything that is stated here - but with the amount of half-knowledged people posting here I guess they have to anyway. Here I would like to take moment to applaud oibaf for asking for a source for that statement from you above. There is also a difference between a mistake and a made up fact. Some would even argue that making up facts is a form of lying.

Now regarding calling a person out I think it does not matter how it is done foremost, but that it is done. There is nothing worse than leaving misinformation uncontested. How this is done is secondary and comes down to personal preference. I, for example, am a fanboy of clear and direct communication. I even have problems understanding what someone wants when sugar coating and gift wrapping is applied to objection.

I am sorry that you are upset about the way I brushed your statement - that Google and Mozilla don't want EVC because of EVCs Design and that it is possible to decode a Main Profile stream with a Baseline decoder - off, but that you then quote Wikipedia, come to the false conclusions based on that quote and then more or less admit that you have no knowledge about the matter at all is pretty disappointing regarding further discussion.

I am somewhat at a loss.

[kurkosdr]

Now regarding calling a person out I think it does not matter how it is done foremost, but that it is done. There is nothing worse than leaving misinformation uncontested. How this is done is secondary and comes down to personal preference. I, for example, am a fanboy of clear and direct communication. I even have problems understanding what someone wants when sugar coating and gift wrapping is applied to objection.
Nobody asked you to "sugarcoat" anything. You can be clear and direct and not be a rude twat at the same time. If you had said "made it up" instead of "pulled that one out of his rear" I wouldn't mind. Basic politeness should be a given and shouldn't take any effort on your part to achieve it.

This is more true in fuzzy subjects. For example, care to explain what do you mean by "decode"? Can an EVC Baseline decoder decode EVC Main in any capacity? Even with artifacts and dropped frames and such? Because that's "decodable". Also, that's what the whole "individually switchable coding tools" is supposed to mean, that you can skip stuff and still be able to decode the bitstream to some capacity. If ISO redefined the term you can see how it can be confusing.

[rwill]

This is more true in fuzzy subjects. For example, care to explain what do you mean by "decode"? Can an EVC Baseline decoder decode EVC Main in any capacity? Even with artifacts and dropped frames and such? Because that's "decodable". Also, that's what the whole "individually switchable coding tools" is supposed to mean, that you can skip stuff and still be able to decode the bitstream to some capacity. If ISO redefined the term you can see how it can be confusing.

This is getting better and better with each post. Have a nice day.

[kurkosdr]

This is getting better and better with each post. Have a nice day.
Look man, if you are trying to pull of the "grumpy video engineer" vibe, let me tell you it's not working. You just come off as rude.

Anyway, I'll ask someone else in some other thread what that "individually switchable coding tools" thing actually means. We are off-topic anyway.

[ksec]

Any news on x266?

[birdie]

Any news on x266?

Nothing. It's extremely delayed.

[FranceBB]

Nothing from my side either... One of my colleagues even tagged the actual guys working on it on a post on LinkedIn but they never replied... :(

[LigH]

No, this is the wrong thread. The x266 VVC encoder will be a specific encoder, and any other encoder is not the topic here. A general thread for all VVC development would be over here (https://forum.doom9.org/showthread.php?t=174940).
In your case, even creating a new thread would be suitable, as I believe you want to discuss an issue specific to this encoder you are using.

Regarding double backslashes: This may happen in programming languages like Python because a backslash is both a path separator in Windows and an escape character for special characters (C printf).

[guest]

No, this is the wrong thread. The x266 VVC encoder will be a specific encoder, and any other encoder is not the topic here. A general thread for all VVC development would be over here (https://forum.doom9.org/showthread.php?t=174940).
In your case, even creating a new thread would be suitable, as I believe you want to discuss an issue specific to this encoder you are using.

Regarding double backslashes: This may happen in programming languages like Python because a backslash is both a path separator in Windows and an escape character for special characters (C printf).

OK, thanks LigH, I will post it there, and see what happens, if that fails then I might consider starting a specific thread.

But the double backslash, would that be an error in how the app was written, or Windows...or even the version of Python.

Are there any usable VCC encoder GUI's available, yet ??

I will delete the below post.

[LigH]

The problem is not the double backslash, but rather that the converter expects a JPEG file in the Windows\system32 directory. No files should be created there by any application. It might miss a proper path to the temp.jpg file and look in default directories alternatively because it did not find it where it should have looked instead, which might be okay for required DLLs but not for data files.

Not many VVC encoders exist yet. Most are still in a testing phase and not well optimized. So there is not much incentive yet in creating a GUI for an encoder which may change rather much in the future. But searching Google for "VVC encoder GUI", I did find a few projects. And I would recommend to search the VideoHelp software archive for "VVC" too, now and then, pretty sure new ones will appear there sooner or later.

[birdie]

All GUI encoding applications suck by definition. If the OP is really interested in video encoding, they must learn to use console. It's not so difficult, children at the age of 9 do it in a few days.

[benwaggoner]

All GUI encoding applications suck by definition. If the OP is really interested in video encoding, they must learn to use console. It's not so difficult, children at the age of 9 do it in a few days.
That is probably one of the biggest changes over my career. From 1995-2010 or so, the GUI tools offered as much or more control as command line. The decline of the workstation software market and the transition to cloud-based adaptive streaming really hurt us there. The last commercial GUI tool that offered pretty much complete parameter access while offering the kind of live preview and parameter rationalization features only GUI can do well was Expression Encoder.

One could do a lot with a commercial-grade GUI to the various open and closed source libraries out there with say $5M of developer, product, UX design, and test resources. But who would collectively spend >>$5M on such a product anymore?

I tried to kick off an effort to do something like this back in 2002-2003, but my second kid was born and spending 80 hours a week to roll the dice on a startup didn't seem like a wise or practical option.

[ksec]

We are coming close to Mid Year 2024......

[rwill]

We are coming close to Mid Year 2024......

Maybe its time to "contribute a reasonable investment towards development of the x266 encoder" again.

[FranceBB]

Well, Sky (Comcast) is already in the Multicoreware partnership program and has been for years now (due to x265), so we're already playing our part I guess...

[birdie]

We are coming close to Mid Year 2024......

Multicoreware has adopted Valve time. :D

[Sirber]

The website from the original post is dead

[FranceBB]

The website from the original post is dead

Yes but the x266 page was just moved to a different page on the multicoreware website.

https://multicorewareinc.com/what-we-do/audio-video-solutions/x266-vvc-encoder/

[birdie]

The website from the original post is dead

You say the link is dead, I'd say the project is dead. :rolleyes:

They promised to release the encoder at the latest 8 months ago. Instead, there's been nothing but silence since then.

[LigH]

I could speculate that they lost developers, found new ones, and those first work on x265 features for different platforms (most commits in the last weeks were related to AArch64).

[GeoffreyA]

You say the link is dead, I'd say the project is dead. :rolleyes:

They promised to release the encoder at the latest 8 months ago. Instead, there's been nothing but silence since then.

It's disappointing. I'd think there are big problems in the encoder, so they're hesitant to release it, or perhaps it's even struggling against x265 and VVenC.

[LigH]

Or it is more profitable to first improve x265 for commercial uses before starting x266 with basic features.

[hajj_3]

Or it is more profitable to first improve x265 for commercial uses before starting x266 with basic features.

this is likely the reason as there aren't that many devices with h.266 hardware decoders so not many companies want to use it yet.

[birdie]

this is likely the reason as there aren't that many devices with h.266 hardware decoders so not many companies want to use it yet.

At the moment there are no consumer devices with a HW VVC decoder.

Intel's Lunar Lake is three weeks away and I'm far from sure it will be a smashing success.

[LigH]

Intel's Lunar Lake is three weeks away and I'm far from sure it will be a smashing success.

Laying off semiconductor experts (https://www.businesspost.ie/news/revealed-intel-offers-irish-staff-up-to-e500k-in-exit-packages-under-layoff-plan/) to preserve the Management Board???

Lunar Lake designs will be all by TSMC.

[kurkosdr]

You say the link is dead, I'd say the project is dead. :rolleyes:
I'd say the VVC format is dead. No optical disc format is using it (like 4K Blu-Ray settled on HEVC), no satellites are broadcasting in it, very few countries have terrestrial broadcasts in it, no browser supports passthrough for it (and even high-end GPUs sold today can't decode it), and very few OTT services are streaming in it. Compare this with HEVC's adoption 4 years after its finalization.

People have stocked up on HEVC-capable UHD TVs during the past 8 years, and good luck telling them that their perfectly good UHD TV (which is already receiving or streaming UHD content in HEVC) isn't good for receiving or streaming UHD because of this newfangled "VVC" thing. It's the same problem that doomed MPEG4 ASP: no new resolution came with it, and breaking existing MPEG2 SD receivers was a no-no. Also, AV1 has captured whatever niche VVC may had as the successor to HEVC in subscription streaming services like Netflix (free-to-view services like YouTube and Twitch were always out of the question for VVC).

Is developing x266 worth it to satisfy a few countries and a few OTT services? Probably not. I'd say Multicoreware has simply lost interest and has moved to the next big thing (MV-HEVC for the Vision Pro? They are gradually adding (https://bitbucket.org/multicoreware/x265_git/commits/?search=MV) MV-HEVC support in x265).

Let's see what ISO and ITU achieve with ECM.

[FranceBB]

No optical disc format is using it (like 4K Blu-Ray settled on HEVC), no satellites are broadcasting in it, very few countries have terrestrial broadcasts in it, no browser supports passthrough for it (and even high-end GPUs sold today can't decode it), and very few OTT services are streaming in it.


It will take time but they'll come.
We're just beginning to see proper software decoding support and the recent commits by Intel itself are laying the foundation of hardware decoding in the upcoming Lunar Lake integrated graphics of their CPUs and I'm sure NVIDIA will follow. If everything goes well, we're gonna have both software and hardware decoding before the end of the year. Of course, there's still no content for it, so it will take a while, but I'm sure we're gonna get there. I think that what hindered the adoption (in Europe) was a very unfortunate series of events that delayed further investments to some future date, but I'm sure we'll get there if and when 8K will become a thing.

[kurkosdr]

It will take time but they'll come.
We're just beginning to see proper software decoding support and the recent commits by Intel itself are laying the foundation of hardware decoding in the upcoming Lunar Lake integrated graphics of their CPUs and I'm sure NVIDIA will follow. If everything goes well, we're gonna have both software and hardware decoding before the end of the year. Of course, there's still no content for it, so it will take a while, but I'm sure we're gonna get there. I think that what hindered the adoption (in Europe) was a very unfortunate series of events that delayed further investments to some future date, but I'm sure we'll get there if and when 8K will become a thing.
8K is a solution looking for a problem to solve, so I wouldn't bet on it, even outside Europe.

Also, broadcasters are still finishing the transition to HEVC, and the ones that haven't started the transition want to use the existing installed base of UHD TVs sold over the past 8 years, telling people they should buy decoder boxes for their new or newish UHD TVs is a tough sell. A few countries have announced VVC plans, but they are the exception. Much like with MPEG4 ASP vs MPEG2, nobody wants to break compatibility with an existing huge installed base for 25~30% gains.

Let's see what ECM achieves. At least it'll be worth the compatibility breakage.

Anyway, my main point is: look at the clues. Multicoreware is more pre-occupied with adding MV-HEVC to x265 than bother to give an update for x266. Whatever demand for VVC encoding there is out there, it's less even compared to boutique stuff like spatial videos for the Vision Pro (which isn't exactly flying off the shelves).

[rwill]

look at the clues

You seem to be drawing certain conclusions from the "clues" for the industry. Like that implementing MV-HEVC is currently more important than working on a VVC encoder.

Now I am drawing different conclusions from the "clues" for MCW. Because most other commercial HEVC encoders got MV-HEVC over a year ago and those companies now all have a more or less working VVC encoder implementation.

[GeoffreyA]

Leaving out broadcasting, I think it's important to consider VVC in relation to AV1. The latter has archieved a fair bit of usage; it plays all right on most computers and devices; there is hardware decoding in current C/GPUs; post-2020 TVs tend to play it; and people, like anime encoders and, ahem, "others," have got familiar with the tools.

VVC, on the other hand, beats AV1 by a fraction, if Fraunhofer's encoder is representative. (Thankfully, there is now encoding in FFmpeg and decoding in players, though in diminution of this, Matroska demuxing hasn't been implemented, hindering usage in anime.) So, why break compatibility, or familiarity, for a small improvement? Indeed, that question still plays out with AV1 and HEVC a lot of the time.

As kurkosdr points out, it reminds me of MPEG-4 ASP and MPEG-2, where the gains were too small, despite DivX's marketing and later adoption in hardware. Then, when H.264 came out, there was no contest; it left older formats in the dust.

[LigH]

Remember, there is also uvg266 (https://forum.doom9.org/showthread.php?t=184093) as useable VVC encoder. It may not support the whole range of features in depth but is worth trying as casual alternative.

[GeoffreyA]

Remember, there is also uvg266 (https://forum.doom9.org/showthread.php?t=184093) as useable VVC encoder. It may not support the whole range of features in depth but is worth trying as casual alternative.

Thanks. I haven't tried that one yet.

[ksec]

VVC, on the other hand, beats AV1 by a fraction,


I guess people have different definition of fraction. But I see average around 10% BD-Rate and up to 20% when compared to AV1. And that is against an AV1 encoder that is quite well tuned.

And we may actually see more VVC hardware Encoder in camera and smartphone than AV1.

[GeoffreyA]

I guess people have different definition of fraction. But I see average around 10% BD-Rate and up to 20% when compared to AV1. And that is against an AV1 encoder that is quite well tuned.

And we may actually see more VVC hardware Encoder in camera and smartphone than AV1.

To be sure, there is a clear visual difference, and the picture is sharper and more consistent within the frame. I much prefer it. AV1, at least mainline aom, loses a lot of details and overdoes it with temporal filtering (which has occasional defects, too, when applied to keyframes and must be adjusted). There's a new SVT-AV1-PSY fork that I want to try, though, and their low-luminance quantisation dropping got merged into mainline. At any rate, I have looked forward to VVC for years but feel disappointed these days how everything has gone.

[ksec]

Time of the year to ask if x266 code name Duke Nukem Forever will come.

[birdie]

Time of the year to ask if x266 code name Duke Nukem Forever will come.

https://m.media-amazon.com/images/I/41x244sdEXL._AC_UF894,1000_QL80_.jpg

:p

[GeoffreyA]

The truth---or source code---is out there :)

[quietvoid]

Apparently they're still working on it: https://www.youtube.com/watch?v=GE4xMNnMEyE

[microchip8]

This is the way...

[rwill]

What does "Average Speedup 0.01x" mean ? I have a suspicion but cannot be sure.