-
I’ve discovered virtually all my problems with Vegas 10 and 11. It’s Cineform avi
-
I had previously discussed this here. There was a real debacle in the Vegas 10 + Cineform update… and the worst part, none of it was even necessary.
I had been a pretty heavy Cineform user. I converted Panasonic TM700 video in 60p (for speed) and 24p (because Vegas doesn’t understand the pulldown needed for 24p-in-60i), and I used it for intermediate output, particularly for complex, multi-project animations.
When Vegas 10 shipped, I was using an older Cineform CODEC, regular Video for Windows stuff, so it shouldn’t have been an issue. But Vegas 10 had add some private secret interface between Cineform and Vegas. And apparently, they didn’t bother to actually check the version of Cineform you were using. So load up a Cineform with the old CODEC, and it was a major crash, instantly. Well… guess that’s better than random crashes somewhere in the hours of a long render, but still.
So I’m pretty much forced to buy NeoScene 5. You actually had to grab the latest Beta, since that was where Sony and Cineform actually agreed on the interface. Or so you’d think. It actually turned out that while I could now read Cineform, rendering crashed. Always. Instantly. Every time. This was true up to Vegas 10d, fixed in 10e. Keep in mind, though, that all along, new CODEC and old, Vegas 9 worked perfectly well with Cineform.
I thought they had pretty much resolved the issues — apparently not. I use Cineform much less than I used to; in fact, I really haven’t gone back to using it much.
[Putting on the Engineer Hat…] And the real kick in the butt — NONE OF THIS WAS NECESSARY. Sony and Cineform had this new API, fine. But it was clearly buggy… no telling who’s bugs, but when things crash like this, that’s a bug. Even if it wasn’t so clear that bugs existed, where’s the harm in making it optional? As an Engineer, particularly in software (but even in hardware sometimes), I may have clever new idea, but I don’t want to clobber the project schedule or the consumer if something goes wrong. So why not have one more switch somewhere in the Vegas preferences, that would turn off whatever special-but-flawed new magic they put into Cineform, and let me use it exactly (and as functionally) as in Vegas 9? And why not check the CODEC/DLL version in the first place, and not use the new API if it’s not there. That’s a major failing, like a first-year programmer’s kind of mistake. I know I’ve been making decisions in software based on library, API, OS, and chip versions since the mid 1980s at least.
-Dave
-
Yes, I’m using 10e. I’ve been trying new projects on 11, usually with success, and even with AVCHD, multicam editing is smooth. Rendering in mp4 is much faster. And I can stabilize clips, but when I create subclips in Vegas 11 to stabilize them, Vegas always crashes at 99%. I sent a complaint to Sony about this, but by the time they responded I had already gone back to 10 and wasn’t interested in trying to figure out how to make it work.
It’s not render speed I’m concerned about, but preview speed. With transitions and more processor intensive effects such as reversing clips, Vegas stutters in preview for AVCHD footage.
http://www.scenethroughglass.com
-
Yeah, regardless of what Cineform says, avi is causing me tons of problems. Or more likely, Sony. Or some combination of both.
http://www.scenethroughglass.com
-
I use an asus PC with windows 7 and 64 bit, with 8 gigs of ram.
I shoot u/w video with a canon 5d mark II, and have found that the constant issues of having very dark objects RIGHT NEXT TO very bright objects, as is typical in underwater scenes we shoot, REQUIRES the correction tools of NeoHD ( or whatever they are calling it today 🙂 )
The cineform avi runs better than the mov from the camera, and the mov was never meant to be an editing format…the bigger value is the expanded colorspace, to me, so that I get really good gradations near the black or dark objects, into the rest of the frame.
So I have the 4-2-2 colorspace to hold the expanded chroma and luma metadata that Vegas will then use, with the much enhanced gradations, and vastly superior visual. My biggest problem has been trying to get a finished video from the 4-2-2 colorspace, to “accurately” translate back down to 4-2-0 colorspace for an H264 encode that I can send to Youtube, for 1080P distribution…. I have two primary needs in showing videos…. The Internet distribution for Palm beach County dive tourism, and the absolute best quality playback from my desktop and a 52 inch LCD monitor, at big Dive industry trade shows like the “DEMA Show” or “Beneath the Sea”…For the trade shows, I am now playing back the Cineform Avi. At DEMA, which was 2 weeks ago, I used 4-2-2 avi’s for everything we played…for the next show, I am working in 4-4-4 now with my new editing ideas, so will likely play back from 4-4-4 RGB.
I am hoping the translation problem of 4-2-2 down to 4-2-0 will be less severe going from 4-4-4 to 4-2-0…. I will know in about 4 hours when Sorenson Squeeze finishes encoding my first attempt at this conversion on a 15 minute tour of Palm Beach diving video for dive shops involved in dive travel, from all over the world.
The issues of 4-2-2 to 4-2-0 were a big shift in luma to much lighter and washed out, along with a yellow shift in chroma….I discovered that the encodes to H264 were automatically shrinking the color spectrum, setting the encode at 16 out of 256, instead of at zero….Now that I am setting at zero, the luma is close to optimal, and the color shift is not terrible….but not perfect either.
The biggest challenge is pixelization from very poor motion prediction of the H264 system, when it is applied to huge schools of baitfish ( movement over the entire screen, overwhelms the prediction model, and you end up blurring or pixelating the fish–which are a key attraction in the video–must be sharp..
See https://youtu.be/zhuffVfpiXY?hd=1
at around 1:30 the encoder is failing miserably at this….it is set to an encode of 2 pass vbr with 15,000 kbps and all the optimal settings that are obvious in Sorenson Squeeze…Squeeze seems to encode sharper than Vegas 10.. I have not tried this yet with Vegas 11.
If any of you guys read this much, thanks for spending the time, and any suggestions on translating 4-4-4 to 4-2-0 optimally, for web distribution, would be very appreciated. Or anything else that comes to mind 🙂
Dan VSome contents or functionalities here are not available due to your cookie preferences!This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.
-
Dan, your problem is waaay to technical for me to be able to help. I just wanted to compliment you on the video! Gorgeous. Makes me homesick – I grew up in Florida … been away from the ocean for far too long.
I’ll follow this thread with great interest , I’m already learning things that will help when I finally buy a camera capable of 4:2:2 .
Steve
Win7 Pro X64 on Dell T3400, MultiTB SATA, 8GB RAM Vegas 10e x64 DVDA 5.2(build 133) Sony HDR-CX550V
-
[Stephen Crye] “Dan, your problem is waaay to technical for me to be able to help. I just wanted to compliment you on the video! Gorgeous. Makes me homesick – I grew up in Florida … been away from the ocean for far too long.
I’ll follow this thread with great interest , I’m already learning things that will help when I finally buy a camera capable of 4:2:2 .
Steve”
Steve,
Thanks for the kind words about the video…While my post may have sounded kind of “geeky”, I am only dealing with these issues because underwater video is such an “extreme” exageration of the issue facing land based video…and I needed to compensate as much as possible….once I have my solutions down, I doubt I’ll ever be talking much about the colorspace or the chromas or the luma 🙂
For now, I am hoping that with collective knowledge found on this site, there will be some people with ideas and interest in this whole 4-4-2 or 4-4-4 color space, and the better ways available to use it for the final playback….whether at an event where you will playback directly from your best master ciniform 4-4-4rgb avi, or some alternative I am not aware of yet ( but hoping for 🙂 that will be precisely the same quality for playback, but not as suitable for editing–and not requiring as much computer horsepower to play this on a big screen LCD without issues….For now, this is not possible to playback from my laptop with hdmi out, due to either the pathetic internal hard drive speeds laptops tend to suffer from, or the slightley less powerful cpu and lower memmory…But the laptop “would be” much nicer to use at a Trade show or event, than having to drag my big Desktop PC around 🙂And then, the hope that there is an encoding solution for a web based format, that takes better advantage of the perfection you can achieve with a 4-4-4 cineform avi or mov. On this topic, I just downloaded the trial of Sorenson Squeeze 8, and was quite impressed with the x264 encode options–Squeeze 7 has only the bare minimum of encoding options you can set for the H264 encode, and misses out on many key aspects I need for videos like the baitball video I linked here, or some of my other ones — Like Jewfish shot deep into the insides of a shipwreck, where marine life has grown all over the inside of the holds, providing spectacular colors— but with Black and extreme Light occuring in almost all the frames (due to the lighting issues of being inside a shipwreck –sometimes total darkness, lit primarily by dual 50 watt cave video lights)….Here I want the ability to have the black and Light extremes handled “better” than is typical with normal H264 encoding settings, AND have wild colors bursting out….
( see https://youtu.be/xKUgKhvcELk?hd=1 the h264 encode is ok, but is just not the cineform avi… )The new x264 options allow virtually every important ability ( for me) of the 264 system, to be applied….So after some tests I did the other day, it looks like I have to upgrade to Squeeze 8…and then begin learning how to best tweak all the settings, for each type of u/w video I would be encoding. For this, I really hope there are some guys here who have good suggestions in this area…
Some contents or functionalities here are not available due to your cookie preferences!This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.
-
Hi Dan;
I have not thought about Sorenson squeeze for many years – in fact, since I started using Vegas. I think I have V5 sitting on a shelf somewhere.
One thing that strikes me about your YouTube vids is the excellent lack of motion artifacts, compared to my vids. For mine, I’m taking AVCHD 1080 60i footage from my Sony HDR-CX550V and using the Vegas AVC .mp4 encoder, set for 1920×0180 30p and 10 Mbps. Motion looks terrible. YouTube always takes forever to “process” my upload before it goes live, so I know the format is not what YT wants.
Please help me understand – I have heard that YT likes h.264 best, but I am not an expert on these matters, or how Squeeze fits into the equation. Do you use Squeeze after rendering via Vegas, or is it chained as a plug-in somehow? Details would be great, I’m so green I don’t know what questions to ask.
An example of my lame encoding efforts – please be aware this is a “home movie” with almost no editing:
https://www.youtube.com/watch?v=4qD-jioVTI8
Thanks!
Steve
Win7 Pro X64 on Dell T3400, MultiTB SATA, 8GB RAM Vegas 10e x64 DVDA 5.2(build 133) Sony HDR-CX550V
Some contents or functionalities here are not available due to your cookie preferences!This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.
-
[Dan Volker] “And then, the hope that there is an encoding solution for a web based format, that takes better advantage of the perfection you can achieve with a 4-4-4 cineform avi or mov. On this topic, I just downloaded the trial of Sorenson Squeeze 8, and was quite impressed with the x264 encode options–Squeeze 7 has only the bare minimum of encoding options you can set for the H264 encode”
Just curious… if you’re intent on using x264 (the increasingly famous open source h.264 encoder — incidently, the same one used for YouTube encoding), what the point of Sorenson? Just like a fancy front-end? I’ll admit I paid something like $50 for a TMPGenc MasteringWorks upgrade, to get x264 encoding along with a pretty nice batch encoding system for most Windows media types. But Sorenson is pretty expensive, if you’re mainly after something that’s otherwise free (you can use x264 for anything you’re already licensed on H.264 for, if you’re concerned about the legalities). Maybe the upgrade price is decent?
-Dave
-
[Dave Haynie] “Just curious… if you’re intent on using x264 (the increasingly famous open source h.264 encoder — incidently, the same one used for YouTube encoding), what the point of Sorenson? Just like a fancy front-end? I’ll admit I paid something like $50 for a TMPGenc MasteringWorks upgrade, to get x264 encoding along with a pretty nice batch encoding system for most Windows media types. But Sorenson is pretty expensive, if you’re mainly after something that’s otherwise free (you can use x264 for anything you’re already licensed on H.264 for, if you’re concerned about the legalities). Maybe the upgrade price is decent?”
Hi Dave,
I already had Squeeze 7 ( it made cleaner, sharper H264 encodes then Vegas 10 or 11), and the upgrade was $149….certainly not cheap, but version 8 for x 264 has close to 25 or so choices you can make in the encode, and the choices look “extremely relevant” to the changes I want to make in my encodes. Perhaps there is a “free” program that offers a similar interface and all the same encoding options–if so, I wish someone was posting heavily about it, so I would have been able to try it…..Unfortunately, I had found nothing with those features in anything other than command-line version non-gui programs, with next to no instructions, and Sorenson was an immediate solution, for a Need that I have RIGHT NOW, and could not afford to wait on 🙂Some of the features I am adjusting already :
qp
Default: Not Set
The first of three possible ratecontrol methods. Set x264 to encode the movie in Constant Quantizer mode. The number you give here specifies the P frame quantizer. The quantizer used for I and B-frames is derived from ipratio and pbratio. CQ mode targets a certain quantizer, which means final filesize is not known (although it can be reasonably accurately estimated with some methods). A setting of 0 will produce lossless output. qp produces larger files than crf for the same visual quality. qp mode also disables adaptive quantization, since by definition “constant quantizer” implies no adaptive quantization.
This option is mutually exclusive with bitrate and crf. See this writeup for more information on the various ratecontrol systems.
Recommendation: Use crf instead
See also: bitrate, crf, ipratio, pbratio
b-bias
Integer: 0
Controls the likelihood of B-frames being used instead of P-frames. Values great than 0 increase the weighting towards B-frames, while values less than 0 do the opposite. This number is no a percentage, or absolute increase, just an arbitrary metric number. The range is from -100 to 100. Note that a value of 100 does not guarantee every P-frame will be converted (use no-b-adapt for that).
Only use this if you think you make better ratecontrol decisions than x264.
b-pyramid
Default: Not set
Allow the use of B-frames as references for other frames. Without this setting, frames can only reference I or P-frames. Although I/P-frames are more valued as references because of their higher quality, B-frames can also be useful. B-frames designated as references will get a quantizer halfway between P-frames and normal B-frames.
Recommendation: Enabled, if you have at least two B-frames. Slows encoding slightly. Note: in older x264 revisions this increased DPB size, but this is now constant based on ref.
ref
Default: 1
Controls the size of the DPB (Decoded Picture Buffer). The range is from 0..16. In short, this value is the number of previous frames each P-frame can use as references. B-frames can use one or two fewer, depending on if they are used as references or not. The minimum number of refs that can be referenced is 1.
Note, this setting used to control the number of refs used. See this doom9 post outlining the difference.
Also note that the ITU-T specification limits DPB and thus limit the ref for each level. If adhering to Level 4.1 specs, the maximum ref for full height 720p and 1080p video are 9 and 4 respectively. But if the video’s height is not the full 720 or 1080 pixels, a higher ref can be used. Level 4.1 is the level implemented on Blu-ray and HD DVD, and the highest level supported in most consumer electronics which support H.264 playback, including Xbox 360, Playstation 3 and Popcorn Hour A-100 Media Extender. The formula for calculating maximum ref is as follows, the value should be rounded down:
maximum ref = 12288 * 1024 / ( width * height * 1.5)
Recommendation: Around 4-6. Each increase has a reduced benefit and constant speed loss. Very large numbers of refs are normally not very useful, but even up to 16 can be helpful for animated content, video game capture, CGI, and other similar content.
bitrate
Default: Not Set
The second of three ratecontrol methods. Encode the video in target bitrate mode. x264 will attempt to encode the video to target the given bitrate as the final average. The parameter given is the bitrate in kilobits/sec. (8bits = 1byte and so on). This setting is usually used in conjunction with pass for two pass encoding. Target bitrate mode means the final filesize is known, but the final quality is not (although it’s possible to estimate with a reasonable degree of accuracy). It is generally not recommended to use bitrate mode without 2pass encoding.
This options is mutually exclusive with cq and crf. See this writeup for more information on the various ratecontrol systems.
Recommendation: Something which gives P frame quantizers around 18-26. Estimated ranges: for SD resolution: 800kbits – 2100kbits. For 720p, 3-6mbit. For 1080p, 8-15mbit+.
crf
Default: Not Set
The final ratecontrol method: Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain ‘quality’. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. It is not extremely exact, but reasonably close (and will average out to be accurate over a large number of videos).
CRF achieves this by reducing the quality of less important frames. In this case, frames in complex or high-motion scenes, where quality is more expensive (in terms of bits) and/or less visible, will have their quantizer increased. The bits saved in cuts like this are redistributed to frames where they will be more effective. CRF mode gives almost exactly equivalent quality to 2pass at the same bitrate; the difference is that you cannot choose the output bitrate.
This options is mutually exclusive with cq and bitrate. See this writeup for more information on the various ratecontrol systems.
Recommendation: The range 18-26 is probably where you will want to look at. If you need absolutely perfect quality you could go down to 16, but it’s probably not worth it. Around 19-21.5 is where a rip will look very good. Higher res encoding can generally get away with higher crf values.
qpmin
Default: 10
Defines the minimum quantizer that x264 will ever use. The lower the quantizer, the closer the output is to the input. At some point, the output of x264 will look the same as the input, even though it is not exactly the same. Usually there is no reason to allow x264 to spend more bits than this on any particular frame / area. For most videos, anything below q16 will be perceptually lossless in this way, and anything below the conservative default of q10 will certainly be.
You can use this setting to prevent creating needlessly oversized files. Take note if you set this aggressively (ie to 16 or such), and your bitrate based encode is not coming out as large as it should be, this is possibly the reason why. You should analyse x264’s stats output at the end of encoding and see if all frames are being at the minimum quantizer.
With adaptive quantization enabled (on by default), raising qpmin beyond its default is strongly discouraged because this could reduce the quality of flat background areas of the frame.
See also: qpmax, ipratio.
ipratio
Default: 1.40 Sets the target average increase in bitrate for I-frames as compared to P-frames. Seen as ‘keyframe boost’ in xvid. Higher values increase the quality of I frames. This makes them better references, which can improve the overall image quality. The problem is that the extra bits taken by the I-frames are taken from the P and B-frames, which makes this variable a balancing act.
See also: pbratio
[edit] pbratio
Default: 1.30
Sets the targest average reduction in bitrate for B-frames as compared to P-frames. This variable works more or less the same as ipratio above.
chroma-qp-offset
Default: 0
Normally, x264 encodes all three colour planes (luma, U (chroma), V (chroma)) at the same quantizer. This value will be added to the quantizers for the U and V planes. This allows you to bias x264 in favour of brightness (luma) by setting positive values (chroma fields will have higher quantizers), or in favour of colour (chroma). Remember than x264 encodes video as YV12, which means chroma takes up only half the space luma does anyway.
Note: x264 only encodes the luma and chroma planes at the same quantizer up to quantizer 29. After this, chroma is progressively quantized by a lower amount than luma until you end with luma at q51 and chroma at q39. This behavior is not adjustable, as it is required by the H.264 standard…..so use in favor of chroma with lower values/negative values—will take this closer to 4-4-4 color space.
pass
Default: Not Set
This is an important setting for 2pass encoding. It controls what x264 will do with the stats file. It has three settings:
• 1: Create a new statsfile. Use this on the first pass.
• 2: Read the statsfile. Use this on the final pass.
• 3: Read the statsfile, and update it as well.
The statsfile contains information about every input frame, which can be input to x264 in order to improve the output. The idea is you run a first pass to generate the statsfile, and the second pass will create an optimised encode of the video. The improvement is mostly gained from better ratecontrol.
partitions
Default: “p8x8,b8x8,i8x8,i4x4”
h264 video is split up into 16×16 macroblocks during compression. These blocks can be further split up into smaller partitions, which is what this options controls.
With this option, you enable individual partitions. Partitions are enabled per-frametype (ie I, P, B). The available partitions are: p8x8, p4x4, b8x8, i8x8, i4x4
• I: i8x8, i4x4
• P: p8x8 (also enables p16x8/p8x16), p4x4 (also enables p8x4/p4x8)
• B: b8x8 (also enables b16x8/b8x16)
You can also set “none” or “all”.
p4x4 is generally not very useful and has an extremely high ratio of speed cost to resulting quality gain.
See also: 8x8dct
me
Default: “hex”
Set the full-pixel motion estimation method. There are four choices:
• dia (diamond) is the simplest search, consisting of starting at the best predictor, checking the motion vectors at one pixel upwards, left, down, and to the right, picking the best, and repeating the process until it no longer finds any better motion vector.
• hex (hexagon) consists of a similar strategy, except it uses a range-2 search of 6 surrounding points, thus the name. It is considerably more efficient than dia and hardly any slower, and therefore makes a good choice for general-use encoding.
• umh (uneven multi-hex) is considerably slower than hex, but searches a complex multi-hexagon pattern in order to avoid missing harder-to-find motion vectors. Unlike hex and dia, the merange parameter directly controls umh’s search radius, allowing one to increase or decrease the size of the wide search.
• esa (exhaustive) is a highly optimized intelligent search of the entire motion search space within merange of the best predictor. It is mathematically equivalent to the bruteforce method of searching every single motion vector in that area, though faster. However, it is still considerably slower than UMH, with not too much benefit, so is not particularly useful for everyday encoding.
• tesa (transformed exhaustive) is an algorithm which attempts to approximate the effect of running a Hadamard transform comparison at each motion vector; like exhaustive, but a little bit better and a little bit slower.
merange
Default: 16
merange controls the max range of the motion search. For hex and dia, this is clamped to between 4 and 16, with a default of 16. For umh and esa, it can be increased beyond the default 16 to allow for a wider-range motion search, which is useful on HD footage and for high-motion footage. Note that for umh, esa, and tesa, increasing merange will significantly slow down encoding.
See also: me
[edit] mvrange
Default: 511.75
Set the maximum range of any one motion vector. The default value is the maximum specified by the h264 standard. It is not level or profile dependant, so don’t touch it.
[edit] mvrange-thread
[edit] subme
Default: 6
Set the subpixel estimation complexity. Higher numbers are better. Levels 1-5 simply control the subpixel refinement strength. Level 6 enables RDO for mode decision, and level 8 enables RDO for motion vectors and intra prediction modes. RDO levels are significantly slower than the previous levels.
1. QPel SAD 1 iteration
2. QPel SATD 2 iterations
3. HPel on MB then QPel
4. Always QPel
5. Multi QPel + bime
6. RD on I/P frames
7. RD on all frames
8. RD refinement on I/P frames
9. RD refinement on all frames -
[Stephen Crye] ”
Hi Dan;
I have not thought about Sorenson squeeze for many years – in fact, since I started using Vegas. I think I have V5 sitting on a shelf somewhere.
One thing that strikes me about your YouTube vids is the excellent lack of motion artifacts, compared to my vids. For mine, I’m taking AVCHD 1080 60i footage from my Sony HDR-CX550V and using the Vegas AVC .mp4 encoder, set for 1920×0180 30p and 10 Mbps. Motion looks terrible. YouTube always takes forever to “process” my upload before it goes live, so I know the format is not what YT wants.
Please help me understand – I have heard that YT likes h.264 best, but I am not an expert on these matters, or how Squeeze fits into the equation. Do you use Squeeze after rendering via Vegas, or is it chained as a plug-in somehow? Details would be great, I’m so green I don’t know what questions to ask.
An example of my lame encoding efforts – please be aware this is a “home movie” with almost no editing:”
HI Stephen,
I don’t think there was anything lame about your video skills in your “home movie”…..
In any event, my process is to import the clips I shot undrewater witht he canon 5 D into the Neo HD product HDlink, which up-converts the 4-2-0 and 8 bit h264 mov file to a 10 bit 4-2-2 cineform avi…this cineform edits much better than the mov does on my PC, and I think it is a much higher quality format to use anyway…
So now in a much larger “color-space”, when I use the other Neo program, “First Light” to create instant ( non-rendered) shifts in black levels, or contrast, or brightness, or Gamma, or tint, white balance, etc, even instant key framing of any of this…it ALL stays in this larger 4-4-2 color space. When I get to the point of rendering several edited clips together, I use Vegas 11 to render them as 4-4-4 Cineform avi, in 10 bit. This part could be voodoo , but it just seems like the translation of colors from my edited video on the timeline, to the final H or x 264 upload for Youtube, seem to be far more accurate when translated from 4-4-4 to the 4-2-0 of the mp4 file. So after I decide I have done all the tweaking I’m going to do, I have Vegas do a final render of all the 444 files in the time line, to a 4-4-4 finished avi. Then I import this into Sorrenson Squeeze 8 (I just upgraded from 7), where I have so many choices for the x 264 encode it will be weeks before I really think I have each setting dialed in optimally…but I like this way more than only having a tiny number of choices ( as in Vegas or Squeeze 7 with the H264 encodes)…Squeeze 7 made sharper h264’s for me than I could get Vegas 10 to do…I used the trial a year ago, and decided the benefits were too great to miss out on….It did piss me off that I had spent all this money on the Vegas 10 back then, and that I should have to buy an external encoder that was very pricey, to get MP4 playback I liked….but I spend enormous time on the u/w projects, and u/w video is costly all by itself–so the reality is, with what I already had invested, the new tweaks I can gain with Vegas 11 and Squeeze 8 just make sense for me.I’m sure there are many people on this forum that know vastly more than I do about what settings are optimal in the x264 encoding, and I am hoping they will make suggestions 🙂
Here are some of the choices you can easily add in to the x264 encode, and Squeeze 8 makes this amazingly easy:
qp
Default: Not Set
The first of three possible ratecontrol methods. Set x264 to encode the movie in Constant Quantizer mode. The number you give here specifies the P frame quantizer. The quantizer used for I and B-frames is derived from ipratio and pbratio. CQ mode targets a certain quantizer, which means final filesize is not known (although it can be reasonably accurately estimated with some methods). A setting of 0 will produce lossless output. qp produces larger files than crf for the same visual quality. qp mode also disables adaptive quantization, since by definition “constant quantizer” implies no adaptive quantization.
This option is mutually exclusive with bitrate and crf. See this writeup for more information on the various ratecontrol systems.
Recommendation: Use crf instead
See also: bitrate, crf, ipratio, pbratio
b-bias
Integer: 0
Controls the likelihood of B-frames being used instead of P-frames. Values great than 0 increase the weighting towards B-frames, while values less than 0 do the opposite. This number is no a percentage, or absolute increase, just an arbitrary metric number. The range is from -100 to 100. Note that a value of 100 does not guarantee every P-frame will be converted (use no-b-adapt for that).
Only use this if you think you make better ratecontrol decisions than x264.
b-pyramid
Default: Not set
Allow the use of B-frames as references for other frames. Without this setting, frames can only reference I or P-frames. Although I/P-frames are more valued as references because of their higher quality, B-frames can also be useful. B-frames designated as references will get a quantizer halfway between P-frames and normal B-frames.
Recommendation: Enabled, if you have at least two B-frames. Slows encoding slightly. Note: in older x264 revisions this increased DPB size, but this is now constant based on ref.
ref
Default: 1
Controls the size of the DPB (Decoded Picture Buffer). The range is from 0..16. In short, this value is the number of previous frames each P-frame can use as references. B-frames can use one or two fewer, depending on if they are used as references or not. The minimum number of refs that can be referenced is 1.
Note, this setting used to control the number of refs used. See this doom9 post outlining the difference.
Also note that the ITU-T specification limits DPB and thus limit the ref for each level. If adhering to Level 4.1 specs, the maximum ref for full height 720p and 1080p video are 9 and 4 respectively. But if the video’s height is not the full 720 or 1080 pixels, a higher ref can be used. Level 4.1 is the level implemented on Blu-ray and HD DVD, and the highest level supported in most consumer electronics which support H.264 playback, including Xbox 360, Playstation 3 and Popcorn Hour A-100 Media Extender. The formula for calculating maximum ref is as follows, the value should be rounded down:
maximum ref = 12288 * 1024 / ( width * height * 1.5)
Recommendation: Around 4-6. Each increase has a reduced benefit and constant speed loss. Very large numbers of refs are normally not very useful, but even up to 16 can be helpful for animated content, video game capture, CGI, and other similar content.
bitrate
Default: Not Set
The second of three ratecontrol methods. Encode the video in target bitrate mode. x264 will attempt to encode the video to target the given bitrate as the final average. The parameter given is the bitrate in kilobits/sec. (8bits = 1byte and so on). This setting is usually used in conjunction with pass for two pass encoding. Target bitrate mode means the final filesize is known, but the final quality is not (although it’s possible to estimate with a reasonable degree of accuracy). It is generally not recommended to use bitrate mode without 2pass encoding.
This options is mutually exclusive with cq and crf. See this writeup for more information on the various ratecontrol systems.
Recommendation: Something which gives P frame quantizers around 18-26. Estimated ranges: for SD resolution: 800kbits – 2100kbits. For 720p, 3-6mbit. For 1080p, 8-15mbit+.
crf
Default: Not Set
The final ratecontrol method: Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain ‘quality’. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. It is not extremely exact, but reasonably close (and will average out to be accurate over a large number of videos).
CRF achieves this by reducing the quality of less important frames. In this case, frames in complex or high-motion scenes, where quality is more expensive (in terms of bits) and/or less visible, will have their quantizer increased. The bits saved in cuts like this are redistributed to frames where they will be more effective. CRF mode gives almost exactly equivalent quality to 2pass at the same bitrate; the difference is that you cannot choose the output bitrate.
This options is mutually exclusive with cq and bitrate. See this writeup for more information on the various ratecontrol systems.
Recommendation: The range 18-26 is probably where you will want to look at. If you need absolutely perfect quality you could go down to 16, but it’s probably not worth it. Around 19-21.5 is where a rip will look very good. Higher res encoding can generally get away with higher crf values.
qpmin
Default: 10
Defines the minimum quantizer that x264 will ever use. The lower the quantizer, the closer the output is to the input. At some point, the output of x264 will look the same as the input, even though it is not exactly the same. Usually there is no reason to allow x264 to spend more bits than this on any particular frame / area. For most videos, anything below q16 will be perceptually lossless in this way, and anything below the conservative default of q10 will certainly be.
You can use this setting to prevent creating needlessly oversized files. Take note if you set this aggressively (ie to 16 or such), and your bitrate based encode is not coming out as large as it should be, this is possibly the reason why. You should analyse x264’s stats output at the end of encoding and see if all frames are being at the minimum quantizer.
With adaptive quantization enabled (on by default), raising qpmin beyond its default is strongly discouraged because this could reduce the quality of flat background areas of the frame.
See also: qpmax, ipratio.
ipratio
Default: 1.40 Sets the target average increase in bitrate for I-frames as compared to P-frames. Seen as ‘keyframe boost’ in xvid. Higher values increase the quality of I frames. This makes them better references, which can improve the overall image quality. The problem is that the extra bits taken by the I-frames are taken from the P and B-frames, which makes this variable a balancing act.
See also: pbratio
[edit] pbratio
Default: 1.30
Sets the targest average reduction in bitrate for B-frames as compared to P-frames. This variable works more or less the same as ipratio above.
chroma-qp-offset
Default: 0
Normally, x264 encodes all three colour planes (luma, U (chroma), V (chroma)) at the same quantizer. This value will be added to the quantizers for the U and V planes. This allows you to bias x264 in favour of brightness (luma) by setting positive values (chroma fields will have higher quantizers), or in favour of colour (chroma). Remember than x264 encodes video as YV12, which means chroma takes up only half the space luma does anyway.
Note: x264 only encodes the luma and chroma planes at the same quantizer up to quantizer 29. After this, chroma is progressively quantized by a lower amount than luma until you end with luma at q51 and chroma at q39. This behavior is not adjustable, as it is required by the H.264 standard…..so use in favor of chroma with lower values/negative values—will take this closer to 4-4-4 color space.
pass
Default: Not Set
This is an important setting for 2pass encoding. It controls what x264 will do with the stats file. It has three settings:
• 1: Create a new statsfile. Use this on the first pass.
• 2: Read the statsfile. Use this on the final pass.
• 3: Read the statsfile, and update it as well.
The statsfile contains information about every input frame, which can be input to x264 in order to improve the output. The idea is you run a first pass to generate the statsfile, and the second pass will create an optimised encode of the video. The improvement is mostly gained from better ratecontrol.
partitions
Default: “p8x8,b8x8,i8x8,i4x4”
h264 video is split up into 16×16 macroblocks during compression. These blocks can be further split up into smaller partitions, which is what this options controls.
With this option, you enable individual partitions. Partitions are enabled per-frametype (ie I, P, B). The available partitions are: p8x8, p4x4, b8x8, i8x8, i4x4
• I: i8x8, i4x4
• P: p8x8 (also enables p16x8/p8x16), p4x4 (also enables p8x4/p4x8)
• B: b8x8 (also enables b16x8/b8x16)
You can also set “none” or “all”.
p4x4 is generally not very useful and has an extremely high ratio of speed cost to resulting quality gain.
See also: 8x8dct
me
Default: “hex”
Set the full-pixel motion estimation method. There are four choices:
• dia (diamond) is the simplest search, consisting of starting at the best predictor, checking the motion vectors at one pixel upwards, left, down, and to the right, picking the best, and repeating the process until it no longer finds any better motion vector.
• hex (hexagon) consists of a similar strategy, except it uses a range-2 search of 6 surrounding points, thus the name. It is considerably more efficient than dia and hardly any slower, and therefore makes a good choice for general-use encoding.
• umh (uneven multi-hex) is considerably slower than hex, but searches a complex multi-hexagon pattern in order to avoid missing harder-to-find motion vectors. Unlike hex and dia, the merange parameter directly controls umh’s search radius, allowing one to increase or decrease the size of the wide search.
• esa (exhaustive) is a highly optimized intelligent search of the entire motion search space within merange of the best predictor. It is mathematically equivalent to the bruteforce method of searching every single motion vector in that area, though faster. However, it is still considerably slower than UMH, with not too much benefit, so is not particularly useful for everyday encoding.
• tesa (transformed exhaustive) is an algorithm which attempts to approximate the effect of running a Hadamard transform comparison at each motion vector; like exhaustive, but a little bit better and a little bit slower.
merange
Default: 16
merange controls the max range of the motion search. For hex and dia, this is clamped to between 4 and 16, with a default of 16. For umh and esa, it can be increased beyond the default 16 to allow for a wider-range motion search, which is useful on HD footage and for high-motion footage. Note that for umh, esa, and tesa, increasing merange will significantly slow down encoding.
See also: me
[edit] mvrange
Default: 511.75
Set the maximum range of any one motion vector. The default value is the maximum specified by the h264 standard. It is not level or profile dependant, so don’t touch it.
[edit] mvrange-thread
[edit] subme
Default: 6
Set the subpixel estimation complexity. Higher numbers are better. Levels 1-5 simply control the subpixel refinement strength. Level 6 enables RDO for mode decision, and level 8 enables RDO for motion vectors and intra prediction modes. RDO levels are significantly slower than the previous levels.
1. QPel SAD 1 iteration
2. QPel SATD 2 iterations
3. HPel on MB then QPel
4. Always QPel
5. Multi QPel + bime
6. RD on I/P frames
7. RD on all frames
8. RD refinement on I/P frames
9. RD refinement on all frames
Reply to this Discussion! Login or Sign Up