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 14th March 2018, 11:26   #41  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
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.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 14th March 2018, 14:00   #42  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
Quote:
Originally Posted by nevcairiel View Post
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.
jonatans is offline   Reply With Quote
Old 15th March 2018, 15:56   #43  |  Link
colinhunt
Registered User
 
Join Date: Dec 2002
Posts: 1,022
It might be interesting to hear/learn why x265 catches up and overtakes xvc from frame 385 onwards in my sample clip encodes.

Last edited by colinhunt; 15th March 2018 at 19:50.
colinhunt is offline   Reply With Quote
Old 17th March 2018, 23:16   #44  |  Link
colinhunt
Registered User
 
Join Date: Dec 2002
Posts: 1,022
I ran a few encodes today, with the aim of comparing xvc and av1. Now, this is far from a definitive comparison, seeing as I often have trouble finding my own butt with both hands, and generally just mess about with encoders like a drunkard stumbling around in the dark.

Aaanyway, here's how I set up the encodes.

source: 1080p24 8bit 4:2:0 469 frames
xvc: speed mode 2, qp30, explicit setting "aqp_strength 16", single pass
av1: cpu_used 2, tile-columns 6, usage vbr, threads 14, bitrate-target 1370kbps, single pass

Encoder versions

xvc: binary from Jonatans' post #32 in this thread
av1: LigH's binary 0.1.0-8449-g6471e8bd7

Encoding times, reported bitrates and filesizes

xvc: 10984 seconds / 1375 kbps (by encoder) / 3 360 139 bytes (.xvc)
av1: 9120 seconds / 1404 kbps (by Mediainfo) / 3 580 224 bytes (.webm)

It should be noted that xvc ran on a single thread at a cpu load of 4%, while av1 ran on 14 threads at an average cpu load of 20% (bouncing between 4-60%).

Metrics
Red is xvc, green is av1. Higher, i.e. closer to 1.000, is better.

3SSIM


MSSIM

Last edited by colinhunt; 17th March 2018 at 23:44.
colinhunt is offline   Reply With Quote
Old 23rd March 2018, 07:14   #45  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
A new toy!

Slower than AV1...

MABS won't include it, fearing MPEG license related problems; but gave manual building instructions which seem to be successful.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 23rd March 2018, 10:00   #46  |  Link
colinhunt
Registered User
 
Join Date: Dec 2002
Posts: 1,022
Quote:
Originally Posted by LigH View Post
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.

Quote:
MABS won't include it, fearing MPEG license related problems; but gave manual building instructions which seem to be successful.
Harsh words there by the MABS dev...
colinhunt is offline   Reply With Quote
Old 23rd March 2018, 10:31   #47  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
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.
jonatans is offline   Reply With Quote
Old 23rd March 2018, 17:48   #48  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 95
Quote:
Originally Posted by jonatans View Post
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.
__________________
https://github.com/MoSal
MoSal is offline   Reply With Quote
Old 23rd March 2018, 19:50   #49  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 24th March 2018, 07:31   #50  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,558
Quote:
Originally Posted by MoSal View Post
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.
foxyshadis is offline   Reply With Quote
Old 24th March 2018, 17:53   #51  |  Link
MoSal
Registered User
 
Join Date: Jun 2013
Posts: 95
@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.
__________________
https://github.com/MoSal

Last edited by MoSal; 26th March 2018 at 19:52.
MoSal is offline   Reply With Quote
Old 26th March 2018, 18:19   #52  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
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.
iwod is offline   Reply With Quote
Old 21st April 2018, 07:26   #53  |  Link
augman000
Registered User
 
Join Date: Jul 2005
Posts: 42
Quote:
Originally Posted by colinhunt View Post
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?
augman000 is offline   Reply With Quote
Old 21st April 2018, 08:30   #54  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 21st April 2018, 14:38   #55  |  Link
augman000
Registered User
 
Join Date: Jul 2005
Posts: 42
Quote:
Originally Posted by LigH View Post
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.
augman000 is offline   Reply With Quote
Old 21st April 2018, 14:50   #56  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Main show stoppers for me with xvc are atm.
a. no decoding through libav/ffmpeg
b. terribly slow encoding
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 21st April 2018, 17:08   #57  |  Link
augman000
Registered User
 
Join Date: Jul 2005
Posts: 42
Quote:
Originally Posted by Selur View Post
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:
Code:
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):
Code:
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.

Last edited by augman000; 22nd April 2018 at 01:24.
augman000 is offline   Reply With Quote
Old 18th May 2018, 10:47   #58  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
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/1jFS...ew?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.
jonatans is offline   Reply With Quote
Old 18th May 2018, 13:32   #59  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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
Code:
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 (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 (MSYS2/MinGW 32+64, GCC 7.3.0)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 18th May 2018 at 14:06.
LigH is offline   Reply With Quote
Old 18th May 2018, 14:02   #60  |  Link
jonatans
Registered User
 
Join Date: Oct 2017
Posts: 56
Quote:
Originally Posted by LigH View Post
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.
jonatans 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 17:03.


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