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

[jonatans]

We have quite recently launched the new next-generation video codec xvc at xvc.io (https://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 (http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Divideon-Creates-xvc-an-HEVC-Codec-With-Reasonable-Pricing-122180.aspx), 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 :)).

[Selur]

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?
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

[jonatans]

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.

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.

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.

[nevcairiel]

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.

[iwod]

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?

Sometimes I wonder how much does it actually cost to buy all the patents in the current HEVC Pool.

[jonatans]

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.

[nevcairiel]

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

[jonatans]

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.

[jonatans]

We have just added an online comparison of xvc and h.264 for low bit rate streaming scenarios: https://www.divideon.com/products-and-services/mobile-video-streaming-with-xvc/

Please have a look and share your thoughts!

[iwod]

We have just added an online comparison of xvc and h.264 for low bit rate streaming scenarios: https://www.divideon.com/products-and-services/mobile-video-streaming-with-xvc/

Please have a look and share your thoughts!

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

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.

[ChaosKing]

Quality looks good but it would be nice to know which h.264 codec was used + settings.

[birdie]

We have just added an online comparison of xvc and h.264 for low bit rate streaming scenarios: https://www.divideon.com/products-and-services/mobile-video-streaming-with-xvc/

Please have a look and share your thoughts!

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

[jonatans]

Quality looks good but it would be nice to know which h.264 codec was used + settings.

Thanks!
For the h.264 encoding, x264 was used with preset placebo.

I have uploaded the uncompressed y4m file here (114 MB):
https://drive.google.com/open?id=1dXxwA7P_81EjOyn_0GFA6Lvm3OX8rnKQ

Encoding with x264:
ffmpeg -i tos.y4m -c:v libx264 -preset placebo -x264-params keyint=1080 -crf 38 tos_x264_120kbps.mp4
Encoding with xvc:
xvcenc.exe -input-file tos.y4m -speed-mode 0 -max-keypic-distance 1080 -qp 31-internal-bitdepth 8 -explicit-encoder-settings "aqp_strength 16" -output-file tos_xvc_120kbps.xvc -verbose 1

FFmpeg version: 20170305-035e932
xvc commit 79466050f8818e352ab0fbc6abe6bb4ed0b455c5

File sizes:
tos_x264_120kbps.mp4 - 358 KB
tos_xvc_120kbps.xvc - 346 KB

[jonatans]

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.

I created the following HEVC encoding using x265:
https://drive.google.com/open?id=1wYBwYipissnaOnS9ydDQ5cfPPxU3XGmz

from the following commands:
x265-64bit-8bit-2018-01-22.exe --input tos.y4m --keyint 1080 --preset placebo --crf 34 tos_x265_124kbps.265
ffmpeg -i tos_x265_124kbps.265 -codec copy tos_x265_124kbps.mp4
File size: 375 KB

Perhaps someone from the AOM group would like to create an AV1-encoding for comparison? ;)
The uncompressed y4m file is available here (114 MB):
https://drive.google.com/open?id=1dXxwA7P_81EjOyn_0GFA6Lvm3OX8rnKQ

[Selur]

any news on pipe support for those y4m files?

[Asmodian]

Pipe support for y4m would be great. It would be a huge usability improvement, especially since I already use y4m piping for encoding with x264 and x265. :)

[jonatans]

any news on pipe support for those y4m files?

Thanks for the feedback.

Pipe support for y4m files was added to the dev branch in December. The dev branch is where all development happens and I would suggest that you use that one if you are trying out xvc.

However, I have now also applied that commit to the master branch.

I've also added information about valid ranges for the command line parameters.

Please let me know if something doesn't seem correct or if you have any other feedback.

[Selur]

Please let me know if something doesn't seem correct or if you have any other feedback.
Some (optional) progress indication would be nice even when not using '-verbose 1'. First thought nothing was happening until I realized that xvcenc actually was using <7% of the available cpu using:
ffmpeg -y -loglevel fatal -threads 8 -i "H:/sequence/ED-360-png/%05d.png" -frames:v 15691 -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -output-file h:\test.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. :)

[jonatans]

Thank you Selur for the comments.

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?

[Selur]

Did you get a chance to compare your encoded result to some other codec? Any comments on the quality?
Not so far plan to do some encoding over the week, wanted to wait for a reply regarding the qp to get a rough idea what it's about. ;)

[Selur]

Argh,... I give up all the following calls:
ffmpeg -y -loglevel fatal -threads 8 -i "H:/sequence/ED-360-png/%05d.png" -frames:v 15691 -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 18 -explicit-encoder-settings "aqp_strength 16" -output-file h:\elephantsDream_360.xvc
ffmpeg -y -loglevel fatal -threads 8 -i "H:/sequence/ED-1080-png/%05d.png" -frames:v 15691 -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 18 -explicit-encoder-settings "aqp_strength 16" -output-file h:\elephantsDream_1080.xvc
ffmpeg -y -loglevel fatal -threads 8 -i "H:/sequence/tearsofsteel-4k.y4m" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 18 -explicit-encoder-settings "aqp_strength 16" -output-file h:\tearsofsteel-4k.xvc
ended with xvcenc crashing after running 2days or so,.. (got another call running, but I won't test this again until an new release,..)
Using another encoder like x264 or x265 instead of xvcenc didn't crash.

Cu Selur

Ps.: I also reencoded a 8bit console lagaringth capture using:
ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 18 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2.xvc

ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 24 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_24.xvc

ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 30 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_30.xvc

ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 34 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_34.xvc

ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 40 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_40.xvc

ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 50 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_50.xvc

ffmpeg -y -loglevel fatal -threads 8 -i "F:\TestClips&Co\files\Console 8bit\ng2.avi" -an -sn -vsync 0 -pix_fmt yuv420p -f yuv4mpegpipe - | xvcenc.exe -input-file - -verbose 1 -qp 60 -explicit-encoder-settings "aqp_strength 16" -output-file h:\ng2_60.xvc
uploaded the files (source&reencodes) to: https://drive.google.com/drive/folders/1fnyiP8j0JZDE7aO6uRyU9Ne0WwWRvfkp?usp=sharing

[jonatans]

Thanks Selur for sharing.

I tried to replicate your ED-360 encoding using both master (730987c) and dev (452170c) and both of my encodings completed successfully.

Did you use the same compiled encoder for all your runs? (I.e. version 1 of xvc - from the master branch)

Did you change anything compared to the other run that you reported in your earlier post (which from my understanding, was completed successfully) other than using -qp 18 -explicit-encoder-settings "aqp_strength 16"?

Please share any information you have about the crash (potential error message or printout, verbose output etc.)

Did you compile for 32-bit or 64-bit architecture?

[Selur]

Did you use the same compiled encoder for all your runs?
yes.

Did you change anything compared to the other run that you reported in your earlier post (which from my understanding, was completed successfully) other than using -qp 18 -explicit-encoder-settings "aqp_strength 16"?
Nope. I simply used the calls I posted.

Please share any information you have about the crash (potential error message or printout, verbose output etc.)
There was no additonal, uncommon printout or error message, just the usual Windows popup that complained about xvcenc crashing.

Did you compile for 32-bit or 64-bit architecture?
64bit. Uploaded the two binaries (xvcenc, xvcdec) to https://drive.google.com/drive/folders/0B_WxUS1XGCPASUZibG5XZkRfeTg?usp=sharing .

Cu Selur

[Tommy Carrot]

I ran a few tests with Selur's build (thanks btw). I did not test a wide variety of bitrate ranges and just tried a few test videos, but this encoder consistently beats av1 in all cases. Very promising, good job jonatans!

[jonatans]

I ran a few tests with Selur's build (thanks btw). I did not test a wide variety of bitrate ranges and just tried a few test videos, but this encoder consistently beats av1 in all cases. Very promising, good job jonatans!

Thank you Tommy!

[jonatans]

New results for xvc published at xvc.io (https://xvc.io/concept/performance/). The xvc codec performs clearly better than HEVC (HM) and AV1, with bitrate savings of 26% and 20%, respectively, for the 360p test sequences in the NETVC test set.

[colinhunt]

Not sure if I'm doing something wrong here. It took my 12-core Xeon roughly 53 seconds per frame to encode a 10-frame test, using a 1080p60 source. I used Selur's (hi!) build of xvcenc and one of his encoding scripts from post #21.

update: There's apparently some sort of a set-up cost at the beginning of the process. A 300-frame long encode just finished in 3179 seconds, i.e. an average of 11 seconds per frame. CPU load held steady at 5.5% during the encode.

[colinhunt]

I uploaded two source files and two encoding tests here: https://drive.google.com/open?id=1Hv9FcBRjEixEuKNNi3UnL-VbQybO6Zfd

The 1080p59.94 source footage was shot by me. Feel free to use the provided source files for your encoding testing (altho the footage is not for re-sale).

The 15-second source clips are encoded in 1) 8-bit 4:2:0 AVC at 42 Mbps (.mp4, 76MB) and 2) 8-bit 4:2:2 DNxHR SQ at 291 Mbps (.mov, 525MB).

[jonatans]

Thanks colinhunt! Nice to see that it's working ok.

Quality seems fine on your encodings, given that it's a compression ratio of around 50:1 compared to the mp4 file and around 350:1 compared to the mov file.

It's true that the encoding is slow, and there is no multi-threading.

However, a nice property of the .xvc files is that you can concatenate any two of them to create a new valid .xvc file.

So if you want to encode a longer sequence and use more than a single core, you can split up the work and then merge the output files at the end. It will however result in closed-GOP intra pictures so it will have a negative visual impact (especially at low rates and at short clips).

I created a simple python script for doing this. It expects a y4m input file but it should be possible to extend it to support any input format by adding a call to ffmpeg and using a seek operation to fetch the right part.
https://drive.google.com/open?id=1hRWN8n9124hM5t_S57ijjl72SpSGMYYV

I have also uploaded new binaries built from the latest commit of the dev branch. The default speed mode is now even slower than in version 1 (but also produces better quality) but there is also a speed-mode 2 which should give faster encoding times than xvc version 1.0 (and hopefully also better visual quality). It should be noted that these are experimental binaries for evaluation purposes only. It has not yet been decided what the final set of coding tools in xvc 2.0 will be.
https://drive.google.com/open?id=1kWFt0ehuhScfkvn7qPuQTZP-Rqqdy9Jx

[colinhunt]

Quality seems fine on your encodings, given that it's a compression ratio of around 50:1 compared to the mp4 file and around 350:1 compared to the mov file.
One of the encodes was actually created from an uncompressed 8-bit 4:2:2 .AVI source, not the .mov. The .avi is almost 4 gigabytes which is wayyy too much for my slow internet connection, hence it's not in the shared folder.

Thanks for the python script and new binaries!

[colinhunt]

Got an error from the new encoding binary (I named it xvcenc_dev.exe). First here's the script I ran:

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

Note: source is 10bit 4:2:2 DNxHD 1080p59.94. ffplay has no problem playing it, and ffmpeg transcodes it just fine.

Error msg: Assertion failed: 0, file C:\Users\jonat\proj\xvc\app\xvc_enc_app\y4m_reader.cc, line 93

Currently encoding the same source using Selur's build, same parameters except without "-speed-mode 2". Hasn't crashed so far.

update - uploaded the DNxHD source to shared folder: "fruit--dnxhd-10bit-422-440mbps--1080p5994.mov" (1.16 GB)

[jonatans]

Thanks for pointing this out!

The reason for the assert is that the y4m read function did not have support for 422. We have just checked in a fix to that. (There was no such support in version 1 either, but that binary might have been compiled without the asserts)

Here is a new binary: https://drive.google.com/open?id=1iJsjuMZtTsnUiv6jNsyQmWu6EwPwOQ10

Now it should be able to understand both 422 and 444 directly from the y4m file so there is no need to indicate "-input-chroma-format 2 -input-bitdepth 10". I hope it works fine now!

[colinhunt]

Thanks!

Hmm.. I'm seeing this upon running the new binary, regardless of whether parameters include "-input-chroma-format 2 -input-bitdepth 10" or not (tried both ways):

Input: -
Output: d:\output.xvc
Size: 1920x1080
Bitdepth: 8
Framerate: 59.9401
QP: 25

Selur's build reported a bitdepth of 10 with same source file.

[jonatans]

Hi again,

I think the problem relates to the settings for the ffmpeg pipe. In order to support 10 bit you need to add "-strict -1" and change from "-pix_fmt yuv422p" to "-pix_fmt yuv422p10le". Or remove the "-pix_fmt" parameter altogether if you want ffmpeg to pipe the same format as the original file.

That seems to be working fine for me.

[colinhunt]

^ Thank you!

I let that previous "Bitdepth: 8" encode finish. When I played it, decoder reported both output and internal bitstream had a bitdepth of 10. Well, no matter, I removed "-pix_fmt" and added "-strict -1" , and encoder is now reporting 10bit.

[colinhunt]

Added a new source file to the share. It's a 10-bit 4:2:2 1080p24.00 DNxHD .mov of motocross bikes rushing off from the starting line. Also added a qp32 xvc encode of that source with a bitrate of approx. 1 Mbps.

Source files in share:

Fruits
https://saitti.kuvat.fi/kuvat/encode_src/fruit-dnxhd-10bit-422.png/_smaller.jpg

Moss
https://saitti.kuvat.fi/kuvat/encode_src/moss-dnxhrsq-8bit-422.png/_smaller.jpg

Moto
https://saitti.kuvat.fi/kuvat/encode_src/moto-dnxhd-10bit-422.png/_smaller.jpg

[foxyshadis]

So is this an automatic 2-pass? The length of time before real encoding starts seems to indicate that it's doing some serious analysis beforehand. Is there a plan for developing a streaming encoder, or is the format generally designed only for archival?

[jonatans]

Also added a qp32 xvc encode of that source with a bitrate of approx. 1 Mbps.

Thanks for sharing additional encodings. Have you compared it to any other codec at the same bitrate?

So is this an automatic 2-pass? The length of time before real encoding starts seems to indicate that it's doing some serious analysis beforehand. Is there a plan for developing a streaming encoder, or is the format generally designed only for archival?

The xvc codec is targeting streaming rather than archival, but so far only offline (non-realtime) encoding. There is no speed mode in xvc (yet) that can do realtime encoding. In the dev version of xvc there is experimental support for automatic multi-pass encoding (-multi-passes 2) and there is also a single pass mode that includes a quick determination of which start picture to use (-multi-passes 1) but the default is normal single pass encoding (-multi-passes 0) and in that mode there is no analysis of the video prior to encoding.

The encoding is quite slow so it will take some time before the first picture has been encoded (and the statistics of that picture is output if -verbose 1 is used), so maybe that is the reason why it appears to take long time before encoding is started.

[colinhunt]

Thanks for sharing additional encodings. Have you compared it to any other codec at the same bitrate?

Ran a comparison just now. Encoded the "moto" clip at 1mbps, using x265 Slow 1-pass preset, to match xvc encode's bitrate. Below is a graph depicting the 3SSIM metric for x265 and xvc encodes compared to the DNxHD original. Closer to 1.000 is better.

https://saitti.kuvat.fi/kuvat/encode_src/moto--dnxhd-10bit-422-1080p2400fps-468frames_xvc--moto-1mbps-speed2-10bit422-1080p5994_x265--moto-1mbps-slow1pass-10bit422-1080p5994-ffmpeg_3ssim.png?img=medium

x265 (green) catches up with xvc (red) briefly at frame 250, also somewhere around frames 332-335, and from frame 385 onwards it fares slightly better than xvc on average. It's perhaps worth noting that I used speed-mode 2 for the xvc encode.

(Argh. Noticed now that I had misnamed the files; instead of 1080p5994 both should have read 1080p24.)

[jonatans]

Ran a comparison just now.

Thanks colinhunt for running the comparison and sharing the results!

[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]

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
https://saitti.kuvat.fi/kuvat/VQMetrics/3SSIM-xvc-av1.png/_medium.jpg

MSSIM
https://saitti.kuvat.fi/kuvat/VQMetrics/MSSIM-xvc-av1.png/_medium.jpg

[LigH]

:eek: A new toy!

:( Slower than AV1...

:rolleyes: MABS won't include it, fearing MPEG license related problems; but gave manual building instructions (https://github.com/jb-alvarado/media-autobuild_suite/issues/734#issuecomment-362054956) which seem to be successful.

[colinhunt]

:( 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.

:rolleyes: MABS won't include it, fearing MPEG license related problems; but gave manual building instructions (https://github.com/jb-alvarado/media-autobuild_suite/issues/734#issuecomment-362054956) 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]

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]

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]

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]

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]

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/1jFSHB4TkZZiUgG8gqimda9X0EPf0A2pE/view?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 (https://www.mediafire.com/file/me5etoudwvl04lw/xvc_2018-03-15_3e1db91.7z) (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 (https://www.mediafire.com/file/rgudhswfap81vvh/xvc-dev_2018-05-18_d2355cd.7z) (MSYS2/MinGW 32+64, GCC 7.3.0)

[jonatans]

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.

[pie]

Building the googletest sources fails

iirc with mingw you need to pass -Dgtest_disable_pthreads=ON or something to that effect.

[LigH]

@pie: That was the old "master" version.
_

@jonatans:

This dev version crashes reading from a Y4M:

Assertion failed!

Program: E:\Programme\xvc\Win64\xvcenc.exe
File: H:/development/media-autobuild_suite-master/build/xvc/app/xvc_enc_app/y4m_reader.cc, Line 124

Expression: pic_fmt.input_bitdepth != 0

Source is the usual "foreman" clip from Derf's collection on xiph.org, only patched to PAL frame rate:

YUV4MPEG2 W352 H288 F25:1 Ip A128:117
FRAME

Maybe a "C420" should be added to the Y4M header so that your Y4M reader knows exactly which YUV variant it is?

[jonatans]

Yes, our y4m parser assumed that the C parameter would be present in the y4m header.

I have just changed so that "C420" is assumed if there is no C parameter present.

I also added support for "Cmono".

[LigH]

A good reason to build anew: xvc-dev 2018-05-18 bbf1325 (https://www.mediafire.com/file/gzai00ew4jjr0bm/xvc-dev_2018-05-18_bbf1325.7z)

[benwaggoner]

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.
SSIM and especially PSNR are not very good metrics, particularly with advanced new codecs. Or anything that is psychovisually tuned.

VMAF is probably the least-bad objective metric we have, but still has some pretty big limitations and blind spots. It wasn't tested with anything >1080p or below something like 300 Kbps. SDR 8-bit only. A quite weak temporal comparison module. And it was trained on just x264, and so doesn't know what to do with new types of artifacts AV1 and HEVC can have.

Plus there's the whole question of how you aggragate individual frame scores into a clip score. Just the mean of the metrics can't discriminate between content that is consistently mediocre versus oscillating between terrible and pristine.

With a new codec, actually looking at it is really the only thing that can give a better than a rough ballpark. Certainly a difference of less than 5 VMAF, 4 PSDR dB, and 3 SSIM dB should be verified visually.

[maxcoolzero]

Wow. Looks cool

[jonatans]

SSIM and especially PSNR are not very good metrics, particularly with advanced new codecs. Or anything that is psychovisually tuned.

VMAF is probably the least-bad objective metric we have, but still has some pretty big limitations and blind spots. It wasn't tested with anything >1080p or below something like 300 Kbps. SDR 8-bit only. A quite weak temporal comparison module. And it was trained on just x264, and so doesn't know what to do with new types of artifacts AV1 and HEVC can have.

Plus there's the whole question of how you aggragate individual frame scores into a clip score. Just the mean of the metrics can't discriminate between content that is consistently mediocre versus oscillating between terrible and pristine.

With a new codec, actually looking at it is really the only thing that can give a better than a rough ballpark. Certainly a difference of less than 5 VMAF, 4 PSDR dB, and 3 SSIM dB should be verified visually.

Thanks Ben, those are all very valid points.

I agree that PSNR is not a very good metric for determining visual quality. It is good for determining how close the compressed pictures are to the original pictures (in a mathematical sense - after all that is what PSNR measures, on a sample by sample basis). So if two different implementations are tuned to minimize MSE ("tune PSNR") then PSNR gives a good indication of how good the implementations are at doing just that. And even though this generally doesn't correlate well with visual quality it is good in the sense that it does not give any "false positives" (i.e. if one compressed picture A is tuned towards PSNR you cannot easily create another compressed picture B with higher PSNR by making it look worse than A).

We have put some results for the NETVC test conditions and test sequences at awcy.divideon.com, comparing xvc to AV1, both codecs with PSNR tuning (https://awcy.divideon.com/?job=1pass-av1-debargha-default-0202%402018-02-16T14%3A34%3A19.005Z&job=1pass-xvc-180226-sp0-chroma-1%402018-02-26T10%3A34%3A38.388Z) including results for PSNR (16.5% savings) MS-SSIM (23.3% savings) and VMAF (18.5% savings). It can be seen that the gains are quite sequence dependent but the overall trend is very clear and quite consistent among the metrics.

There is also a comparison between xvc and HM (https://awcy.divideon.com/?job=1pass-HM-16.17-ra10%402017-11-17T12%3A29%3A11.462Z&job=1pass-xvc-180226-sp0-chroma-1%402018-02-26T10%3A34%3A38.388Z) which shows slightly larger bitrate savings.

But, as you correctly point out, what matters in the end is the visual quality which can only be determined by actually looking at compressed video (encoded under fair conditions when it comes to complexity etc.)

Please share your impressions if you have had a chance to look at any xvc encoded sequences or made any visual comparisons.

[LigH]

xvc-dev 2018-05-24 9722ca7 (https://www.mediafire.com/file/ob3xwv4lkef2kld/xvc-dev_2018-05-24_9722ca7.7z/file) (dev branch commits (https://github.com/divideon/xvc/commits/dev))

[jonatans]

New version of xvc just released!

The source code is available in the master branch at https://github.com/divideon/xvc.

More info about the release in the official press release: http://www.releasewire.com/press-releases/divideon-releases-xvc-20-an-open-source-video-codec-with-a-royalty-free-baseline-1005793.htm

A few highlights:
- Better compression performance
- A royalty-free baseline profile
- Multi-threaded encoding
- Dual-licensing scheme: LGPL and commercial license

Enjoy! / Jonatan

[LigH]

Fresh build of xvc v2.0 2018-07-04 (commit 283009f) in my archive (https://www.mediafire.com/?4dcbb2dwc5tby). No obvious code additions since last dev build in May.

[colinhunt]

^ Thanks!

[colinhunt]

Hmm, I can't make xvc 2.0 do multi-threading. Tried with "-threads 10" and "-threads -1" but it insists on running on a single core. Cmdline:

xvcenc.exe -input-file moto.yuv -input-width 1920 -input-height 1080 -input-bitdepth 8 -framerate 24 -verbose 1 -threads -1 -speed-mode 2 -qp 30 -explicit-encoder-setti
ngs "aqp_strength 16" -output-file output.xvc

[jonatans]

Thanks for making it available LigH. And thanks for testing colinhunt!

Did you try to run it long enough for the multi-threading to kick in?

Our multi-threading implementation uses picture level parallelism and due to the prediction structure it is only after the first two pictures have been completely encoded that multiple pictures are encoded in parallel. (Before that everything is coded in a single thread)

I just tried both my own compiled xvcenc and the one provided by LigH and both are able to do multi-threading.

[colinhunt]

Well, shoot. My impatience got the best of me yet again! I'll re-run the cmdline, and this time I'll wait for longer than 30 seconds. Thanks Jonatan!

update: it has now processed 19 pictures, based on the list it outputs on screen, but I still don't see multi-threading. Average CPU usage hovers at 5-6% and it looks like only a single core/thread is running at 100%.

...okay, I noticed now there is *some* life in the graphs for 7-8 threads but those peak at 5% before quickly dying back down to 0%. Not quite what I expected tbh.

update #2: I changed "-threads -1" to "threads 20" and now re-running the cmdline. A moment ago xvc's CPU usage hit 47%, while 10-ish threads were running at 100%. Encoder spat a number of lines of text on screen, followed by CPU usage dropping to 15% ... It jumped to 25% while I was typing that previous sentence ... And now to 45%. Here comes another set of text on screen, CPU use goes down to 10% and the cycle starts again.

[colinhunt]

Encoding finished in 94 minutes. Some months ago the same source file with same encoding parameters (except multi-threading, of course) took 183 minutes to encode. So almost 50% faster now with multi-threading.

[jonatans]

Hmm, that does not seem to be right. You should get substantially more than 2x speed-up (unless you are actually running it on a 2 core CPU ;) ).

Perhaps you can try using this binary instead:

https://drive.google.com/open?id=1sP7KQdj6C8VPe6wdnP5Mdixkvo5TqsSI

The reason for why you don't see higher than 50% CPU usage could potentially be related to memory-usage. With 20 threads and 1080p resolution, xvc might try to allocate more memory than what is available on the system. Are you running on a 20 core system? Perhaps you can try using something in the order of 8 or 10 threads instead to get more stable performance. Or try with lower resolution video just to see if you can get all cores fully utilized.

As you have correctly noted there is currently no way of letting xvcenc figure out the optimal number of threads to use (as is done in xvcdec). This is also related to the memory-usage. With additional testing on a wide variety of combinations of CPU-cores and memory-availability, it should be possible to figure out a good scheme for doing this automatically, but we haven't done that yet.

[iwod]

The first version of xvc was released in September 2017 and was able to clearly outperform all existing video codecs including HEVC. The second version of xvc delivers even better performance and makes it possible to reduce the bitrate compared to the recently released AV1 codec by between 10% and 20% for the same visual quality.

I really rather like the PR. The humble, tone down figures. Pretty sure the first version already had similar to AV1 performance or better. At least according to other members clips and testing.

[colinhunt]

Perhaps you can try using this binary instead
I'll give it a shot.

The reason for why you don't see higher than 50% CPU usage could potentially be related to memory-usage. With 20 threads and 1080p resolution, xvc might try to allocate more memory than what is available on the system.
It was hogging a bit over 5GB, on a 32GB system.

Are you running on a 20 core system?
No, the CPU's a 10-core / 20-thread Xeon.

Perhaps you can try using something in the order of 8 or 10 threads instead to get more stable performance.
I'll try with 10 threads next time. Thanks Jonatan.

[Leeloo Minaï]

I tried binary from jonatans and multi-threading seems to work well, at least for me.

Is it possible to show encoding progress in the next release ?

[colinhunt]

xvcenc.exe -input-file moto.yuv -input-width 1920 -input-height 1080 -input-bitdepth 8 -framerate 24 -verbose 1 -threads 20 -speed-mode 2 -qp 30 -explicit-encoder-settings "aqp_strength 16" -output-file output.xvc

v1 binary: 183 minutes, no multi-threading.
v2 binary (LigH's): 94 minutes. 20 threads, CPU usage peaked at 47%.
v2 binary (Jonatan's): 51,3 minutes. 20 threads, RAM usage 5.9GB, CPU usage peaked at 56%.

v2 binary (Jonatan's): 51 minutes. 10 threads, CPU usage peaked at 55%.

v2 binary (Jonatan's): 51 minutes. 40 threads, RAM usage 8.5GB, CPU usage peaked at 59%.
v2 binary (Jonatan's): 51 minutes. 8 threads, RAM usage 2.1GB.

[LigH]

No clue why mine is slower. Plain GCC 7.3.0 build. What's different in jonatans', new dev revision or higher CPU optimization while compiling C sources?

[MoSal]

- Dual-licensing scheme: LGPL and commercial license

Is the first L in LGPL intentional?

[Zebulon84]

LGPL = Lesser General Public License.
Lesser because it allows the work to be linked to work with other type of license. Here it allows it to be used as a library (.dll) in any software. If it was GPL, it could only be used within GPL software.

[MoSal]

LGPL = Lesser General Public License.
Lesser because it allows the work to be linked to work with other type of license. Here it allows it to be used as a library (.dll) in any software. If it was GPL, it could only be used within GPL software.

I know. That's why I'm asking. Dual licensing is usually GPL/commercial. Or GPL/LGPL.

LGPL/commercial still makes sense if it's about the commercial licensee making source modifications and not contributing back. But, if this is about other limitations in the LGPL, then one would be better served with another license like the MPLv2.

[jonatans]

Is the first L in LGPL intentional?

Yes.

No clue why mine is slower. Plain GCC 7.3.0 build. What's different in jonatans', new dev revision or higher CPU optimization while compiling C sources?

I don't know really. Mine is built from xvc version 2, master branch, commit 283009f using the Visual Studio compiler.

I also get much slower encoding times with your build. Will try to look further into what causes the difference.

xvcenc.exe -input-file moto.yuv -input-width 1920 -input-height 1080 -input-bitdepth 8 -framerate 24 -verbose 1 -threads 20 -speed-mode 2 -qp 30 -explicit-encoder-settings "aqp_strength 16" -output-file output.xvc

v1 binary: 183 minutes, no multi-threading.
v2 binary (LigH's): 94 minutes. 20 threads, CPU usage peaked at 47%.
v2 binary (Jonatan's): 51,3 minutes. 20 threads, RAM usage 5.9GB, CPU usage peaked at 56%.

v2 binary (Jonatan's): 51 minutes. 10 threads, CPU usage peaked at 55%.

v2 binary (Jonatan's): 51 minutes. 40 threads, RAM usage 8.5GB, CPU usage peaked at 59%.
v2 binary (Jonatan's): 51 minutes. 8 threads, RAM usage 2.1GB.

Thanks for the extensive testing colinhunt. The reason why you do not see higher speed-up might be related to that the sequence you are encoding is roughly equally long as the segment length you are using. If you would be using a sequence that was 4 times as long or if you would set -max-keypic-distance to something like 160 you might get a higher speed-up factor (but that would of course also affect the compressed result).

[colinhunt]

The reason why you do not see higher speed-up might be related to that the sequence you are encoding is roughly equally long as the segment length you are using.
The source file, which I've shared earlier in this thread, is 468 frames long. What's the default segment length? That's what I'm (probably?) using.

[jonatans]

The source file, which I've shared earlier in this thread, is 468 frames long. What's the default segment length? That's what I'm (probably?) using.

Default segment length is 640. To get high level of parallelism with a 468 frames long sequence you might try for example -max-keypic-distance 160 or even -max-keypic-distance 128.

[jonatans]

Some more speedups and printout of PSNR has been added to the master branch of https://github.com/divideon/xvc (use -tune 1 if you want to perform analysis based on PSNR and -tune 0 for best visual quality).

It would be interesting to hear more reports on the usage of threading in xvc in different configurations and on different platforms to see if there are settings that can be adjusted for improved performance.

Other comments and suggestions are of course also welcome.

[LigH]

New upload: xvc v2.0 2018-08-30 #1cbe133 (https://www.mediafire.com/file/n89izdm9z96zu9f/xvc_v2.0_2018-08-30_1cbe133.7z/file) (MSYS2, MinGW32 + GCC 7.3.0 / MinGW64 + GCC 8.2.0)

[Tommy Carrot]

I made only 1 test encode, so i dont know if it's a general behaviour or not, but the resulting video is identical to the one made with the older build from may, but it took nearly twice the time to finish. After the first keyframe is finished, it waits several minutes seemingly doing nothing (using 25% cpu on a 4 core haswell i5) until it starts to encode the inter-frames. Maybe i remember incorrectly, but i dont think the older build did that long wait. After that it seems to work ok, using 96-98% cpu at times. I set the number of threads to 4.

[LigH]

Does the 32 bit (GCC 7.3.0) build delay the same way as the 64 bit (GCC 8.2.0) build?

[Tommy Carrot]

Yes, the 32 bit build is doing the same. I had a 10 minute "idle time" between the first keyframe and the first inter-frame encoded. The whole encoding is taking 23 minutes. The old build did it in 11 minutes with identical output.

[jonatans]

I have uploaded 64-bit binaries built with Visual Studio. Available here: https://drive.google.com/open?id=1K0KLaaHRvH9i-SZHodEB_vDrj5XrajkA

[Tommy Carrot]

Your visual studio build doesn't do that long delay, it finished the same encode in 10 minutes.

edit: just to clarify, it still waits 2-3 minutes before it finishes the first inter-frame, it just seems to be generally faster.

[LigH]

Then we may need someone with experience in GNU profiling tools to discover the reason...

[benwaggoner]

Your visual studio build doesn't do that long delay, it finished the same encode in 10 minutes.

edit: just to clarify, it still waits 2-3 minutes before it finishes the first inter-frame, it just seems to be generally faster.
I'm guessing there is some kind of long lookahead taking place, so a bunch of frames are getting encoded and refined in RAM before the first inter frame in decode order gets written. This happens in all codecs to some degree. For example, a GOP like

IbBbPbBbP

Actually needs to get written to the file as:
IPBbbPBbb

The second frame can't be written until the fifth frame is finalized.

[LigH]

New upload: (MSYS2, MinGW32 + GCC 7.3.0 / MinGW64 + GCC 8.2.0)

xvc v2.0 2018-09-23 #d3e8b46 (https://www.mediafire.com/file/xjvj0e1s368av38/xvc_v2.0_2018-09-23_d3e8b46.7z/file)

New commit d3e8b46 in master: Allow parsing one picture nal after segment header

[Gravitator]

xvc v2.0 2018-09-23 #d3e8b46
C:\>xvcenc

Usage:
-input-file <string> -output-file <string> [Optional parameters]

Optional parameters:
-rec-file <string>
-input-width <16..65535>
-input-height <16..65535>
-input-chroma-format <0..3>
0: Monochrome
1: 4:2:0 (default)
2: 4:2:2
3: 4:4:4
-input-bitdepth <8..14>
-internal-bitdepth <8..14>
-framerate <0.0054..90000>
-skip-pictures <int>
-temporal-subsample <int>
-max-pictures <int>
-sub-gop-length <1..64> (default: 16)
-max-keypic-distance <int> (default: 640)
-closed-gop <int> (default: 0)
-num-ref-pics <0..5> (default: 2)
-checksum-mode <0..1>
0: Reduced checksum verification (default)
1: Maximum checksum robustness
-deblock <0..1> (default: 1)
-beta-offset <-32..31>
-tc-offset <-32..31>
-qp <-64..63> (default: 32)
-multi-passes <0..2>
0: Single-pass (default)
1: Single pass with start picture determination
2: Multi-pass
-speed-mode <0..2>
0: Placebo
1: Slow (default)
2: Fast
-tune <0..1>
0: Visual quality (default)
1: PSNR
-profile <0..1>
0: Full (default)
1: Baseline
-threads <int>
-1: auto-detect
0: disabled (default)
1+: number of threads
-verbose <0..1>
There is no "-explicit-encoder-settings "aqp_strength 16"" ?

[Gravitator]

Can you add the ability to pause xvc coding in ffmpeg?

[jonatans]

Can you add the ability to pause xvc coding in ffmpeg?

Sounds interesting but it's not something we have looked in to. Is this a capability that is available for any other codecs in ffmpeg? Can you provide an example?

[jonatans]

xvc v2.0 2018-09-23 #d3e8b46

There is no "-explicit-encoder-settings "aqp_strength 16"" ?

In xvc, internal encoder settings (settings that control how decisions and evaluations are made in the encoder) are exposed via the "-explicit-encoder-settings" cli parameter. These settings are primarily intended for development purposes and are not intended to be modified by the user and that is why this setting is not shown in the printout.

The full list of settings that can be modified by the "-explicit-encoder-settings" parameter can be found in the ParseExplicitSettings function in encoder_settings.cc.

We used this setting to generate the encode for our online demo (at https://www.divideon.com/products-and-services/mobile-video-streaming-with-xvc/) as described in https://forum.doom9.org/showthread.php?p=1832272#post1832272. This was done in order to more closely meet the bitrate target. The difference in bitrate between two "-qp" steps are typically in the order of 12% so aqp_strength can be used to generate bitrate points in between.

[Gravitator]

Sounds interesting but it's not something we have looked in to. Is this a capability that is available for any other codecs in ffmpeg? Can you provide an example?
Привет!
I have a 50% load of coding can suddenly jump into 100% (the system squeaks) for a long time, then go back to 50%.
A pause can give: a breather, give a use for other heavy programs, it is possible that it will allow back to reduce the load (there may be a conflict of processes, or is it a feature of the coder's floating load ...).
Or we can wait for separate scripts, GUI with a pause. :D

[jonatans]

Привет!
I have a 50% load of coding can suddenly jump into 100% (the system squeaks) for a long time, then go back to 50%.
A pause can give: a breather, give a use for other heavy programs, it is possible that it will allow back to reduce the load (there may be a conflict of processes, or is it a feature of the coder's floating load ...).
Or we can wait for separate scripts, GUI with a pause. :D

I see. The mutlithreading in the xvc software is so far entirely based on picture-level parallelism and it will encode as many pictures as it can in parallel, as long as they don't depend on each other. The prediction structure of reference pictures will cause the processor load to sometimes go down while waiting for new reference pictures to be completed.

If you want to ensure that your processor load never reaches 100% you can set the -threads parameter to a value that is lower than the number of cores available on your system. But this will of course also increase the encoding time somewhat.

[foxyshadis]

Can you add the ability to pause xvc coding in ffmpeg?

Are you on Windows? Just press the pause key in the command window and FFmpeg will stop feeding the encoder frames until you press it again.

Pausing happens through the application ideally, not individual codecs inside of it.

[Gravitator]

Are you on Windows?
Win10x64
Just press the pause key in the command window and FFmpeg will stop feeding the encoder frames until you press it again.
There is no reaction to pressing the Pause key.

[Vin]

XVC is simply the best codec right now. Able to beat HEVC and AV1. But the real question. Is there a chance that the codec is going to actually be usable for anything other than just testing any time soon? Browser support, player support?
Any kind of hope?

[Selur]

decoding support in ffmpeg/libav would be great

[nevcairiel]

If you want widespread decode support, there should be a royalty free license for decoding-only. Let content distribution pay the bills.

But there also is no content, and without getting any major content distributor on board it's mostly irrelevant anyway.

[hajj_3]

XVC is simply the best codec right now. Able to beat HEVC and AV1. But the real question. Is there a chance that the codec is going to actually be usable for anything other than just testing any time soon? Browser support, player support?
Any kind of hope?

H.266/VVC is due to be ratified in October 2020, that will provide a large compression advantage over AV1. If the creator of XVC wants to make some money then he should patent any tools that are great that he has created then submit those tools to the MPEG-LA for inclusion in the H.266/VVC standard. He could earn a decent amount from that and a lot of people would benefit due to how widespread the codec will be.

[iwod]

H.266/VVC is due to be ratified in October 2020, that will provide a large compression advantage over AV1. If the creator of XVC wants to make some money then he should patent any tools that are great that he has created then submit those tools to the MPEG-LA for inclusion in the H.266/VVC standard. He could earn a decent amount from that and a lot of people would benefit due to how widespread the codec will be.

I think many part of xvc are what VVC will be, so it is like a head start into a commercial implementation.

[Gravitator]

Have a fresh build? And advise good settings for encoding in the 8000kbit/s range (Park_Joy).

[jonatans]

Fresh build of xvc for Windows x64 here: https://drive.google.com/file/d/1MOZ_Mysg2ms92FQ5zv6iwdICSEdWya5G/view?usp=sharing

Let me know if you would like a build for a different platform (or if you would like to use ffmpeg with xvc support instead).

For Park_Joy, 8 mbps you should probably be using around QP 27 for 720p and QP 30 for 1080p.

I would suggest -speed-mode 2 if you want the result reasonably fast, or -speed-mode 1 if you want the highest quality.

Example command line:
xvcenc.exe -input-file park_joy_420_720p50.y4m -speed-mode 2 -qp 27 -threads 16 -rec-file rec.y4m -output-file enc.xvc -verbose 1

Took around 30 minutes to encode on my laptop and gave bitrate of 7.7 mbps.

[Gravitator]

And the modified ffmpeg?

[jonatans]

Fresh ffmpeg with xvc support: https://drive.google.com/file/d/1YwuCF3J8VTLDuuafCrtnMxkPLNKeJnn8/view?usp=sharing

Example command line:
ffmpeg.exe -i park_joy_420_720p50.y4m -c:v libxvc -speed-mode 2 -qp 27 -threads 16 enc.mp4

[Gravitator]

Correct...

-speed-mode <0..2>
0: Placebo
1: Slow (default)
2: Fast
3: Faster
----------------------------------
Add the build number to the info field?

[kanaka]

Is any tool to repack file.xvc do file.mp4 and file.mp4 to file.xvc?

[LigH]

The MP4 container will probably not accept xvc content officially, it has relatively strict specifications. The ffmpeg linked above (https://forum.doom9.org/showthread.php?p=1863434#post1863434) by jonatans may do so due to a high similarity to other MPEG video content formats. (Please note the difference between a container format and a content format; .mp4 is a container, .xvc is a raw video content stream.)

It's more likely that MKV may accept xvc content some day, but check their changelogs if a current version does. Version 30.1.0 "Forever And More" (2019-01-05) did not yet announce that in their docs/NEWS.txt of the MKVtoolnixGUI installation.

Disclaimer: Statements above are my humble opinions, I may be wrong.

[kanaka]

Please note the difference between a container format and a content format; .mp4 is a container, .xvc is a raw video content stream


I know difference, but I have script playxvc.bat

xvcdec.exe -bitstream-file %1 -output-file - | mpv.exe -

Dblclick on xvc file play this file in mpv. I cant do this with mp4 file.

[kanaka]

I've made tests of this codec (version from git, 18 january). It seems that xvc codec dont keep the same quality.

http://screenshotcomparison.com/comparison/128501

av1 q 36 vs xvc q 30 (and still too much blur). Other movies was acceptable.
I can't compare size becouse encoding was interrupted

[LigH]

Well, yes ... playxvc.bat uses xvcdec to decode *.xvc to an intermediate format mpv recognizes immediately. I would assume Y4M. But if you have an xvc video stream multiplexed in an MP4 container, xvcdec won't recognize the xvc video content stream inside the MP4 container. You would have to demultiplex it from the MP4 first, then decode the raw xvc content, and then forward it to the player ... very complicated.

Instead, use the ffplay inside ffmpeg_xvc20190121.zip (https://drive.google.com/file/d/1YwuCF3J8VTLDuuafCrtnMxkPLNKeJnn8/view) provided by jonathans.

[jonatans]

Thanks kanaka for testing and reporting!

Please note that the quantization scale is different in AV1 and xvc, so a lower qp in xvc might still produce lower rate (and worse quality) than AV1.

Without a completed encoding and matching file sizes I'm afraid screenshot comparisons doesn't provide much information.

If you are interested in still image comparisons you could perhaps start with encoding a single frame and make sure the file sizes are roughly the same.

Indication of command line settings and encoding times is of course also helpful to better understand what is being compared.

Regarding support for repacking .xvc files to .mp4 and vice versa, we have not yet added support for this in our ffmpeg version but it is on our todo list.

I hope the xvc-in-mp4 support in ffplay is sufficient for the time being, as suggested by LigH.

[kanaka]

Indication of command line settings and encoding times is of course also helpful to better understand what is being compared.


I uploaded movies to gdrive:
https://drive.google.com/drive/folders/1OtzOcp2p15ulCJMcmRvX42bYkM5cp855


./xvcenc -input-file 0007QDNTE7P37UMM.y4m -output-file 0007QDNTE7P37UMM_q30.xvc -internal-bitdepth 8 -max-keypic-distance 120 -qp 30 -threads 8 -verbose 1

./aomenc --frame-parallel=0 --tile-columns=3 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --threads=8 --end-usage=q --cq-level=36 --test-decode=fatal -o 0007QDNTE7P37UMM-av1opus.webm 0007QDNTE7P37UMM.y4m


I wanted to get medium quality movies so I started xvcenc with qp 32, next 31, and finally 30.
What qp should I set to get similar quality?

[jonatans]

Thanks for sharing the command lines.

A couple of recommendations:
- Do not use "-internal-bitdepth 8". It will make the quality worse for no real benefit.
- Make sure to use corresponding key-frame interval (I believe it would be "--kf-max-dist=120" in aomenc if you want to have at most 120 picture interval between access points).

Regarding what -qp to use to end up with similar quality, it is a bit difficult to guess since it can be quite sequence dependent. Is the sequence you are using available anywhere in uncompressed form? One approach is to start with a faster -speed-mode to get an indication of the bitrate a certain -qp value gives for a certain sequence, and then encode with a slower speed mode.

Perhaps around -qp 25 would be a good starting point for finding correspond quality and/or bitrate for this test case.

[Gravitator]

C:\>ffmpeg_xvc_enc.exe -i z:/x.mov -c:v libxvc -speed-mode 3 -qp 30 -threads 1 z:/x.mp4
ffmpeg version N-85113-g298f56e Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 5.3.1 (GCC) 20160211
configuration: --enable-gpl --enable-nonfree --enable-ffplay --enable-libxvc --extra-ldexeflags=-static --pkg-config-flags=--static --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32-
libavutil 55. 59.100 / 55. 59.100
libavcodec 57. 90.100 / 57. 90.100
libavformat 57. 72.100 / 57. 72.100
libavdevice 57. 7.100 / 57. 7.100
libavfilter 6. 83.100 / 6. 83.100
libswscale 4. 7.100 / 4. 7.100
libswresample 2. 8.100 / 2. 8.100
libpostproc 54. 6.100 / 54. 6.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'z:/x.mov':
Metadata:
major_brand : qt
minor_version : 0
compatible_brands: qt
creation_time : 2019-01-24T07:05:07.000000Z
encoder : FFmbc 0.7
Duration: 00:00:04.71, start: 0.000000, bitrate: 144682 kb/s
Stream #0:0(eng): Video: prores (apch / 0x68637061), yuv422p10le(smpte170m/unknown/unknown, progressive), 1920x948, 144708 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 24k tbc (default)
Metadata:
creation_time : 2019-01-24T07:05:07.000000Z
handler_name : DataHandler
Stream mapping:
Stream #0:0 -> #0:0 (prores (native) -> xvc (libxvc))
Press [q] to stop, [?] for help
[libxvc @ 0000021db5dca360] Using 0 encoder threads
Output #0, mp4, to 'z:/x.mp4':
Metadata:
major_brand : qt
minor_version : 0
compatible_brands: qt
encoder : Lavf57.72.100
Stream #0:0(eng): Video: xvc (libxvc) ([37][0][0][0] / 0x0025), yuv422p10le, 1920x948, q=2-31, 200 kb/s, 23.98 fps, 24k tbn, 23.98 tbc (default)
Metadata:
creation_time : 2019-01-24T07:05:07.000000Z
handler_name : DataHandler
encoder : Lavc57.90.100 libxvc
Assertion failed!

Program: C:\ffmpeg_xvc_enc.exe
File: /home/jonatan/xvc/src/xvc_common_lib/resample.cc, Line 90

Expression: 0

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
He does not like the resolution of 1920x948.

[kanaka]

Perhaps around -qp 25 would be a good starting point for finding correspond quality and/or bitrate for this test case.

Thanks jonathans. It means that qp is variable and should be adapted for every movie? If yes, then this is big disadvantage. Business wants one settings for all movies, which give similar quality (like crf).

I've made test again. Different sample of this movie. (I know that this movie is not HQ, specially)

I've uploaded xvc, av1 and y4m to : https://drive.google.com/drive/folders/1OtzOcp2p15ulCJMcmRvX42bYkM5cp855

It seems that qp25 is ok
http://screenshotcomparison.com/comparison/128563

xvc encoded with params

./xvcenc -input-file 0007QDNTE7P37UMM-sample.y4m -output-file 0007QDNTE7P37UMM-sample_q25.xvc -max-keypic-distance 120 -qp 25 -threads 8 -verbose 1


av1:

aomenc.exe --frame-parallel=0 --tile-columns=3 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --threads=4 --end-usage=q --cq-level=36 --kf-max-dist=120 --bias-pct=75 --test-decode=fatal -o 0007QXNOHNT8PWFC-sample_q36_c4_kf120.webm 0007QXNOHNT8PWFC-sample.y4m


And the result... xvc give better compression, but it is not so amazing.

0007QDNTE7P37UMM-sample_q25.xvc - 562.9 kB
0007QDNTE7P37UMM-sample_q36_c4_kf120.webm - 744,9 kB

[jonatans]

He does not like the resolution of 1920x948.

Thanks Gravitator for pointing this out. The problem should be fixed in this version: https://drive.google.com/file/d/1uEy7FDrxBUCLaJNtTHCynlYr3ShLZCrd/view?usp=sharing

/ Jonatan

[Gravitator]

And the result... xvc give better compression, but it is not so amazing.

0007QDNTE7P37UMM-sample_q25.xvc - 562.9 kB
0007QDNTE7P37UMM-sample_q36_c4_kf120.webm - 744,9 kB

Привет!
This lack of regulation of decimals...
Why not 2-pass for AOM?

[benwaggoner]

And the result... xvc give better compression, but it is not so amazing.

0007QDNTE7P37UMM-sample_q25.xvc - 562.9 kB
0007QDNTE7P37UMM-sample_q36_c4_kf120.webm - 744,9 kB
It is really hard to draw useful comparisons when both bitrate and subjective aspects are different between two encodes. In the absence of a highly accurate objective metric, double-blind subjective rating of different encodes that then get BD-rate calculated are the gold standard.

For someone doing private testing where that's not feasible, I recommend using 2-pass encoding and compare encodes at the same bitrate.

Also, remember we are comparing encoders, not the actual bitstream formats. The bitstream's capabilities provide an upper bound on what an encoder can do. But the psychovisual and rate control features of a given encoder can make a bigger difference than those between bitstreams. Hence x264 beating libaom in lots of real-world scenarios even though AV1 is inarguably the more capable bitstream. But x264 is just a much more mature and tuned encoder than libaom.

[kanaka]

For someone doing private testing where that's not feasible, I recommend using 2-pass encoding and compare encodes at the same bitrate.
I test posibility to use new codecs in business.
First we encoded x264 with 2pass, but 2pass with the same bitrate is not good solution for encoding different movies. I have 2 movies: one is single continuos shot (interview) and the second is movie from car's camera.
Encoding with constant quality: first movie save 70% of size... and second is bigger (with crf) becouse movie is very dynamic.

Encoding with constant quality we save about 20% of network bandwith (becouse we have a lot of interviews) and give us sure of quality.


Also, remember we are comparing encoders, not the actual bitstream formats. The bitstream's capabilities provide an upper bound on what an encoder can do. But the psychovisual and rate control features of a given encoder can make a bigger difference than those between bitstreams. Hence x264 beating libaom in lots of real-world scenarios even though AV1 is inarguably the more capable bitstream. But x264 is just a much more mature and tuned encoder than libaom.

I understand that these codecs are in development ... so I made my own tests. Both codecs are great and will be better, but they are terribly slow. I do not know how to speed up these encoders. processor with AVX2?, faster clock? I tested scalability. The growing number of threads does not give noticeable acceleration

[jonatans]

Why not 2-pass for AOM?

I guess aomenc was used with 2-pass encoding for this test since "--passes=2" was set.

..but they are terribly slow. I do not know how to speed up these encoders.

In xvcenc you can try -speed-mode 2 or even the experimental -speed-mode 3 to increase encoding speed, but it will also result in reduced compression performance. Increasing number of -threads should also speed up encoding, at least if you are encoding a "long enough" sequence.

[Gravitator]

I guess aomenc was used with 2-pass encoding for this test since "--passes=2" was set.

What does the union give? --passes=2 --cq-level=36

[kanaka]

In xvcenc you can try -speed-mode 2 or even the experimental -speed-mode 3 to increase encoding speed, but it will also result in reduced compression performance. Increasing number of -threads should also speed up encoding, at least if you are encoding a "long enough" sequence.

Thanks again.

I made another test - very dynamic movie.
https://drive.google.com/drive/folders/1OtzOcp2p15ulCJMcmRvX42bYkM5cp855

0007QXNOHNT8PWFC-sample_q36_c4_kf250.webm - 655.9 kB
0007QXNOHNT8PWFC-sample_q25_kf250.xvc - 824.5 kB
0007QXNOHNT8PWFC-sample_q30_kf250.xvc - 402.2 kB

q 30 is too bad, but q 25 is bigger than av1 qp 36. Strange

[kanaka]

What does the union give? --passes=2 --cq-level=36

It's from https://forum.doom9.org/showthread.php?p=1860475#post1860475

According hvmaf-720 (https://ibb.co/6ZQ6sTn)
av1 gp 36 shuld give similar quality to h264 crf 23.

[Gravitator]

Shows different bitrates :o
ffmpeg_xvc_enc.exe -i z:/1.y4m -pix_fmt yuv422p -c:v libxvc -speed-mode 3 -qp 30 z:/test.mp4
ffmpeg version N-85113-g298f56e Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 5.3.1 (GCC) 20160211
configuration: --enable-gpl --enable-nonfree --enable-ffplay --enable-libxvc --extra-ldexeflags=-static --pkg-config-flags=--static --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32-
libavutil 55. 59.100 / 55. 59.100
libavcodec 57. 90.100 / 57. 90.100
libavformat 57. 72.100 / 57. 72.100
libavdevice 57. 7.100 / 57. 7.100
libavfilter 6. 83.100 / 6. 83.100
libswscale 4. 7.100 / 4. 7.100
libswresample 2. 8.100 / 2. 8.100
libpostproc 54. 6.100 / 54. 6.100
Input #0, yuv4mpegpipe, from 'z:/1.y4m':
Duration: 00:00:05.20, start: 0.000000, bitrate: 276481 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 1280x720, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 25 tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> xvc (libxvc))
Press [q] to stop, [?] for help
[libxvc @ 00000138a6d74480] Using -1 encoder threads
Output #0, mp4, to 'z:/test.mp4':
Metadata:
encoder : Lavf57.72.100
Stream #0:0: Video: xvc (libxvc) ([37][0][0][0] / 0x0025), yuv422p, 1280x720 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 12800 tbn, 25 tbc
Metadata:
encoder : Lavc57.90.100 libxvc
frame= 130 fps=1.0 q=-0.0 Lsize= 496kB time=00:00:04.52 bitrate= 898.2kbits/s speed=0.0349x
video:493kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.470185%

C:\>ffmpeg_xvc_enc.exe -i z:/test.mp4
ffmpeg version N-85113-g298f56e Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 5.3.1 (GCC) 20160211
configuration: --enable-gpl --enable-nonfree --enable-ffplay --enable-libxvc --extra-ldexeflags=-static --pkg-config-flags=--static --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32-
libavutil 55. 59.100 / 55. 59.100
libavcodec 57. 90.100 / 57. 90.100
libavformat 57. 72.100 / 57. 72.100
libavdevice 57. 7.100 / 57. 7.100
libavfilter 6. 83.100 / 6. 83.100
libswscale 4. 7.100 / 4. 7.100
libswresample 2. 8.100 / 2. 8.100
libpostproc 54. 6.100 / 54. 6.100
[libxvc @ 000002412dad4280] Using 0 decoder threads
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'z:/test.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2mp41
encoder : Lavf57.72.100
Duration: 00:00:05.20, start: 0.000000, bitrate: 780 kb/s
Stream #0:0(und): Video: xvc (xvc1 / 0x31637678), yuv422p10le(progressive), 1280x720, 777 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 12800 tbn, 12800 tbc (default)
Metadata:
handler_name : VideoHandler
At least one output file must be specified

[Gravitator]

It is necessary to update the ffmpeg :o
C:\>ffmpeg_xvc_enc.exe -i z:\4K1.mkv -vf zscale=tin=smpte2084:min=bt2020nc:pin=bt2020:rin=tv:t=smpte2084:m=bt2020nc:p=bt2020:r=tv,zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0.000:peak=0.000,zscale=t=bt709:m=bt709:r=tv -pix_fmt yuv420p10le -strict -1 -c:v libxvc -speed-mode 3 -qp 30 -threads 1 z:\test.mp4
ffmpeg version N-85113-g298f56e Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 5.3.1 (GCC) 20160211
configuration: --enable-gpl --enable-nonfree --enable-ffplay --enable-libxvc --extra-ldexeflags=-static --pkg-config-flags=--static --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32-
libavutil 55. 59.100 / 55. 59.100
libavcodec 57. 90.100 / 57. 90.100
libavformat 57. 72.100 / 57. 72.100
libavdevice 57. 7.100 / 57. 7.100
libavfilter 6. 83.100 / 6. 83.100
libswscale 4. 7.100 / 4. 7.100
libswresample 2. 8.100 / 2. 8.100
libpostproc 54. 6.100 / 54. 6.100
Input #0, matroska,webm, from 'z:\4K1.mkv':
Metadata:
creation_time : 2018-07-22T13:06:52.000000Z
ENCODER : Lavf58.2.103
Duration: 00:00:02.31, start: 0.000000, bitrate: 21316 kb/s
Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1600 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
Metadata:
DURATION : 00:00:02.293000000
Stream #0:1(rus): Audio: aac, 48000 Hz, stereo, fltp (default)
Metadata:
title : ╨Ф╤Г╨▒╨╗╨╕╤А╨╛╨▓╨░╨╜╨╜╤Л╨╣
ENCODER : Lavc58.9.100 libfdk_aac
DURATION : 00:00:02.307000000
Stream mapping:
Stream #0:0 -> #0:0 (hevc (native) -> xvc (libxvc))
Stream #0:1 -> #0:1 (aac (native) -> aac (native))
Press [q] to stop, [?] for help
[AVFilterGraph @ 000002064b194140] No such filter: 'zscale'
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:0
Conversion failed!

[benwaggoner]

It's from https://forum.doom9.org/showthread.php?p=1860475#post1860475

According hvmaf-720 (https://ibb.co/6ZQ6sTn)
av1 gp 36 shuld give similar quality to h264 crf 23.
Is that for just this clip, or a more general prediction? QP has some correlation with CRF, but CRF works as a psychovisually tuned offset to QP.

[kanaka]

Is that for just this clip, or a more general prediction? QP has some correlation with CRF, but CRF works as a psychovisually tuned offset to QP.

It's only general prediction. I started encoding with qp 36 but now I encode with qp 32 because 36 is not enough for some movies.

Encoding Xvc or av1 takes too much time so i have i shot to quess what qp should I use.

[Gravitator]

The quality is amazing! Even in -speed-mode 3 mode! Are you planning to release a decoder to the masses?

[jonatans]

The quality is amazing! Even in -speed-mode 3 mode! Are you planning to release a decoder to the masses?

Thanks Gravitator for testing and reporting about the amazing quality!

The source code for the xvc decoder is available as open source under LGPL license: https://github.com/divideon/xvc

We have also developed integrations with different frameworks and players such as FFmpeg and ExoPlayer, available on request.

[Gravitator]

Give the opportunity to regulate the quantfactor I>P/P>B ?

[Gravitator]

Why is the -speed-mode 3 option missing in the updated ffmpeg? > Https://forum.doom9.org/showthread.php?p=1867899#post1867899

[jonatans]

Why is the -speed-mode 3 option missing in the updated ffmpeg? > Https://forum.doom9.org/showthread.php?p=1867899#post1867899

The updated ffmpeg in https://forum.doom9.org/showthread.php?p=1867899#post1867899 uses the public master branch of xvc from https://github.com/divideon/xvc while -speed-mode 3 is so far only available in our private development branch.

[augman000]

Hi Jonatan,

Is it possible to build an ffmpeg (or if not, an xvcenc/xvcdec) that would run on XP 32-bit? I have an older PC that I would like to do some testing on.

In my earlier tests, xvc is very efficient for low bitrate, low resolution situations. On this older PC, xvc seems ideal.

Any assistance would be much appreciated. If this can be built, I will run some tests and share my results here. Hopefully that will assist in development.

Thanks.

[LigH]

According to one of the developers I just contacted via IRC, the support for Windows XP in ffmpeg has been dropped quite a while ago (with version 4 (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=Changelog;h=33e0161e0dcbcb2efe5d04899f708ad8b90e5829;hb=HEAD#l109)), to improve the threading.

In addition, many linked libraries today will have their own restrictions (I remember x265 requiring special options, other codecs may not even care). So I doubt you will find any recent ffmpeg version still supporting it.

[benwaggoner]

Is it possible to build an ffmpeg (or if not, an xvcenc/xvcdec) that would run on XP 32-bit? I have an older PC that I would like to do some testing on.

In my earlier tests, xvc is very efficient for low bitrate, low resolution situations. On this older PC, xvc seems ideal.

Any assistance would be much appreciated. If this can be built, I will run some tests and share my results here. Hopefully that will assist in development.

Are you looking to test encoding or playback? I don't think 32-bit XP encoding is material to anyone anymore unless the goal is to benchmark encoding on an Atom-based security camera or something.

For decoding, yeah, that can make sense as a low bar. But for a forthcoming codec, the market is already 64-bit dominant. Pretty much everything has shipped as 64-bit for a while now. Looking at the latest Steam hardware survey (https://store.steampowered.com/hwsurvey), 96% of gaming PCs are on a 64-bit OS. The results would be interesting, but even if xvc barely worked on 32-bit, I don't know if that would negatively impact its prospects.

[jonatans]

Hi Jonatan,

Is it possible to build an ffmpeg (or if not, an xvcenc/xvcdec) that would run on XP 32-bit? I have an older PC that I would like to do some testing on.

In my earlier tests, xvc is very efficient for low bitrate, low resolution situations. On this older PC, xvc seems ideal.

Any assistance would be much appreciated. If this can be built, I will run some tests and share my results here. Hopefully that will assist in development.

Thanks.

Hi augman000, sorry for the slow response.

It is possible to build xvc for 32 bit. For Visual Studio 14 2015, you can follow the steps at https://github.com/divideon/xvc but replace cmake -G "Visual Studio 14 2015 Win64" .. with cmake -G "Visual Studio 14 2015" ..

I've uploaded 32-bit binaries for Windows here if you would like to try it out: https://drive.google.com/file/d/1lcGZc90ZFJj6_mn3pddrlWIHG5gJqNcy/view?usp=sharing

This is built from the master branch of https://github.com/divideon/xvc.

I would be happy to hear how the experiment turns out. :)

[Gravitator]

Привет!
Are there any improvements in coding? Please share ffmpeg assembly (I follow the blurring of b-frames).

[LigH]

I believe xvc may not compile well in GCC 10.1:

In file included from ../src/xvc_common_lib/transform_data.cc:22:
../src/./xvc_common_lib/transform_data.h:32:16: error: 'int16_t' does not name a type
32 | static const int16_t kDct2Transform4[4][4];
| ^~~~~~~
../src/./xvc_common_lib/transform_data.h:33:16: error: 'int16_t' does not name a type
33 | static const int16_t kDct2Transform8[8][8];
| ^~~~~~~

...

[jonatans]

Thanks LigH for reporting.

The problem was fixed in https://github.com/divideon/xvc/commit/e875a2e17d9a0c92089dae582167a85f4e858cd4

[Gravitator]

Looks like XVC moved to x265 as --hevc-aq.

[benwaggoner]

Looks like XVC moved to x265 as --hevc-aq.
Huh? Where did you get that?

I thought that VVC picked up some xvc features and contributions.

[LigH]

Now that would be some remarkable inheritance. https://cosgan.de/images/smilie/froehlich/a020.gif

[benwaggoner]

Now that would be some remarkable inheritance. https://cosgan.de/images/smilie/froehlich/a020.gif
In fact jonatans told me about how VVC got a some good xvc features at IBC last year. The specifics have faded with time, alas.

[jonatans]

Looks like XVC moved to x265 as --hevc-aq.

I don't know anything about this. I don't think there is any relation between xvc and --hevc-aq in x265.

In fact jonatans told me about how VVC got a some good xvc features at IBC last year. The specifics have faded with time, alas.

Thanks Ben. Yes, in VVC there is the concept of "general constraint info" which makes it possible to indicate at the top level if some coding tools and features are disabled in the bitstream. This concept is inspired by the "restriction flags" in xvc which serves exactly the same purpose.

In EVC there are actually more features directly brought in from xvc such as a mode for determining the output order of pictures (Picture Order Count derivation) and a mode for implicit derivation of which reference picture to use for inter prediction.

/ Jonatan