M2T is fine for my purposes. My camera (old FX1) is native M2T, so 90% of the resulting footage isn't touched on recompression (I have no-recompress enabled, and it is working). I leave it at 1440x1080i and let Handbrake do the deinterlacing later (decomb filter), since I render at multiple resolutions. Quality of the M2T is just fine, especially after it's mashed down for the web.

I believe there is a way to control the maximum bitrate on quality-based encoding using Handbrake, although it's not part of the GUI. What would be a good "peak" value?

Also the settings you mention there would be for later recompression by hosted playback, right? I was looking at the site you linked to last night, and it doesn't seem to offer final encoding suggestions, it seems to be geared more for providing the best quality encodes for later re-compression by services. Which doesn't really help, since a lot of the CPU-heavy settings don't matter in that situation

...What about final delivery, ie. isn't CABAC and deblocking a really bad idea for Flash playback?

I used to use settings like those, but found that the trees in the rather fast pan at about 8 min. 36 seconds into this video (http://www.torealize.net/2physics.html) were breaking up - with portions of the trunks displaced perhaps 10%-15% from the other portions of the same tree trunk.

I (mostly) solved that problem by setting both the Reference Frames and Maximum B-Frames to 2 instead of 4 (it still could stand a bit of improvement - perhaps more experimenting someday will fix it totally; if you watch, be sure to click the full-screen button so that you can see the flaws).

Incidentally, the above-linked video is encoded at only 500 kbps (2 pass) and still looks good, mainly because of the prep work done in Vegas. As I mentioned in another thread, clean up video noise by using the free Smart Smoother or similar, shoot greenscreen and blur the background whenever possible, keep fades and pans to minimum, and other common-sense measures to reduce bandwidth requirements. Then at least you'll lighten the bandwidth requirements if streamed over the internet from your own server.

Obviously, this doesn't matter if you have a fast hard disk, but I have an old thumb drive that's very slow; even so, it is able to handle the 500kbps OK.

Do you think my main problem here is using quality-based encoding? I liked that because it really prevented breakup/quality problems, but maybe it's just too much for Flash.

I'll have to see if I can find the maximum quality bitrate setting.

There is no constraint that I know of on CQ bitrates. If you find one in the x264 params, please let us know, although it is the average bitrate that is of concern for playability.

Peak bitrates are easily absorbed by the buffers. It is the sustained high ABR coupled with indigent processor load that eventually overwhelms and causes breakup during playback.

If your source is HDV and you are smart rendering, your assumption is correct that it is a useful intermediate for your purposes. Smart render using Sony MXF is also an option in your workflow.

Although the original research was done with upstream processing in mind, another thread of our inquiry developed the local delivery recommendations that I illustrated above. Again, those most closely approximate Vimeo Flash-based streaming delivery, which is the recognized global standard for quality vs. playability. Jerry (amendegw) has also had success at bitrates lower than 2Mbs if server space is a consideration, and such bitrates are possible, given some constraints.

CABAC and deblocking pose no compatibility problems that I or Handbrake are aware of. Almost all of their presets use the two in concert, as do other implementations of x264. What is your source of information about this question?

Jerry will probably jump in on this discussion and give you some more specific details since he has a bit more experience with onsite hosting of streaming video than I.

That being said, you are welcome to reinvent the wheel if you wish, but if you follow the links at the top of the page I linked above, you will find that half-dozen of us have spent a couple of years on this inquiry.

>If your source is HDV and you are smart rendering, your assumption is correct that it is a useful intermediate for your purposes. Smart render using Sony MXF is also an option in your workflow.

My personal favorite is smart-rendering HDV into 25 Mbps Sony MXF which avoids re-data-compressing the audio and (for some reason that I don't understand) does less damage to the re-rendered bits of video as well.

For CABAC/deblocking, it's not a compatibility issue, it's that they supposedly add a higher CPU load (at least according to the information I've read over the past year), and assuming that Flash is already a CPU hog/inefficient, it seems like they would not help promote smooth playback.

But I could give it a shot.

OK, I'm starting a test render using the exact settings you indicate above, at 2000kbit 2-pass. We'll see what it's like.

After I'll also try re-rendering in vegas to MXF, see if that helps eek a bit more quality out.

I'm not at all concerned about bandwidth or storage space, I'm just trying to present the best quality at the best compatibility to viewers.

Along those lines, any suggestions for a lower bandwidth 640x360 encode?

"it's not a compatibility issue, it's that they supposedly add a higher CPU load"

Again, please post the source of your information. You are implying an effect on Flash-based decoding that I have not considered. CAVLC is pretty much a dead duck except for some older Apple iPod/iPhone technologies and is relatively inefficient from a compression standpoint.

"I'm just trying to present the best quality at the best compatibility to viewers."

Unfortunately, it's playability on your neighbors' systems that is the lowest common denominator. If it'll play on a 500Mhz Win98 system, it'll play on anything.

It's actually Handbrake itself that says this. For the CABAC option it says "if you're looking to minimize CPU requirements for video playback, disable this option."

On deblocking: "The deblocking filter takes a lot of CPU power, so if you're looking to minimize CPU requirements for video playback, disable it."

Also about a year ago I was doing a lot of test encodes, and I found that both Flash and VLC had great difficulty with higher bitrate CABAC encodes, but Flash had less problem with CAVLC encodes at the same bitrate (and no problems in VLC). So that setting did have a very noticeable impact. I've never used deblocking before, so I don't know what kind of real-world impact it has.

But then the tradeoff is you are encoding to higher bitrates to achieve the same quality with less compression. The tradeoff on CPU stress vs. end user streaming bandwidth must be favorable or Handbrake and online delivery services wouldn't be using them, right?

However, I can see you are an intelligent lifeform. As such, I eagerly await the results of your testing on these considerations, which I confess I have not delved into (save for encoding "Avatar" to 400x224 for playback on my cellphone).

Seriously, I haven't tried Baseline profiles for online HD streaming.

See, this is actually what I'd like to know - exactly what x264 settings these online delivery services are using for 720p encodes. At least then I'd be in the same "compatibility" boat as them, but I've done a LOT of web searches and that information seems a closely guarded secret.

Your suggested settings above (which I understand you're saying are very close to what those services are using) looks nearly identical to my RF23 encodes, but are about 8% smaller. I think the problem is my current video doesn't have any particularly difficult-to-encode scenes; not the kind of thing where you instantly see a problem (I had one of those a year ago - horrible fading transition which I eventually fixed with the CQ setting).

From trying to study the clips in VLC, it seems that the bandwidth swings aren't as high with the ABR as with CQ; so the minimum is higher but the maximum is lower. I'm hopeful this will help things.

It's not that I've had complaints on my current encodes, but I see the issues myself versus the original files and it bugs me enough that I want to fix it.

For 640x360 would you use the same settings at a lower bitrate, or would you turn off some of the high profile stuff?

Online commercial streaming services aren't using x264, I can promise you that much.

Your questions are good ones, and entirely welcome, but you are going to have to lead that discussion, since the work Nick, Jerry, Laurence, and others have done relates mainly to HD delivery.

x264 internal parameters (not all are available in Handbrake) are shown here:
http://mewiki.project357.com/index.php?title=X264_Settings&oldid=4313

Really, for such low resolution (640x360), the relative bitrates would be so low that Baseline vs. Main Profile delivery would seem irrelevant in terms of playability, but probably not so for compression. Feel free to continue here or in one of the other threads, and your testing will be interesting, to say the least. Best of luck.

Well, one difference I've seen in the encodes is with the trickiest section, the CQ had a sustained period of 7000-8000kbit, while the 2000 ABR was more around the 5000-5500kbit range. That's better, I'm guessing.

I'll be uploading these new renders later, and will see if playback is any different.

I had the same questions regarding CABAC etc. and got some feedback here from people who know about this stuff.

My conclusion was simply to go with current x264 defaults and just tweak the CQ or ABR.

My later conclusion, in view of the number of devices and resolutions one has to support these days, was to leave all that to someone else i.e. YouTube, Vimeo etc..

Facebook does use x264 for its video. You can retrieve the mp4 from your browser cache and query it with MediaInfo or AviNaptic. Look in column I in this spreadsheet to see what they were doing in January with a 1280x720 upload. CABAC was on.

For 640x360 I guess you'd want to average around 500kbps, plus or minus a couple of hundred depending on the footage. 8000 seems like a huge spike, so yes, the ABR values sound better. I didn't realise there would be so much difference between CQ and ABR given the same average bit rate.

You could download MeGUI and install the presets and see what they give you. The coders put a lot of work into tweaking them and keeping them up to date. Bear in mind the version of x264 in Handbrake is older, so recommended settings might not be exactly like for like.

Edit: And note that Facebook uses the much older version 1232 of x264. The current builds are up to version 1947. That's why you see gaps in some of the parameters read by MediaInfo/Avinaptic. Because the features didn't exist in that old version.

I'm fairly satisfied with my new results.

I've re-rendered 2 videos as 2000/192, both originally encoded to CQ RF23/160 (decided I need a slight audio boost), one dropped 7.9% in size, the other dropped 24.5% (it had more motion and a more detailed background). With the more advanced encoding settings, I think the quality level between the two is very similar.

I've also re-rendered my 640x360 vids after some slight tweaks to the 720p settings, as 700/128. Video quality is already on the negative side of the bubble at 700kbit, I don't think it can handle any lower. File sizes are 10% and 22% smaller than the originals at CQ RF24/128. I had originally used even fewer high profile settings on my 360p encodes (in the mistaken belief that a lower quality video didn't need to bother with that sort of thing), so video quality if anything is slightly - only slightly - better.

Now I wish that 1080p was more mainstream. I've managed to make some gorgous 1920x1080 4500kbit encodes tonight (even though the source is 1440x1080, rendering to non-square pixels is a problem for Flash playback). I'm sure the higher bitrate helps the most, but detail is much crisper due to not resampling vertical resolution, and even motion seems more fluid.

Edit - also forgot to mention: MXF format is a real problem for audio. It renders out two separate mono uncompressed PCM channels, instead of a single stereo stream, and I can't get Handbrake to produce anything besides mono sound. I can't seem to get Vegas to render to normal stereo, or Handbrake to merge the two mono streams into a single stereo channel. So I'm back to M2T.

768x432 or 512x288 might give you a slight edge over 640x360 as they are mod 16. And I read that with x264 it's not a case of mod 8 being 2nd best only to mod 16. What is important is how many pixels away from mod 16 you are (the fewer the better), since it pads to mod 16.

Also, in Vegas Pro 10 you can smart render to 1440x1080 to XDCAM EX. It's much faster than the other methods and gives the better quality in the re-rendered bits that mxf does and m2t doesn't (put the slider at 31). I don't know if Handbrake will accept it but it's worth a try. More here but note Laurence's findings re audio limitations.

I did adjust the M2T profile quality slider to 31 (defaults to 15)... smart render continued working. It's all still MPEG2 isn't it, and wouldn't 31 be the same regardless of container?

That's for the resolution suggestions, I'll try them at the same bitrate and see what happens.

The smart-rendered bits are the same but the bits that won't smart render are less lossy with mxf or xdcam ex than they are with m2t. Apart from where you have applied fx etc., this includes the bits at the beginning and end of clips where you don't have a full GOP. In the case of HDV, up to the first and last half second will get dumb-rendered.

Obviously slider-to-31 has no effect on the smart-rendered bits, but I can't remember if it has an effect with the dumb-rendered bits in the case of the 3 formats we're discussing. I usually save a preset with it anyway just to make sure. You could check if it has an effect by examining the scopes or muting tracks at best/full.

Wooo, I like XDCAM EX format. Renders hella fast. Handbrake seems fine with it, stereo audio and all, and there's a definite quality improvement on re-rendered segments versus M2T @ 31.

I have some solid graphics with red letters on a white background, and on the M2T there's a bit of a dark shadow in the red around the border. On the XDCAM render, the red is perfect right to the edge. Why is that?

I can even see the difference in my 720p re-renders.

Edit: only problem, can't get sound to play back in Media Player, so I can't use it for archival...

In haste so I'm shooting from the hip without testing...

Why is that?

Maybe the newer XDCAM EX and MXF respect the quality slider and m2t doesn't? Maybe there is even a different MPEG-2 codec under the hood? It is mysterious, and slightly frustrating, that the same quality and speed that XDCAM EX has cannot be built into the HDV render.

can't get sound to play back in Media Player

Haali splitter might get that working. Or VLC perhaps?

Scratch my praise of XDCAM format for smart rendering - I'm actually getting corruption in the areas around the smart rendered portions, that I *don't* get with M2T smart renders. The corruption is clearly visible when I re-import the clip onto the Vegas timeline.

You know, I don't get that, but maybe it's because I'm doing it a little differently. That is, I render my raw m2t footage into large .mxf segments with markers added (via Ultimate S's "put markers at events script) and the volumes normalized. I do this mainly because Vegas seems to handle a few large mpeg2 sections much more responsively than it does many small clips. With Cineform avi I leave the clips separate because there is no performance hit with many small clips and this lets me color correct the clips separately with First Light. Anyway, with my HDV footage, I may well be getting artifacts at the ends of the clips during this first prerender, but these would not be the joined parts that show up in my final project (which are .mxf to .mxf). My final project is mxf to mxf and looks great even at the transitions, titles and other changed parts. The quality at the smart-rendered parts is much better than I've experienced with m2t to m2t. I do this approach of prerendering large sections to .mxf because I work with such large amounts of footage and it helps me to keep it all straight, and because the performance is better. I also like working with normalized audio. It sounds like it might also get rid of the artifacts you are running into (though I had no idea of this problem before).