View Full Version : x264 settings to get Higher Quality videos on YouTube
StreamRipper
16th December 2008, 20:11
I've been trying to get Higher Quality videos on youtube.
Of course most people are not smart enough to use &fmt=22 or other variable in the URL (see the following forum thread to learn the details http://stream-recorder.com/forum/watch-older-youtube-videos-higher-quality-youtube-t3086.html)
I've used x264vfw (Build date Nov 25, 2008). The problem is that we do screen capture using Camtasia and other software to produce video tutorials. Here they are
http://www.youtube.com/user/appliantechnologies
The picture is not very dynamic, so the bit-rate is pretty low. And YouTube requires a bit-rate of 800 kbps and higher.
I've started using Single Pass encoding Ratefactor based with Ratefactor=1. I've also changed Min QP, Max QP and Max QP step equal to 1 and disabled CABAC.
Adaptive DCT is turned off, because otherwise YouTube videos have pretty weird artifacts.
I use 640x480 videos as recommended.
After using these setting I've managed to increase bit-rate to about 800. But I still can't get it high enough for some videos.
I'm not very good at these I,P,B frames, CABAC, Trellis and other things. Could you please suggest me the best settings to get the bit-rate of 800+ kbps for the video tutorials? Thank you very much in advance!
Dark Shikari
16th December 2008, 20:43
I'm pretty sure at this point in time that there's no way to bypass Youtube's re-encoding process. If you want to be able to upload without your videos being re-encoded, you can either host it yourself like I do (http://mirror05.x264.nl/Dark/Flash/saextra.html) or use one of the sites that allows it (example: Zoome).
cogman
16th December 2008, 22:26
Dark, I thought I read somewhere that if you have the right settings youtube won't re-encode (they are craptastic settings).
All in all, though, I agree. Probably the best way to get the highest quality from youtubes encoder is to send them a denoised, raw (IE Lossless) video. After that, you pray to the gods that your video is easily encoded by their encoder.
Dark Shikari
16th December 2008, 22:29
Dark, I thought I read somewhere that if you have the right settings youtube won't re-encode (they are craptastic settings).That was back with FLV1 (not H.264) and they patched that hole because of abuse, AFAIK.
StreamRipper
17th December 2008, 08:38
I don't mind to get the video re-encoded. The problem is that when you send a low bit-rate video even if it looks really amazing, the Higher quality option doesn't appear. So I just need the proper settings for x264 to increase bit-rate. Is there anything you can suggest about it?
nm
17th December 2008, 09:30
I don't mind to get the video re-encoded. The problem is that when you send a low bit-rate video even if it looks really amazing, the Higher quality option doesn't appear. So I just need the proper settings for x264 to increase bit-rate. Is there anything you can suggest about it?
Try some other codec (huffyuv, perhaps) and complain to Google/Youtube about the bitrate limit.
2Bdecided
17th December 2008, 11:58
Use ABR.
If that doesn't help, force more I-frames by reducing the keyframe interval. For static content, that will drive the bitrate up proportionally.
Cheers,
David.
StreamRipper
19th January 2009, 23:42
ABR didn't seem to help.
I didn't know how to force more I-frames, so I did the following changes in the settings:
Min GOP size=5
Max GOP size=25
Scenecut threshold=10
Adaptive DCT=off
CABAC=off
MinQP=1
MaxQP=1
MaxQP step=1
QP factor between I and P = 1.40
Aktan
20th January 2009, 00:51
I believe the higher quality option is based on your video resolution, not the bitrate
Help link: http://help.youtube.com/support/youtube/bin/answer.py?answer=91450&topic=16612
I also agree with Dark Shikari, that was FLV and the hole has been patched :mad:
imk
20th January 2009, 00:54
I find that uploading a ridiculously high quality source at 1080p will result in a better looking re-encoded video.
I did a test just yesterday. I uploaded two videos that were of a high quality source (http://imk.cx/videos/files/uploaded1080source.png).One was 720p and the other was 1080p.
These were the results:
720
http://imk.cx/videos/files/youtube720source.png
1080
http://imk.cx/videos/files/youtube1080source.png
Both versions look pretty terrible in their final rendition, but the one that came from a 1080p source retains more detail throughout the scene.
(The videos were resized to 854x479 because that's the resolution YouTube plays the video at when in the browser window and not full screen.)
Aktan
20th January 2009, 01:02
Also note, x264 lossless currently isn't supported since YouTube's decoder doesn't decode it correctly currently
Trahald
20th January 2009, 15:07
ive only ever gotten 2-pass encodes to display the 'watch in HD' link. i use a bitrate over 1k and set level to 5.0. these are videos with isolated motion as well.
Inventive Software
21st January 2009, 01:22
Re: lossless not supported by Youtube's decoder: (they haven't implemented the standard then :rolleyes:) Use a q value more than 0 (you can use decimal IIRC) and that means it won't be lossless.
Dark Shikari
21st January 2009, 01:27
Re: lossless not supported by Youtube's decoder: (they haven't implemented the standard then :rolleyes:) They use mencoder for encoding--they just haven't updated to a recent version.
zilog jones
26th April 2009, 02:04
I've been doing some testing with YouTube uploads recently and the whole system seems a mess. I'm trying to upload HQ non-SD videos, which are now 640x480 for 4:3 or 854x480 (not sure if right) for 16:9 (&fmt=35). I'm using the 1-pass CQ HQ x264 preset and MKV on MeGUI with pretty good results, giving around 3-4Mbit/s. However I've noticed some weird things:
- It will encode at other aspect ratios with a height of 480. I've gave it a 732x480 video and the result was 736x480 (guess it only likes mod 8 or mod 16), and 676x556 became 592x480.
- x264 lossless still doesn't work right :)
- I might be getting the same problem as imk was with his HD uploads - if I upload at somethingx480 the result looks quite bad, almost like vertical resolution has been halved (even though it's still 480). But if I upload at a higher resolution e.g. 768x576 (as my source is PAL anyway), the 640x480 output looks significantly better. I thought doing my own resizing (using lanczos4) would be better but I am clearly wrong! This poses an annoying problem with NTSC sourced material - anyone had better luck with 480 line uploads?
I have to say, the technical support at YouTube regarding encoding for uploading leaves a lot to be desired. The website mentions MKV support nowhere, and it says very little regarding how to achieve best results.
Aktan
26th April 2009, 14:40
- I might be getting the same problem as imk was with his HD uploads - if I upload at somethingx480 the result looks quite bad, almost like vertical resolution has been halved (even though it's still 480). But if I upload at a higher resolution e.g. 768x576 (as my source is PAL anyway), the 640x480 output looks significantly better. I thought doing my own resizing (using lanczos4) would be better but I am clearly wrong! This poses an annoying problem with NTSC sourced material - anyone had better luck with 480 line uploads?
Yep, I just encountered this. I recently uploaded a 720x480 clip with the 4:3 flag and found that the vertical resolution seemed to been halved even if the FLV is still at the 640x480 res. I see jags everywhere :mad:
zilog jones
26th April 2009, 17:30
My solutions to that so far are to either crop 8 pixels vertically (it will render at whatever x 472 fine) or just upscale to 720 - or maybe even double the resolution! :)
benwaggoner
26th April 2009, 20:19
I find that uploading a ridiculously high quality source at 1080p will result in a better looking re-encoded video.
I did a test just yesterday. I uploaded two videos that were of a high quality source. One was 720p and the other was 1080p.
I'd think that a great 720p and a great 1080p would come out looking pretty similar when scaled to 720p. If anything, coming in with a source they don't have to scale would eliminate the risk of them using a sub-optimal resolution.
I regret that YouTube has sent the whole UGC industry off in the wrong direction. On modern systems, we're generally more limited by upstream bandwidth than CPU speed. And pretty much by definition, you already can decode the file you're trying to upload on the machine you're uploading from.
Most users would have had a better experience if YouTube provided a lightweight local client transcoding software that could validate already compatible streams.
I wonder how much of their huge losses come from having to provision all the CPU power for server-side transcoding, including cooling, etcetera...
Yoshiyuki Blade
26th April 2009, 23:49
Yeah, it would be nice for us video junkies to use our own time/CPU power to encode our videos. The end results would be much more efficient because we will know exactly when our transcoding will finish.
Right now, if I wanted to upload some gameplay videos that i FRAPS'ed, I'll have to transcode it anyway because it would be a waste of time to upload gigabytes of data that'll be butchered to hell. So it ends up being Source -> medium bitrate video -> upload -> youtube encode butchering -> done. It'd be nice to have Source -> low bitrate, youtube compliant video -> upload -> done.
chaynik
29th April 2009, 12:58
I've had great luck uploading FFV1 (ffmpeg's implementation of huffyuv) to youtube. Unlike huffyuv, ffv1 supports the 4:2:0 colorspace (native to h264, mpeg4, mpeg2, etc) and has some adaptive routines to further shrink down the size while remaining lossless. Perfect intermediate IMO for youtube uploads.
Dark Shikari
29th April 2009, 13:05
I've had great luck uploading FFV1 (ffmpeg's implementation of huffyuv) to youtube.FFV1 has absolutely nothing to do with HuffYUV.Unlike huffyuv, ffv1 supports the 4:2:0 colorspace (native to h264, mpeg4, mpeg2, etc) and has some adaptive routines to further shrink down the size while remaining lossless. Perfect intermediate IMO for youtube uploads.Perhaps you meant FFVHUFF, not FFV1?
chaynik
29th April 2009, 13:28
Yes, that's what I meant. My mistake.
zilog jones
29th April 2009, 18:38
That is interesting that it accepts at least one lossless codec. Anyone tried FFV1 or any others? What about MJPEG?
Regarding the vertical resolution halving issue with 480 line HQ videos, this definatley occurs with HD 720p videos too :( This must have been what was happening to imk's videos. To get good results with my PAL videos for both HD and HQ I upscaled to 1536x1152 - obviously being VHS sources they look quite blurry in "HD" but in the standard YouTube window they're not too shabby and there's no serious blocking or anything.
I have noticed apparent dropped frames with some of my HD videos played in HQ mode - it looks like frames are being dropped when playing within the website or using MPC+ffdshow, but when playing in VLC they look fine. Reported framerate is still 25fps. Any ideas?
imk
29th April 2009, 20:03
Not related to quality entirely, but I found that if I upload a really high-quality MP4, YouTube will actually re-encode it with video and audio out of sync. The video will play choppy, too.
http://www.youtube.com/watch?v=hmuRCUJmDik&fmt=22
If I upload a MKV instead of a MP4, it seems to handle it fine.
zilog jones
29th April 2009, 20:40
Yes, MKV seems to be the most reliable containter - I've uploaded >20Mbit/s x264 video with no problems.
I've also noticed if you upload HD video with no audio, it will not play it back properly within the website - the loading circle keeps flickering in the centre throughout playback. If you download the video it will play fine though. I didn't try using AudioSwap to see if it is just the lack of an audio stream that causes this.
JohannesL
1st May 2009, 21:22
I use 720p x264 encoded H.264 with --crf 20 and pretty basic settings for all of my videos, and it turns out pretty good: http://www.youtube.com/watch?v=5dYl8-8PhnE&feature=channel_page&fmt=22
zilog jones
1st May 2009, 23:32
That video seems to suffer from the same issue I noticed when uploading 720p, i.e. it is vertically blurred. It's very noticeable if you download the video (using one of the many Firefox plugins for example) and watch it at full size. What resolution was it rendered at? I assume it's from an emulator. You should try uploading at something like 1280x960 and compare the difference.
JohannesL
16th May 2009, 14:22
In the beginning, only 1280x720 uploads would get HD on YouTube. SM64 is 1.429 letterboxed to 4:3, so for a while, I cropped out the borders, scaled to 1028x720 and pillarboxed to 1280x720. I recently found out any video with a height above 720 will get HD now, so I tried to crop out the borders and scale to 1280x896 and upload, and YouTube downscaled it to 1028x720. The quality is a bit better than my 1280x720 uploads.
10L23r
17th May 2009, 04:26
is it better to upload a 640*480 vid or a 480*360 vid for regular (not hd) viewing? what resize algorithm does the encoder use?
and, does anyone know how the hell youtube's entire encoding process works
Dark Shikari
17th May 2009, 04:46
and, does anyone know how the hell youtube's entire encoding process worksIt's just your standard mencoder chain.
chaynik
26th May 2009, 11:50
It's just your standard mencoder chain.
Why mencoder and not ffmpeg?
Trahald
26th May 2009, 13:21
I've also noticed if you upload HD video with no audio, it will not play it back properly within the website - the loading circle keeps flickering in the centre throughout playback. If you download the video it will play fine though. I didn't try using AudioSwap to see if it is just the lack of an audio stream that causes this.
Yeah... I post stuff with no audio and noticed that too. Never made the connection. I need to put a silent audio track in.
Dark Shikari
26th May 2009, 14:04
Why mencoder and not ffmpeg?Better for handling bizarre proprietary formats due to w32codecs, probably.
JohannesL
18th June 2009, 14:57
Using this Avisynth script on a 640x448 RGB video game source:
function nnedi22x(clip a) {return a.nnedi2(1,true).turnright().nnedi2(1,true).turnleft().spline36resize(a.width*2,a.height*2,-0.5,-0.5)}
avisource("Direct64.avi")
lumvid = ConvertToYV12().NNEDI22x()
chromvid = PointResize(Width()*2,Height()*2).ConvertToYV12()
MergeChroma(lumvid,chromvid)
LimitedSharpenFaster()
(Results in 1280x896 YV12)
And then encoding with x264 at CRF 21 and uploading, I got this quality:
http://www.youtube.com/watch?v=Uazn8oNRYVg&fmt=22
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.