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.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th December 2017, 10:26   #1  |  Link
jonatans
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 ).
jonatans is offline   Reply With Quote
Old 18th December 2017, 19:25   #2  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Quote:
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?
Quote:
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
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 19th December 2017, 11:39   #3  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
Quote:
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.

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

Quote:
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.
jonatans is offline   Reply With Quote
Old 19th December 2017, 14:07   #4  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
Quote:
Originally Posted by Selur View Post
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 20th December 2017, 14:19   #5  |  Link
iwod
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.
iwod is offline   Reply With Quote
Old 22nd December 2017, 12:39   #6  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
Quote:
Originally Posted by iwod View Post
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.
jonatans is offline   Reply With Quote
Old 22nd December 2017, 13:22   #7  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,344
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
nevcairiel is offline   Reply With Quote
Old 22nd December 2017, 14:27   #8  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
Quote:
Originally Posted by nevcairiel View Post
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 is offline   Reply With Quote
Old 25th January 2018, 15:34   #9  |  Link
jonatans
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!
jonatans is offline   Reply With Quote
Old 27th January 2018, 19:37   #10  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
Quote:
Originally Posted by jonatans View Post
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!
At this moment i really wish someone could explain to me how to always be optimistic, because they say I am a pessimist.

Quote:
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.
iwod is offline   Reply With Quote
Old 27th January 2018, 20:15   #11  |  Link
ChaosKing
Registered User
 
Join Date: Dec 2005
Location: Germany
Posts: 1,795
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
ChaosKing is offline   Reply With Quote
Old 27th January 2018, 20:26   #12  |  Link
birdie
Artem S. Tashkinov
 
birdie's Avatar
 
Join Date: Dec 2006
Posts: 337
Quote:
Originally Posted by jonatans View Post
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!
Without x265, VP9 and AV1 results (which is close to completion) this comparison looks quite barren.
birdie is offline   Reply With Quote
Old 29th January 2018, 10:59   #13  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
Quote:
Originally Posted by ChaosKing View Post
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=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
jonatans is offline   Reply With Quote
Old 29th January 2018, 11:44   #14  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
Quote:
Originally Posted by birdie View Post
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=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
jonatans is offline   Reply With Quote
Old 31st January 2018, 20:43   #15  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
any news on pipe support for those y4m files?
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 31st January 2018, 21:18   #16  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
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
Asmodian is offline   Reply With Quote
Old 1st February 2018, 13:13   #17  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
Quote:
Originally Posted by Selur View Post
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.
jonatans is offline   Reply With Quote
Old 2nd February 2018, 21:54   #18  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Quote:
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:
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
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.
__________________
Hybrid here in the forum, homepage

Last edited by Selur; 3rd February 2018 at 09:22. Reason: added ps with encoding time
Selur is offline   Reply With Quote
Old 5th February 2018, 09:56   #19  |  Link
jonatans
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?
jonatans is offline   Reply With Quote
Old 5th February 2018, 17:53   #20  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Quote:
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.
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Reply

Tags
codec, compression, video codec, video encoding, xvc

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.