xvc - a next-generation video codec at xvc.io

[nevcairiel]

The high peaks (or low valleys, if you want) look disturbing. I can only assume those are I frames, a smoother difference between the frame types would feel more appropriate.

[jonatans]

Originally Posted by nevcairiel

The high peaks (or low valleys, if you want) look disturbing. I can only assume those are I frames, a smoother difference between the frame types would feel more appropriate.

The peaks are not related to I-pictures. They represent the temporal layer 0 pictures. The default coding structure in xvc is a hierarchical B-picture tree with 15 B-pictures.

Giving higher quality to pictures of lower temporal layers actually improves the overall quality in general. If the coding settings are modified to give more equal distribution you will get worse quality in most pictures. The quality of the pictures in low temporal layers needs to be reduced and since the pictures in higher temporal layers use those pictures as reference pictures, there will be a negative impact on the prediction.

As long as the lowest quality pictures are of good quality and there are no visual problems I don't think there is anything inappropriate with a bit of peaks and valleys in objective quality scores. Colinhunt's graph indicates that for most of the sequence the lowest quality xvc pictures are actually better than the highest quality x265 pictures.

I would be very happy to hear comments and feedback regarding the visual quality.

[colinhunt]

It might be interesting to hear/learn why x265 catches up and overtakes xvc from frame 385 onwards in my sample clip encodes.

[colinhunt]

I ran a few encodes today, with the aim of comparing xvc and av1. Now, this is far from a definitive comparison, seeing as I often have trouble finding my own butt with both hands, and generally just mess about with encoders like a drunkard stumbling around in the dark.

Aaanyway, here's how I set up the encodes.

source: 1080p24 8bit 4:2:0 469 frames
xvc: speed mode 2, qp30, explicit setting "aqp_strength 16", single pass
av1: cpu_used 2, tile-columns 6, usage vbr, threads 14, bitrate-target 1370kbps, single pass

Encoder versions

xvc: binary from Jonatans' post #32 in this thread
av1: LigH's binary 0.1.0-8449-g6471e8bd7

Encoding times, reported bitrates and filesizes

xvc: 10984 seconds / 1375 kbps (by encoder) / 3 360 139 bytes (.xvc)
av1: 9120 seconds / 1404 kbps (by Mediainfo) / 3 580 224 bytes (.webm)

It should be noted that xvc ran on a single thread at a cpu load of 4%, while av1 ran on 14 threads at an average cpu load of 20% (bouncing between 4-60%).

Metrics
Red is xvc, green is av1. Higher, i.e. closer to 1.000, is better.

3SSIM


MSSIM

[LigH]

A new toy!

Slower than AV1...

MABS won't include it, fearing MPEG license related problems; but gave manual building instructions which seem to be successful.

[colinhunt]

Originally Posted by LigH

Slower than AV1...

20 or so percent slower, yeah, but in my test xvc was running on single thread while av1 was running on 14 threads. It'll be interesting to see xvc performance once/if they implement multi-threading.

MABS won't include it, fearing MPEG license related problems; but gave manual building instructions which seem to be successful.

Harsh words there by the MABS dev...

[jonatans]

Thanks colinhunt for reporting more performance numbers!

Just a quick comment on the patent situation in xvc. Divideon (the developers of the xvc codec) is an MPEG member and we are in continuous dialog with the patent holders to try our best to get all the necessary agreements in place. But even though that may take some time, I would like to highlight that xvc is already in a better position than other codecs when it comes to licensing. Unless you are using a codec that is more than 25 years old, you will be at risk of infringing patents (and that would also be the case for software implementations like x264/x265 and libaom), and you will be at risk of receiving requests for paying a license for using those patents. The difference with xvc and the other codecs is that we promise to help you out (e.g. by designing around the patent in question) if the patent holder makes an unreasonable claim.

[MoSal]

Originally Posted by jonatans

I would like to highlight that xvc is already in a better position than other codecs when it comes to licensing. Unless you are using a codec that is more than 25 years old, you will be at risk of infringing patents (and that would also be the case for software implementations like x264/x265 and libaom), and you will be at risk of receiving requests for paying a license for using those patents.

I'm not sure why you are not getting it. FUDing upfront is going to be as fruitful as FUDing down the line, that is, not fruitful at all.

Good luck with your post-xvc endeavors.

[LigH]

I will focus on the technical aspects and follow the development loosely until I see the chance to actually use it practically. Best wishes from my side.

[foxyshadis]

Originally Posted by MoSal

I'm not sure why you are not getting it. FUDing upfront is going to be as fruitful as FUDing down the line, that is, not fruitful at all.

Good luck with your post-xvc endeavors.

That's not FUD. FUD is Google boldly carrying On2's torch with a promise that nothing they make has ever been touched by a patent, and basically being forced to indemnify their adopters when the inevitable patent pool formed once the source code came out. (Which, to their credit, they actually did for all VP8 users up to that point. Pre-Google adopters could take it up with On2.)

Saying that "things happen" and the next version will excise any patent-protected process is a realistic warning to their users to hope for the best but expect rocky roads and re-encodings.

[MoSal]

@foxyshadis

1- You might want to check what FUD means.

2- I would trust the actual lawyers, with actual relevant experience and expertise, who are hired by multiple corporations (not just Google), to okay everything that gets added to AV1, over an unpractical scheme, augmented with inconcrete promises of legal protection, and tired attempts at spreading FUD against the competition.

[iwod]

I am starting to understand and guess what xvc might be.

It tries to be an all JVET H.266 encoder, and once all the body and decision are made regarding to tools and features used in spec, xvc with its feature selection will be the first JVET h.266 encoder on the market.

[augman000]

Originally Posted by colinhunt

ffmpeg -y -loglevel fatal -threads 8 -i "10bit-dnxhd.mov" -frames:v 100 -an -sn -vsync 0 -pix_fmt yuv422p -f yuv4mpegpipe - | xvcenc_dev.exe -input-file - -verbose 1 -input-chroma-format 2 -input-bitdepth 10 -speed-mode 2 -qp 25 -explicit-encoder-settings "aqp_strength 16" -output-file d:\output.xvc

Is there any way to modify this to also add the decoding (xvcdec) after encoding? If so, how?

[LigH]

Maybe if you use "-output-file -" and pipe xvcdec_dev ... but I would not recommend it: if it works at all, it would not leave any file on your disk.

[augman000]

Originally Posted by LigH

Maybe if you use "-output-file -" and pipe xvcdec_dev ... but I would not recommend it: if it works at all, it would not leave any file on your disk.

I did try that and for one reason or another it did not work properly.

But I think you're right. As long as xvc takes to encode a video, not having the actual file to revert back to is a pretty bad idea.

By the way: I am really liking xvc. It is beating AV1, x265, and VP9 in my tests with PSNR and SSIM scores. I'd like to measure VMAF as well but I have been unsuccessful in all my attempts to compile a working win64/win32 binary.

Thanks.

[Selur]

Main show stoppers for me with xvc are atm.
a. no decoding through libav/ffmpeg
b. terribly slow encoding

[augman000]

Originally Posted by Selur

Main show stoppers for me with xvc are atm.
a. no decoding through libav/ffmpeg
b. terribly slow encoding

I do agree regarding the lack of ffmepg integration. But, for speed, with lower resolutions at leaast (haven't tested higher yet), it isn't so bad for the quality it produces.

Here is a quick test on my i7-3770k, Win 7 x64 PC of a 10 second, 428x240 clip using Timer 3.01 from Igor Pavlov (author of 7-Zip) for accurate timings:

PSNR       SSIM      TIME      CODEC / OPTIONS
================================================================
44.845179  0.983561  252.955s  libaom-av1 -b:v 100K -cpu-used 4
46.537460  0.988025  334.294s  xvcenc -qp 25 -speed-mode 2
45.024133  0.983995  444.758s  libaom-av1 -b:v 100K -cpu-used 3

And here is the same clip at 480p (854x480):

PSNR       SSIM      TIME      CODEC / OPTIONS
================================================================
47.507486  0.990071  1179.726  libaom-av1 -b:v 300K -cpu-used 4
47.905909  0.991473  1237.431  xvcenc -qp 25 -speed-mode 2
47.662076  0.990272  1939.154  libaom-av1 -b:v 300K -cpu-used 3

Obviously this is just one 10s clip at a very low resolution. But for my me, these results are pretty good.

[jonatans]

We have now added support for multi-threaded encoding in the dev branch of xvc. I have created new binaries available here:

https://drive.google.com/file/d/1jFS...ew?usp=sharing

Threading is disabled by default. In order to turn it on, set the '-threads' parameter to the number of threads desired. The implementation is a variant of picture-based threading with the main benefit of not having any impact on picture quality (it gives identical bitstreams as when running without threads). It has the downside of increasing memory usage linearly with number of threads. Also note that it takes some time for utilization to reach its peak performance. As an example, when using 8 threads you typically need to code at least 128 pictures for this to happened.

Please let me know if you have any feedback or any suggestions for improvements.

[LigH]

Just tried to build the sources in the MSYS2/MinGW environment of MABS, but since I also have MSVC 2015 installed, CMake detects it first and prefers to create MSVC solutions, so I had to explicitly request

cmake -G "MSYS Makefiles" ..

Building the googletest sources fails with GCC 7.3.0 (error: 'AutoHandle' does not name a type; did you mean 'LongToHandle'?); but decoder and encoder have been built already.

MediaFire: xvc 2018-03-15 3e1db91 (MSYS2/MinGW 32+64, GCC 7.3.0)

The help output of xvcenc does not yet mention "-threads" as available parameter.

In addition: "Error: Unknown argument: -threads" ... apparently my MinGW builds do not know about threading. Is that not enabled in the github repo?
_

Aah, I should have taken the "dev" branch, not "master". Once again...

MediaFire: xvc-dev 2018-05-18 d2355cd (MSYS2/MinGW 32+64, GCC 7.3.0)

[jonatans]

Originally Posted by LigH

Aah, I should have taken the "dev" branch, not "master". Once again...

Yes, the '-threads' option is currently only available in the dev branch. That is where all new tools and features are added in preparation for the release of the next version of xvc.