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 7th November 2016, 19:49   #101  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
Quote:
Originally Posted by Jamaika View Post
Test Clare codec AV1 vs X165 is underestimated because preset is good, bpg has veryslow.
Preset for X265 is:
0.ultrafast
1.superfast
2.veryfast
3.faster
4.fast
5.medium (default)
6.slow
7.slower
8.veryslow
9.placebo
Preset for VPX/AOM is:
0. rt + 37% quality
5. good (default) + 50% quality
9. best + max.63% quality
I associate it mistakenly with the parameter VPX "cq-level". So you could set for veryslow quality VPX best + max.63%.

No one probably doesn't know what effect it has value of quality "min-q". The first frame is always a big mistake for added value for codec VPX and AV1.

Interesting is also why each encoder VPX&AOM has a different parameter of quality.
FFmpeg has CRF.
What possesses Adobe plugin 1.003? Must enter function "cq-level". Changing the value of quality means a change bitrate and the number of frames P. 37% is 2frames, 50% is 4 frames, 63% is 6 frames. It is a pity that libvpx isn't such fuction. Approached by a characteristic size of the frame to the X265. Changing good to best doesn't change the size of the bitrate, only the number of reference vectors in frame.
Edit: The function pass 2 is a falsification. There is no dynamic frame B. Analyzer video Elecard doesn't show that it has been implemented.
Huh ?

Quote:
Image compression

All images are compressed losslessly and over a range of qualities for each codec:

BPG:
lossless: bpgenc -m 8 -f 420 -lossless -o [output] [input(PNG)]
between q=3 and q=45: bpgenc -m 8 -f 420 -q $q -o [output] [input(PNG)]

AV1:
lossless: aomenc --passes=2 --lossless=1 -o [output] [input(Y4M)]
between q=5 and q=63: aomenc --passes=2 --end-usage=q --cq-level=$q -o [output] [input(Y4M)]

Daala:
lossless: encoder_example -v 0 -o [output] [input(Y4M)]
between q=5 and q=85: encoder_example -v $q -o [output] [input(Y4M)]

FLIF:
lossless: flif -Q 100 [input(PNG)] [output]
between q=-329 and q=79, with a step of 12: flif -Q $q [input(PNG)] [output]

JPEG2000:
lossless: kdu_compress -no_info Creversible=yes -slope 0 -o [output] -i [input(PPM)]
between q=38912 and q=45056, with a step of 64: kdu_compress -no_info -slope $q -o [output] -i [input(PPM)]

JPEG XR:
lossless: JxrEncApp -d 1 -q 1 -o [output] -i [input(PPM)]
between q=5 and q=85: JxrEncApp -d 1 -q $q -o [output] -i [input(PPM)]

MozJPEG:
lossless: cjpeg -rgb -quality 100 [input(PNG)] > [output]
between q=5 and q=95: cjpeg -quality $q [input(PNG)] > [output]

WebP:
lossless: cwebp -mt -z 9 -lossless -o [output] [input(PNG)]
between q=5 and q=95: cwebp -mt -q $q -o [output] [input(PNG)]
Indeed if the default ist good it would be not the highest preset as bpg uses i wonder why clare decided this
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 7th November 2016 at 20:12.
CruNcher is offline   Reply With Quote
Old 12th November 2016, 12:49   #102  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
The Netflix encoding department had a meet-up where they discussed VP9 vs. H.265 vs. H.264. The Alliance for Open Media was also there and gave a presentation on AV1, where they said they are aiming for a 50% increase in efficiency over VP9/H.265 with AV1. They also said that AV1 in it's current state already beats VP9 by 25-30% (with not yet released Google internal tools). They said that in order to achieve the 50% increase in efficiency over VP9, they are willing to accept a 40% increase in decoding complexity and a 5 to 10 times higher encoding complexity than VP9, see:

https://youtu.be/thvSyJN1vsA

jq963152 is offline   Reply With Quote
Old 13th November 2016, 19:43   #103  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 508
Quote:
Originally Posted by jq963152 View Post
They said that in order to achieve the 50% increase in efficiency over VP9, they are willing to accept a 40% increase in decoding complexity and a 5 to 10 times higher encoding complexity than VP9, see:
You can see increase in efficiency over the codec VP9. Certainly is an interesting alternative to HEVC codecs. In AV1 is less undulation pixels at low bitrate and better views gray. It can develop. Currently, they have time to improve the decoder LAV 10bit. Does not recognize the files AV1. And most important adding new implementations to encoding speed.
https://www.sendspace.com/filegroup/...FiztpTDNDeyMc9

Last edited by Jamaika; 13th November 2016 at 19:46.
Jamaika is offline   Reply With Quote
Old 16th November 2016, 16:22   #104  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 152
Quote:
Originally Posted by jq963152 View Post
The Alliance for Open Media was also there and gave a presentation on AV1, where they said they are aiming for a 50% increase in efficiency over VP9/H.265 with AV1. They also said that AV1 in it's current state already beats VP9 by 25-30% (with not yet released Google internal tools). They said that in order to achieve the 50% increase in efficiency over VP9, they are willing to accept a 40% increase in decoding complexity and a 5 to 10 times higher encoding complexity than VP9, see:

https://youtu.be/thvSyJN1vsA

They also target a release in the first half of 2017 for AV1.

The results on low bitrate VP9 from Netlfix were very interesting. Shows the power of automated testing of quality. Interesting to see what comes of that work. And good that they're offering to do the same with AV1 as part of the development process.
dapperdan is offline   Reply With Quote
Old 17th November 2016, 00:22   #105  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
Quote:
Originally Posted by dapperdan View Post
The results on low bitrate VP9 from Netlfix were very interesting.
The other videos in their channel are also very interesting, like the following one for example, where they actually explain how they are encoding videos at Netflix:

https://youtu.be/fsRLHHIoC6E

jq963152 is offline   Reply With Quote
Old 20th November 2016, 15:50   #106  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
Is any member of the Alliance for Open Media reading this thread?

If yes, then please do the following for AV1:

1. Drop support for 4:2:0 and 4:2:2, i.e. please support 4:4:4 only
2. Drop support for 8-bit, i.e. please support 10-bit and higher only
3. Drop support for limited range (16-235), i.e. please support full range (0-255) only

If you don't do this, then we're probably going to be stuck with crappy chroma subsampling, 8-bit and limited range for a lot longer, which would be a disaster.

Last edited by jq963152; 20th November 2016 at 15:54.
jq963152 is offline   Reply With Quote
Old 20th November 2016, 16:17   #107  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,447
A codec is not the place to lobby for your politics in format choices. If someone can't compress the image they have, then they are going to use another codec.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 20th November 2016, 16:20   #108  |  Link
jq963152
Registered User
 
Join Date: Apr 2012
Posts: 691
Quote:
Originally Posted by nevcairiel View Post
A codec is not the place to lobby for your politics in format choices.
Where else would that be then?

Quote:
Originally Posted by nevcairiel View Post
If someone can't compress the image they have, then they are going to use another codec.
If you have a 4:2:0 limited range image, you can still encode it in 4:4:4 full range, so what exactly is your point?
jq963152 is offline   Reply With Quote
Old 20th November 2016, 16:28   #109  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,447
Quote:
Originally Posted by jq963152 View Post
Where else would that be then?
If they want to use such formats, the codecs exist that can handle all of it. So convince the content providers, its a political debate, not a technical one, and you can't force it on a technical level.

If there is enough demand, then hardware implementations of AV1 will also adopt support for higher chroma. Everything is a matter of demand. If content exists, hardware will come (or content is at least widely planned to roll out).

Quote:
Originally Posted by jq963152 View Post
If you have a 4:2:0 limited range image, you can still encode it in 4:4:4 full range, so what exactly is your point?
That just wastes space and/or degrades quality. An image should be compressed as close to the raw material one has - and if thats 4:2:0 or 4:2:2, which a lot of content is, then don't artifically upscale chroma, just because someone is on a crusade. Cheap upscaling is almost as bad as downscaling in the first place.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 20th November 2016, 17:07   #110  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,080
Quote:
Originally Posted by jq963152 View Post
3. Drop support for limited range (16-235), i.e. please support full range (0-255) only
RGB -> full range YCbCr conversation will result in overshooting so it is no real option.
huhn is offline   Reply With Quote
Old 20th November 2016, 17:43   #111  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 802
Quote:
Originally Posted by huhn View Post
RGB -> full range YCbCr conversation will result in overshooting so it is no real option.
What do you mean?
mzso is offline   Reply With Quote
Old 20th November 2016, 17:56   #112  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,080
"you can get to big numbers."

which is not possible with limited range.

edit:
Quote:
When performing YCbCr to R ́G ́B ́ con-
version, the resulting R ́G ́B ́ values have a
nominal range of 16–235, with possible occa-
sional excursions into the 0–15 and 236–255
values. This is due to Y and CbCr occasionally
going outside the 16–235 and 16–240 ranges,
respectively, due to video processing and
noise.
http://www.compression.ru/download/a...space/ch03.pdf

full range YCgCo should be fine https://en.wikipedia.org/wiki/YCgCo

Last edited by huhn; 20th November 2016 at 18:01.
huhn is offline   Reply With Quote
Old 20th November 2016, 19:00   #113  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 802
Quote:
Originally Posted by huhn View Post
"you can get to big numbers."

which is not possible with limited range.

edit:

http://www.compression.ru/download/a...space/ch03.pdf

full range YCgCo should be fine https://en.wikipedia.org/wiki/YCgCo
So basically the gist of it is that a flawed algorithms, from flawed sources produce inferior results. Those outside values are technically invalid, so I don't see why they'd be relevant.

Last edited by mzso; 20th November 2016 at 19:05.
mzso is offline   Reply With Quote
Old 21st November 2016, 01:46   #114  |  Link
Nintendo Maniac 64
Registered User
 
Nintendo Maniac 64's Avatar
 
Join Date: Nov 2009
Location: Northeast Ohio
Posts: 353
Is native YUV support really all that beneficial when using 10bit?
Nintendo Maniac 64 is offline   Reply With Quote
Old 21st November 2016, 08:23   #115  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,080
you need to compress the chroma channel more than the luma for proper picture quality bit deep has nothing to do with that.
huhn is offline   Reply With Quote
Old 21st November 2016, 10:38   #116  |  Link
GTPVHD
Registered User
 
Join Date: Mar 2008
Posts: 237
http://aomedia.org/about-us/

http://www.bbc.co.uk/rd/blog/2016/10...eo-compression

More and more companies join the Alliance for Open Media.
GTPVHD is offline   Reply With Quote
Old 21st November 2016, 11:52   #117  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,447
Quote:
Originally Posted by Nintendo Maniac 64 View Post
Is native YUV support really all that beneficial when using 10bit?
You'll always need to split RGB into another scheme for efficient encoding, because RGB has a lot of redundant information. So splitting it into Luma+Chroma makes encoding much more efficient.
On top of that this allows you to compress chroma more then luma, which plays into the nature of our eyes. With pure RGB you couldn't do that - the best you could do is compress one color channel more then the others, but thats not even close to as efficient.

YCbCr (or YUV in other terms) is what we have to do that. Some other approaches have been brought forward, like YCgCo, but they have not been adopted widely because many existing processing pipelines just know how to work with YCbCr, and the advantages of those suggested alternatives were not that great.

If someone can define a groundbreaking new scheme to split Luma and Chroma in a more efficient way (say a significant difference), reducing even more redundant information while being able to (visually) losslessly re-create the original image, I'm sure there would be industry interest eventually. But so far all the needs we had to modify YCbCr could be done with different transfer matrices to increase the colorspace.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 21st November 2016, 13:01   #118  |  Link
mzso
Registered User
 
Join Date: Oct 2009
Posts: 802
Quote:
Originally Posted by GTPVHD View Post
http://aomedia.org/about-us/

http://www.bbc.co.uk/rd/blog/2016/10...eo-compression

More and more companies join the Alliance for Open Media.
BBC is a good addition. They did research and released papers on what framerate requirements (with what "shutter time" ) are necessary for "perfect" motion representation...
So their input for HFR might be really useful.
mzso is offline   Reply With Quote
Old 21st November 2016, 14:27   #119  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,949
Not only that think about Dirac VC2 Open Broadcast

And they're still standing a lot more on the doorstep waiting to get in
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 21st November 2016 at 14:53.
CruNcher is offline   Reply With Quote
Old 21st November 2016, 21:25   #120  |  Link
Motenai Yoda
Registered User
 
Motenai Yoda's Avatar
 
Join Date: Jan 2010
Posts: 688
Quote:
Originally Posted by mzso View Post
BBC is a good addition. They did research and released papers on what framerate requirements (with what "shutter time" ) are necessary for "perfect" motion representation...
So their input for HFR might be really useful.
NHK did it too and found 120fps (over 100) and 240Hz shutter time to be the right values
http://informationdisplay.org/IDArch...asNextGen.aspx
__________________
powered by Google Translator

Last edited by Motenai Yoda; 21st November 2016 at 21:33.
Motenai Yoda is offline   Reply With Quote
Reply

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 02:23.


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