We have quite recently launched the new next-generation video codec xvc at xvc.io. The complete source code for encoding and decoding is available at GitHub with the development happening in the dev branch: https://github.com/divideon/xvc/tree/dev.

The xvc codec is free to use for everyone for personal use, evaluations and research. There is also a commercial license available.

The ambition is for xvc to be the world's most efficient video codec while still keeping decoding complexity at a reasonable level in order to support efficient software decoding on various platforms.

In an article about xvc, Streaming Media comments on the performance of xvc as "Pretty impressive performance" with xvc being the quality leader compared to HEVC, H.264, VP9 and AV1 for the two "real-world files".

Please try it out and share what you think of it. All sorts of feedback is highly appreciated. The encoder has not yet been optimized for speed and is currently very slow (unless your point of reference is AV1, in which case the xvc encoder is actually very fast ).

Divideon has developed several proof of concept integrations for xvc playback using ExoPlayer, VLC and ffmpeg. Feel free to contact support@xvc.io if you have any questions or need help integrating with your platforms.

Will those integrations be part of the normal releases of VLC, ffmpeg any time soon?

Quote:

Encoding

The following is an example command line for encoding a raw YUV sequence using an intra picture interval of 256 pictures:

Also would be nice if the command line encoder would accept y4m content via pipe to avoid humongous yuv files.

Also: any recompiled Windows 64bit binaries available atm?

Cu Selur

__________________
Hybrid here in the forum, homepage
Notice: Since email notifications do not work here any more, it might take me quite some time to notice a reply to a thread,..

Will those integrations be part of the normal releases of VLC, ffmpeg any time soon?

We have not initiated integration with the normal releases of VLC and FFmpeg. We plan to make the wrapper code available together with the next official release of xvc and we are open to make such integration at any point in time.

Quote:

Also would be nice if the command line encoder would accept y4m content via pipe to avoid humongous yuv files.

Good point! This functionality has just been checked in to the dev branch.

Quote:

Also: any recompiled Windows 64bit binaries available atm?

Not yet. We'll probably start publishing binaries for different platforms at the next official release of xvc (or possibly even sooner). For the time being we recommend users to compile xvc themselves. Let me know if you have any questions related to building xvc.

Will those integrations be part of the normal releases of VLC, ffmpeg any time soon?

The reference software is non-free, so it'll face some challenges being distributed with open-source software like VLC or FFmpeg. If the codec is to become popular, a free and open-source decoder would be needed, since those make the basis for a large share of video players and tools.

While I think that is a nice way of solving the patent problem, but what happen if a patents was responsible for let say 10% of the compression gain, and at a later stage had to be pulled.

Companies who decide on codec had those cost saving in mind. And all of a sudden it is no longer there?

True. And that is why we try to make it very clear that there is a risk that there will be third party patent assertions, just as with any other codec. And users of the codec will have to account for that risk and be prepared to react to it. The main difference with xvc and other codecs is that xvc has a framework for dealing with third party patent assertions from organizations that are not interested in taking part of the licensing program.

Whenever a third party patent infringments is asserted, the first option is to invite the patent holder to join the licensing program. If this is not successful, the validity of the infringement assertion will be assesed (to determine if the assertion should be challenged in court). And only if none of these two options is successful will the technology be removed.

In practice, we do not expect this situation to occur very often (if it occurs at all) and we are confident that we will be able to quickly circumvent such technology and offer an alternative solution with similar performance.

In fact, most of the compression tools provides quite small compression gain in isolation (below 1%) so the impact of turning off just a couple of them would be very minor.

But doesn't that then potentially mean that previously encoded files become un-decodable as some features are disabled?

Correct. If a specific technology needs to be removed from xvc in the next xvc version, bitstreams that made use of that technology can no longer be decoded by the latest xvc decoder.

This is somewhat similar to how for example different generations of MPEG codecs or H.26x codecs or VPx codecs, not necessarily offer support for decoding bitstreams of their previous generation. With the difference that with xvc, it might potentially occur more frequently.

If technology removal occurs, service providers with large assets of xvc bitstreams have the options of:
1) transcode their bitstreams to the new xvc version (which might be a lightweight process depending on the technology that is being replaced and which might even offer better compression if the new xvc version also includes new compression tools)
2) come to an agreement with the patent holder outside of the xvc licensing program in order to be able to continue to use the technology.
3) ditch the xvc version of their legacy assets and fall back to their h.264 version for those assets (which they'll probably anyway have, in order to support some legacy platforms) and just use the new xvc version for new assets.

At this moment i really wish someone could explain to me how to always be optimistic, because they say I am a pessimist.

Quote:

If technology removal occurs, service providers with large assets of xvc bitstreams have the options of:
1) transcode their bitstreams to the new xvc version (which might be a lightweight process depending on the technology that is being replaced and which might even offer better compression if the new xvc version also includes new compression tools)
2) come to an agreement with the patent holder outside of the xvc licensing program in order to be able to continue to use the technology.
3) ditch the xvc version of their legacy assets and fall back to their h.264 version for those assets (which they'll probably anyway have, in order to support some legacy platforms) and just use the new xvc version for new assets.

1. Well there goes Youtube, Hulu, Netflix, or basically every other big streaming site or providers. So after patents problem 1 they re-encode their files, then when patents problem number 2 happens they repeat that again?

2. What if you cant come to agreement if they purposely charge you an outrageous amount?

3. Ditching everything they have done?

I dont think this is a technology problem, but an go to market problem.

Without x265, VP9 and AV1 results (which is close to completion) this comparison looks quite barren.

I agree that it would be interesting with visual comparisons with other codecs. At this point though, h.264 is the only codec supported for playback in all browsers. And since h.264 is the codec that is most widely used today I would argue that it is still a relevant comparison, in order to get an understanding of what level of quality difference to expect when switching to xvc.

The process indication should at least output the current frame number (missing that with 'verbose 1' too ), since at least for longer sequences it is kind of hard to at least have a rough

Also a question what does qp stand for? I assumed that it would stand for quantizer parameter, but a range from -64 to 63 seems rather strange to me since I would normally assume that a quantizer of 0 would mean lossless. So what would happen with negative quantizers?
With the default qp (32) and verbose output enabled I see that the qp is fluctuating

So:
Good news: Encoding seems to be working.
(kind of expected) Bad news: no multi threading at all.

Cu Selur

Ps.: took me 35269 s to encode 15691 pictures, so more than 2 seconds per frame with 6-7% cpu usage.

__________________
Hybrid here in the forum, homepage
Notice: Since email notifications do not work here any more, it might take me quite some time to notice a reply to a thread,..

Last edited by Selur; 3rd February 2018 at 09:22.
Reason: added ps with encoding time

The only level of progress indication right now is with "-verbose 1" and it is done on SubGop level (and not frame level) since the print-out is coupled with the delivery of encoded data from the encoder lib to the command line application.

You are completely correct in that there is no multi-threading support on the encoder yet. This is of course a desirable feature that we would like to see support for soon (together with other speed improvements) but so far we are still more focused on producing really high quality with no specific encoding time limitations.

You are right in that "-qp" stands for "quantization parameter". In general terms, a higher qp gives coarser quantization steps (lower quality) and a lower qp gives finer quantization steps (higher quality). However, internally xvc will use the "-qp" as input for calculating which base qp to use for different pictures, depending on the SubGop length and the current picture's position in the SubGop. Furthermore, within a picture, different blocks will use different qp depending on the local energy.

The range of "-qp" is -64 to 63. There is no mathematical lossless mode in xvc and depending on the internal bitdepth it might actually make sense to use qp below 0, although in general I would say that "-qp" should probably be between 15 and 45 in order to produce useful result.

Did you get a chance to compare your encoded result to some other codec? Any comments on the quality?