Vp9 typical use case - 2Pass vs 1Pass vs RT : Youtube vs Hangout

[Anil]

Hi,

I saw a post on doom9 which mentioned that YouTube. Is this info correct?

"Dailymotion uses 6000 kbit for 1080p. Youtube 4000 kbit (at 30fps - but only if the video complexity is enough. A tutorial video for example will never get 4000. My NFS 1 videos often only get half of the bitrate)

Dailymotion though uses always 6000 kbit. And they even encode 2pass ! with x264 preset slow !!"

What is the typical use case planned for Vp9 codec?

1. Will Youtube use 2pass Vp9 encoding or 1Pass?
2. Hangout most likely will use 1Pass with --rt enabled for Real Time encoding. 
3. Quality/Speed varies a lot with the cpu-used parameter (eg. cpu-used=3 vs cpu-used=7). What is the setting usually used for  encoding for Hangout?

Thanks

Anil

[Colleen Kelly Henry]

Honestly it doesn't look wrong but its confusing...

Are we talking etc or live linear or VOD?

1 pass vs 2 pass doesn't mean good or bad. CRF is a great one pass rate control for x264 and 1 or 2 pass constrained quality is great for vp9 :)

YouTube uses 264 and vp9 so just saying bitrate isn't enough...

--
You received this message because you are subscribed to the Google Groups "Codec Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to codec-devel...@webmproject.org.
To post to this group, send email to codec...@webmproject.org.
Visit this group at http://groups.google.com/a/webmproject.org/group/codec-devel/.
For more options, visit https://groups.google.com/a/webmproject.org/d/optout.

[Anil]

I was trying to figure out which mode is Google Devs/YouTube targeting to make Vp9 popular for user base.

My understanding is that the main users will be 

1) Youtube (best quality. So 2pass or 1pass)

2) Google Hangout (Real Time)

Bitrate/Quality comparison is a completely different topic. 

Before getting into that I wanted to know which modes YouTube/Hangouts will be using

I am hoping, once the results are good, the google devs will have some results here https://github.com/google/compare-codecs

Thanks

Anil

[Renganathan Ramamoorthy]

Hello Anil, 

What is the typical use case planned for Vp9 codec?

​VP9 is a general purpose codec. We support both VOD (YouTube, vimeo, daily motion etc) and live encodes (RTC case)

Will Youtube use 2pass Vp9 encoding or 1Pass?

YouTube does use a 2-pass encode of VP9 as they are not constrained by real time encode and it allows for better quality VP9. 

 

Hangout most likely will use 1Pass with --rt enabled for Real Time encoding. 
Quality/Speed varies a lot with the cpu-used parameter (eg. cpu-used=3 vs cpu-used=7). What is the setting usually used for  encoding for Hangout?

You should try 5,6 and 7 for real time communication usecase. If you share your encoder settings, people might be able to recommend improvements. 

Thanks. 

​

 

-- Pangu

[Anil Sunil]

Hi Renganathan,

doom9 thread that mentioned about Youtube using Vp9 as 1pass is here

https://www.doom9.org/showthread.php?p=1708026

I found this strange, since I thought YouTube would be using 2pass for compressing videos for storage in YouTube servers without any time constraint. Thanks for confirming that YouTube is using 2Pass and not 1Pass.

For Real Time testing, I used command line similar to one that I got from the developers in this forum.

Currently only cpu-used =7/8 are close to 720p@30fps real time. However the quality of Vp9 with cpu-used=7 is not much better than real time Vp8 case.

command line used:

../build/vpxenc --codec=vp9 --i420 --psnr --kf-min-dist=32 --kf-max-dist=32 -w 1280 -h 720 --fps=30000/1000 --limit=300  --target-bitrate=4000 --disable-warning-prompt -p 1 --cpu-used=-7 --rt --tile-columns=2 -t 4 -o bs/Johnny_1280x720_30_rc4000.ivf ../../yuv/Johnny_1280x720_30.yuv

[Anil]

Also,

What value of cpu-used does YouTube use for compressing videos?

Or what is the recommended value of cpu-used for offline compression?

Thanks

Anil

[Colleen Kelly Henry]

Unless you are youtube, or netflix, or facebook, or vimeo, or someone like that I suspect your encoding should be designed around different constraints. 

If I were YouTube (still) I'd use cpu-used 0 and "best" mode for their very tippy top end content to save whatever bits I could, and then 1 or 2 for the rest of their top...ish content... and h.264 for the long tail that nobody watches. 

... but I'm not YouTube. Anymore. 

;)