Does YouTube still use x264?

[Chengbin]

Does YouTube still use x264? I don't see any reference to this besides Dark Shikari's 5 year old blog post.

If they are, what settings do they use?

[Dark Eiri]

Yes it does.

Seems to be using fast preset / High@4.0 with 2 ref frames, ~3800kbps for 1080p content (seems to spike to 5 Mbps in some cases, though) and medium preset / Main@3.1 with 3 ref frames, ~1000kbps for 480p.

Combined with what I believe is FAAC LC 128 kbps for < 720p and 192 kbps for >= 720p.

[Stereodude]

Combined with what I believe is FAAC LC 128 kbps for < 720p and 192 kbps for >= 720p.I don't think that's correct. The DASH streams I've seen report 128kbit AAC for the separate audio stream that is used with the 1080p video stream. For your typical 1080p content this is what Youtube offers:
format code extension resolution note
171 webm audio only DASH webm audio , audio@ 48k (worst)
140 m4a audio only DASH audio , audio@128k
160 mp4 192p DASH video
133 mp4 240p DASH video
134 mp4 360p DASH video
135 mp4 480p DASH video
136 mp4 720p DASH video
137 mp4 1080p DASH video
17 3gp 176x144
36 3gp 320x240
5 flv 400x240
43 webm 640x360
18 mp4 640x360
22 mp4 1280x720 (best)

[EncodedMango]

I believe I read somewhere that they had started rolling out VP9 on Youtube.

[Dark Eiri]

I don't think that's correct. The DASH streams I've seen report 128kbit AAC for the separate audio stream that is used with the 1080p video stream. For your typical 1080p content this is what Youtube offers:
format code extension resolution note
171 webm audio only DASH webm audio , audio@ 48k (worst)
140 m4a audio only DASH audio , audio@128k
160 mp4 192p DASH video
133 mp4 240p DASH video
134 mp4 360p DASH video
135 mp4 480p DASH video
136 mp4 720p DASH video
137 mp4 1080p DASH video
17 3gp 176x144
36 3gp 320x240
5 flv 400x240
43 webm 640x360
18 mp4 640x360
22 mp4 1280x720 (best)

I have several youtube ripped videos, 720 and 1080p, coupled with AAC audio @ 160~192 kbps. But yeah, for DASH they are using only 128kbps.
I truly miss the WebM + OGG 1080p versions.

[Stereodude]

But yeah, for DASH they are using only 128kbps.Isn't DASH all they offer for 1080p and above now?

[Dark Eiri]

Isn't DASH all they offer for 1080p and above now?

Yes. 720p is not DASH (yet), so I guess it still keeps the higher bitrate audio? I'll check it when I'm home.

It's truly saddening that the 192 kbps OGG audio from the WebM versions isn't available anymore... I truly do not care for 4K video (specially music videos) if it has crappy sounding audio.

[osgZach]

All I know is I hate YouTube more and more with every passing day.

On top of the poor support outside of 30fps/ 4:2:0, and the draconian content/DRM management system, and the completely backwards "new" comment system

They break 1080p on all browsers but Chrome. I still cannot see 1080p for my new uploads IN 1080p, because they want me to use Chrome which conveniently supports media extensions, blah blah blah :rolleyes:

[Stereodude]

On top of the poor support outside of 30fps/ 4:2:0, and the draconian content/DRM management system, and the completely backwards "new" comment system

They break 1080p on all browsers but Chrome. I still cannot see 1080p for my new uploads IN 1080p, because they want me to use Chrome which conveniently supports media extensions, blah blah blah :rolleyes:I've found a fair number of videos that aren't 30fps though I haven't a clue how specifically they were uploaded. Also, 1080p playback works fine for me in Firefox.

[ProVision]

What's DASH? (Sorry for not being helpful :/)

Wait, I can view 1080p videos on Firefox. osgZach, which browser do you use?

[Video Dude]

What's DASH? (Sorry for not being helpful :/)


Dynamic Adaptive Streaming over HTTP (http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP)



So with DASH, YouTube uses lower quality / lower bitrate audio. Is the video also lower quality?

[benwaggoner]

On top of the poor support outside of 30fps/ 4:2:0
The 4:2:0 limitation is very common in all sorts of HW decoders, and very, very little content is really helped by >4:2:0, particularly at HD resolutions.

They break 1080p on all browsers but Chrome. I still cannot see 1080p for my new uploads IN 1080p, because they want me to use Chrome which conveniently supports media extensions, blah blah blah :rolleyes:
1080p in YouTube certainly works well for me in IE11 (both Win7 and Win8.1). It was working fine in IE10 too. Both machines have 2560x1600 monitors, and I wouldn't be surprised if there was some behavior relating to screen/window size limiting 1080p if it thinks you're not going to see all the pixels.

[osgZach]

Interlace is an ancient standard too but there is no shortage of people here who berate it (and with good reason). Just because you CAN get away with using old standards doesn't mean you should when better ones exist. For those of us dealing with RGB footage however, poor chroma resolution is a tireless PITA. I have ways I personally work around it to restore some of the color but that's kind of beside the point. Nothing ever moves forward if people don't adopt it, and higher color spaces have their uses.

Youtube still serves 1080p in flash. But if you're using the HTML5 player, I have yet to see 1080p work in Firefox, Seamonkey, IE, etc. Also there are older encodes that are still available in HTML5/1080p because of their age I believe. But the flash player performs like junk IMHO and I stopped using it a long time ago. There is even a bug that will not show you 1080p streams of your own files, if you are logged in to your account.

YouTube is pretty broken in my book.

[Procrastinating]

The 4:2:0 limitation is very common in all sorts of HW decoders, and very, very little content is really helped by >4:2:0, particularly at HD resolutions.


Nowadays, doesn't it make more sense to use 4:4:4 and let x264 quantize the colour? Not matter how high bitrate, 4:2:0 content always looks slightly fuzzy for me.

VP9 has been enabled for some specific youtube footage, but I haven't yet found examples of user-uploaded vp9 footage?

[Blue_MiSfit]

You folks dealing with RGB footage are definitely in the minority. If you look at it from YouTube's perspective, there's not much point in changing their whole playback chain so a very small percentage of users get a feature only they will likely appreciate.

Things will be better with H.265, hopefully :)

[benwaggoner]

Nowadays, doesn't it make more sense to use 4:4:4 and let x264 quantize the colour? Not matter how high bitrate, 4:2:0 content always looks slightly fuzzy for me.
It would if most mainstream decoders supported it, but they don't, so there we are. Hopefully we'll see higher-precision come with the HEVC wave. I'm at least hoping to see the 10-bit Main 10 profile become standard.

[mandarinka]

Does anybody have some information regarding what profile will those mobile SoC with announced HEVC decoders have support for?

For example Snapdragon 805, Mediatek MT6595 is reported to ahve 4K decoding support too I think... It would be almost too nice if they did Main 10, of course.

[Monarc]

Things will be better with H.265, hopefully :)

With youtube?

If they make their own codec (vp9), why should they use H.265?


greetings

[Asmodian]

Because a lot of devices are getting hardware H.265 decoding but I haven't heard of anything getting hardware VP9 decoding. That said I bet these SoCs will not have 4:4:4 support. :(

[LoRd_MuldeR]

AFAIK, only the "Main" and "Main 10" Profiles of H.265/HEVC have been officially released so far. And those are limited 4:2:0/8-Bit and 4:2:0/10-Bit.

So I guess "Main" is what we are gonna see in consumer devices...

[nevcairiel]

Due to Main10 being part of the initial specification (unlike H.264), there is hope that they will feel compelled to support this as well.

[sneaker_ger]

Haven't seen mobile SoCs descriptions but e.g. the 2014 LG 4k TVs will/do already support 10 Bit decoding. Since UHDTV standards will likely include at least 10 Bit I guess chances of seeing it in mobile solutions in the future as well aren't that slim, though maybe not for the very first devices.

[Xdar]

Sorry for gravebump but I just have to get an input about this.
YouTube really is confusing me.
I did multiple render test and uploaded the Videos on YouTube.
My workflow usually is: uncompressed .avi (720p)->editing->uncompressed .avi (UT video codec)->x264 with RipBot

Now while the file looks excelent on my PC, YouTube totally destroys the quality and lots of macro blocks come up, especially in 360p. The 360p quality is very important to me, since lots of people watch in 360p and don't even bother with 720p or 480p.

So after I tried many things like the ultra slow and fast preset, deblocking with -6:-6, -4:-3, -2:-1, 0:0, 3:2, 6:6, maxi everything out, Bitrate from 5000-50'000, the quality didn't change at all and I was still unpleased with the 360p verison.

So I tried to encode with different codecs and I actually got better results with .wmv and xvid (same bitrate as with x264).
Especially with wmv, when the video is static it gets ultra sharp, even on 360p. However, it still isn't what I was other channels seem to achive with ease.

Next thing I'm going to try is webM/VP9

[detmek]

Filter your video to remove noise, grain and/or fine details. All of those require higher bitrate but YT has upper bitrate limit for different resolutions.
You got better results with Xvid because Xvid does not preserve noise, grain and fine details, which acts like denoise filter.

[Monarc]

try filter or x265.

someone (german doom9 -> link (http://forum.gleitz.info/showthread.php?46202-Youtube-Videos-bitte-mal-ne-Meinung-abgeben&p=435787&viewfull=1#post435787)) use this:


LoadPlugin("c:\Program Files\AviSynth\plugins.manual\FFT3DGPU.dll")

AVIsource("d:\Storage\Work\Dxtory\TESV 2013-03-13 22-33-44-888.avi")

# Correct brightness of YV12-Dxtory captures
Levels(0, 1.2, 230, 0, 255)

# Because the forced YouTube re-encode uses a lower bitrate than needed for a high detail capture (above 720p),
# many details will be lost and converted to blurring artefacts in the final video.
# To keep a reasonable amount of detail, we limit them to the maximum wich could be re-encoded (by YT) without
# producing artefacts in scences with high complexity.
(last.height > 720) ? Lanczos4Resize(1280,720) : last

# Temporal stabilization (prevents bitrate comsumption from flickering structures)
FFT3DGPU(sigma=1.5, bt=4, bw=32, bh=32, ow=16, oh=16)

# Upscaling (forces YT to re-encode with higher bitrates)
# Beside storing an (nearly) Original version on YT, this forces their re-encode to downscale our upload.
# It ends up in videos wich are well-balanced in detail-level and smoothing.
Lanczos4Resize(2048,1152)

# Over-Sharpen: maintaining details/DOF
Sharpen(1.0)


i don't know, how good it works.
his demo: http://www.youtube.com/watch?v=zdwet-UNEEU

[Xdar]

Thanks for the input guys!

try filter or x265.

someone (german doom9 -> link (http://forum.gleitz.info/showthread.php?46202-Youtube-Videos-bitte-mal-ne-Meinung-abgeben&p=435787&viewfull=1#post435787)) use this:

UNEEU"]http://www.youtube.com/watch?v=zdwet-UNEEU[/URL]

Looks great on the YT video. I will try it out (I actually speak German).

Edit: Is there also a way to prevent grain when recording? Like what would help more, recording with much or few screen gamma?

[detmek]

Better try to deal with grain after recording. You can experiment with different filters until you find good one. If you try to do this during recording you may damage video and ged suboptimal result.
Beside fft3dfilter and fft3dgpu you can use fluxsmooth, removegrain, mvtools2 or some more complex scripts like QTGMC or SMDegrain. Fluxsmooth is fast and good light denoiser.

[nm]

If the source video is actually noisy, motion compensated filters such as MDegrain2 (in MVTools2, can be used through SMDegrain) really help with getting highly detailed but compressible video. If the source is clean, such as video game footage, these filters are probably useless.

Spatial noise reduction filters can be used to decimate fine texture so that less bits are needed in those areas and the overall quality might turn out better at low bitrates. Usually I'd let the encoder and its psy opts deal with this, but I don't know how Youtube has things set up. It's worth a try.

[Xdar]

I tried some filters that got listed but honestly I can't see an improvement on YouTube. Of course I have no prove, but I think YouTube handles some codecs better at 360p than others. As you guessed right, my video footage is gameplay, so there isn't any grain or noise at all. Maybe my videos have too much detail, but then, here and there I see videos with many details and they still have good and sharp quality (360p while max resolution is 720p).

It's really frustrating, can't see why Google won't make a simple template/preset which people can use to encode their videos and get them uploaded without recompression.

[benwaggoner]

One cheap way to get some temporal noise reduction is to use the x264 --nr parameter. It only removes noise from predicted blocks, so it tends to keep the grain texture from IDR frames, but leaves the grain locations the same throughout the GOP. It can definitely improve compressibility. While not as good as the external filters, it's way faster and wouldn't require any workflow changes.

[Bloax]

# Because the forced YouTube re-encode uses a lower bitrate than needed for a high detail capture (above 720p),
# many details will be lost and converted to blurring artefacts in the final video.
(last.height > 720) ? Lanczos4Resize(1280,720) : last

# Upscaling (forces YT to re-encode with higher bitrates)
# Beside storing an (nearly) Original version on YT, this forces their re-encode to downscale our upload.
# It ends up in videos wich are well-balanced in detail-level and smoothing.
Lanczos4Resize(2048,1152)

This seems like a strange combo, since it always resizes the video to 1280x720 only to scale it back up again.
And then it promptly applies Sharpen(1) to it to exaggerate the down-upscaled details.. Instead of the original ones?

Certainly it makes it possible to use non-antialiased 1080p(+) video, but it seems strange to otherwise discard details if you're going back to above the original resolution in the end - instead of say, smoothing the original details in an attempt to make Youtube not turn them to garbage and then upscale it.