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.