HDV can I do this??

[Dale Guthormsen]

Good afternoon,

I shoot a lot fo footage in the sky. lots of blue most of the time here.

When I render this to1280x720 mp4 in some clips I get pixilation to some degree.

can I add a gausian blur to just the blue of the image to smooth them out with out effecting the raptors I am filming???


Is there another way to accomplish that?


thank you,

[Seth Bloombaum]

This is kind of an interesting problem. There are a series of things you can try on the encoding side, which probably ought to be tried first before blur. The blur is going to be a bit complicated, presumably not wanting to blur the birds, but doable.

A little theory - this error is usually called macroblocking. It occurs when the encoder is starved for bits - complex scene, no more bits available, so, it starts creating groups of pixels that it treats as one pixel (usually 16x16 or 32x32 pixel groups). The usual solution is to give the encoder more bitrate to play with. Sometimes, all you have to do is select "variable bitrate".

The potential problem with increasing bitrate comes with distribution. A user-generated content (ugc) site might only accept clips under a certain total file size; this would be the most common constraint. If you're doing your own streaming solution, you need to keep in mind your target audience. A single bitrate file probably shouldn't be over 600 or 800Kbps for a good streaming experience for a broadband-access audience, which ain't much for HD, especially HD with high picture complexity. The ugc services get around this by having a low bitrate / smaller pixel dimensions file as the default, then the viewer can select hq or hd, and maybe accept longer buffering times, depending on their access.

Select a short clip (say, 10 to 20 seconds) in which this encoding error is prominent. It should include a good shot of a raptor. You're going to do all the tests that follow with this clip, and there are a lot of them, so you want something that's going to encode fast. Think about some file naming convention for your renders - you're going to be comparing a lot of files - make it clear in the file name what settings were used.

First thing, try all the MP4 encoding codecs you can. This includes the Sony AVC, the Mainconcept AVC/AAV-MP4, and the QT MPEG4. You might as well throw WMV9 into the mix - many ugc sites accept it as well, though it's generally second in picture quality to MP4 for a given bitrate, this might be an application where it does better.

Ideally, you'd test all these encodes at a given bitrate. See if one of them shows better performance in the blue sky.

Then, when you've settled on an encoder, give it all the bitrate you can. If you've been using CBR, try VBR, or vice versa.

If you still have trouble with macroblocking, Gaussian Blur may be the next step. This works because it reduces picture complexity. First thing to do is try the minimum horizontal blur, .001, then try .002. Somewhere here, .002 or .003, you're going to have unacceptable blurring of the subject, but keep going until you find an amount that encodes smoothly.

If you've not found joy yet, now you'd use a chromakey filter to generate a mask that only passes the sky, and blur it... and, I'm out of my depth with masking and compositing in Vegas, but the goal would be to create a composite of a blurred sky layer and a sharp everything else layer.

Perhaps someone with more masking and compositing experience will chime in here.

[Mike Kujbida]

Dale, try changing the Pixel format in your project properties from 8-bit to 32-bit.

Here's one thing that the online help menu has to say that is applicable to your problem:
When using 8-bit input/output, the 32-bit floating point setting can prevent banding from compositing that contains fades, feathered edges, or gradients.

Be advised that this requires more CPU power but, as I recall, you have an i7 so this shouldn't be a problem.

Do a search in the online help for more information on this option.

Glenn Chan has an article on his site titled Color Spaces in Vegas 8 that should be of some help as well.

[Dale Guthormsen]

Mike,

thanks a million, I will start running the tests on tuesday and will get back to you when I finally get this sorted out. It is an interesting endevor.

I will start with the 32 bit change and go from there!!

[Seth Bloombaum]

Well. Granted that the testing I suggested is a project in itself, perhaps two hours of speedy testing... and Mike suggested ticking a checkbox, which sounds waaay better, even to me!

Dale did not say "banding in previews", he said "pixellation in renders", which I've interpreted as an encoder/bitrate issue.

If a switch to 32-bit mode clears this up I'll be surprised... but happy for Dale.

Please do post back and let us know the results.

PS. To do a quick test of encoder bitrate starvation, just encode a sample as you've done before, doubling the bitrate. Then, if indicated, you can go through the optimization I've suggested above.