Versatile Video Coding (VVC) / H.266: HEVC successor

[ksec]

Interestingly Sisvel (the patent pool company) is on the list of access advance patent owners.

Throughout these years the Group has worked closely with over 25 patent owners, including:

3M; British Broadcasting Corporation (BBC); DTVG Licensing (a subsidiary of DIRECTV); Electronics and Telecommunications Research Institute (ETRI); France Telecom/Orange; Fraunhofer IIS; Hewlett Packard; LG Electronics; Motorola; Nippon Telegraph and Telephone Corporation; NTT DOCOMO; Nokia; Panasonic; Radiotelevisione Italiana (RAI); Royal KPN; Royal Philips; Samsung; Siemens; SIDSA; SK Telecom; TB Invent; TDF; Telecom Bretagne; Telecom Italia; ThingMagic; Victor Company of Japan (JVC) and Zebra Technologies.

[ksec]

https://www.rapidtvnews.com/2022120763207/v-nova-globo-kick-off-lcevc-experimental-broadcast-for-world-cup.html

The showcase also features the first end-to-end trial over DASH streaming of an LCEVC-enhanced VVC video, as an example of the capabilities that are developing to support the upcoming TV 3.0 standard, Brazil’s next-generation DTT system that is being specified by the Brazilian SBTVD Forum and is due to be deployed in 2025. It is the first time these technologies are being used in a complete end-to-end production to provide 4K HDR video with immersive and personalised audio. The system will facilitate the distribution of current and future formats, including 8K resolution, HDR and Next-Generation Audio (NGA) to over-the-air broadcast (OTA) and over-the-top (OTT) streaming platforms.

The LCEVC live showcase is running during the FIFA World Cup Qatar 2022 from 20 November to 18 December 2022.

[hajj_3]

https://www.rapidtvnews.com/2022120763207/v-nova-globo-kick-off-lcevc-experimental-broadcast-for-world-cup.html

I guess that hardware decoders for vvc ecm (h.267) won't be ready for 2025 so lcevc + vvc makes sense.

[benwaggoner]

I guess that hardware decoders for vvc ecm (h.267) won't be ready for 2025 so lcevc + vvc makes sense.
Do you think LC-EVC + H.267 wouldn't make sense? I've not been following the ECM work in detail yet.

[ksec]

Do you think LC-EVC + H.267 wouldn't make sense? I've not been following the ECM work in detail yet.

At the moment ECM is basically further improved VTM + a somewhat different take of LC-EVC.

[asarian]

vvenc 1.6.1 is something to behold, though it's extremely slow.

Tried it with `--preset slower --qp 20` (near perfect detail preservation) and it's really really really good. Beats AV1 by a wide margin.

Are there pre-built Windows binaries for it yet? I'd love to use it. :)

[Boulder]

Are there pre-built Windows binaries for it yet? I'd love to use it. :)

I suppose you can use Media-autobuild Suite to compile a binary (along with many others) if none are readily available.
https://github.com/m-ab-s/media-autobuild_suite

[asarian]

:thanks:

[LigH]

New uploads: [Windows][GCC 12.2.0][64 bit]

VTM Encoder/Decoder Version 19.0rc1 (https://www.mediafire.com/file/9wskhtq5fk4e9y3/VTM_19.0rc1_cf6653dc.7z/file) cf6653dc

Fraunhofer VVC Encoder ver. 1.6.1 (https://www.mediafire.com/file/b9eug58oimoiyv9/vvenc_1.6.1-34d3898.7z/file) 34d3898

Fraunhofer VVC Decoder ver. 1.6.0 (https://www.mediafire.com/file/zbp8ei1alwpchhc/vvdec_1.6.0-6494d7a.7z/file) 6494d7a

You should read back more before asking for already existing things :p

[ksec]

NHK Highlight VVC Advances for 8K

https://8kassociation.com/industry-info/8k-news/nhk-highlight-vvc-advances-for-8k/

[benwaggoner]

NHK Highlight VVC Advances for 8K

https://8kassociation.com/industry-info/8k-news/nhk-highlight-vvc-advances-for-8k/
Spatial enhancement layers have been around forever, and are commonly used in videoconferencing. They've rarely been used in VOD or broadcast, as the overhead of the layers has been significant. The total bits required to get the top layer can easily be 10-20% more than if the top resolution had been encoded directly. I've not dived deeply into VVC's scalable implementation to see if they've made the layering overhead smaller, which could help.

An 8K top layer, or even a 4K, can be quite low with content that doesn't have that much detail in the first place, as the upscaled lower resolution can look pretty much the same. For lots of content, 2160p and 1080p don't look that different, and for moving image viewing distances it's hard to find examples where >2160p has discernible additional detail outside of carefully constructed A/B comparisons. Particularly not with classic 24p with 1/48th sec shutter speed as motion blur will eradicate any theoretical extra detail with even very slight motion.

The LC-EVC approach is interesting as well, being metadata driven with much lower overhead than a whole spatial enhancement layer.

[sonnati]

The LC-EVC approach is interesting as well, being metadata driven with much lower overhead than a whole spatial enhancement layer.

I'm not sure LC-EVC is metadata driven. Outside some frame level params and a parametric synthetic grain generator there's an actual enhancement layer (with very simple time prediction).

[birdie]

A new series of patches (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7922) to add VVC support in FFMpeg has been published. They use vvdec/vvenc libraries for decoding/encoding. Authored by Thomas Siedel (https://spin-digital.com/wp-content/uploads/2018/04/spin-digital-022w.jpg) from Spin Digital. They are compatible with FFMpeg 5.1.2. I'll test them ASAP. Finally something worth testing. Found them accidentally using Google.

[ksec]

A new series of patches (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7922) to add VVC support in FFMpeg has been published. They use vvdec/vvenc libraries for decoding/encoding. Authored by Thomas Siedel (https://spin-digital.com/wp-content/uploads/2018/04/spin-digital-022w.jpg) from Spin Digital. They are compatible with FFMpeg 5.1.2. I'll test them ASAP. Finally something worth testing. Found them accidentally using Google.

I was surprised considering their previous stand on AV1 only. Turns out this is on patchwork and not on official FFmpeg 5.2 Dev.

[birdie]

I was surprised considering their previous stand on AV1 only. Turns out this is on patchwork and not on official FFmpeg 5.2 Dev.

Yep, they are just published, not yet merged.

AFAIK FFMpeg developers don't oppose them, they just need well written code which will be properly maintained.

[ksec]

Yep, they are just published, not yet merged.

AFAIK FFMpeg developers don't oppose them, they just need well written code which will be properly maintained.

I am not sure if it is officially official. But I remember a few members of FFmpeg have on multiple occasions said they do not intend to include VVC into mainline work given how some of them are working on AV1 and are committing to AV1.

There were VVC related work submitted in 2020 already. And AFAIK none of them have been included.

[birdie]

I am not sure if it is officially official. But I remember a few members of FFmpeg have on multiple occasions said they do not intend to include VVC into mainline work given how some of them are working on AV1 and are committing to AV1.

I've never heard anyone say or imply that. Citations needed.

There were VVC related work submitted in 2020 already. And AFAIK none of them have been included.

And it was merged (https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=commit&s=VVC), no prob.

[birdie]

The above patches build with the current FFMpeg git snapshot (they are not compatible with version 5.1.2) and you can watch VVC encoded videos just fine.

https://i.ibb.co/dMj6Q0L/Screenshot-2022-12-27.webp

[ksec]

An interesting comparison between CPU and Hardware H.264 / H.265 and AV1 Encoding.

https://rigaya.github.io/vq_results/

[birdie]

An interesting comparison between CPU and Hardware H.264 / H.265 and AV1 Encoding.

https://rigaya.github.io/vq_results/

This is a topic about VVC.

[ksec]

I've never heard anyone say or imply that. Citations needed.



And it was merged (https://git.ffmpeg.org/gitweb/ffmpeg.git?a=search&h=HEAD&st=commit&s=VVC), no prob.

Apart from Nuo Mi's commit, all the other VVC has nothing to do with H.267 itself but Dolby Vision Configuration Box aka 'dvvC'.

But I do remember it was a question from Nuo Mi on integration with VVC and FFmpeg. So I will probably look it up later.


Edit: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201221060710.12230-6-nuomi2021@gmail.com/#60590

Lynne Dec. 22, 2020, 4:10 p.m. UTC | #4
Dec 21, 2020, 07:07 by nuomi2021@gmail.com:

> you can download test clips here:
> https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/
>

Honestly, I'm not sure about this patch. Its an external library decoder, which
doesn't help us very much, and its for a codec competing with another codec
(AV1) for which we don't really have a native decoder for yet. Not to mention
some of us were involved with the effort to standardize and/or write a decoder
for AV1, so there's also a personal element to not wanting VVC to have any
success.

So I'm kind of against this particular patch as-is. I'd be okay with it being a native
decoder built into our codebase. But as-is, this serves nothing to help the
project, but only corporations who invested into the codec and want to see
some return on their investment from enforcing licensing on our users.
And no one is even really using this codec at the moment.



Nuo Mi Dec. 22, 2020, 5:02 p.m. UTC | #5
Hi Lynne,
Thanks for the comments.
We only have a small patch for the vvdec wrapper. All other codes (raw
demuxer, cbs reader, parser, and cbs writer in the future) will benefit the
native decoder and the vvc ecosystem.

I do not think av1 is the savior. No matter how it promised you, if we only
have one codec to choose from, it will be a disaster for all of us.
But, if you and the ffmpeg tech committee decided to reject all vvc patches
in the future, I can accept it and stop work on this.

BTW, do you know the detailed plan for av1 native decoder? will we port
dav1d back or implement a new one?

thanks

[FranceBB]

Not to mention
some of us were involved with the effort to standardize and/or write a decoder
for AV1, so there's also a personal element to not wanting VVC to have any
success.


this was a personal opinion which would be fine, however this:


So I'm kind of against this particular patch as-is.


is not.
I do understand people working on AV1 and such, but coming to the point of blocking an H.266 VVC decoding patch is too much. We should really be able to easily decode any codec, no matter what. With this logic, we would have never had reverse engineered decoders for codecs like DNxHR and Apple ProRes for video or indeed DolbyE and DolbyED2 for audio. Sure, one could make a reasoning on why he might want to see one codec succeed and another one fail, but not having the decoding isn't gonna help anyone, if anything it's gonna make things worse!

Think about DolbyE for instance.
You might want to say "Ah, FLAC should succeed so I'm not gonna add decoding".
Will corporations move to FLAC? Nope, they will just buy software decoders like DolbyDP600 and potentially make things worse as it would feed money straight to Dolby.
The same applies to video codecs, not having a video decoder for Apple ProRes would lead to people giving money to Apple 'cause they wouldn't be able to refuse such a masterfile, same thing for DNxHR with AVID and the same thing with MPEG-LA for H.266 VVC.

In a nutshell, I'm glad that nowadays Libav can decode pretty much anything (including proprietary codecs) and I really wouldn't want to see it stopping right now 'cause it would only make things harder for those who use those in professional settings like the various broadcasters.




I do not think av1 is the savior. No matter how it promised you, if we only
have one codec to choose from, it will be a disaster for all of us.


This is exactly right and I think exactly the same.



But, if you and the ffmpeg tech committee decided to reject all vvc patches
in the future, I can accept it and stop work on this.


This is even more dangerous.
We had 1 good guy working on the VVDec integration and they're making him go away and stop working on it, potentially. I mean, honestly, I really hope the people in the FFMpeg committee change their mind 'cause right now this way of thinking it's really not good and it's not gonna happen.
I mean, we can all be proud and thankful to google for what it has done with AV1 and everything, but we shouldn't really limit decoding to just open codecs 'cause it would mean the END of the open source tools in professional settings.

[nevcairiel]

Note that the main complaint is not against VVC in general, and such a complaint would never be able to stand anyway, but rather the patch merely being a thin wrapper around an external decoding library controlled by a corporation, rather then actual efforts to bring open and native decoding to FFmpeg.
If someone were to develop a native decoder for FFmpeg, and not an external library, none of these arguments would even exist. All these other proprietary codecs you mention have native decoders in FFmpeg.

I would recommend those "professional" users deriving revenue from FFmpeg to chip in and further such a project. FFmpeg does not make money, but developers need to eat.

PS:
The argument against "wrappers" is that they don't really further the open-source multimedia ecosystem. Even decoders benefit from competition, which is why dav1d was created by a group of ffmpeg developers (and others), instead of just using aom.

[Wiabol]

A decoder developed by a corporation. Bold opinion for a bunch of Google fanboys.

VVC, just as AV1 are becoming too complex to be integrated into the main codebase. That's why there's David.

[birdie]

Note that the main complaint is not against VVC in general, and such a complaint would never be able to stand anyway, but rather the patch merely being a thin wrapper around an external decoding library controlled by a corporation, rather then actual efforts to bring open and native decoding to FFmpeg.
If someone were to develop a native decoder for FFmpeg, and not an external library, none of these arguments would even exist. All these other proprietary codecs you mention have native decoders in FFmpeg.

I would recommend those "professional" users deriving revenue from FFmpeg to chip in and further such a project. FFmpeg does not make money, but developers need to eat.

PS:
The argument against "wrappers" is that they don't really further the open-source multimedia ecosystem. Even decoders benefit from competition, which is why dav1d was created by a group of ffmpeg developers (and others), instead of just using aom.

Tons of codecs are supported exactly this way in FFMpeg - by using "thin" wrappers for external libraries.

This includes AV1 as well.

[rwill]

The argument against "wrappers" is that they don't really further the open-source multimedia ecosystem. Even decoders benefit from competition, which is why dav1d was created by a group of ffmpeg developers (and others), instead of just using aom.

But this "argument" can easily be debunked.

VVdeC is under 3-clause BSD. IT hardly can be more open source than that. By that "argument"s logic x265 should be removed too as it is integrated with a wrapper and developed by a corporation.

[birdie]

I've just talked to FFMpeg developers in their IRC channel.

No one opposes VVC, it's just no one is currently interested in it, thus no one wants to review the patches to merge them. There are no other reasons. As simple as that.

At least yesterday's FFMpeg GIT snapshot works fine with them, so there's that.

I'm pretty sure if companies behind VVC actually cared, they'd sponsor someone to get this code merged. Darn.

[nevcairiel]

But this "argument" can easily be debunked.

VVdeC is under 3-clause BSD. IT hardly can be more open source than that.

No where did I mention the license. Everyone relying on the exact same codebase to do decoding also doesn't debunk the competition I mentioned.

By that "argument"s logic x265 should be removed too as it is integrated with a wrapper and developed by a corporation.

We are talking about decoders here. Encoding is a very different task, and a much more complex thing to implement (well).

--

At the end of the day, no format is being blocked based on it being disliked or in competition to anyones favorite format. People may express that sentiment, as is their right, but it will not be taken into account by other developers to decide if its suitable for merging. The main reason something doesn't get merged is either one of two things - patchset needs work, and/or no developer is available (or interested) in dealing with it.

[rwill]

No where did I mention the license. Everyone relying on the exact same codebase to do decoding also doesn't debunk the competition I mentioned.


Yes, you did not mention the license, you did mention the "open-source multimedia ecosystem" though. And one wrapped decoder is better than none.



We are talking about decoders here. Encoding is a very different task, and a much more complex thing to implement (well).


Well decoding seems to be a complex thing too because last time I checked the FFmpeg H.262 and H.264 decoders failed in decoding conformance streams correctly.

HEVC support is much better but they are "wrapping" OpenHEVC there?

[nevcairiel]

OpenHEVC was/is a fork of libavcodec, which then got re-integrated into ffmpeg eventually. It does not require any external dependencies to work.

[FranceBB]

I would recommend those "professional" users deriving revenue from FFmpeg to chip in and further such a project. FFmpeg does not make money, but developers need to eat.


Not FFMpeg but open source in general and believe me, they do. Think about AVC Intra classes in x264, if it wasn't for NRK funding the development, we wouldn't have those.
Same goes for DolbyE and DolbyED2 decoders written by Nicolas Gaullier who works for a French broadcasting company, Sky/Comcast funding x265 development with Multicoreware and I could go on, but there are lots of TVs helping out as they can in open source development. Even me, in my little, I try to contribute as much as I can to the community.


I'm pretty sure if companies behind VVC actually cared, they'd sponsor someone to get this code merged. Darn.

Easier said than done.
I'm still trying to get the code for the DolbyED2 Atmos decoder merged to the main FFMpeg codebase and I begged the mailing list to no avail.
If someone has the power to merge, please merge: https://trac.ffmpeg.org/ticket/9864

[MartinEesmaa]

I updated libvvenc codes for new vvenc patch:
https://github.com/MartinEesmaa/FFmpeg-FixVVC/commit/6622bf8e566a7656bbae306d336f2f89c3462381

Original patches:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7922

Builds of latest FFmpeg VVCEasy:
https://github.com/MartinEesmaa/VVCEasy/blob/master/FFMPEGVVC.md#ffmpeg-downloads-xhe-aac--vvc-endecoder-plugin-compiled-by-martin-eesmaa

- Martin Eesmaa

[birdie]

A patch series to support VVC encoding/decoding in ffmpeg via vvenc/vvdec has again been resubmitted (https://patchwork.ffmpeg.org/project/ffmpeg/cover/20230103134040.41140-1-thomas.ff@spin-digital.com/). There are minor fixes here and there:

This patch set adds H266/VVC support.
This includes parsing, muxing, demuxing, decoding and encoding.
Decoding is done using the external library VVdeC
(https://github.com/fraunhoferhhi/vvdec.git) and can be enabled with
--enable-libvvdec.
Encoding is done using the external library VVenC
(https://github.com/fraunhoferhhi/vvenc.git) and can be enabled with
--enable-libvvenc.

Changes since v4:

General:
- Add original author to patches 01-03
- Add co-author to patches 04 and 05

PATCH 02/10 configure / cbs_h266_syntax_template
- bugfix: add cbs_h266, cbs_h266_select (moved from patch 03/10)
- bugfix: parsing multilayer in cbs_h265_syntax_template

PATCH 03/10 libavcodec/vvc_parser.c
- bugfix: check startcode length (3 or 4 byte) to
find correct frame end position

PATCH 06/10 libavformat/movenc.c
- merge movenc.c with upstream

PATCH 07/10 libavcodec/libvvdec.c
- bugfix: set correct avframe pts for decoded picture
- bugfix: print additional info if decoding fails

Nuo Mi (3):
avcodec: add enum types for H266/VVC
avcodec: add cbs for H266/VVC
avcodec: add bitstream parser for H266/VVC

Thomas Siedel (7):
avcodec: add MP4 to annexb support for H266/VVC
avformat: add demuxer and probe support for H266/VVC
avformat: add muxer support for H266/VVC
avcodec: add external decoder libvvdec for H266/VVC
avcodec: add external encoder libvvenc for H266/VVC
avformat: add ts stream types for H266/VVC
avcodec: increase minor version for H266/VVC

[FranceBB]

Yep.
Looks like Thomas Siedel from Spin Digital is trying again to get it approved and merged to master and at this point I really hope it is.

[FranceBB]

Hey guys,
there's gonna be a webinar with the multicoreware guys about x266, at what point the project is etc.
I strongly encourage everyone to participate.

https://us02web.zoom.us/webinar/register/WN_P1yr85_ZSDKIvWPmw2jUxw

It's gonna be January 31st at 5PM UK Time.

[Jamaika]

Decoder VVC
https://github.com/ffvvc/FFmpeg

[Jamaika]

VVCSoftware_VTM 19.2-06a9a140
https://www.sendspace.com/file/jmqw85

[birdie]

I've discovered a large library of uncompressed 4K videos under the Creative Commons Attribution 4.0 International License from the European Space Observatory. You can get them here (https://www.eso.org/public/videos/). Will try to compress them visually losslessly using x264, x265 and VVENC and see who wins.

The codec used is hqx (https://wwwapps.grassvalley.com/docs/WhitePapers/professional/GV-4097M_HQX_Whitepaper.pdf) (CHQX (https://codecs.multimedia.cx/2013/05/final-words-on-canopus-hq-hqa-and-hqx/) / 0x58514843), yuv422p16le(10 bpc) - no idea what it is, but it must be uncompressed (https://www.videohelp.com/software/Grass-Valley-HQX-Codec).

Grass Valley HQX, as an intermediate codec, is specifically designed for editing and post-production: Can withstand re-encoding without significant quality loss. Is built for high speed and low-CPU usage. Allows accurate inter-frame cuts (not grouped around keyframes). Has well-defined chroma characteristics. It is available for both Windows and Macintosh platforms, handles many different video resolutions up to and including 8K (DCI), incorporates an alpha channel for graphics handling, and is available in 8-bit and 10-bit versions. The Grass Valley Codec Pack includes/allows you to import and export video files that use the Grass Valley HQ, Grass Valley HQX, Grass Valley Lossless, and Grass Valley DV codecs.

[FranceBB]

The codec used is hqx (https://wwwapps.grassvalley.com/docs/WhitePapers/professional/GV-4097M_HQX_Whitepaper.pdf) (CHQX (https://codecs.multimedia.cx/2013/05/final-words-on-canopus-hq-hqa-and-hqx/) / 0x58514843), yuv422p16le(10 bpc) - no idea what it is, but it must be uncompressed (https://www.videohelp.com/software/Grass-Valley-HQX-Codec).

Nope.
The GV codec has three profiles: HQ, HQX, Lossless.
In this case they used the HQX profile which is lossy, so it's not lossless nor uncompressed, it's compressed and lossy.
It's a very good mezzanine file, though, generally used for those who need to edit or indeed store it as TX Master for playout in Grass Valley based systems. It's basically the Grass Valley's rival of AVID's DNxHR.

[birdie]

Nope.
The GV codec has three profiles: HQ, HQX, Lossless.
In this case they used the HQX profile which is lossy, so it's not lossless nor uncompressed, it's compressed and lossy.
It's a very good mezzanine file, though, generally used for those who need to edit or indeed store it as TX Master for playout in Grass Valley based systems. It's basically the Grass Valley's rival of AVID's DNxHR.

I've not noticed any perceivable compression artifacts, the bitrate is outright insane, for the file that I downloaded, it's 1 332 878 kb/s, which surely looks like compression, if there is any, is minimal.

4K Bluray has around 75Mbps bitrate - files from the observatory are ~ 18 times denser.

[FranceBB]

I've not noticed any perceivable compression artifacts, the bitrate is outright insane, for the file that I downloaded, it's 1 332 878 kb/s, which surely looks like compression, if there is any, is minimal.

4K Bluray has around 75Mbps bitrate - files from the observatory are ~ 18 times denser.

Yeah, they're called mezzanine files. It's what professional broadcast studios use internally.
For instance, you might have Grass Valley playout ports that play such a file and then output a signal via SDI. Such a signal is then received by an hardware encoder which encodes it as either MPEG-2 for SD channels, H.264 for HD/FULL HD channels and H.265 for UHD channels at consumer tier bitrates, generally around 2.5 Mbit/s for MPEG-2, 12 Mbit/s for H.264 FHD and 25 Mbit/s for H.265 UHD.
Internally, though, it's really not uncommon to see those kind of mezzanine files used and stored/archived.
Keep in mind that what users see is not what studios archive.
As I said, AVID systems use DNxHR, which is quite similar and can reach similar bitrates.

[Asmodian]

The codec used is hqx (https://wwwapps.grassvalley.com/docs/WhitePapers/professional/GV-4097M_HQX_Whitepaper.pdf) (CHQX (https://codecs.multimedia.cx/2013/05/final-words-on-canopus-hq-hqa-and-hqx/) / 0x58514843), yuv422p16le(10 bpc) - no idea what it is, but it must be uncompressed (https://www.videohelp.com/software/Grass-Valley-HQX-Codec).

Uncompressed 3840x2160 10 bpc @ 25 fps is 6220800 kbps (10 x 3 x 3840 x 2160 x 25). 1332878 kb/s is 4.67 times smaller. A very light compression ratio for video, but still compressed. ;)

[benwaggoner]

Uncompressed 3840x2160 10 bpc @ 25 fps is 6220800 kbps (10 x 3 x 3840 x 2160 x 25). 1332878 kb/s is 4.67 times smaller. A very light compression ratio for video, but still compressed. ;)
Yeah, lossless compressed HEVC is only 2-3x larger. We have a ton of peer-reviewed data about mezzanine codecs not impacting final video quality visibly after dozens of generations of reencodes.

[birdie]

The biggest takeaway from today's MulticoreWare x266 webinar: the codec has actively been developed, it's not ready yet, version 1.0 will be released as open source in the second half of this year. The webinar will be published later.

The codec is developed from scratch, i.e. code from VVenc and the VTM reference coder is not used but consulted with.

ffmpeg integration is absolutely planned.

A lot more was said and shared but I wasn't paying enough attention.

[FranceBB]

A lot more was said and shared but I wasn't paying enough attention.

I'll share the slide later

[benwaggoner]

I'll share the slides later
Looking forward to them!

[FranceBB]

It's still early stages, but x266 is currently 13.3 times faster than VTM15 using the same input sources (tested with both FULL HD and UHD materials) and settings thanks to the manually written asm, however it requires about 5% more bitrate. This is with lossy encoding, however it will also support lossless encoding. It's not open source yet but it will supposedly be in Q2 2023 although there's no official date just yet. Once it will, it will take a bit more time to implement a few more stuff 'till version 2.0, then the ffmpeg implementation will probably happen. Down the line GPU acceleration will also be something that will be looked into, however it won't be OpenCL lookahead like we had in x264, but something new entirely and probably CUDA based but it's really too early to tell.
This is the exciting official roadmap (in green it's what has already been done):

https://i.imgur.com/HMCUo0A.png

I'm surprised not to see you at the zoom meeting, Ben.
I would share the slides from the meeting but I just noticed that it says "confidential - limited distribution", so I guess you'll have to wait for the multicoreware guys themselves to upload them.

[birdie]

I would share the slides from the meeting but I just noticed that it says "confidential - limited distribution", so I guess you'll have to wait for the multicoreware guys themselves to upload them.

Weirdly they never mentioned whether the webinar was public or under some sort of NDA. Considering they repeated multiple times that they would release it publicly, I guess there's nothing confidential about it.

[poisondeathray]

Down the line GPU acceleration will also be something that will be looked into, however it won't be OpenCL lookahead like we had in x264, but something new entirely and probably CUDA based but it's really too early to tell.

probably CUDA? Was that mentioned in the presentation or other slides?

Green team would be happy, but I doubt AMD / Intel / ARM/ Apple/ everyone else / would be happy

Thanks for the info & progress update

[FranceBB]

probably CUDA? Was that mentioned in the presentation or other slides?


No mention of CUDA in the slides, just a very vague "GPU hardware acceleration" as things that will be looked into, so I asked the question myself on whether it will be OpenCL or other open initiatives or CUDA.
They said that it's still really far too early to tell, v1.0 is barely there and a lot of coding tools + CPU Assembly optimizations need to be added before we'll even start to talk about that, however they said that given that NVIDIA has some nice things they can leverage on, they MIGHT consider CUDA.




Thanks for the info & progress update

No problem, it's something I care about and I really look forward to gets my hands dirty and make some real comparisons myself as soon as the first build is out.