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

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