Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
![]() |
#1 | Link |
Registered User
Join Date: Oct 2017
Posts: 56
|
xvc - a next-generation video codec at xvc.io
We have quite recently launched the new next-generation video codec xvc at xvc.io. The complete source code for encoding and decoding is available at GitHub with the development happening in the dev branch: https://github.com/divideon/xvc/tree/dev.
The xvc codec is free to use for everyone for personal use, evaluations and research. There is also a commercial license available. The ambition is for xvc to be the world's most efficient video codec while still keeping decoding complexity at a reasonable level in order to support efficient software decoding on various platforms. In an article about xvc, Streaming Media comments on the performance of xvc as "Pretty impressive performance" with xvc being the quality leader compared to HEVC, H.264, VP9 and AV1 for the two "real-world files". Please try it out and share what you think of it. All sorts of feedback is highly appreciated. The encoder has not yet been optimized for speed and is currently very slow (unless your point of reference is AV1, in which case the xvc encoder is actually very fast ![]() |
![]() |
![]() |
![]() |
#2 | Link | ||
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,566
|
Quote:
Quote:
Also: any recompiled Windows 64bit binaries available atm? Cu Selur |
||
![]() |
![]() |
![]() |
#3 | Link | |||
Registered User
Join Date: Oct 2017
Posts: 56
|
Quote:
Quote:
Quote:
|
|||
![]() |
![]() |
![]() |
#4 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,373
|
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
![]() |
![]() |
![]() |
#5 | Link |
Registered User
Join Date: Apr 2002
Posts: 756
|
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. |
![]() |
![]() |
![]() |
#6 | Link | |
Registered User
Join Date: Oct 2017
Posts: 56
|
Quote:
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. |
|
![]() |
![]() |
![]() |
#7 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,373
|
But doesn't that then potentially mean that previously encoded files become un-decodable as some features are disabled?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
![]() |
![]() |
![]() |
#8 | Link | |
Registered User
Join Date: Oct 2017
Posts: 56
|
Quote:
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. |
|
![]() |
![]() |
![]() |
#9 | Link |
Registered User
Join Date: Oct 2017
Posts: 56
|
We have just added an online comparison of xvc and h.264 for low bit rate streaming scenarios: https://www.divideon.com/products-an...ming-with-xvc/
Please have a look and share your thoughts! |
![]() |
![]() |
![]() |
#10 | Link | ||
Registered User
Join Date: Apr 2002
Posts: 756
|
Quote:
Quote:
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. |
||
![]() |
![]() |
![]() |
#11 | Link |
Registered User
Join Date: Dec 2005
Location: Germany
Posts: 1,822
|
Quality looks good but it would be nice to know which h.264 codec was used + settings.
__________________
AVSRepoGUI // VSRepoGUI - Package Manager for AviSynth // VapourSynth VapourSynth Portable FATPACK || VapourSynth Database |
![]() |
![]() |
![]() |
#12 | Link | |
Artem S. Tashkinov
Join Date: Dec 2006
Posts: 408
|
Quote:
|
|
![]() |
![]() |
![]() |
#13 | Link | |
Registered User
Join Date: Oct 2017
Posts: 56
|
Quote:
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=1dX...FA6Lvm3OX8rnKQ 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 |
|
![]() |
![]() |
![]() |
#14 | Link | |
Registered User
Join Date: Oct 2017
Posts: 56
|
Quote:
I created the following HEVC encoding using x265: https://drive.google.com/open?id=1wY...DQ5cfPPxU3XGmz 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=1dX...FA6Lvm3OX8rnKQ |
|
![]() |
![]() |
![]() |
#16 | Link |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,441
|
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.
![]()
__________________
madVR options explained |
![]() |
![]() |
![]() |
#17 | Link |
Registered User
Join Date: Oct 2017
Posts: 56
|
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. |
![]() |
![]() |
![]() |
#18 | Link | |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,566
|
Quote:
Code:
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 ![]() 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. ![]() Last edited by Selur; 3rd February 2018 at 09:22. Reason: added ps with encoding time |
|
![]() |
![]() |
![]() |
#19 | Link |
Registered User
Join Date: Oct 2017
Posts: 56
|
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? |
![]() |
![]() |
![]() |
#20 | Link | |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,566
|
Quote:
![]() |
|
![]() |
![]() |
![]() |
Tags |
codec, compression, video codec, video encoding, xvc |
Thread Tools | Search this Thread |
Display Modes | |
|
|