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 18th July 2019, 08:20   #1161  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,901
New upload (MSYS2; MinGW32 / MinGW64: GCC 9.1.0):

VPx v1.8.1-34-g53dc2d9d9
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 21st August 2019, 06:58   #1162  |  Link
utack
Registered User
 
Join Date: Apr 2018
Posts: 39
Is there a way to get libvpx not to "crush" flat or dark parts of the image so much? It is one of the major weak points it still has that can ruin certain parts of a stream and that x264 solved ages ago.
Both tune-content=film and aq-mode=1/2 do not seem to suffice to control this behaviour.
Is there another method like limited the quantizer range or such?
Thank you
utack is offline   Reply With Quote
Old 21st August 2019, 08:31   #1163  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,901
Apart from raising the bitrate? ... Reducing "noise" is one of the most important ways to encode efficiently; maybe you can change the amount with the VP9 specific parameter
Code:
            --noise-sensitivity=<arg>  	Noise sensitivity (frames to blur)
but its default is already 0, so this may make it only worse...

Or it might be possible to move bitrate distribution away from usually preferred frames (keyframes, "golden frames"), which may hurt the quality in other scenes.

Unfortunately, not all encoders offer control over the same kind of algorithms. They may not even contain the same set of algorithms. If VPx has no exposed parameters to control rate distribution in relation to specific content dynamics, "enough bitrate" (or a forced limit for the maximum quantization) may be your only hope.
__________________

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

Last edited by LigH; 21st August 2019 at 08:34.
LigH is offline   Reply With Quote
Old 22nd August 2019, 18:44   #1164  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,928
Quote:
Originally Posted by utack View Post
Is there a way to get libvpx not to "crush" flat or dark parts of the image so much? It is one of the major weak points it still has that can ruin certain parts of a stream and that x264 solved ages ago.
Both tune-content=film and aq-mode=1/2 do not seem to suffice to control this behaviour.
Is there another method like limited the quantizer range or such?
Thank you
This is where adaptive quantization algorithms shine, and where PNSR-tuned encoders can fall flat.

I've yet to see a VPx series encoder that had a good adaptive quant algorithm. I don't know that this is a limitation of the bitstream itself; it's more likely just a reflection of the psychovisual maturity of the encoders.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 23rd August 2019, 20:09   #1165  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 732
I recall there being an actual limitation in the bitstream. The AQ has to be done via segmentation maps where you pick quants you can use and then you can assign one of those to blocks through assigning them to one or another segment. Roughly speaking. I recall that it was believed to be a hinder to AQ being useful.
mandarinka is offline   Reply With Quote
Old 23rd August 2019, 22:50   #1166  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,928
Quote:
Originally Posted by mandarinka View Post
I recall there being an actual limitation in the bitstream. The AQ has to be done via segmentation maps where you pick quants you can use and then you can assign one of those to blocks through assigning them to one or another segment. Roughly speaking. I recall that it was believed to be a hinder to AQ being useful.
Oh, yeah. That would require weird loops where you'd encode the frame once, figure out the segments, and then reencode again. MPEG-4 part 2 had a similar issue in its adaptive quant which also was a huge hassle to tune.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 25th August 2019, 19:49   #1167  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,308
Quote:
Originally Posted by utack View Post
Is there a way to get libvpx not to "crush" flat or dark parts of the image so much? It is one of the major weak points it still has that can ruin certain parts of a stream and that x264 solved ages ago.
Both tune-content=film and aq-mode=1/2 do not seem to suffice to control this behaviour.
Is there another method like limited the quantizer range or such?
Thank you
If 10 bits is an option that would fix a major part of described issue.
IgorC is offline   Reply With Quote
Old 26th August 2019, 16:00   #1168  |  Link
Beelzebubu
Registered User
 
Join Date: Feb 2003
Location: New York, NY (USA)
Posts: 55
Quote:
Originally Posted by benwaggoner View Post
Oh, yeah. That would require weird loops where you'd encode the frame once, figure out the segments, and then reencode again.
Why? For example, x264 heuristically assigns quant deltas before the frame encode. To fit this in a segment-ID design, all you need is a clustering algorithm (see e.g. webp).
Beelzebubu is offline   Reply With Quote
Old 26th August 2019, 20:52   #1169  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,518
Super interesting stuff. I totally agree that these types of issues are what disqualify VP9 for my use cases. It's better than AVC at low bitrates for sure, but when we go for high quality / transparency as required for premium OTT delivery of Hollywood content it's a bit lacking in exactly this way.

It's useful for UHD, but there we usually can use HEVC which just ends up looking better.

If we had good AQ I could totally see VP9 being incredibly useful, especially in cases where HEVC is off the table!

Last edited by Blue_MiSfit; 26th August 2019 at 20:55.
Blue_MiSfit is offline   Reply With Quote
Old 27th August 2019, 20:57   #1170  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,928
Quote:
Originally Posted by Beelzebubu View Post
Why? For example, x264 heuristically assigns quant deltas before the frame encode. To fit this in a segment-ID design, all you need is a clustering algorithm (see e.g. webp).
Oh, it would be possible, just a lot more finicky to do so optimally. x264 devs figured out how to do adaptive quant in xvid eventually, although it was slower and less optimal than in x264.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 10th September 2019, 09:15   #1171  |  Link
Spyros
Registered User
 
Join Date: Jun 2019
Posts: 2
SVT-VP9 performance boost on AVX2

Phoronix - Intel's Open-Source VP9 Video Encoder Just Scored A Massive ~3x Performance Boost

Quote:
SVT-VP9 is now a lot faster on AVX2 CPUs from both Intel and AMD.

[...]

The i7-7740X went from 30 FPS to 120 FPS, the E5-1680 v3 from 38 to 113 FPS, and the E5-2687W v3 from 46 to 150 FPS. Damn!
Spyros is offline   Reply With Quote
Old 10th September 2019, 17:32   #1172  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 2,928
Impressive, but not fundamentally surprising. Libvpx never received the sort of sustained high-touch optimization or tuning that the x24? series of encoders got. A really good encoder matters more than a bitstream with really good potential without encoders well tuned to use that potential.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 15th September 2019, 09:21   #1173  |  Link
dapperdan
Registered User
 
Join Date: Aug 2009
Posts: 180
That particular speed up isn't impressive, nor does it say much about libvpx.

Effectively they forgot to flick a switch to send the fast code to all platforms that could use it. Then they noticed and fixed it. The headline could just as easily been "vp9-svt pointlessly 3x slower on some platforms until now".

That all said, I'm intrigued to see how the SVT family of encoders turns out. They seem to be throwing a fair bit of engineering at it, though initially it seemed the VP9 team were redirected to work on the AV1 encoder, so good to see some work on it again, even if it's just basic stuff like that. Part of the SVT idea is that optimisations can be shared between codec families I believe, so VP9 should be benefitting even when not the focus.

Their effective use of all a available cores seems like their secret weapon. In many real world situations that might give them an edge that other encoders would have to work hard to match if coming from the libvpx codebase.
dapperdan is offline   Reply With Quote
Reply

Tags
google, ngov, vp8, vp9, vpx, webm

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 20:15.


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