I am quite sure it is a CUDA issue with the 4K files. I doubt that the MC AVC encoder was/is actually written for that resolution and GPU acceleration. Keep in mind that it isn't written by SCS but by Mainconcept. Baseline or Main won't make much of difference in render times for 320p. I doubt a 280 is any better because it would again be encoded by the same Mainconcept encoder. You should definitely drop the 32bit down to 8bit. Handbrake can do multiple renders too but I don't think it can do scripts. Anyway, as long as you watch the downscaled video on a small device it won't be noticeable whether it was done straight from VP or with HB. How would you deliver the 4K files and what would it be watched on?

All video files are delivered on my websites, they are websites where people sign up and can stream or download videos. I have full control over the delivery path since I wrote all the websites which is great because I'm not bound by limitations others are saddled with like Youtube limits or whatever, hence why I can transition to 4k right away. Customer hardware varies from laptops to pc's to tablets to phones to tv devices, you name it. The low quality 320x180 version is the baseline version meant to work on the crappiest phones out there running on the crappiest cell networks. It has to be baseline because in my tests there were many old phones that were only able to play videos in baseline profile and would fail if the video was main or high profile. The 1280x720 versions are decent quality versions that work on most anything modern and can be streamed or downloaded, I make WMV and MP4 versions of those. And the 4k version is meant to be download only, offering the best possible quality for those with displays > 1920x1080 which is becoming much more common nowadays, at least with my customers anyways. So in summary a customer can watch the 320x180 version if they are on a phone or on a really crappy network connection, watch either 1280x720 version to stream on most any device with good quality, and save the large 4k version if they want to keep a pristine quality version of a given video.

It's a shame that cuda 4k mc support may be broken :( That means that getting a fermi card is probably pointless for me. I may try an amd card but as you say there is a good chance that will be broken as well, unless their opencl support is more complete I suppose. I may end up just suffering with 2 day renders for now until 8 core haswell-e comes out, then switch out to that. In theory that could cut down my render times to 1 day...in theory. Or maybe Sony will get more broad in their gpu encoding support. One can dream I suppose.

I will say the cpu based MC AVC 4k encodes look really nice! I started rendering a shoot on Friday and it's about half way done so I've been able to watch some of the videos, and the quality is quite nice. Likewise with the AX100, I've used it on two shoots so far and I have to say there is simply no going back, I'm 4k all the way now. That camera really produces stunning quality footage for the price

Pete,

I downloaded your project and I had to set the project properties to 8-bit as well. 32-bit was taking significantly longer to render and your footage isn't 10-bit anyway so there is no need for it.

Here are my render times:

1:45 rendering to 3840 x 2160 MC AVC
0:22 rendering to 1280 x 720 MC AVC
0:19 rendering to 320 x 180 MC AVC

I created the templates exactly as you had in your screen shots. Everything was an exact match with no deviations.

That's using my 2008 Mac Pro Xeon E5462 2.80Ghz 8-Core, 16GB memory, ATI Radeon HD 5870, with Bootcamp Windows 7 Pro 64-bit (that I picked up on eBay for $740) and Vegas Pro 13.0. (Not bad for a 5 year old computer!) ;-)

During the render, the 8-cores were at about 35% and the Radeon HD 5870 was pushing 86%. This says to me that that the cores might not be as significant as the GPU for MainConcept AVC.

~jr

Thanks Johnny! One question for you and Smoke, when you guys switch to 8 bit does the video become milky? When I switch from 32bit to 8 bit the video loses much of it's contrast, blacks become grey, etc, it looks bad to be honest. Are you guys seeing this or is there an extra conversion step you guys take to fix this? I presume this is happening because on 8 bit it's not showing the full 0 to 255 range for whatever reason, but I don't know how to fix that.

Another question, I read elsewhere that using 8 bit is ok if you don't do color correction or apply other effects. But if you apply other effects then it's better to switch to 32 bit even when using an 8 bit camera like mine. The explanation I got was that it's better to convert the 8 bit camera footage to 32 bit space, and then let the nle do all it's subsequent math in 32 bit like adding visual effects, color correction, etc. You guys think that's true?

EDIT: Oh one more question for you Johnny, so it looks like you were able to get gpu assist on MC AVC encode at 4k? If true that's good news, it means that opencl gpu assist works for 4k!

> "One question for you and Smoke, when you guys switch to 8 bit does the video become milky? When I switch from 32bit to 8 bit the video loses much of it's contrast, blacks become grey, etc, it looks bad to be honest. Are you guys seeing this or is there an extra conversion step you guys take to fix this? I presume this is happening because on 8 bit it's not showing the full 0 to 255 range for whatever reason, but I don't know how to fix that."

The reason is because 0 - 255 is not legal for video. Only 16 - 235 is legal for video. You fix it using Levels and Color Curves.

This isn't because you switched from 8-bit to 32-bit either... it's because when you switched to 32-bit, you mistakenly selected a compositing gamma of 1.000 (Full range) instead of 2.222 (Video). So you artificially expanded the blacks and whites without knowing it. If you correctly select a compositing gamma of 2.222 (Video), you video will be shown with the correct gamma for the footage you shot. If you want it to have more contrast, feel free to color correct it any way you want, but changing the gamma in the project properties is like adjusting the gamma of an image in Photoshop; i.e., that's not what the photo really looks like, it's just how you told Photoshop to interpret it.

BTW, your video was way outside the legal range limits. Open the Video Scopes and take a look. Your whites are way above 100 and blacks are way below 0. You're going to need to correct this anyway although if you are making videos for small cell phones you and your customers might not care if the video is broadcast legal. Personally, I make all of my videos broadcast legal and use Color Curves to correct the look to give it the curve that I like.

> "Another question, I read elsewhere that using 8 bit is ok if you don't do color correction or apply other effects. But if you apply other effects then it's better to switch to 32 bit even when using an 8 bit camera like mine. The explanation I got was that it's better to convert the 8 bit camera footage to 32 bit space, and then let the nle do all it's subsequent math in 32 bit like adding visual effects, color correction, etc. You guys think that's true?"

This is what I call a "half-truth" because taken out of context it can't be disputed but when put it into context it might not be true.

32-bit floating point (video levels) is recommended when working with 10-bit YUV or when using xvYCC/x.v.Color media. You are using neither. It can also prevent banding from compositing that contains fades, feathered edges, or gradients especially with Generated Media. Do you have this problem? If not, there is no need to use it. So unless you have footage that can benefit from it, or a problem that it fixes, it does not make sense to use the 32-bit floating point with an 8-bit camera any more than it makes sense to put premium gas in a car that takes regular gas just because premium gas is better.

Having said that... the answer to the question "Does 32-bit floating point give greater accuracy?" is definitely yes. That's leads some people to suggest that you should always use it but let me give you a similar scenario:

Your AX100 camera shoots 120fps. 120fps is clearly better than 30fps or 60fps right? I mean the movement is going to be so much smoother right? So why not shoot a wedding video of two people standing at the altar almost motionless at 120fps? It's gotta be better right? Yea, but at the same time it's overkill. Sony warns that "The 32-bit floating point settings allow greater precision for processing video, but require significantly more processing power than working with 8-bit video.". Why would you use something that requires "significantly more processing power" when it's giving you no benefit and it already takes too long to render? It doesn't make sense. Sometimes turning every knob up to 10 isn't the best solution. (11 is another story... lol). ;-)

> "EDIT: Oh one more question for you Johnny, so it looks like you were able to get gpu assist on MC AVC encode at 4k? If true that's good news, it means that opencl gpu assist works for 4k!"

Yes, it seemed to be quite happy to use my GPU. I'm convinced that ATI cards perform much better for Vegas Pro than NVIDIA cards do because they implemented OpenCL much better than NVIDIA who only cares about their proprietary CUDA technology.

BTW, Windows Media Player could not play the 4K MP4 files from Vegas Pro or the original file for that matter, but QuickTime Player could play them although it was a slide show on my Bootcamp partition with Windows. It played very smoothly on Mac OS X partition (both the source and the render). I'll have to test with my other Windows workstation and see if I get similar results.

~jr

> " I'll have to test with my other Windows workstation and see if I get similar results."

OK, I ran the same tests on my Windows Workstation which is:

Intel Core i7-3930K 3.2GHz 6-Core, 16GB Memory, NVIDIA Quadro 4000.

Here are my render times with Vegas Pro 12.0:

1:26 rendering to 3840 x 2160 MC AVC
0:26 rendering to 1280 x 720 MC AVC
0:17 rendering to 320 x 180 MC AVC

So this is a 6-core with a higher clock speed and it did render a little faster for 4K and 180 but slower for 720 (strange)

I did notice a huge difference in quality between the CUDA render and CPU render with the CPU render being perfect and the CUDA render having all sorts of compression artifacts. I'm not sure what's going on there. Maybe this is why the default in the templates provided by Sony is CPU Only? :(

~jr

I re-rendered the 4K MC AVC again but this time with CPU Only. The result is still far behind a 10Mbps out of HB. To be honest, if you would offer this as a downloadable version I would want my money back.

I am previewing it on a 23" 1920x1080 monitor as well as on a 32" HDTV. In both I can see allot of blocky areas where the codec just falls apart. It is most apparent in the brown tall flower container on the right. Even 32bit didn't make any difference.

As I mentioned earlier, you may want to rethink your delivery and try HB; it gives much better results at a lower bit rate. It does have a command line interface too and maybe you can get the same automation done. If so, I would only make a master render out of VP with XAVC-S and bring that into HB. If HB could do frame serving that would be even better.

I stopped using GPU rendering because of artifacts. CPU rendering does not have this major problem. I eat the render time because quality is extremely important to me.

The title of this thread is misleading. It appears to me sony will never get it together.

Thanks again guys for taking time to reply! I'll reply generally below:

"The reason is because 0 - 255 is not legal for video. Only 16 - 235 is legal for video. You fix it using Levels and Color Curves."

Does that still apply if the videos will only be watched on computer devices? I'm not much concerned about normal tv broadcasting since that's not where my audience is, they all mostly use laptops, tablets and phones.

"This isn't because you switched from 8-bit to 32-bit either... it's because when you switched to 32-bit, you mistakenly selected a compositing gamma of 1.000 (Full range) instead of 2.222 (Video). So you artificially expanded the blacks and whites without knowing it. If you correctly select a compositing gamma of 2.222 (Video), you video will be shown with the correct gamma for the footage you shot. "

See on my machine that doesn't make any difference at all. Basically in 32 bit mode if I set compositing gamma to 1.000 or 2.222, the video in the preview looks identical, no change whatsoever. What does change with each gamma setting in 32 bit mode is how effects are applied, those definitely change how they are composited on the scene. But the stock video in 32 bit mode looks identical with 1.000 gamma or 2.222 gamma. Switching to 8 bit ruins the footage for me, it actually end up not looking like what it really does. I own the film location so I sat there and compared 32 bit 1.000/2.222 to 8 bit, and both 32 bit modes looked accurate to what I was physically seeing whereas 8 bit mode looked as if there was a fog machine in the room, it just wasn't accurate. Hmm, very strange how we're seeing different results! Not really sure what's up here.

"BTW, your video was way outside the legal range limits. Open the Video Scopes and take a look. Your whites are way above 100 and blacks are way below 0. You're going to need to correct this anyway although if you are making videos for small cell phones you and your customers might not care if the video is broadcast legal. Personally, I make all of my videos broadcast legal and use Color Curves to correct the look to give it the curve that I like."

Yeah I don't worry about broadcast legal, all my business is done on the internet on computers so I don't really need to worry about any of that.

"This is what I call a "half-truth" because taken out of context it can't be disputed but when put it into context it might not be true."

Ok I see what you mean, I figured in my case since my renders happened overnight and were always complete when I'd wake up, then why not leave it at 32 bit to be safe and not worry about it. It's only become an issue now in 4k because render time has grown dramatically.

"Yes, it seemed to be quite happy to use my GPU. I'm convinced that ATI cards perform much better for Vegas Pro than NVIDIA cards do because they implemented OpenCL much better than NVIDIA who only cares about their proprietary CUDA technology. "

Interesting, ok I may go try an amd card. I did notice that Sony seems to be emphasizing opencl more this time around, so maybe that's where they are putting more of their tine and testing as well.

"BTW, Windows Media Player could not play the 4K MP4 files from Vegas Pro or the original file for that matter, but QuickTime Player could play them although it was a slide show on my Bootcamp partition with Windows. It played very smoothly on Mac OS X partition (both the source and the render). I'll have to test with my other Windows workstation and see if I get similar results."

Funky, for me Windows Media Player is the best player because it fully supports the hardware. For example I had a lowly Mac Air with HD5000 gpu on Windows 8.1 that could play my 4k raw source footage at full frame rate with Windows Media Player without breaking a sweat, the fans wouldn't even kick up. If I used a 3rd party media player then it played like crap and the fans would max out. My new Macbook Pro with Windows 8.1 plays my 4k videos no problem as well.

"I did notice a huge difference in quality between the CUDA render and CPU render with the CPU render being perfect and the CUDA render having all sorts of compression artifacts. I'm not sure what's going on there. Maybe this is why the default in the templates provided by Sony is CPU Only? :("

Seems to mimic what Smoke said. Maybe Cuda support is just fubar'd. Comparing amd opencl to cpu encoding did you notice any major differences?

"I re-rendered the 4K MC AVC again but this time with CPU Only. The result is still far behind a 10Mbps out of HB. To be honest, if you would offer this as a downloadable version I would want my money back.

I am previewing it on a 23" 1920x1080 monitor as well as on a 32" HDTV. In both I can see allot of blocky areas where the codec just falls apart. It is most apparent in the brown tall flower container on the right. Even 32bit didn't make any difference."

Interesting, I'm viewing them on a 2560x1600 30" pc monitor as well as a 65" 1920x1080 tv and they look really good to me, far beyond what say my DirecTV tv provides me quality wise. Maybe you're more sensitive to artifacts than I am? Mind you to be honest I'm mostly looking at my shoot footage which was filmed indoors, the test footage that I gave you guys was outside with lots of fine edges and other organic details, maybe that's why it fell apart as perhaps 28mbps isn't enough for that. My indoor shoot footage that has more flat colored walls and stuff like that, that looks really good. There are artifacts of course, I can't go crazy on bitrate otherwise it will smash my poor webservers, but it still looks pretty good overall I think. I will try some encodes at 50mbps just to see how much better they look and how much file sizes change.

> "Does that still apply if the videos will only be watched on computer devices? I'm not much concerned about normal tv broadcasting since that's not where my audience is, they all mostly use laptops, tablets and phones."

While computer devices support 0 - 255, many media players wrongly assume that all video is 16-235 and then expand the luminance. If you feed a media player that is expecting 16-235 a video that is 0-255 it will bow out the whites and crush the blacks and you may even get solid colors where detail use to be. So while I agree that it shouldn't matter on a computer, it often does because of the way media players are written. If it looks good to you when you check it on other devices, then that's all that really matters. If it looks darker, then the media player is expanding your luminance levels.

> "See on my machine that doesn't make any difference at all. Basically in 32 bit mode if I set compositing gamma to 1.000 or 2.222, the video in the preview looks identical, no change whatsoever. "

Sorry for not being more clear. You need to toggle between "32-bit floating point (video levels)" and "32-bit floating point (full range)". Just flipping the gamma doesn't show a difference (not sure why... maybe a bug?).

> "Funky, for me Windows Media Player is the best player because it fully supports the hardware. For example I had a lowly Mac Air with HD5000 gpu on Windows 8.1 that could play my 4k raw source footage at full frame rate with Windows Media Player without breaking a sweat, the fans wouldn't even kick up."

I was using Windows 7. Perhaps Windows 8 contains the needed codecs. When I said it couldn't play the video I meant that there was absolutely no video! The Windows Media Player in Windows 7 doesn't play the 4K video. Not the source file or the render. That means you'll need to tell your customers that they must be on Windows 8 if they want to watch the 4K video or not to use Windows Media Player on earlier versions. (it also works on Mac OS X, just not Windows 7)

> "Seems to mimic what Smoke said. Maybe Cuda support is just fubar'd. Comparing amd opencl to cpu encoding did you notice any major differences?"

It was messed up with OpenCL as well but only for the 4K render. The other renders were fine with CPU being slightly better but on the 4K it was very noticeable. This doesn't surprise me since 4K didn't exist when MainConcept developed that encoder. With Sony's big push for 4K at NAB, I'm sure if 4K worked flawlessly with the MainConcept AVC encoder, Sony would have created templates for it.

~jr

"Sorry for not being more clear. You need to toggle between "32-bit floating point (video levels)" and "32-bit floating point (full range)". Just flipping the gamma doesn't show a difference (not sure why... maybe a bug?). "

Ah you're right, I see it now as well.

"It was messed up with OpenCL as well but only for the 4K render. The other renders were fine with CPU being slightly better but on the 4K it was very noticeable. This doesn't surprise me since 4K didn't exist when MainConcept developed that encoder. With Sony's big push for 4K at NAB, I'm sure if 4K worked flawlessly with the MainConcept AVC encoder, Sony would have created templates for it."

Ok well that means no more gpu acceleration for me I guess :( I think I'll take yours and Smoke's advice and try out 8 bit. Maybe the 32 bit look I was seeing wasn't right, but I was just used to that contrasty look. That would also explain why my video levels are off in 32 bit mode on the scopes, I bet they will be in range when I set it to 8 bit. I'll toy around with it, thanks guys.