x264vwf filesize (H264 rendering KBPS and filesize insane)

[Joris Ceoen]

Hello everyone, first time on this forum for me...

So I've been dabbling with tons of codecs for video rendering (I'm using Sony Vegas) for videos on YouTube, and it seems that a video I watched recently suggests there is a H264 codec that 'bypasses' YouTube's re-encoding system, because it already uses that by standard (AVI container).

This codec at first seems great... however, when using the exact same settings as the person in the video, I end up with insane filesizes... 1.26 GB for a 13 seconds video!
Not only that, but the raw footage I recorded with DXTory is around 1623625kpbs... while the rendered result is DOUBLE that size (see attachement #1). There are no options in the x264vwf interface to like... lower this or make it equal to the original file. The only good thing is that yes, the quality is about the same as the raw one (with almost no pixel bleeding or artefacts).

Lastly, when I finally upload the video to YouTube, the quality is just downright terrible (a frame of the 1.26 GB file of 13 seconds can be found in the attachements). All the frames are like this, and no matter what kind of settings I change, when I upload a video rendered with the H264 codec it results in awful quality that is completely sub-par to what is said in the tutorial video nor does it come even close to the quality of videos I uploaded all those years before. I really want to get rid of YT re-encoding my videos, or at least changing drastically what is shown on-screen (like red colours bleeding out insanely), and while it seems that now the reworking progress gets almost completely ignored, with the video being published nearly instantly, the results are unusable.

My question is, what am I understanding wrong, is this an outdated codec, are my settings bad? How can the filesize of H264 vary so greatly compared to results of MainConcept AVC/AAC, produce excellent results in the final product before uploading to YT but when it's actually online and streaming, it's as if the 1080p function is 240p fullscreen.

Can anyone please help me out.

[Joris Ceoen]

About the colours, that is how it was in-game. The map transformed the colours. I used this footage to see how the rendered would deal with many different strange colours to see exactly how well it compressed. It compresses amazingly in the end-result, but sadly when uploaded to YouTube there seems to be a terrible problem in the quality. How can this even happen when it is supposed to not even re-encode at all...

[sneaker]

it seems that a video I watched recently suggests there is a H264 codec that 'bypasses' YouTube's re-encoding system, because it already uses that by standard (AVI container).

No, it's not possible to bypass the re-encoding. Period.

There are no options in the x264vwf interface to like... lower this or make it equal to the original file.

Resulting bitrate is set using the CRF parameter (lower CRF = higher bitrate) or bitrate parameters. x264vfw does not know about original file size so you cannot say "make it lower than original file", you have to manually calculate the bitrate. I recommend using CRF. E.g. start with CRF 16 and then see if you are happy with the quality/size. If not: increase or decrease CRF as you find necessary.

[sneaker]

It compresses amazingly in the end-result, but sadly when uploaded to YouTube there seems to be a terrible problem in the quality.

At 1.26 GiBytes for 13 seconds the bitrate is 0.8 Gbit/s. Of course that looks amazing. Now how many people have 0.8 Gbit/s Internet? How is Youtube supposed to serve such a video? Of course it has to recompress. And then you end up with at best 0.025 Gbit/s for a 4K video. And if your video is full of uncompressible content like if you were on shrooms it will look terrible. Especially right after uploading because it takes time for Youtube to create the different streams. At the start it may only have the low bitrate/low resolution versions ready. If you right-click>"Stats for nerds" it will show what codec and resolution you are currently seeing.

[Joris Ceoen]

It compresses amazingly in the end-result, but sadly when uploaded to YouTube there seems to be a terrible problem in the quality.

According to your Explorer screenshots the compressed video bitrate is 3 Gbit/s. Of course that looks amazing. Do you know anyone with a 3 Gbit/s Internet connection? How is Youtube supposed to serve such a video? Of course it has to recompress. And then you end up with at best 0.025 Gbit/s for a 4K video.

Ok, that clarifies a lot. But then, is there an option in the x264vwf to lower the bitrate? I mean, even if I put the slider at the lowest of low quality (all the way to the right) it still results in my video having this 3 Gbit/s indication (however the filesize is considerably smaller). Can I manually change the Gbit/s? I may just understand it wrong, for which I apologise beforehand

It compresses amazingly in the end-result, but sadly when uploaded to YouTube there seems to be a terrible problem in the quality.

At 1.26 GiBytes for 13 seconds the bitrate is 0.8 Gbit/s. Of course that looks amazing. Now how many people have 0.8 Gbit/s Internet? How is Youtube supposed to serve such a video? Of course it has to recompress. And then you end up with at best 0.025 Gbit/s for a 4K video. And if your video is full of uncompressible content like if you were on shrooms it will look terrible. Especially right after uploading because it takes time for Youtube to create the different streams. At the start it may only have the low bitrate/low resolution versions ready. If you right-click>"Stats for nerds" it will show what codec and resolution you are currently seeing.

Ok. It seems that the quality has now stabilized a bit, so you were right on that part. I guess there is no other way but to see and compare results after a few houres of waiting.

Anyways, here are some video results:

@50mbps
https://www.youtube.com/watch?v=YzK8YNp_RJ0

@120mbps
https://www.youtube.com/watch?v=ARrcwEmIPAU

mp4 format instead of avi
https://www.youtube.com/watch?v=8hWCL74YtCQ

The 13 secs 1.26gb file at insane quality settings (16)
https://www.youtube.com/watch?v=PnDRV1RufBk

[sneaker]

file size = bitrate * duration. So if the duration is constant (e.g. 13 seconds) and the file size shrinks then the bitrate shrinks by the same amount. The 3 Gbit/s is actually some wrong measurement. I only looked at your explorer screenshot but now manually calculated the bitrate from 1.26 GB for 13 seconds. It is still too high unless you have Gigabit-Internet.

But, let me reiterate:

it's not possible to bypass the re-encoding. Period.

You will never make it happen.

[Joris Ceoen]

file size = bitrate * duration. So if the duration is constant (e.g. 13 seconds) and the file size shrinks then the bitrate shrinks by the same amount. The 3 Gbit/s is actually some wrong measurement. I only looked at your explorer screenshot but now manually calculated the bitrate from 1.26 GB for 13 seconds. It is still too high unless you have Gigabit-Internet.

But, let me reiterate:

it's not possible to bypass the re-encoding. Period.

You will never make it happen.

Ok, thanks for the answers. I already guessed that would be the answer, but at least now I got an additional confirmation. It surely processes much shorter than it did on my older videos, which is an improvement nontheless. But, I'll keep the filesize to a realistic goal and try to get the best results regardless.

[raffriff42]

a video I watched recently suggests there is a H264 codec that 'bypasses' YouTube's re-encoding system, because it already uses that by standard (AVI container).

Here are my comments on that video (re-posted here, as I expect they will be deleted over there)

Nicely edited and everything. Thanks for being short and to the point! But some advice may cause problems for some people.

Using a DV template *might* force a keyframe on every frame (like DV has) which will make your compressed file 20x-100x larger than it should be.

Sony built-in templates can't be changed, so someone trying to follow this advice *might* write a DV file instead instead of x264 (large file size, low quality).

I have not checked either of these DV-related issues for myself, and even if I did, different versions of the same program can behave differently. Even if this method works for you, it may not work for someone else.

The AVI container has sometimes had audio sync problems after YouTube processing. YouTube suggests MOV or MP4, and these have worked well for me.

Don't change frame rate or you will get frame blending or stuttering. Keep it the same as your source video.

In x264vfw, "zero latency" is for live streaming (as in video conferencing) and has nothing to do with audio sync. Zero latency does not help a video file in any way, but it does makes the file about 20% larger.

"Constant rate factor", "quality=18" is excellent advice, but "ultrafast" speed has had quality issues for me in action scenes (the bitrate hits a certain limit), so now I always use "veryfast." This makes file size somewhat smaller too.

You can't bypass YouTube's re-encoding system - and that's a good thing. Otherwise bad guys would be able to hide viruses in their video files, or just make your computer crash for the lulz.

The way to communicate information about your file online is with a MediaInfo report (View menu, Text; right click, Select All, Copy; paste your report in a reply)

I have seen x264vfw files turn out larger than expected - but not as large as you seem to have! A better way would be to use Vegas' built-in MainConcept h.264 encoder, set to high quality & bitrate. Even better would be to render an intermediate using a lossless codec (or near-lossless, eg DNxHD) and do the final compression in Handbrake. This post summarizes the process I use, and it hasn't changed much in the five years since I posted it.

[Joris Ceoen]

Even better would be to render an intermediate using a lossless codec (or near-lossless, eg DNxHD) and do the final compression in Handbrake. This post summarizes the process I use, and it hasn't changed much in the five years since I posted it.

Wow, thank you for your input, this sounds really interesting! I'm now setting up all the stuff, but a few things remain unclear for me in your method. I used to render my projects from 32-bit. In your method, it should be 8-bit right? So my project setting should be 8-bit. Then, to the video footage I apply the Computer RGB to Studio RGB filter, right? Is it normal that it looks a tiny bit more bright? It's not a big deal as far as I can discern from the preview, but I hope it doesn't deform too much. 32-bit didn't deform any colours from the original RAW video file.

Lastly, for resolution you suggest using the same as my project settings, but my files are recorded in pure 60FPS, and no such option is possible from the resolution drop-down (only 1080i/59.94). It doesn't affect the FPS right? Only the resolution I hope.

Anyhow, I'm gonna try it out and let you know what the results are!

[raffriff42]

Thanks and you're welcome.
I'm not sure if YouTube supports 10-bit yet. Others here probably do (anyone?)

Check the effects of the Studio RGB filter on a short test video, as viewed on YouTube, before deciding if you want to use it.

If you're recording at 60 fps, keep the project @ 60 if possible. You should be able to get it with a "custom template" in Vegas.
If you can't get it, 59.94 won't be terrible. One frame per 1000 might be dropped, not sure. Be sure to turn frame blending off.

[sneaker]

Youtube should support 10 bit uploads but only HDR videos are served as 10 bit as of now. Everything else is only served as 8 bit.

[jagabo]

I used to render my projects from 32-bit. In your method, it should be 8-bit right?

8 bit, 24 bit, and 32 bit are all the same thing. 8 bit means 8 bits per channel. 24 bits is 8 bits per channel with 3 channels (R, G, B, or Y, U, V), 32 bits is 8 bits per channel with 4 channels (R, G, B, and Alpha, or Y, U, V and Alpha).

Then, to the video footage I apply the Computer RGB to Studio RGB filter, right? Is it normal that it looks a tiny bit more bright?

No. Leave the RGB at computer levels (0,0,0=black, 255,255,255=white). Unless your editor converts to YUV incorrectly.