EVC - Essential Video Coding / MPEG-5

[TomV]

Publicly available documents are posted here... https://mpeg.chiariglione.org/standards/exploration/future-video-coding/requirements-a-new-video-coding-standard
The public Call for Proposals (https://mpeg.chiariglione.org/sites/default/files/files/standards/parts/docs/New%20Video%20Coding%20Standard%20%20Call%20for%20Proposals.docx) is pasted below...

1 Introduction
There is a constant demand for more efficient video coding technologies, however coding efficiency is not the only factor which determines the industry choice of video coding technology for products and services.

2 Background
Video coding technologies should address the needs of existing and emerging real-world use cases. Video coding technology should also be easy to adopt from both technological and business perspectives.
At MPEG meeting 122 in April 2018 some industry representatives identified the need for a “licensing-friendly” video codec that would facilitate the timely availability of clear and transparent Type 2 licensing terms. Discussions during the meeting resulted in draft Requirements for a New Video Coding Standard [1] which suggested a streamlined standard development process.

3 Objectives
The primary objective is to develop a new video coding standard that addresses combinations of technical and business requirements that are not adequately met by existing standards.
The new video coding standard should provide a video compression solution which combines:
• coding efficiency similar to that of HEVC
• complexity suitable for real time encoding and decoding
• timely availability of licensing terms
• the ability to address existing and emerging use cases, including
o offline encoding for streaming VOD
o live OTT streaming

4 Streamlined Development Process
It is anticipated that the following development process will achieve the above objectives:
• A brief statement of requirements, as contained in the present document
• A call for proposals
• A testing of the responses received
• Identification of functionalities, each of which provides a specific benefit in terms of efficiency, complexity or ease of implementation
• Definition of a test model, test sequences and test conditions
o The test model should consist of two tool sets: a base and an enhanced tool set
o The base tool set should be configured with tools that were made public more than 20 years ago or for which a Type 1 declaration is received
o There should be additional tools in the enhanced tool set, each of which shall provide a significant improvement in coding efficiency and be capable of being cleanly switched off on an individual basis
• Specifying a target threshold level of performance improvement for the addition of any new tool to the enhanced tool set (e.g. 3% improvement in compression efficiency)
• Systematically reviewing the contribution to performance of previously adopted tools and removing those whose removal results in performance loss that falls below a target removal threshold (e.g. 1% loss of compression efficiency)
• Giving preference to adopting a smaller number of high performance tools relative to a larger number of lower performance tools
• Giving preference to the adoption of only one proposal (from one or more organizations) per functionality if the conditions so allow

The standard should be written so that tools can be cleanly switched off wherever possible and practical. All other considerations being equal, preference may be given to tools that were made public more than 20 years ago.

Proponents shall be encouraged to commit to the timely publication of licensing terms (e.g. within 2 years of FDIS stage) either individually or as part of a patent pool.

5 Profiles and Levels
The standard shall define profiles and levels targeted at different application scenarios that are of interest to industry.
In addition, the standard shall facilitate the creation of defined subsets of the standard by external bodies, e.g. by making tools as switchable as possible. Examples of such external bodies may include ATSC, BDA, DVB, etc.

6 Requirements
6.1 Compression Performance
For 10 bit operation, the base tool set should have a compression performance that is at least as good as AVC High 10. A combination of base plus enhanced tool sets should have a compression performance that is similar to or better than that of HEVC Main 10.
6.2 Picture Formats
The new codec shall support rectangular picture formats that will include all commonly used picture formats, ranging at least from VGA to 8Kx4K. Picture formats of arbitrary size shall also be supported, within limits specified by Levels.
6.3 Colour Spaces and Colour Sampling
a) YCbCr colour spaces with 4:2:0 sampling, 10 bits per component shall be supported
b) High dynamic range and wide colour gamut shall be supported
c) YCbCr/RGB 4:4:4 and YCbCr 4:2:2 should be supported
d) Bit depths up to 16 bits per component should be supported
6.4 Frame Rates
Fixed and variable rational frame rates shall be supported, with upper limits specified by levels.
6.5 Source Video Content Characteristics
The standard shall support the encoding of the full variety of characteristics of video content encountered in the envisioned applications (to the maximum extent feasible). This includes (electronic and film) camera-captured scenes, text and graphics mixed into a camera-captured video source, rendered animation content, rendered computer graphics, etc.
6.6 Complexity
The complexity shall allow for feasible implementation of encoding and decoding within the constraints of the available technology at the expected time of usage.
A decoder conforming to a profile consisting of base plus enhanced tool sets should be no more than three times as complex as for HEVC Main 10.
Key hardware and software metrics may include memory bandwidth, maximum block sizes, decoder runtime, power consumption, etc.
6.7 Low Delay
Encode plus decode latency as low as one frame duration shall be supported.
6.8 Random Access and Trick Modes
The standard shall support random access to certain positions in time of a stored video stream, and allow fast channel switching in the case of multi-channel services.
Pause, fast forward, normal speed reverse, and fast reverse access to a stored video bitstream shall be supported.
6.9 Error Resilience
Video bitstream segmentation and packetization methods for the target networks shall be supported.
Proper balance of increase in complexity, loss in coding efficiency and benefits achieved by the error resilience measures at the coding layer should be achieved.
6.10 Buffer Models
Buffer models shall be specified for target applications.

7 Timeline
The tentative timeline is as follows:
• Finalize Requirements and Evaluation Guidelines documents in October 2018
• Submission of decoded sequences and bitstreams by 9 January 2019
• Evaluation of proposals in January 2019
• Working draft in January 2019
• CD in March 2019
• DIS in July 2019
• FDIS in January 2020

[TomV]

At the recent MPEG meeting in Marakesh, proposals were submitted for EVC. I'll share more details as soon as I'm able to.

[benwaggoner]

Yeah, I've recently heard of EVC as potentially becoming the preferred codec for 8K encoding. Sounds like we'd be able to do some head-to-head comparisons with HEVC pretty soon. If decode complexity is up to 3x more than HEVC, I'd want to see >25% efficiency improvements over HEVC for another codec to make sense from a technical perspective.

"Licensing friendly" is very interesting, but hard to predict the value of.

[Jamaika]

As a layman I have some questions? Is it new codec or container?
Is this different from the assumptions of the VVC codec?
What codecs can we import into mpeg5. Nothing is mentioned about audio codecs.

[TomV]

As a layman I have some questions? Is it new codec or container?
Is this different from the assumptions of the VVC codec?
What codecs can we import into mpeg5. Nothing is mentioned about audio codecs.
EVC will be a new video coding standard, not a container. Don't be confused by the fact that MPEG-4 has multiple standards, including the MP4 container file format, and audio coding (AAC), as well as multiple video coding standards. This effort isn't meant to duplicate all that MPEG-4 produced. It is a separate effort from VVC.

From a recent blog post by the chairman of MPEG... https://www.linkedin.com/pulse/forty-years-video-coding-counting-leonardo-chiariglione/

At its 125th meeting MPEG has reviewed the responses to its Call for Proposals on a new video coding standard that sought proposals with a simplified coding structure and an accelerated development time of 12 months from working draft to FDIS. The new standard will be called MPEG-5 Essential Video Coding (EVC) and is expected to reach FDIS (Final Draft of International Standards) in January 2020.

The new video coding project will have a base layer/profile which is expected to be Option 1 and a second layer/profile that has already shown a performance ~25% better than HEVC. Licensing terms are expected to be published by patent holders within 2 years.

The baseline profile would be based on technologies that are no longer patented, and perhaps patents that will be licensed royalty free. It should have a complexity that is roughly on par with HEVC, or slightly higher, and an efficiency that is significantly better than AVC, but slightly less than HEVC. The main profile should have compression efficiency that is meaningfully better than HEVC (~ 30% when the standard is final), with a complexity that is maybe 3x HEVC.

Note the accelerated timeline. The goal is a final standard in one year.

[hajj_3]

It sounds like this codec is dead in the water before it has even begun.

1. There is no requirement for a single patent pool for the high profile version.
2. 2 years to publish patent licensing conditions is a long time. No-one is going to decide to adopt it during those 2 years due to the mess that HEVC licensing is.
3. Why would anyone want the free baseline profile that will offer roughly the same quality as HEVC when AV1 already matches that description but has already been ratified and will have hardware decoders way sooner? This would mean hardware chip vendors would have to use even more die space to add another codec decoder on their chips which many would not want to do.
4. Given that VVC will be ratified just months after this providing significantly more compression than this why would someone adopt the paid high profile version of this instead of paying a higher amount to licence the greatly superior VVC that will also have much greater hardware decoding support?

[TomV]

It sounds like this codec is dead in the water before it has even begun.
Maybe you should wait to read the actual proposals that were submitted in the recent MPEG meeting.

Adopters are willing to bear a reasonable cost (patent royalties, and higher compute requirements) if there is a clear benefit in compression efficiency. While AV1 claims zero royalty cost, the compute cost vs HEVC is extreme, and there is little to no actual benefit in compression efficiency (subjective quality of the video, vs. HEVC). At least, not if you're using the right HEVC encoder.

[Beelzebubu]

Maybe you should wait to read the actual proposals that were submitted in the recent MPEG meeting.

Adopters are willing to bear a reasonable cost (patent royalties, and higher compute requirements) if there is a clear benefit in compression efficiency. While AV1 claims zero royalty cost, the compute cost vs HEVC is extreme, and there is little to no actual benefit in compression efficiency (subjective quality of the video, vs. HEVC). At least, not if you're using the right HEVC encoder.

So you're allowed to choose the right HEVC encoder... I can only guess the same is true for AV1 then. Which AV1 encoder did you use for the subjective evaluations?

Don't mix up libaom, the PSNR-optimized reference encoder, and AV1, the standard - especially when using something else than PSNR as your output. People did this for libvpx also, and that unfairly (https://medium.com/netflix-techblog/performance-comparison-of-video-coding-standards-an-adaptive-streaming-perspective-d45d0183ca95) puts the standard in a bad spotlight.

[iwod]

It sounds like this codec is dead in the water before it has even begun.

1. There is no requirement for a single patent pool for the high profile version.
2. 2 years to publish patent licensing conditions is a long time. No-one is going to decide to adopt it during those 2 years due to the mess that HEVC licensing is.
3. Why would anyone want the free baseline profile that will offer roughly the same quality as HEVC when AV1 already matches that description but has already been ratified and will have hardware decoders way sooner? This would mean hardware chip vendors would have to use even more die space to add another codec decoder on their chips which many would not want to do.
4. Given that VVC will be ratified just months after this providing significantly more compression than this why would someone adopt the paid high profile version of this instead of paying a higher amount to licence the greatly superior VVC that will also have much greater hardware decoding support?

I am going to assume this codec will be similar to HEVC in technical terms, baseline decoding or even mainline decoding could reuse a lot of the current decoding block for HEVC. The additional die space requirement will likely be minimal. And likely a hybrid solution is possible with software update.

The current target of VVC isn't that much higher than what EVC is stating here. VVC is currently at 30+%, aiming to be 40%, and would like to achieve 50% if possible. While EVC is aiming to be 30% reduction.

I do agree though the patent pool within 2 years is way too long. And I am not understanding why they are doing this instead of working with VVC. I am guessing is because VVC are going with MCIF and aren't going through the MPEG group anymore?

[iwod]

So you're allowed to choose the right HEVC encoder... I can only guess the same is true for AV1 then. Which AV1 encoder did you use for the subjective evaluations?



Which AV1 encoder are their to choose from?

[nevcairiel]

Adopters are willing to bear a reasonable cost (patent royalties, and higher compute requirements) if there is a clear benefit in compression efficiency.

That still doesn't explain what the point of that baseline profile is. Worse and slower then HEVC? Who would ever use that? Anyone that matters already adopted HEVC or AV1, or even VP9, which sits in that performance space. Who is left?

For the alternate encoders, AV1 is very new, so they don't exist yet (publicly anyway). EVC on the other hand doesn't even exist yet on paper. So that comparison is still rather mood.
I'm sure EVE-AV1 will eventually exist and judging from EVE-VP9, it'll likely be a significant improvement over libaom.

Noone measures the performance of the MPEG reference encoders because everyone knows they are absolute rubbish. Yet libvpx or libaom are supposed to be the gold standard, and the entire codec is judged by their performance.

[Beelzebubu]

Which AV1 encoder are their to choose from?

I couldn't find the paper slides, but an incomplete list is here (https://youtu.be/qubPzBcYCTw?t=2477).

[iwod]

That still doesn't explain what the point of that baseline profile is. Worse and slower then HEVC? Who would ever use that? Anyone that matters already adopted HEVC or AV1, or even VP9, which sits in that performance space. Who is left?

For the alternate encoders, AV1 is very new, so they don't exist yet (publicly anyway). EVC on the other hand doesn't even exist yet on paper. So that comparison is still rather mood.
I'm sure EVE-AV1 will eventually exist and judging from EVE-VP9, it'll likely be a significant improvement over libaom.

Noone measures the performance of the MPEG reference encoders because everyone knows they are absolute rubbish. Yet libvpx or libaom are supposed to be the gold standard, and the entire codec is judged by their performance.

Hypothetically speaking, EVC baseline reads to me as a Royalty free cut down version of HEVC that could replace the current standard which is AVC.

[utack]

Hypothetically speaking, EVC baseline reads to me as a Royalty free cut down version of HEVC that could replace the current standard which is AVC.

But if you really want "roughly HEVC quality" and "royalty free" that is the market gap filled by VP9
And VP9 is deployed already, with every browser a lot of hardware supporting it out there

[TomV]

So you're allowed to choose the right HEVC encoder... I can only guess the same is true for AV1 then. Which AV1 encoder did you use for the subjective evaluations?

Don't mix up libaom, the PSNR-optimized reference encoder, and AV1, the standard - especially when using something else than PSNR as your output. People did this for libvpx also, and that unfairly (https://medium.com/netflix-techblog/performance-comparison-of-video-coding-standards-an-adaptive-streaming-perspective-d45d0183ca95) puts the standard in a bad spotlight.

If you don't know me, I make encoders for a living. I started x265 (with my team at MulticoreWare) 6 years ago, and led x265 until last year. For the past year I've been one of the leaders at Beamr, where I've worked with our much larger and more experienced team to insure that my new encoders (Beamr 4 and Beamr 5) are the best in the world.

Of course I recognize that libaom/aomenc is a PSNR optimized reference implementation of AV1. As I pointed out in a talk I gave a few months ago (https://youtu.be/vgE8-4rcXl0?t=2625), aomenc is actually part reference encoder, part production encoder. When you study the encoding tools (algorithms) in AV1, you realize that there is a crazy amount of computational complexity in most tools for very small incremental encoding efficiency gains. The net result, as Tim Terriberry pointed out at about 33:07 in this presentation (https://www.youtube.com/watch?v=qubPzBcYCTw) is that AV1 is more than 1000 (158 x a lot) times more complex than VP9. So, the opportunity for EVC is to provide a better combination of encoding efficiency, performance, and royalty cost/certainty than competing codecs. It seems to me that the baseline profile is targeting the same or better royalty cost/certainty as VP9, with a better combination of encoding efficiency and performance, while the main profile is targeting a higher coding efficiency (at a reasonable cost of compute), with much better royalty cost / certainty than HEVC. EVC main profile would then have significantly better encoding efficiency at a lower cost of compute than AV1, with similar patent license certainty, at a reasonable license cost. This is all brand new, so we'll have to see how the proposal is evaluated within MPEG, how well the standardization effort goes, and how many companies in the video domain choose to adopt and invest in EVC. Right now, we're at square 1. It's far too early to make any accurate predictions as to where EVC will be 1 year from now (when it hopes to be finalized), or beyond.

Keep in mind that standards that are developed within international standards bodies are preferred by many companies and other organizations over standards developed by individual companies or a consortium of companies, for a variety of reasons including the expected quality of the standard (completeness, documentation, interoperability, etc.).

[iwod]

But if you really want "roughly HEVC quality" and "royalty free" that is the market gap filled by VP9
And VP9 is deployed already, with every browser a lot of hardware supporting it out there

VP9 isn't really "standard", unlike AV1 which is well defined.
VP9 isn't supported by Apple, and likely never will be in Hardware. ( Because of Patents )
VP9 is pretty much a Google standard.
There are far more HEVC hardware decoder out there than VP9.

I reread the paper, and turns out the baseline is aiming at AVC HP10 quality or better. May be it is just better if we move on to AV2 or VVC.

[dapperdan]

Do they explain the strategy to avoid the problems that ruined their previous 4 or 5 attempts at royalty free standards (and/or royalty free subsets) some of which are detailed here: http://blog.chiariglione.org/forty-years-of-video-coding-and-counting/

But I believe there was at least two attempts to make a royalty free subsets of AVC not discussed there. What are they doing differently this time? Apart from removing the accidental veto power they gave to every member that sank the previous attempt. How confident are we they've not left similar poison pill provisions this time?

[TomV]

VP9 isn't really "standard", unlike AV1 which is well defined.
VP9 isn't supported by Apple, and likely never will be in Hardware. ( Because of Patents )
VP9 is pretty much a Google standard.
There are far more HEVC hardware decoder out there than VP9.

I reread the paper, and turns out the baseline is aiming at AVC HP10 quality or better. May be it is just better if we move on to AV2 or VVC.
Is AV1 a final standard? It wasn't when they announced at NAB 2018. Now they have an Errata 1, and when you download the standard it gives you a warning that it will be labeled a draft. So it's unclear whether it's really final. I've heard a lot of feedback, even from AV1 supporters that the way the standard is written and the reference implementations are written leaves a lot to be desired, from a standards point of view. The AOM has a very different process from ISO/ITU, MPEG/VGEG where working groups meet, proposals are submitted, discussed and voted on, etc.

You should expect EVC baseline profile to be significantly more efficient than AVC high profile 10. Close to HEVC.

[TomV]

Do they explain the strategy to avoid the problems that ruined their previous 4 or 5 attempts at royalty free standards (and/or royalty free subsets) some of which are detailed here: http://blog.chiariglione.org/forty-years-of-video-coding-and-counting/

But I believe there was at least two attempts to make a royalty free subsets of AVC not discussed there. What are they doing differently this time? Apart from removing the accidental veto power they gave to every member that sank the previous attempt. How confident are we they've not left similar poison pill provisions this time?

If I understand correctly, this not going to be a committee putting the standard together, as with AVC, HEVC, VVC. In fact, it's not a joint ISO MPEG/ITU VCEG standard (just ISO/MPEG). With EVC, companies, or small groups of companies submitted proposals, and only one proposal will be accepted. From that point forward, the winning proposal will be driven to the standard by the winning submitter. That company or group will be responsible for insuring the patents are licensable as well as for the technical standard.

[mandarinka]

I couldn't find the paper slides, but an incomplete list is here (https://youtu.be/qubPzBcYCTw?t=2477).

Realistically speaking, everything "closed source" is likely only available to the Netflixes of this world, am I right? With the Intel's thing likely geared to datacenter/services use too?

I guess the only thing that will cater to the old group of hobbyist and small users like divx/xvid, x264 and x265 did, will possibly be Rav1e (which is a new project that have yet to prove it can produce a competetive encoder, it will likely take a lot of time).

[benwaggoner]

But if you really want "roughly HEVC quality" and "royalty free" that is the market gap filled by VP9
And VP9 is deployed already, with every browser a lot of hardware supporting it out there
For real-world content, I have yet to see a VP9 encoder that can consistently match a well tuned x264 encode in double-blind testing. I don't know of any cases where VP9 is technically competitive with HEVC in real-world usage.

[iwod]

Is AV1 a final standard? It wasn't when they announced at NAB 2018. Now they have an Errata 1, and when you download the standard it gives you a warning that it will be labeled a draft. So it's unclear whether it's really final. I've heard a lot of feedback, even from AV1 supporters that the way the standard is written and the reference implementations are written leaves a lot to be desired, from a standards point of view. The AOM has a very different process from ISO/ITU, MPEG/VGEG where working groups meet, proposals are submitted, discussed and voted on, etc.

You should expect EVC baseline profile to be significantly more efficient than AVC high profile 10. Close to HEVC.

Yes it wasn't 1.0 in NAB 2018, it was released a few months later if I remember correctly, and later revised again with Errata. But it is at least officially 1.0, although not the 1.0 we have in mind if we follow the usual MPEG prospective.

It is nice to know what EVC baseline is aiming at. But why EVC? and not VVC? I mean why not EVC baseline + VVC?

As a consumer. I don't mind paying $2 more ( That is $1 for the cost of patents and $1 for their devices margin ) for supporting of new codec. It is just tiring watching these companies fighting over each other.



For real-world content, I have yet to see a VP9 encoder that can consistently match a well tuned x264 encode in double-blind testing. I don't know of any cases where VP9 is technically competitive with HEVC in real-world usage.

Thanks. Something I wanted to include in my original reply, but was afraid to be attacked by the VP9 / AV1 camp again.

[Beelzebubu]

For real-world content, I have yet to see a VP9 encoder that can consistently match a well tuned x264 encode in double-blind testing. I don't know of any cases where VP9 is technically competitive with HEVC in real-world usage.

As mentioned in my earlier reply, see Netflix' (https://medium.com/netflix-techblog/performance-comparison-of-video-coding-standards-an-adaptive-streaming-perspective-d45d0183ca95) blog post for sufficient evidence to support that there are good VP9 encoders out there.

[utack]

For real-world content, I have yet to see a VP9 encoder that can consistently match a well tuned x264 encode in double-blind testing. I don't know of any cases where VP9 is technically competitive with HEVC in real-world usage.

I think it depends on what you are doing?
For stuff like YouTube (low bitrate, high resolution) VP9 and even libvpx seem to do quite well.
For things like low resolution, archiving, bluray discs and other high bitrate cases the perceptual tuning in x264 seems to win.

[benwaggoner]

I think it depends on what you are doing?
For stuff like YouTube (low bitrate, high resolution) VP9 and even libvpx seem to do quite well.
There a big classes of content that look terrible on YouTube. Like any game footage. With enough bits, codecs converge on excellent quality. But I've not seen anything on YouTube in VP9 that I couldn't beat with x264 at the same bitrate and encoding time.

For things like low resolution, archiving, bluray discs and other high bitrate cases the perceptual tuning in x264 seems to win.
Perceptual tuning is important at all bitrates. It's what makes the small video good and the good video small.

[benwaggoner]

As mentioned in my earlier reply, see Netflix' (https://medium.com/netflix-techblog/performance-comparison-of-video-coding-standards-an-adaptive-streaming-perspective-d45d0183ca95) blog post for sufficient evidence to support that there are good VP9 encoders out there.
It's a nice paper, but doesn't present any real evidence, and has some real errors in its codec comparison. For example its "psnr" tuning omits --tune psnr for x264 and x265! And we don't have info on other tuning that got used. Was --tune film applied in x264? What aq-mode in x265? And worse, it is just fixed QP without rate control or adaptive quant, which is far from a real-world scenario. Libvpx has long-standing problems with poor rate control and adaptive quant, so this test turns off most of the stuff that makes x264/5 good and avoids a lot of the stuff in libvpx that causes problems. These encodes simply aren't representative of real-world use, so the study is comparing encodes heavily tuned for a non-existent scenario.

Also, while VMAF is out least-bad objective measure, but it is far from flawless. It doesn't catch blocking in blacks, it is quite forgiving of quality strobing, etcetera.

For me to find the results meaningful, I want full command-line parameters and either the output clips or statistically significant MOS scores from a well designed double-blind experiment.

I've been evaluating codecs since the 90's, and "promising BD curve' has maybe a 5% conversion rate to "big visible improvement."

I have fairly earned my cynical old man skepticism :)!

[Asilurr]

But I've not seen anything on YouTube in VP9 that I couldn't beat with x264 at the same bitrate and encoding time.That sounds like a challenge (https://forum.doom9.org/showthread.php?t=175776) to me. If you're willing to invest time into a few encodes of your own, a challenge that you can settle yourself.

Proposed workflow:
1. Grab latest FFmpeg nightly build from Zeranoe (https://ffmpeg.zeranoe.com/builds/), to bind all encodes to this common frame.
2. Feed ToS_1920x800_xdither.y4m into it, obtaining the two libvpx reference sets that I will elaborate upon below. These will have the hardware footprint of your machine (hopefully something reasonable, 4-16 logical processors, typical of what a real-world user would have access to at home), enabling apples-to-apples comparisons. Make sure to note the total encoding times (both passes) and average bitrates, then feed those into #3.
3. Replicate both the bitrate and the total encoding time with x264, again directly into the aforementioned FFmpeg build, to create two additional sets for comparison purposes. Feel free to go berserk with any optimization that you can think of, the only hard constraint is to disable parallelization (for one of these sets) as detailed below. Do keep in mind that you can guesstimate the final bitrates with reasonable accuracy if you use the first 1500 frames of the source as reference (FFmpeg equivalent: -frames:v 1500), that will greatly simplify the trial&error process of finding the x264 parameters which match the libvpx results.
[Optional!] 4. Redo #3 but using x265 instead.
5. Report your x264 parameters and encoding times, then share your results and comment freely (and verbosely) what your eyes actually see into these sets. Ignore the silly metrics altogether, ignore the "theory" behind the encoding, simply comment upon what a real-world user would see with their own eyes.

First libvpx reference set, designed to follow (naively) a typical Youtube-like encoding. That is to say strictly single-threaded (although we do file-based encodes here, not chunk-based as they do), and also at low bitrates; please make sure to disable explicitly any parallelization in the corresponding x264/x265 encodes. By copy-pasting the following directly you should end up with an average bitrate of about 1000k, although the encode is purely CRF-based.
ffmpeg -i TOS_1920x800_xdither.y4m -c:v libvpx-vp9 -pass 2 -row-mt 0 -frame-parallel 0 -tile-rows 0 -tile-columns 0 -threads 1 -g 120 -aq-mode 0 -auto-alt-ref 1 -enable-tpl 1 -rc_lookahead 25 -qmin 12 -qmax 63 -crf 45 -b:v 0 -deadline good -cpu-used 0 -skip_threshold 0 -static-thresh 0 -arnr_max_frames 10 -arnr_strength 5 -sharpness 0 -noise-sensitivity 1 crf45libvpx.mkv

Second libvpx reference set, aimed at high bitrates that should ensure visual transparency. Also a bit more "realistic" (from the perspective of a real-world user, as most will prefer file-based encodings over the hassle of the chunk-based counterparts), as it permits unrestricted parallelization. By copy-pasting the following directly you should end up with an average bitrate of about 4000k, but again the encode is purely CRF-based. Please use the specified -threads parameter as it is (for this particular instance of VP9 encoding), regardless of how many logical processors there are available to your machine.
ffmpeg -i TOS_1920x800_xdither.y4m -c:v libvpx-vp9 -pass 2 -row-mt 1 -frame-parallel 0 -tile-rows 0 -tile-columns 2 -threads 16 -g 120 -aq-mode 0 -auto-alt-ref 1 -enable-tpl 1 -rc_lookahead 25 -qmin 0 -qmax 63 -crf 25 -b:v 0 -deadline good -cpu-used 0 -skip_threshold 0 -static-thresh 0 -arnr_max_frames 3 -arnr_strength 1 -sharpness 2 -noise-sensitivity 0 crf25libvpx.mkv

That much said, all of the above is off-topic therefore the discussion should continue on the original thread dedicated to the challenge. I'm quite curious about your own results as this should be a fair real-world comparison of codecs (nota bene: tailored for a real-world user too, rather than a video compression specialist / engineer / scientist), with results obtained on the same machine to mitigate the impact of the hardware footprint. Interested in running these 4-6 encodes, Ben?

[Beelzebubu]

It's a nice paper, but doesn't present any real evidence, and has some real errors in its codec comparison. For example its "psnr" tuning omits --tune psnr for x264 and x265! And we don't have info on other tuning that got used.

Ah, fair! OK, so we know that they used --psy-rd=0 instead of --tune=psnr. Those of us familiar with the x264 source code (sorry, not an x265 expert here) know that --tune=psnr basically implies --psy-rd=0 --aq-mode=0. So they effectively used --tune=psnr but kept AQ enabled.

Is that fair? Probably not, no. In my experiments, enabling AQ hurts PSNR by slightly over 3% in BDRATE terms, so you can adjust the results accordingly. In this particular case, I don't think it affects the overall conclusion.

For me to find the results meaningful, I want full command-line parameters and [..]

The paper has them. (Your other concern about posting clips or MOS scores stands.)

I have fairly earned my cynical old man skepticism :)!

I think it's great to see it backed up, so we can constructively discuss it :) If that's cynical old-man skepticism, let's do more of it!

[IgorC]

Thanks. Something I wanted to include in my original reply, but was afraid to be attacked by the VP9 / AV1 camp again.
Everybody believes what wants to believe.

You prefer Beny's word (who is well known here to be pro-patent, pro HEVC, pro H.264 ) or if somebody wants to see really subjective results:
http://www.compression.ru/video/codec_comparison/hevc_2018/figures/chart_subj_vs_ssim.png
http://www.compression.ru/video/codec_comparison/hevc_2018/#subjective_report

[TomV]

http://www.compression.ru/video/codec_comparison/hevc_2018/#subjective_report
Good evidence that objective metrics are useless, eh?

Before you reach conclusions based on the subjective results, you should consider the MSU test design. In my opinion, it needs improvement. It does not meet a number of the criteria for a well-designed encoder comparison test, which I outlined in this blog post 18 months ago... http://x265.org/compare-video-encoders/

[IgorC]

Good evidence that objective metrics are useless, eh?

See "subjective test" part.


In my opinion, it needs improvement. It does not meet a number of the criteria for a well-designed encoder comparison test
It will help if You will be more specific.
If you wish let's get this topic into https://forum.doom9.org/showthread.php?t=174834&page=2


http://x265.org/compare-video-encoders

Yes, I'm familiar with this article. Still You are welcome to be more specific. And we are very familiar with already such a common practice of some developers of patented formats how A or B comparison is bad when someone compares lets say VP9 and HEVC.

I prefer independent comparisons like from MSU or Netflix who actually found VP9 at least on par with HEVC.

What about opinions on x265.org about x265 vs VP9? Nothing pesronal but it's reasonable that people will take it with a grain of salt, right?

[benwaggoner]

Yes, I'm familiar with this article. Still You are welcome to be more specific. And we are very familiar with already such a common practice of some developers of patented formats how A or B comparison is bad when someone compares lets say VP9 and HEVC.

I prefer independent comparisons like from MSU or Netflix who actually found VP9 at least on par with HEVC.

Preferring data from companies who have already determined a preference or benefit from a given conclusion isn't optimal whatever their implicit bias. And we are discussing issues prevalent with ALL codec comparisons, and are not necessarily indicative of any intentional bias or intent to obfuscate or mislead on anyone's part. Comparing codecs is extremely hard, and comparing encoders is very hard to do in any generalizable way.

What about opinions on x265.org about x265 vs VP9? Nothing pesronal but it's reasonable that people will take it with a grain of salt, right?
Opinions backed up with real-world samples are very interesting. I simply don't learn much from encodes that are constrained in ways extremely dissimilar to real-world use cases, or that compare plots of an objective metric. People watch video, and what's interesting is what people think of the video they watch, as that video can be practically created for a given use case.

Studies are great at answering the question asked by the methods. But it is dangerous to over-extrapolate from the answer a study gives to the question one really wants to answer.

The question "what's the best codec" is meaningless without answering "what are you trying to do with the codec?"

So much of these discussions conflate encoder implementation with bitstream specification, which are so basic and so different as to make a combined answer impossible. In many ways, the only question that can be definitively answered is "what is the subjectively best quality that can be encoded by today's best encoders for codecs in question for this scenario in question at this particular time."

And the answer for that absolutely changes over time! x264 beat x265 for a bunch of scenarios four years ago that x265 beats x264 for now. AV1 certainly beats the H.264 reference encoder, but won't beat x264 doing live encoding of 1080p24 cel animation. But I bet with proper tuning, libaom likely beats x264 for 1080p24 cel animation without any particular encoding time constraint. x265's cel animation just got better with 3.0 with --tune animation added, for scenarios when parameters can vary by content type.

I use the example of cel animation because that's something that different encoders vary wildly in how well they handle, even targeting the same bitstream. Standard test video libraries don't have much cel animation, so they often don't get tuned for until a prospective customer tries some.

[benwaggoner]

See "subjective test" part.

Reading over the methods of the test, I see they were all done using 10 second clips of industry standard test clips. Everyone has access to those clips, and encoders wind up being tuned to do those clips well. Like hundreds of hours for each of those 10 second sequences. And that's not cheating; it's optimizing for clips known to be particularly challenging. The whole comparison rests on 60 seconds of video that was chosen specifically to tune/test encoders on, with no attempt to make them representative of real-world content.

Stuff that's not included in those six clips:

Edits
Fades
Dissolves
Brightness variations
Motion graphics
"Normally" difficult content
Cel animation
CGI animation
Grainy content
Titles or credits
Letter/pillar boxing
Subtitles
Duration long enough to require more than one GOP


These are all critical things! We don't know how the encoders vary in keyframe strobing because there isn't any. Or how they work with grain, or combined natural image with text/graphics. Or fades to/from black. Or edits. Or how well they do weighted prediction.

This tells us how encoders do with six standard test clips that represent only a small fraction of real-world content types, and which encoders have had long opportunity to specifically tune against.

Also, x264/5 were tuned against those clips a lot less than reference encoders were. This test winds up implicitly biased against encoders tuned on a wide variety of sources instead of just the "standard" clips. But tuning against a wide variety of real-world sources is one of the key indicators of a good real-world encoder!

A better test would involve content that encoder developers hadn't seen before, randomly selected from out of a large library of real-world content, making sure to get examples of common video types. I would think at least a hundred different sources would be needed for reasonable coverage.

[TomV]

See "subjective test" part. Yes... note how much variance they reported between their objective testing and their subjective testing. They proved that objective testing is not nearly accurate enough to be useful when comparing codec implementations or coding standards.

[utack]

Discussion feels pretty stuck here.
The point of the "MPEG" camp seems to be that all the MPEG standards have reasonable good encoders, and AV1/VP9 do not, which no matter what you think of each standard is currently valid.

But here is the actual question: how is this connected to EVC at all?
Are the big plans to have EVC similar enough to HEVC that new and good encoders can be dropped practically at the same time is finalized? Is it similar enough to HEVC that all the deployed hardware decoders out there can be used for it and everyone using it has a massive potential userbase right away?
Because if this is not the case, and we turn the clock forward two years, then AV1 will have decoders being shipped consumer electronics, AV1 will most likely have about 5-6 encoders of which at least 1 should be pretty good by then, and EVC is just out the door with a slow and not so good reference encoder.
So what is the plan for it?

[TomV]

In a recent press release (https://mpeg.chiariglione.org/sites/default/files/files/meetings/docs/w18113.docx) from MPEG...
MPEG starts work on MPEG-5 Essential Video Coding
At its 125th meeting, MPEG commenced work on a new video coding standard to be known as MPEG-5 Essential Video Coding (EVC). There is a constant demand for more efficient video coding technologies, however, coding efficiency is not the only factor which determines the industry choice of video coding technology for products and services. MPEG-5 EVC seeks to provide a standardized video coding solution to address business needs in some use cases, such as video streaming, where existing ISO video coding standards have not been as widely adopted as might be expected from their purely technical characteristics.
MPEG-5 EVC will include a baseline profile that contains only technologies that are over 20 years old or are otherwise expected to be royalty-free. Additionally, a main profile adds a small number of additional tools, each of which is capable, on an individual basis, of being either cleanly switched off or else switched over to the corresponding baseline tool. Organisations making proposals for the main profile are encouraged to make a commitment to the timely publication of licensing terms. The target coding efficiency for the call for proposals was to be at least as efficient as HEVC. This target was exceeded by approximately 24% in the responses to the call for proposals, which were evaluated at this meeting. The development of the MPEG-5 EVC standard is expected to be completed in 2020.

[TomV]

But here is the actual question: how is this connected to EVC at all? So what is the plan for it?
We have to wait to see the specific proposals that were submitted and discussed at the recent MPEG meeting, and then to see which of the proposals will be accepted. We'll have a much better idea of the relative compression efficiency and the business case for EVC once we see the winning proposal.

[bstrobl]

We have to wait to see the specific proposals that were submitted and discussed at the recent MPEG meeting, and then to see which of the proposals will be accepted. We'll have a much better idea of the relative compression efficiency and the business case for EVC once we see the winning proposal.

Will only one proposal be taken and further developed with tools from others or will the codec be a combined development of multiple proposals? I can understand why only one proposal would be picked due to time constraints, however am still not sure how happy the other members will be if only one proposal is taken since that would be akin to VPx development with only one company calling the shots. Hardware vendors may also be unhappy with coding tools that can be turned on/off at will since that costs silicon.

[TomV]

It's my understanding that only one proposal will be accepted. There won't be coding tools that can be turned on/off at will... there will be a base profile and a main profile. If your silicon supports the main profile, those coding tools are always on.

[benwaggoner]

Discussion feels pretty stuck here.
The point of the "MPEG" camp seems to be that all the MPEG standards have reasonable good encoders, and AV1/VP9 do not, which no matter what you think of each standard is currently valid.
I wouldn't say "all" MPEG standards have reasonably good encoders. MPEG-2, H.264, and HEVC do. We don't have production-ready VVC encoders, and EVC is even farther away. I would argue there was never a really good MPEG-4 part 2 encoder (a challenging task due to some inherent bitstream limitations, and also because pt 2 never got broad commercial use).

But here is the actual question: how is this connected to EVC at all?
Are the big plans to have EVC similar enough to HEVC that new and good encoders can be dropped practically at the same time is finalized? Is it similar enough to HEVC that all the deployed hardware decoders out there can be used for it and everyone using it has a massive potential userbase right away?

[QUOTE]Because if this is not the case, and we turn the clock forward two years, then AV1 will have decoders being shipped consumer electronics, AV1 will most likely have about 5-6 encoders of which at least 1 should be pretty good by then, and EVC is just out the door with a slow and not so good reference encoder.
So what is the plan for it?
What happens with the AV1 encoder market is hard to predict. We don't really know what the "potential" of AV1 is for different use cases. There could be non-obvious bitstream limitations like MPEG-4 pt 2 had that limit its utility. There's not nearly enough 4K or 8K content encoded to iteratively tune encoding to see how good a codec it can be at high resolutions.

I'm sure that AV1 will get competent encoders for scenarios that get sustained investment. UGC scenarios like YouTube and Facebook's are already getting serious investment. Beyond that, a lot will depend on what happens relative to other codecs. Best case for AV1 is if a broad >20% subjective quality efficiency improvement over HEVC at similar encoding time is demonstrated, patent issues around HEVC and VVC remain unresolved, no patent issues emerge around AV1, EVC doesn't appear to offer any advantages over AV1, and AV2 doesn't seem to be a substantially better option coming soon. That market would look more like H.264 v. AV1, and AV1 would get huge investments.

But if VVC, EVC, or AV2 look to be substantially superior to AV1, and patent issues don't wind up being a huge differential advantage, or if it isn't demonstrated that AV1 is generally better than HEVC, it could be a H.264 -> HEVC -> Next Big Codec evolution.

And 20% improvement isn't enough to drive changes in many markets. Broadcast/cable/sat doesn't switch codecs without a 2x improvement. Swapping out set top boxes is WAY more friction than upgrading a browser. Those are the markets where the majority of encoder revenue and thus engineering efforts are focused on, and they've already bet on HEVC. There the interesting competition will be between VVC, EVC, and AV2 for the primary codec of the 2020's.

If EVC offers 2x efficiency gains over HEVC, OR is at least as good as HEVC and patent issues wind up being a huge driver, it is in a good position for adoption. Its biggest competitor could be AV2, as they are aiming for similar patent situations. EV2 is intended to come out quite a bit earlier, which would be an advantage everything else being equal. VVC isn't much behind EV2, so a lot will depend on relative compression efficiency and patent friction.

I don't have any particular predictions here or a lot of first hand knowledge. I am confident that VVC is going to be substantially better in subjective quality than HEVC or AV1. But I don't have any real sense of where it would land relative to AV2 or EVC.

[TomV]

MPEG standards have a decided advantage in compression efficiency / complexity... a.k.a. bang for the buck. As new coding tools are proposed, they are evaluated in terms of the compression efficiency gains versus the impact on computation (reduction in performance on a given computer system). The coding tools in HEVC, and the tools expected in EVC and VVC have much higher gain/pain on average than the tools in AV1.

[benwaggoner]

MPEG standards have a decided advantage in compression efficiency / complexity... a.k.a. bang for the buck. As new coding tools are proposed, they are evaluated in terms of the compression efficiency gains versus the impact on computation (reduction in performance on a given computer system). The coding tools in HEVC, and the tools expected in EVC and VVC have much higher gain/pain on average than the tools in AV1.
And the MPEG codecs get a LOT of input from decoder HW companies, to make sure the design is implementable. Generally the goals for a new bitstream specify a maximum decoder complexity increase relative to compression efficiency improvements.

[iwod]

MPEG standards have a decided advantage in compression efficiency / complexity... a.k.a. bang for the buck. As new coding tools are proposed, they are evaluated in terms of the compression efficiency gains versus the impact on computation (reduction in performance on a given computer system). The coding tools in HEVC, and the tools expected in EVC and VVC have much higher gain/pain on average than the tools in AV1.

Good to hear. HEVC was sort of a disappointment to me, it doesn't give the intended bitrate saving as I had hoped for, and does most of the bitrate saving in 4K only.

I wonder if their target are based 8K again? Would there be effort to gain higher efficiency for low bitrate? I would love to see a 1080P 1Mbps VVC offering the same or better quality than HEVC 1080P 2Mbps, and in reality that may be a tall order.

[benwaggoner]

Good to hear. HEVC was sort of a disappointment to me, it doesn't give the intended bitrate saving as I had hoped for, and does most of the bitrate saving in 4K only.

I wonder if their target are based 8K again? Would there be effort to gain higher efficiency for low bitrate? I would love to see a 1080P 1Mbps VVC offering the same or better quality than HEVC 1080P 2Mbps, and in reality that may be a tall order.
Yeah, "2x" efficiency improvements aren't from the mature version of the previous standard to the reference encoder of the new standard. It's more reference encoder to reference encoder. It takes years after a new standard gets implemented before it has mature encoders that really take advantages of all the new tools available.

[birdie]

Huawei, Qualcomm and Samsung give backing to MPEG-5 EVC:

https://www.broadbandtvnews.com/2020/05/12/huawei-qualcomm-and-samsung-give-backing-to-mpeg-5-evc/

What a mess ;-)

Now we'll have VVC, EVC, and AV1.

[ksec]

Huawei, Qualcomm and Samsung give backing to MPEG-5 EVC:

https://www.broadbandtvnews.com/2020/05/12/huawei-qualcomm-and-samsung-give-backing-to-mpeg-5-evc/

What a mess ;-)

Now we'll have VVC, EVC, and AV1.

It sort of put a spin into it but in reality the actual EVC proposal itself were jointly submitted by those three companies. i.e They are backing their own proposal.

All three are also backing VVC as well as a member of MC-IF.

I think it is a lot of power play and politics behind closed doors that we dont see.

VVC is currently "the" state of art video compression technology, with basically all the major companies backing. ( After all we all want the best tech, right ? ) but if they cant come to terms inside MC-IF, what Samsung, Huawei and Qualcomm are saying is that they will go their own way with EVC. The three together are basically 85%+ of all Non-Apple Smartphone market. ( The rest belongs to Mediatek and some tiny players )

[benwaggoner]

There is a whole lot of game theory happening here. The more technically viable alternate codecs are, the more pressure there is for reasonable licensing terms for the others. One of the big reasons why H.264 came out with a reasonable license is that VC-1 was available as a viable alternative with quite reasonable licensing terms.

When a codec is SO much technically superior like HEVC was, that's when folks start getting greedy and we wind up with multiple patent pools of varying clarity.

The irony is that the better alternative codecs are, the less likely they are to be used :).

[Shevach]

Where i can get sources of EVC?

[soresu]

There is a whole lot of game theory happening here. The more technically viable alternate codecs are, the more pressure there is for reasonable licensing terms for the others. One of the big reasons why H.264 came out with a reasonable license is that VC-1 was available as a viable alternative with quite reasonable licensing terms.

When a codec is SO much technically superior like HEVC was, that's when folks start getting greedy and we wind up with multiple patent pools of varying clarity.

The irony is that the better alternative codecs are, the less likely they are to be used :).
Regardless of who does what in backing, AV1 has the backing of Google through Youtube and it's Play store TV/film media - and they are extremely unlikely to ever turn back to a new proprietary codec.

That's not something any SoC manufacturer can ignore forever, not when it puts then at a clear UX disadvantage in bandwidth constrained environs.

Indeed with rumblings of AV1 related job postings at Qualcomm, so there is finally some movement there at last.

That just leaves Huawei and Apple to join the crowd at this point.

[SeeMoreDigital]

Regardless of who does what in backing, AV1 has the backing of Google through Youtube and it's Play store TV/film media - and they are extremely unlikely to ever turn back to a new proprietary codec.

That's not something any SoC manufacturer can ignore forever, not when it puts then at a clear UX disadvantage in bandwidth constrained environs.

Indeed with rumblings of AV1 related job postings at Qualcomm, so there is finally some movement there at last.

That just leaves Huawei and Apple to join the crowd at this point.Just in-case anyone has missed it... AV1 video decoding is now supported in 2020 LG televisions.

https://i.ibb.co/s3ddDzm/LG-2020.png


Cheers

[ksec]

Regardless of who does what in backing, AV1 has the backing of Google through Youtube and it's Play store TV/film media - and they are extremely unlikely to ever turn back to a new proprietary codec.


WMV or RMVB are proprietary codec. I think you mean non-royalty free Codec.

[Blue_MiSfit]

AFAIK Google Play uses HEVC for HDR content :devil:

I think they used to use VP9 for that, but the quality wasn't great.

[utack]

AFAIK Google Play uses HEVC for HDR content :devil:

I think they used to use VP9 for that, but the quality wasn't great.

Do you need to deal with licensing to redistribute the content or could they possibly offload that to the studios ignoring the headace around it?

[ksec]

Do you need to deal with licensing to redistribute the content or could they possibly offload that to the studios ignoring the headace around it?

As far as I am aware there were never any royalty required for online distribution. HEVC Advance tried that and only came with backlash and then stop proceeding. Which was what happen initially with AVC as well if I remember correctly.

Just a note, Google is currently paying HEVC royalty for their Pixel Phone, Nest, and Chromecast.

[ksec]

AFAIK Google Play uses HEVC for HDR content :devil:

I think they used to use VP9 for that, but the quality wasn't great.

Along with 360 degree video as well. It was amazing. :devil:

[Shevach]

Where i can get sources of EVC?

i looked through the presentation "MPEG 5 Essential Video Coding (EVC)", by Ken McCann, Chairman of MPEG Ad hoc Group on EVC.

Results of a comparison between EVC Baseline and AVC/H.264 are presented (although it's not mentioned what AVC/H.264 profile applied).
According to the results EVC is significantly superior to H.264/AVC (30% bitrate reduction achieved).
Frankly speaking, it's unexpected. Excepting 64x64 quadtree, EVC Baseline and H.264/AVC are similar.

i would like to conduct comparisons by myself. However, how can i get at least EVC ETM3.0 binaries?

[Shevach]

i already received the reply from Leonardo Chiariglione (MPEG chairman):

"There is reference software but currently that is only available to MPEG members"

In my opinion the absence of access to EVC reference model for wider audience makes discussions on EVC theoretical

[utack]

According to the results EVC is significantly superior to H.264/AVC (30% bitrate reduction achieved).


If we are talking 30% reduction reference software to reference software measured by psnr then good luck beating x264 in pratical use case any time soon....

[soresu]

AFAIK Google Play uses HEVC for HDR content :devil:

I think they used to use VP9 for that, but the quality wasn't great.

I did say new proprietary codecs - HEVC is itself getting on a bit now (slightly older than VP9).

Not to mention VP9 profile 2 is not nearly as well supported by HW ASIC decoders as profile 0.

[benwaggoner]

I did say new proprietary codecs - HEVC is itself getting on a bit now (slightly older than VP9).
Well, HEVC is still quite a bit more advanced and efficient than VP9, and has much more mature encoders available.

[foxyshadis]

If we are talking 30% reduction reference software to reference software measured by psnr then good luck beating x264 in pratical use case any time soon....

It's not. EVC is just AVC++, it's AVC with some of the rad stuff from HEVC and some other good ideas, as long as it's unpatented. It's an interesting and unusual direction for MPEG to go, but AV1 might be more competition than expected. MPEG hasn't used PSNR as anything but a "whoa, -20dB, something went really wrong here" check in decades.

It's interesting that so many things are now falling out of patent because they were originally proposed in the 90's for H.26L (which eventually became H.264/AVC) and accepted or rejected for being too complex. Twenty years on, they're not as complex and not as patented.

[ksec]

i already received the reply from Leonardo Chiariglione (MPEG chairman):

"There is reference software but currently that is only available to MPEG members"

In my opinion the absence of access to EVC reference model for wider audience makes discussions on EVC theoretical

Yes, unfortunate, if I remember correctly ( correct me if I am wrong ) this was done because EVC had a baseline royalty free status that required additional protection during development.

There are a few papers and video describing those results done by academic and standard industry practice, so I believe they should be legit. Some paper are not free, but I will try to dig up a video I watched a while ago on the topic.

Edit:
Here: https://www.youtube.com/watch?v=0Itt0cOvgXU

A Talk with BenWaggoner Introduction and Jonathan Samuelsson ( Both are on doom9 :) )

They were comparing with AVC High 10.



I am not sure if I had ask this question before, is EVC basically a flavour of XVC?

[foxyshadis]

I am not sure if I had ask this question before, is EVC basically a flavour of XVC?

XVC is similar in goals and tools, though the bitstream is rather different, but it's Divideon's private codec, versus EVC being MPEG's. I don't think the confusion was intentional, but each swapping one letter of the TLA certainly doesn't help.

[jonatans]

XVC is similar in goals and tools, though the bitstream is rather different, but it's Divideon's private codec, versus EVC being MPEG's. I don't think the confusion was intentional, but each swapping one letter of the TLA certainly doesn't help.

Correct, the structure and design philosophy of EVC and xvc are similar but there is no level of interoperability between the two. The xvc codec was brought in as a candidate when EVC standardization started and some tools from xvc have been included in EVC.

[Shevach]

Claims of EVC designers on 30% bit reduction versus H.264/AVC (apparently High Profile) given same visual quality seem strange, especially if taking into consideration that only significant improvement of EVC over AVC/H.264 is 64x64 quadtree. On gradual (or smooth) video content 64x64 quadtree would provide a significant gain (even 30% bit-rate reduction if all blocks are 64x64), but on high-detailed video content i am not sure.

Therefore, i would like compare by myself EVC and H.264/AVC.

[dapperdan]

When a codec is SO much technically superior like HEVC was, that's when folks start getting greedy and we wind up with multiple patent pools of varying clarity.


Every MPEG audio and video standard has these same royalty shenanigans.

So either they surprise themselves every time with how amazing the codec they've produced is, or their process of pretending patent licencing terms don't matter when deciding what goes into a standard is fundamentally broken.

I'm going to pick the latter, because the head of MPEG wrote a blog saying basically "our process around patents is fundamentally broken" and factions of their members appear to be forcing through 2 different, competing standards with a different patent model as a result.

[benwaggoner]

Every MPEG audio and video standard has these same royalty shenanigans.

So either they surprise themselves every time with how amazing the codec they've produced is, or their process of pretending patent licencing terms don't matter when deciding what goes into a standard is fundamentally broken.

I'm going to pick the latter, because the head of MPEG wrote a blog saying basically "our process around patents is fundamentally broken" and factions of their members appear to be forcing through 2 different, competing standards with a different patent model as a result.
It doesn't ALWAYS happen. They periodically learn their lesson! AVC wound up with a single patent pool with well documented and understood terms that allowed pretty much anyone who wanted to include AVC in products or services to do so quite affordably.

That was a result of both

MPEG-4 Part 2 having a murky licensing story, which was considered a big barrier to its adoption.
Microsoft had VC-1 as a SMPTE spec and very simple and inexpensive licensing. The existance of a technically viable alternative put a lot of pressure on getting competitive and comprable licensing terms.


In retrospect, MPEG-4 part 2 Advanced Simple Profile really wasn't a compelling enough improvement over MPEG-2 to get the big codec licencees in broadcast/cable/sat to go through the enormous switching costs, so I don't know if a good license would have really helped that much.

And also, while VC-1 Main Profile was competitive with AVC Baseline Profile, which are what was being used at the moment, AVC High Profile clearly pulled away from anything VC-1 was capable of.

But hey, anything that gets licensees realize they're not only competing for a bigger slice of the pie but also for the size of the pie itself engenders sanity.

[foxyshadis]

Claims of EVC designers on 30% bit reduction versus H.264/AVC (apparently High Profile) given same visual quality seem strange, especially if taking into consideration that only significant improvement of EVC over AVC/H.264 is 64x64 quadtree. On gradual (or smooth) video content 64x64 quadtree would provide a significant gain (even 30% bit-rate reduction if all blocks are 64x64), but on high-detailed video content i am not sure.

Therefore, i would like compare by myself EVC and H.264/AVC.

I meant to reply to this earlier after looking into it more, sorry. There are two EVCs: Baseline and Main. Baseline is the 100% royalty free version, Main is the "might be a small patent pool but it's supposed to be very cheap" version. Baseline won't net you any wins over AVC unless you have video where the 64x64 helps, particularly since their deblocking and entropy coding is actually slightly worse.

Main is where all the fun stuff is, 128x128, AMVR, better inferred motion vectors, Adaptive Transform (slightly more compact DCTs plus reflection onto neighboring subblocks), and other things.

[ksec]

I meant to reply to this earlier after looking into it more, sorry. There are two EVCs: Baseline and Main. Baseline is the 100% royalty free version, Main is the "might be a small patent pool but it's supposed to be very cheap" version. Baseline won't net you any wins over AVC unless you have video where the 64x64 helps, particularly since their deblocking and entropy coding is actually slightly worse.

Main is where all the fun stuff is, 128x128, AMVR, better inferred motion vectors, Adaptive Transform (slightly more compact DCTs plus reflection onto neighboring subblocks), and other things.

And yet they are claiming baseline being 30% better than AVC.

May be we really need an encoder to test it out.

[Greenhorn]

And yet they are claiming baseline being 30% better than AVC.

May be we really need an encoder to test it out.

Not having an encoder for non-partners does seem like a very bad idea, but what's odd about them claiming that their AVC encoder (in all but name) is better than another, much older AVC encoder? The bitstream standards aren't supposed to be granular enough for two compliant encoders to be anything like the same. (And not only x264 but several/many other AVC encoders outperform JM already.)

[benwaggoner]

And yet they are claiming baseline being 30% better than AVC.

May be we really need an encoder to test it out.
Bear in mind that it's tons of stuff from AVC, plus a lot of other stuff licensed under very friendly terms from (mainly) Samsung, Huawei, Qualcomm. 30% better than AVC in baseline isn't unreasonable on its face. If it is really FRAND, it might serve as a competitor to AV1 with perhaps a little less compression efficiency, but lower decoder and encoder complexity.

Haven't heard much about additional gains in Main yet.

[hajj_3]

I'm surprised that a reference encoder hasn't been released yet since that it was ratified a couple of months or so ago. I'm not sure why they think withholding an encoder benefits them?

[Jamaika]

FFmpeg adds samsung muxer/demuxer/parser evc
https://github.com/FFmpeg/FFmpeg/commit/7b15f1780f6e4b70bdb774af721ba0ad7a5cf6c3

[kurkosdr]

o There should be additional tools in the enhanced tool set, each of which shall provide a significant improvement in coding efficiency and be capable of being cleanly switched off on an individual basis
Does anyone know what this "cleanly switched off" part means? Let's say I have an EVC Baseline decoder (which can be distributed royalty-free), and a given EVC bitstream uses one of those additional coding tools, is that EVC bitstream decodable by an EVC Baseline decoder in an acceptable manner?

[rwill]

Let's say I have an EVC Baseline decoder (which can be distributed royalty-free), and a given EVC bitstream uses one of those additional coding tools, is that EVC bitstream decodable by an EVC Baseline decoder in an acceptable manner?

No - not at all. It is possible to not use a tool by setting its tool flag in the sequence parameter set to zero, then it will never touch a path with intellectual property from that tool. So it is possible to remove a tool from the standard by renaming the tool flag to something like reserved_0bit and always write a zero there and removing all references to the tool from the standard.

You need to encode with the tool disabled so the stream works without the tool.

[kurkosdr]

No - not at all. It is possible to not use a tool by setting its tool flag in the sequence parameter set to zero, then it will never touch a path with intellectual property from that tool. So it is possible to remove a tool from the standard by renaming the tool flag to something like reserved_0bit and always write a zero there and removing all references to the tool from the standard.

You need to encode with the tool disabled so the stream works without the tool.

This is what I don't understand: From the perspective of the decoder, you still have to implement every single patented tool in EVC Main if you want to be able to play every EVC Main stream you might come across, right? Already-encoded files don't magically change, they still need a decoder capable of understanding the data structures used by the now-removed coding tool.

So, if every entity owning a patented tool decides to go its own merry way instead of joining a patent pool, you still have to get a license from every tool owner to implement a fully-compatible EVC Main decoder, right?

Although I understand how the ability to turn off patented coding tools on the encoder side can help with "content fees", since if a tool owner is uncooperative, a web streaming service can simply not use the particular tool in further encodes. But then of course you have the problem of already-encoded content you have to re-encode (which is not trivial from a financial cost perspective if you have tons of them).

So, I fail to see what real-world problem EVC Main solves. At least EVC Baseline is useful in the sense that it's a royalty-free ISO format that's more modern than MPEG-1 (all newer ISO video formats except EVC Baseline are covered by patents in at least one country).

[Jamaika]

And I see another problem. Free codecs are no longer developed. So have they become history?
https://github.com/mpeg5/xeve
https://github.com/mpeg5/xevd
https://gitlab.com/v-nova-public/ETM

[rwill]

This is what I don't understand: From the perspective of the decoder, you still have to implement every single patented tool in EVC Main if you want to be able to play every EVC Main stream you might come across, right? Already-encoded files don't magically change, they still need a decoder capable of understanding the data structures used by the now-removed coding tool.

So, if every entity owning a patented tool decides to go its own merry way instead of joining a patent pool, you still have to get a license from every tool owner to implement a fully-compatible EVC Main decoder, right?

Although I understand how the ability to turn off patented coding tools on the encoder side can help with "content fees", since if a tool owner is uncooperative, a web streaming service can simply not use the particular tool in further encodes. But then of course you have the problem of already-encoded content you have to re-encode (which is not trivial from a financial cost perspective if you have tons of them).

So, I fail to see what real-world problem EVC Main solves. At least EVC Baseline is useful in the sense that it's a royalty-free ISO format that's more modern than MPEG-1 (all newer ISO video formats except EVC Baseline are covered by patents in at least one country).

Well I think that "turning tool off" thing is more for the case where some party which was not involved with the EVC Standardization Process makes an IP claim for one of the tools and tries to cash in should EVC Main has established itself in an ecosystem. The original tool owners had to do that FRAND statement to get included...

Sure people have to re-encode when a feature gets removed but if the alternative is to pay off some predatory acting party its at least another option. And having that option is better than scrapping the whole standard if the terms of a litigation happy IP owner turn out to be unacceptable. For example there currently is some litigation in Germany going on regarding some WLAN-Router Producer and some, I think, Chinese company. The Router Producer currently tries to avoid claims by patching the claimed WiFi 6 (?) features out of the Routers. There is also something going on with some streaming provider and some HEVC IP owner where the feature cannot be worked around easily. This seems to be a problem for the streaming provider because it currently looks like they have to pay up sooner or later.

Having worked on EVC I'd say Baseline is more advanced than H.264 while being less complex, so there is that. For example it is nice that EVC does not contain all the complexity of interlaced. I currently see it in the Royalty Free Niche for applications where some sort of Video is needed, like video games, educational software or information systems. Main Profile I don't know, the additional tools help with compression efficiency but I think currently most people would pick HEVC there because HEVC is already well established.

[rwill]

And I see another problem. Free codecs are no longer developed. So have they become history?
https://github.com/mpeg5/xeve
https://github.com/mpeg5/xevd
https://gitlab.com/v-nova-public/ETM

Well EVC never had high momentum. ETM is the reference software so it does not count. xeve and xevd - I think the developers that did them did get paid to work on them. Now that the encoder and decoder are more or less stable there is no more need to drop resources into them.

Do you have something special in mind where they currently need further work?

[kurkosdr]

Well I think that "turning tool off" thing is more for the case where some party which was not involved with the EVC Standardization Process makes an IP claim for one of the tools and tries to cash in should EVC Main has established itself in an ecosystem. The original tool owners had to do that FRAND statement to get included...

Sure people have to re-encode when a feature gets removed but if the alternative is to pay off some predatory acting party its at least another option. And having that option is better than scrapping the whole standard if the terms of a litigation happy IP owner turn out to be unacceptable. For example there currently is some litigation in Germany going on regarding some WLAN-Router Producer and some, I think, Chinese company. The Router Producer currently tries to avoid claims by patching the claimed WiFi 6 (?) features out of the Routers. There is also something going on with some streaming provider and some HEVC IP owner where the feature cannot be worked around easily. This seems to be a problem for the streaming provider because it currently looks like they have to pay up sooner or later.
See, this is what Leonardo Chiariglione doesn't understand: constantly having to re-encode your videos when a coding tool becomes unavailable isn't a viable proposition, because there are huge electricity and server time costs involved in every re-encoding. I mean, just look at that time YouTube re-encoded all their videos to VP8 as part of their HTML5 transition: it was a monumental effort that was done incrementally, there was a time when joining the HTML5 beta got you a fraction of the videos present on YouTube. And that was for one re-encode. You can't just do something like that every time a coding tool in EVC Main becomes unavailable. And then there is the issue that if a patent owner demands payment tomorrow, you can't just shut down your service and make your service unavailable until everything has been re-encoded. And then there is the issue of being sued for "past-infringement".

Which is why I find EVC Main weird: It has no hope of competing against the established HEVC, and it purposely steps on patents so it's not royalty-free either. Sure, being able to disable coding tools at the encoder side is nice, but realistically you are not going to re-encode all your videos and it doesn't protect you from "past infringement".

I currently see it in the Royalty Free Niche for applications where some sort of Video is needed, like video games, educational software or information systems. Main Profile I don't know, the additional tools help with compression efficiency but I think currently most people would pick HEVC there because HEVC is already well established.
Out of curiosity, is EVC Baseline actually used somewhere? Because the way I see it, EVC Baseline took so long to come about that everyone who wanted royalty-free video has already settled on VP8, VP9, and AV1.

The only case I see for EVC Baseline is that VP9 and AV1 have patent assertions against them (see Sisvel's patent pool), so if some court finds some patent in the pool valid and essential, you are stuck with VP8. Which is worse than H.264. But then again if such a valid patent exists, we'd have seen some litigation by now. Companies like Google (YouTube) and Meta (Twitch) seem to assume the risk of that happening to be extremely low. The way I see it, ISO got leapfrogged in the royalty-free video formats market by AOM, just like they have historically been leapfrogged in surround sound formats by Dolby (Dolby Digital came before MPEG Multichannel, Dolby Atmos came before MPEG-H 3D Audio).

Though I can see a case for EVC Baseline for people who want something better than VP8 and no open patent assertions, so I am glad it exists and has a decent encoder and decoder. That's why I am curious if such cases actually exist.

[hajj_3]

I think the purpose of EVC was just to try to pressure the companies behind VVC to create 1 patent pool and to charge a low licensing fee.

[kurkosdr]

I think the purpose of EVC was just to try to pressure the companies behind VVC to create 1 patent pool and to charge a low licensing fee.
Which clearly failed, VVC is still a fragmented mess when it comes to licensing. And EVC Main has the potential to evolve into a similar fragmented mess (again, nobody will re-encode when a tool becomes unavailable), and EVC Baseline is too weak to compete.

The companies behind the VVC and HEVC patents are more worried about AV1, which actually has an installed base.

[benwaggoner]

I think the purpose of EVC was just to try to pressure the companies behind VVC to create 1 patent pool and to charge a low licensing fee.
And/or to have a backup.

Insiders focused on content distribution rather than patent licensing revenue still have fond memories of the VC-1/H.264 competition, which lead to H.264 getting clear and reasonable licensing rules and costs. More than any MPEG codec before or since, really. H.264 was informed by the lessons of MPEG-4 part 2, lessons which had lost much power by the time HEVC came out.

Driving more reasonable codec licensing costs and rules was a real motivator for Microsoft in VC-1, and Windows Media overall. I think licensing MPEG-2 patents for the Windows SKUs DVD player had cost Microsoft more than $1B.

Codec licensing is very interesting from a game theory perspective. Doubtless all the HEVC licensees would have been more profitable if they'd come together in a single standard body like MPEG-LA for H.264. But as long as someone else is going rogue anyway, the incentives to get a bigger share of a smaller pie can be strong.

[kurkosdr]

And/or to have a backup.

Insiders focused on content distribution rather than patent licensing revenue still have fond memories of the VC-1/H.264 competition, which lead to H.264 getting clear and reasonable licensing rules and costs. More than any MPEG codec before or since, really. H.264 was informed by the lessons of MPEG-4 part 2, lessons which had lost much power by the time HEVC came out.

Driving more reasonable codec licensing costs and rules was a real motivator for Microsoft in VC-1, and Windows Media overall.

When it comes to "content fees", the H.264 patent holders dropped "content fees" for free-to-view content shortly after Google bought On2 Technologies, open-sourced VP8, and started encoding all YouTube videos to VP8. This tells you which format was essential in making that happen. Simply put, Google gave the H.264 patent holders a clear message that YouTube can and will ditch H.264 if they have to. VC-1 was never really significant to anything, everyone knew it was a format prone to the same licensing issues H.264 had without being as good as H.264. VC-1 is a cheaper-to-license format for Blu-Rays and that's it (and since Blu-Rays are all about a high-level presentation with lots of extras and lossless audios, VC-1 is not significant in Blu-Ray either, most Blu-Rays use H.264 to get better quality for a given bitrate).

Then H.265 came around and patent holders got greedy and didn't give free-to-view web content the same exception from "content fees", and that's how they ended up with a capable competitor (VP9) implemented on every new UHD TV sold (every new UHD TV is expected to do YouTube 4K HDR). Google wasn't and isn't bluffing: they are perfectly capable of ditching all of the ISO/ITU formats and giving you only VPx and AV1 if they have to. I mean, what are the Samsungs and LGs going to do? Sell you a UHD TV that can't do more than 1080p on YouTube? Who will buy that? Even Apple had to implement VP9 in their Apple TV product despite the fact this means they can't assert their HEVC patents against VP9 implements anymore (see the "defensive termination" clauses in the VP9 and AV1 patent license).

Even when it comes to decoder licensing, H.264 patent holders were more pressed by Google threatening to ditch H.264 decoding and passthrough in Chrome than anything else.

I think licensing MPEG-2 patents for the Windows SKUs DVD player had cost Microsoft more than $1B.

Does this include the other DVD stuff such as copy-protection license and Dolby Digital or it's just MPEG-2?

[excellentswordfight]

When it comes to "content fees", the H.264 patent holders dropped "content fees" for free-to-view content shortly after Google bought On2 Technologies,
No they didnt, as there was no content fees for free internet videos prior to this. This free-model was first extended to 2016 in the beginning of 2010, it was then revisited a few months later (probably affected by VP8/google) that it would stay free for the rest of its lifetime, and not continue to be updated on a 5y cycle.

[benwaggoner]

When it comes to "content fees", the H.264 patent holders dropped "content fees" for free-to-view content shortly after Google bought On2 Technologies, open-sourced VP8, and started encoding all YouTube videos to VP8. This tells you which format was essential in making that happen. Simply put, Google gave the H.264 patent holders a clear message that YouTube can and will ditch H.264 if they have to. VC-1 was never really significant to anything, everyone knew it was a format prone to the same licensing issues H.264 had without being as good as H.264. VC-1 is a cheaper-to-license format for Blu-Rays and that's it (and since Blu-Rays are all about a high-level presentation with lots of extras and lossless audios, VC-1 is not significant in Blu-Ray either, most Blu-Rays use H.264 to get better quality for a given bitrate).
VP8 did come around when content fees were finally nixed (and thank goodness). But the basic capped and reasonable price for H.264 decoders and encoders had already been established by MPEG-LA, which was the only patent pool.

Then H.265 came around and patent holders got greedy and didn't give free-to-view web content the same exception from "content fees", and that's how they ended up with a capable competitor (VP9) implemented on every new UHD TV sold (every new UHD TV is expected to do YouTube 4K HDR). Google wasn't and isn't bluffing: they are perfectly capable of ditching all of the ISO/ITU formats and giving you only VPx and AV1 if they have to. I mean, what are the Samsungs and LGs going to do? Sell you a UHD TV that can't do more than 1080p on YouTube? Who will buy that? Even Apple had to implement VP9 in their Apple TV product despite the fact this means they can't assert their HEVC patents against VP9 implements anymore (see the "defensive termination" clauses in the VP9 and AV1 patent license).
No argument that HEVC was a mess. With MPEG-LA it was possible to look up the costs and figure out how much one would owe under a given business model. For HEVC, there wasn't even public terms available for one of the major patent pools for years.

That said, HEVC has still been a huge success in a lot of industries, the main exception being web browser based delivery.

Does this include the other DVD stuff such as copy-protection license and Dolby Digital or it's just MPEG-2?
The $1B number was just for the MPEG-2 decoder license alone.

[LigH]

M-AB-S added support for xeve/xevd ...

I am not sure yet how to enable it, though. There seems to be no support for a media-autobuild_suite.ini option yet, so I guess it is enabled via ffmpeg_options.txt parameter list entry.
__

New uploads: (MSYS2/MinGW 32+64, GCC 14.1)

xeve 0.5.1 954ed6e (https://www.mediafire.com/file/zlm07qkanf8rncp/xeve_0.5.1_954ed6e.7z/file)
xevd 0.5.0 ae43605 (https://www.mediafire.com/file/gcwza4uz9rbimhf/xevd_0.5.0_ae43605.7z/file)

[LigH]

ffmpeg with xeve/xevd libs (https://forum.doom9.org/showthread.php?p=2004928#post2004928)

[Jamaika]

Improved evc and vvc plugins
https://github.com/Jamaika1/plugins_ffmpeg_vvc_evc_htj2k/commit/cdb27363877b39811c17bd2c26c2d237422fccf1

ffmpeg_avx.exe -v verbose -i "input.mp4" -y -c:v libxeve -vb 3000k -c:a aac -ac 2 -ar 48000 -ab 128k -s 1920x1080 -xeve-params threads=8:aq_mode=1:cutree=1 -frames:v 1000 -pix_fmt yuv420p10le output_xeve.mkv
ffmpeg_avx.exe -v verbose -i "input.mp4" -y -c:v libuvg266 -vb 3000k -c:a aac -ac 2 -ar 48000 -ab 128k -s 1920x1080 -frames:v 1000 -pix_fmt yuv420p output_uvg266.mkv

unfinished projects, trash, unlikely to be resumed after the pandemic
https://github.com/xatabhk/davs2-10bit
https://github.com/Jamaika1/plugins_ffmpeg_vvc_evc_htj2k/commit/510ff6e930c17fb14e534f37559f0f406f14acac
https://github.com/Jamaika1/plugins_ffmpeg_vvc_evc_htj2k/commit/695fd4f719872a14812263ee2733a435752a3e98

https://www.sendspace.com/file/inbvbc

[LigH]

I see ffmpeg can be built including libuvg266; is it more difficult than adding it to the list of enabled libraries? If not, M-AB-S might do it...

At least one may have to exclude it in 32 bit builds.

[Jamaika]

Codec uvg266 is currently 8bit. VVC ffmpeg decoder is only 10bit. Full compatibility I think in a year. As I added libuvg266. It was simple, but I did not talk with the creators.

[LigH]

Unknown option "--enable-libuvg266".
Apparently it needs more than just a parameter. That was the main point of my question.

Anyway, this is the EVC thread. We might discuss that in the uvg266 thread instead.

[Jamaika]

Each codec is included in allcodec.c
extern const FFCodec ff_libuvg266_encoder;

OBJS-$(CONFIG_LIBUVG266_ENCODER) += libuvg266.o
FOR gcc you don't have to use the definition in config.h because there is no definition for CONFIG_LIBUVG266_ENCODER like there is for CONFIG_LIBKVAZAAR_ENCODER.

matroskaenc.c
case AV_CODEC_ID_VVC:
return ff_isom_write_vvcc(dyn_cp, extradata,
extradata_size, 0);
case AV_CODEC_ID_EVC:
return ff_isom_write_evcc(dyn_cp, extradata,
extradata_size, 0);

[benwaggoner]

Codec uvg266 is currently 8bit. VVC ffmpeg decoder is only 10bit. Full compatibility I think in a year. As I added libuvg266. It was simple, but I did not talk with the creators.
First time I've heard of a decoder that only supports 10-bit!

[Jamaika]

So how do I make it 8bit?
ffplay_avx.exe uvg266.mkv -strict -2

[LigH]

New uploads: (MSYS2/MinGW 32+64, GCC 14.2.0)

xeve 0.5.1 56fc939 (https://www.mediafire.com/file/3dqm6ma1myq5tfy/xeve_0.5.1_56fc939.7z/file)
xevd 0.5.0 aae32ae (https://www.mediafire.com/file/ux1haxwoarzo0mm/xevd_0.5.0_aae32ae.7z/file)

[LigH]

New uploads: (MSYS2/MinGW 32+64, GCC 14.2.0)

xeve 0.5.1 1_7b21466 (https://www.mediafire.com/file/5aof2h647x539zu/xeve_0.5.1_7b21466.7z/file)
xevd 0.5.0 0_d4331b7 (https://www.mediafire.com/file/b51archsrxpw83e/xevd_0.5.0_d4331b7.7z/file)

[Jamaika]

I don't know if the original library has stopped being updated. I also don't know if the new library is a successor to the evc codec, but it's been quite active on GitHub lately.
https://github.com/OxideAV/oxideav-evc
https://github.com/OxideAV/oxideav-jpegxs

[ksec]

There is a new xeve 0.6 and 0.7 released last week

https://github.com/mpeg5/xeve/releases