Heaven shakes!

Martin L wrote on 10/31/2016, 5:25 AM

Just some advise please,

I have just finished editing a film episode and when rendering it out it is quite shaky. Still images flicker when panning, crossfades are blocky and heaven shakes wildly. See a few short examples here: https://www.dropbox.com/sh/n91rxf3ow24x14m/AAD0p05q7QmcngTiogVBNmp5a?dl=0

(this particular clip is an mp4 filmed with a DJI Osmo. I did a BCC Track motion with the text in the sky and rendered it to an AVI YUV clip which looks great. The AVI is brought onto the Vegas timeline in the film project and has some slight color correction applied using New Blue Color Fast. From there I render it out to different formats)

I tried several different render settings and formats: MainConcept mp4, that I ususally use for most clients, has serious problems. 8-bit or 32-bit video levels make no difference. Main or High makes no difference. One pass or Two pass is the same. I do not use GPU acceleration.

What does make a difference is bit rate. I need to crank it up to 130 mbps with average 50 mbps in order to get acceptable results - resulting in a huge file. My usual Youtubefriendly setting with 28/12mbps makes the heaven shake.

If I use Sony AVC rendering to mp4 with 25,6 mbps the result is much better, and the file isn't that huge.

And rendering to AVI YUV gets almost perfect results, but with a larger than life file size.

Now, is this normal that the bitrate has to be that high in MainConcept mp4? Why is Sony AVC mp4 obviously better in this case?

Is there anything I can do to improve the rendering results regarding crossfades, stills and the "colors of heaven"?

What works best for smooth crossfades? Any trick?

Thanks

Martin L, Sweden.

Comments

Former user wrote on 10/31/2016, 9:40 AM

what format is the original footage Martin?

Martin L wrote on 10/31/2016, 9:49 AM

This particular clip is an mp4 filmed with a DJI Osmo. I did a BCC Track motion with the text in the sky and rendered it to an AVI YUV clip which looks great. The AVI is brought onto the Vegas timeline in the film project and has some slight color correction applied using New Blue Color Fast. From there I render it out to different formats.

The rest of the footage in the project is a mix of Canon C100, DJI Osmo, GoPro and even some iPhone.

NickHope wrote on 10/31/2016, 11:16 AM

For YouTube upload I frameserve to MeGUI and render to H.264 (AVC) with the x264 codec. I set the CRF to 18 and leave the rest at default settings. I have a very old tutorial (that also includes unnecessary stuff about deinterlacing) here.

You can probably do exactly the same thing in Handbrake, and you should be able to automate it with Vegas2Handbrake. Adjust the CRF value to taste. Lower value = higher quality.

In either case you'll get more quality per bit with x264 than with those old AVC encoders in Vegas, and less chance of pixellation etc..

john_dennis wrote on 10/31/2016, 1:20 PM

I suspect there are so many pixels changing in this video that it will take a higher bit rate to look good. Since I don't have your source media, I took your 50 Mbps sample and frame served it to Handbrake. At CQ=22 the bit rate was still 25.9 Mbps. At CQ=24, the bit rate was still 21 Mbps. At CQ=26, the bit rate was 16.1 Mbps.

It looks like this.

The bit rate distribution looks like this...

Martin L wrote on 10/31/2016, 2:52 PM

Thanks Nick and John! I am not familiar with MeGUI and Vegas2Handbrake, nor the CQ things you mentioned John. But I am eager to know. Does V2H work with Vegas 14? (that's what I am using)

john_dennis wrote on 10/31/2016, 3:04 PM

While I was running the trial, Vegas2Handbrake worked in 14.

Read this thread.

Constant Quality is a concept used by some encoders to maintain a certain level of visual quality as opposed to a target bit rate. 

NickHope wrote on 10/31/2016, 11:17 PM

Martin, CRF (constant rate factor) and CQ (constant quality) are the same thing. Some years ago when there was a lot of x264 testing going on here, it was "generally agreed" that simple CQ/CRF does more or less as good a job as multi-pass encoding, despite what one might expect, and of course it's faster. CRF 18 should give a very high quality result, and is good for sending to services like YouTube where you want to give them the best chance of making a decent re-encode. But the file size is large and it's too low a CRF figure really for self-hosting in a web player, where the numbers John tested are more appropriate.

Martin L wrote on 11/1/2016, 2:17 AM

Ok, thanks. Good information. So basically, my video requires a lot of bitrate because of the content, such as panning, crossfades which get a lot of pixels moving in the whole image. The encoding is therefore more importatnt than usual, I guess. I'll have alook at V2H and see if I can learn how to use it. Thanks again!

The film episodes I am workiing on is part of a sailing series which I will pitch to Swedish National Television once I have edited all episodes and gotten a high quality render.

john_dennis wrote on 11/1/2016, 10:46 AM

If you plan to have your work broadcast you need to contact them for their specs on the file formats and bit rates they will accept. Broadcasters have standards for submission that you will likely have to meet.

Martin L wrote on 11/1/2016, 10:49 AM

Sure, we haven't come that far yet with this project. Let's see if the content is good enough. :)