I personally find the Sony AVC a bit softer compared to MC AVC. MC AVC with GPU is also a bit faster then Sony AVC with GPU on my system.

Hardware acceleration in itself degrades the rendered video, so I would leave that out of the soup when making comparisons . . .
;?)

On my system and at the same bit rate, with GPU is better, sharper then CPU only.

I have always said and no one has proven otherwise - the Mainconcept encoder is a goto when the less problematic workflow is sought with best results. The only users that I have seen that settle for Sony AVC out of the box are those outputting to non-discriminating usage in web delivery.

You can fine tune SonyAVC and it is a pain in the neck.

I used Main Concept for a few years then switched to Sony AVC some months ago because it encoded faster (I used gpu encoding). I didn't visually notice any difference and never really had any issue with Main Concept, I switched purely for the speed boost. My videos tend to be encoded at high bitrate though, like 1920x1080 20mbps is the best version posted on my websites along with 1280x720 12mbps, maybe it's more noticeable at lower bitrates. They looked basically interchangeable to me and I would switch back to Main Concept if they improved the speed of their encoder.

That shows how different systems are. MC AVC renders 30% faster then Sony AVC on my system; I too only use GPU rendering. 1920x1080@20mpbs seems a bit high for YT playback.

I used both before, but the quality was not superb to my eyes.
And then i switched to frameserver +ripbot264 combo :-)

I had so many issue with YT correctly handling MC encoded files I've switched to the Sony encoder. Like others have said there doesn't seem much in it quality wise and I'm feeding YT at least 4Mbps 720p. What does matter most to me is being able to just get the video uploaded and for it to playout by YT without duplicated pixels down the side or other issues. It could be of course that the problem is with YT itself but any grief I can avoid no matter where it comes from I will.

Bob.

Size, quality, speed.
x264 wins all three.

musicvid,

Where did you read/hear that the GPU accelerated video compression in Vegas 12 Pro has lesser quality than the CPU compressed version? I'm talking specifically about the MC AVC or Sony AVC "render to" options.

I thought that they used the same algorithms just that one uses the CPU and the other the GPU. Unlike Intel's Quicksync which obviously trades speeds for quite a bit of quality. But there is no CPU only Quicksync option so that isn't an apples-to-apples comparison as it the one I presented above.

Or are you simply making a generalization that GPU accelerated compression is of lesser quality than CPU compression?

In addition, does this mean that the GPU accelerated effects are of lesser quality than if CPU alone is used in Vegas?

I'm just curious because I didn't know this.

Mainconcept AVC in Vegas is three completely different encoders. CPU, OpenCL and CUDA. Differently algorithms for each. The GPU encoders are not just "acceleration" of an existing encoding algorithm.

A GPU encoder can as good as anything out there. This is just not the case, and may never be. File encoding is actually not a very good application of GPU use. Meaning massively parallel compute. Compromises need to be made to get max speed. Speed after all is why people what a GPU encoder.

Sony AVC seems to be one encoder and the GPU acceleration seems to be only on motion searching. This is only a guess.

Here is a link comparing AVC encoders and it shows the Mainconcept AVC GPU encoders are behind the Mainconcept CPU encoder.
http://compression.ru/video/codec_comparison/h264_2012/

Here is a link that talks about why video encoding is not a very good application for GPU compute.

Norman probably said it better than I could.
I looked at direct high-motion comparisons between GPU and CPU encoding some time back, and decided that it wasn't worth the extra hardware cost just for the sake of a modest speed boost. I understand newer "solutions" like OpenCL and CSV can be worse, and I'm a stickler for accurate ME over speed (even with CPU), as you may already know.

"
And once again, that same round of tests puts x264 ahead of MC.

>does this mean that the GPU accelerated effects are of lesser quality than if CPU alone is used in Vegas?
Apart from few bugs, current state of GPU-accelerated effects doesn't produce worse quality.
It is possible that plugins are different in this regard, though.

Apart from few bugs, current state of GPU-accelerated effects doesn't produce worse quality.

Agreed. 1+2=3 on a GPU just like a CPU. So if an effect does the same computations then you should get the same result.

Effects are an application that is very applicable to GPU compute. Massively parallel compute.
Take for example, levels. The new level computed for each pixel is completely independent of all other pixels so they can all be done in parallel.

And once again, that same round of tests puts x264 ahead of MC.

I am not an expert on the GPL license that x264 is developer under but I think if Sony wrote a encoder interface for x264 and made the source for that available then we could all have x264 directly from Vegas like other encoders.

Of course that would effectively publish the encoder interface in Vegas, but that does not tie them down to that. They can change that at will.

I really dislike the intermediate process we have to go through to get to x264.

Sony doesn't do native open source, GPL/GNU, etc., period. Not their license restriction, it's Sony's.
I think it's part of their licensing agreements with MC, et al.
Unlikely to change anytime soon.

Also, it's not "just" x264 that makes Handbrake better.
It's libav, lanczos, yadif, MCDeint, EEID12, etc.,etc.
BTW they're all open source too.

There "is" an x264vfw encoder, but it's crippled out of the box because of avi limitations.
There "is" a yadif plugin, but it's pretty basic compared to Handbrake Decomb.

Best thing for someone lamenting this situation is download the Vegas SDK, grab some source, and start writing plugins!
;?)

Best thing for someone lamenting this situation is download the Vegas SDK and start writing plugins!

Video and audio plug-ins only. The encoder/decoder interface is proprietary.

That embedded video is VERY informational.

I had no idea GPU compression was such a technical challenge. There is no easy way to transfer CPU compression code easily to GPU compression code to get the same quality output while harnessing all of those GPU cores from what these guys in the video are saying. And they seem to be scary smart people;)

I think I'll continue to frameserve to Ripbot from Vegas while this technology matures.

After watching this video it seems as though the programmers of Vegas would best spend their time increasing the GPU of the timeline assembly and improving stability. Get the GPU assembling the timeline and feeding it to the CPU based encoder right?

I appreciate everyone's participation in the thread. I'll admit the technical information goes over my head. I would appear the general consensus is that there is a marginal difference if any.

Great thread. Just the kind of info what I was looking for.
Our renders sometimes cover footage that can be upwards of 3 hours long. MC MP4 has had render times in some settings around 20 hours. The Sony MP4 codec under certain circumstances saves us up to 70% of the time with the same quality. I find that MC is slow on 2 of our office machines so we switched awhile ago to the Sony. Now a 3 hour video renders in about 5 to 6 hours.

Thanks
Michael
Just Rite Productions