MeGUI offered me a whole load of updates today from the stable update server, including an updated version of x264. I accepted the lot. Fingers crossed. I'll report back if I have any problems.

A quick note-to-self (and the converted)...

It turns out the latest MeGUI/x264 did change something, at least on my laptop.

In MeGUI version 1911 / x264 version 1867 you had to make 2 changes from the x264 defaults in order to get an mp4 file (muxed with Nero AAC) to open in Vegas 8.0c:

1. Disable B-Pyramid (--b-pyramid none)
2. Disable P-frame Weighted Prediction (--weightp 0)

However, in the newer MeGUI version 1989 / x264 version 1911 you have to make just one change from the defaults in order to get such a file to open in Vegas 8.0c, and it's a different parameter:

1. Set Adaptive B-Frames to 2-Optimal (--b-adapt 2)

Another change is that a MeGUI/x264 mp4 file muxed with FAAC audio no longer crashes 10.0c. But FAAC in a MeGUI mp4 causes big problems with YouTube. Better to use Nero AAC.

Just about any MeGUI/x264 mp4 you can make will open in Vegas Pro 10.0c.

Working that lot out was no fun.

Edit: Full table of breakages is here.

I'm one of the interested lurkers and I've taken to heart much of what you geniuses have discovered. But I'm feeling the need for an update to the big picture:

With the recent evolution of use of MeGui, and especially with the latest iteration of it, where do we stand relative to Handbrake? Bottom line, can MeGui give significantly better image quality at low bitrate than Handbrake? I've been using Handbrake and it has been so much better than MC or other .MP4 option, and it is so easy to use, I'm wondering if I should once again use MeGui (I tinkered with it a couple of years ago).

Succinctly: Given the evolving sophistication of .MP4 encodes, what are the pros and cons of Handbrake vs. MeGui?

Edit: I usually start with progressive clips - not interlaced; so I'm mostly interested in factors other than decomb in making my choice.

There's not much in it, especially if you're not decombing. What are you encoding for exactly? What resolution? Self-hosting or upload to YouTube, Vimeo etc.?

HiDef (1280x720), currently self-hosting (www.torealize.net), eventually also for YT & Vimeo (short versions).

The reason that I'm trying so hard to get the bitrate down is that participants on another forum tell me that my videos barely play, with lots of buffering, in UK and Australia. I'm currently using 2-pass 500Kb/s encodes with Handbrake, but would like to get it down to maybe half that.

I'm still experimenting - reducing noise in clips, blurring background behind chromakeys, etc. - and can use all the help I can get.

If self-hosted videos <=1.5Mbs do not play well on their systems, then there is something wrong at their end. It is not your encodes. If they are not letting the video load completely before starting playback, then they need to be educated.

If you are not decombing and not resizing, there is probably little advantage of one over the other. They both use x264. My advanced settings for <=2Mbs in Handbrake are here (very similar to what we get from Vimeo):
http://dl.dropbox.com/u/20519276/HB2Mbs.png

"If they are not letting the video load completely before starting playback, then they need to be educated."

Unfortunately, the JW Player that I'm using starts playing even before the "play" button is pressed in some browsers even though I have the instant start option set to False in my coding. A new JW Player just was published yesterday, so may give it a try to see if that instant-start problem can be fixed.
--------------
Regarding the settings that you show in your .PNG, I'm using those exact settings except that I had to go back to 2 and 2 instead of 4 and 4 for the Reference Frames and Maximum B-Frames; the 4 and 4 settings produced shearing of the image during playback of fast pans - even when played from my own hard disks (I'm also using -2 and -1 deblocking).

As I type I'm encoding my most difficult video (the physics video) with less noise in a noise-generator event in hopes of saving bits for other higher-priority events - then I'll put it into Handbrake and give it a try at maybe 250 Kb/s.

I can't imagine how I could have gotten anything with nearly this quality without the patient exploration by you and the others who have contributed so much to these long threads. Again - Thanks!

"the 4 and 4 settings produced shearing of the image during playback of fast pans - even when played from my own hard disks"

That's useful information; I will run some additional tests. Are you also seeing the shearing from Vimeo? Are you seeing it only in full screen mode? Vimeo is using 4 ref frames as well.

My Vimeo account expired some time ago due to inactivity, so at the moment I can't test it on Vimeo.

Full-screen mode? Always there, whether playing in the little window that I use for the default JW Player, or full screen from JW Player, or playing from my hard disk in Windows Media Player - I couldn't get rid of it until I changed the HB settings to 2 & 2.

I tried to find an old .MP4 so that I could get a screen grab to post here, but can't find one. I'll try to encode it again at 4 & 4 and then host it so you can analyze it for yourself.

In the meantime, maybe I should verbally describe what I mean by "shearing." On a fast pan of a park, I noticed that tree trunks would tear in a way that displaced about 1/4 of the image to the left (trailing) the rest of the image by maybe 10%. You can see that pan (with the 2 & 2 setting) at 8 min. 35 seconds into this clip in case you want to see the corrected pan:

www.torealize.net/video/test/MXF-HB.mp4)

I've been doing a few experiments myself, starting with progressive clips, and now have enough ideas so that I hope to start a new thread on this "shearing" and related topics - any day now (I hope!)

You're going to see very little difference between Handbrake and MeGUI in terms of quality:bitrate ratio.

MeGUI uses a later version of x264 than Handbrake, but that's unlikely to make significant difference.

Nothing to choose in resizing. I'm using the same Lanczos3 downscale that Handbrake is.

In my opinion the QTGMC deinterlacing you can do with MeGUI is superior to the Handbrake default decomb (which itself is very good) but there is a price to be paid in encoding time. As you are shooting progressive this doesn't affect you.

As deinterlacing is not involved, your workflow should be faster with MeGUI than with Handbrake, once you're in the swing of it, because you don't have to render an intermediate file first. Can't remember testing it though, as I don't have any progressive footage.

I should say that I am still refining my x264 settings for self-hosting. You are likely to see the x264 recommendations in my tutorial change again in the next few days pending some more tests and answers to this.

Here in Bangkok on a pretty good connection your videos loaded steadily (certainly not fast). Once they started they didn't need to pause again.

The thing that might help you much more than the precise video format, is to get the videos onto a CDN (content delivery network) as opposed to your own web host's server. Then you should find that download speed is faster around the world. From what I remember, Vimeo use the Bit Gravity CDN, which is really fast here (and elsewhere I understand), but it's pricey. I use the Amazon Cloudfront CDN, which is charged depending on storage and bandwidth used and calls to the server. I found it pretty cheap. Apparently SmugMug use it for their pics (and I assume their videos). I only have a couple of videos left on Cloudfront, because all my eggs are now in the YouTube basket. One is here. You should see it load pretty fast, assuming someone else in your Cloudfront "node" catchment has watched it within a couple of weeks (can't remember the exact time-frame before it falls off a regional node).

If you decide to give Cloudfront a try, you need to sign up for the Amazon S3 storage service first. Cloudfront is basically an add-on to that. Then you can set up a CNAME with your web host so that your URLs are neat. I use http://cdn.bubblevision.com. Then you can use the free Cloudberry Explorer to upload and manage files. In Cloudberry you need to set the ACL settings to Public(everyone).

If a CDN improves the download speed of your videos, I would start rendering them bigger than what you have. Look at the Best(16) sizes here.

Screwing the bitrate down to 250 Kbps seems unnecessary and a shame.

You might consider going back to deblocking defaults at very low bitrates. The extra detail of -2,-1 might make the encoder's job a bit harder.

FYI the current x264 (version 1913) defaults for Reference Frames is 3 ("recommended 2 to 3") and Maximum B-Frames is 3 ("recommended 1 to 5"). 4 reference frames may be too high. Apart from your shear, that might be contributing to Vimeo's stutter.

Thanks for the ton of useful info - I'll digest it more in depth a bit later.

My 250 kb/s HB encoding just finished. I haven't set up a JW Player .HTML for it yet, but can be downloaded from:

www.torealize.net/video/test/2-2-250.mp4

I was surprised that the low-bitrate didn't hit the image quality as hard as I had feared.

Here's the exact procedure I followed:

1. The few live shots are mostly from a Panasonic TM700 @ 1920x1080 progressive. (Two brief clips are from a Sony HC-1 HDV, deinterlaced with Mike Crash Smart Deinterlacer in Vegas 9c-32 bits, rendered to Cineform intermediate.)
2. Edit in Vegas 8c
3. Render to Cineform in 9e-64 bit (I always do this as it never fails; I avoid 32-bit plugins for this .AVI archive render.)
4. Render that to .MXF in Vegas 10, still @ 1920x1080 progressive
5. Pull into HB, resize to 1280x720; I used the 2&2 setting for a smooth pan, and my usual -2 & -1 deblocking (I'll do deblocking experiment with defaults when I find the time)

Tomorrow I should have a version that gives shearing on the pan @ 8 min. 35. sec.

Here's the .MP4 with the strange shearing, starting at 8 min. 35 seconds:

http://www.torealize.net/4-4.html

Seems to be not as bad as the last time created an .MP4 with Reference Frames and Maximum B-Frames both set at 4 (I've done some re-editing on this project to reduce noise and high-bandwidth hogging events); but the pan still shows some "shearing" in my player (I'm getting on the web with Firefox running in a Linux Ubuntu distro from within a virtual machine, VMWare Player). For some reason, I can only get a blurry screen grab when I press PrtScrn, but no shearing.

Interestingly, I just played it from Firefox running in Win7-64 bits and I don't see any shearing at all, same as on my hard disk (I was certain that I had seen it while playing from my hard disk before I cleaned up the noise). Anyway, I'll post this to see if any one else sees shearing. It may be just a consequence of my using Linux. (But it does clear up totally when I used the 2 & 2 settings instead of 4 & 4)

With reference to your 4-4 render, I do see the shearing in Firefox 3.6 and IE 8 with Flash Player 10.2. The shearing is inconsistent. The picture never breaks up in exactly the same way. In the small window it seems to be slightly worse in FF than IE, and worse with hardware acceleration turned off than on. At full screen it's more like shearing when hardware acceleration is turned off, and stuttering when hardware acceleration is turned on.

Offline I see no shearing in WMP11 with the CyberLink decoder, or in GOM Player with it's own Gretech video decoder. In VLC I get a bit of a mess, similar to shearing, which I've often seen when playing back AVC files.

Not sure what lessons can be learned from this, but I think it's to do with similar issues posted here, here and here. Maybe this subject could be pursued under that last link, as I think most forum users have probably tuned out of this thread by now. The solution seems to be in the minutiae of AVC/mp4 settings. YouTube, for all its ghastly fuzziness and blockiness, at least seems to avoid this stuttering/shearing.

Edit: Answers to this post make me wonder if CABAC is key in all of this. Maybe try disabling that in Handbrake and see what happens.

I'm wondering why you are putting a 1280x720 video in such a small window.

I'm also wondering about your workflow you used for the shearing image shot. If you pause it as it pans past the tree, each image is made up of 3 images. Maybe there's no way around that with Vegas' pan-crop. I don't use it often.

easiest question first:
"I'm wondering why you are putting a 1280x720 video in such a small window."

When I check it out on my wife's old laptop (with lo-pixel-count display), it was not possible to see all the image when I put it into a full 1280x720 window. This way, those with small displays can see it OK, and those with modern displays can click on the "full screen" button.

Question:
Do you see the same anomalies with my 2 & 2 encode at www.torealize.net/2physics.html?

If it is playing OK for you, I'll probably defer further experiments to improve it until I get more time to look into it.

Regarding the 3 images while in pause, I noticed that too. I can't remember if Vegas' Smart Resample does that in large stills as well as in frame interpolation during speed-change manipulations, or maybe it's a characteristic introduced by Handbrake. Again, I'll see if I can play this idea a bit more when I get time.