FAQ (x266 Webinar 31 JAN 2023)
MulticoreWare is in discussions with our partners closer to the release of v1.0. We will be sure to update you all in the next Webinar
Yes, MulticoreWare is aware that there are other VVC Encoders available.
Lossy single-frame is already supported by MulticoreWare. Future versions of x266 will also enable lossless encoding, much like x265 does.
Cb and Cr channels are coded separately, but the same luma prediction modes may be applied to the chroma components. In VVC, there are tools like CST (Chroma Separate tree), where chroma can have separate block structures. Additionally, VVC has tools like CCLM, LMCS, etc where there is an inter dependency between chroma and luma components
The evolution of video codec standards is dependent on factors like Market adoption. People are looking to add new capacities for video codecs. It is entirely possible for more people to adopt these codecs in the upcoming months, based on their use cases (Live/VOD). Every successive H Standard has been computationally intensive, so based on these use cases, the adoption of H.266 can be identified.
The real-time processing is still a work in progress as we aim to add more capabilities and improve speed. Some x265 capabilities will be accessible in Ultraziq as well as x266.
We recognize the concerns for x265: we anticipate an increase in x265. The same is true for x266 and will be determined by factors such as cloud computing. x266 licencing conditions and partnerships have been adjusted, and things can only get better from here.
MulticoreWare is working on it, but we're not there yet. The plan is to ultimately merge it with FFmpeg, although that is a long way off.
Consortium members have been connecting with us and mentoring us on a regular basis. They do have an impact on the tools and features that are developed. We will make certain that a framework is in place to solicit people's opinion and alter priorities depending on their input.
We did have plans to explore opportunities for hardware accelerations and FPGAs. We are currently closing in on v1.0; right after it is done, we will definitely explore the hardware acceleration and FPGAs area.
Promoting these encoders is the responsibility of those who create them. Google and other players would like to support various codecs.
We are looking at hardware and process-centric optimization. We are also looking at AI/ML-based codecs, exploiting legacy-based codecs, and how we can effectively use ML to improve what x265 and Ultraziq do. Roadmap includes ARM-based x265 that mainly focuses on power usage.
That is precisely how it has been designed. We have looked at the underlying architecture for it to run. There will of course be a penalty on performance, but the system would work. Offloading to GPU is also possible.
Everything in the x265 specifications and in the periphery for x265 will also apply to x266. Additionally, this has extra AI-based functions.
HEVC supports high bit-depth content, but they are designed for coding LDR content and do not consider the characteristics of HDR content. Hence compressing HDR is not too efficient.
Yes - It is an open-source project, it will be released when we hit v1.0, and it becomes meaningful to release for testing by the open-source community. x265 also was released for the public with basic functionality and performance, which the open-source community contributed further to improve.
There haven't been many advancements in video players, but we anticipate more this year. To accelerate this acceptance, we are working with our consortium partners.
Although its impact on video codec standardisation is minimal, MulticoreWare does make an effort to the video codec standardization.
Yes, we at MulticoreWare are following them to the extent possible. So far, x266 has been entirely developed by MulticoreWare.
It is a work in progress. We will be able to update you when the benchmarking is done via email.