8c render errors with avc rendering

farss wrote on 3/5/2009, 11:08 PM

"Anybody else seeing this."

No but I'd suggest you try to wrangle whatever is causing the pixelation in the low lights before it gets to an encoder. I know that's not easy to damn impossible without causing other problems but it's worth a shot.
Reason I say this is if you don't get rid of it it can come back again. Some displays make noise look significantly worse than it really is, some decoders in some set top boxes also seem not so good as well.
Best solution I've found in general is to slightly underexpose thereby pushing the image more into the blacks and then crush the blacks just a tad in post using a color curve. Then I'm left with a much less noisy image that will withstand a lot of compression as the noise in the blacks is not using up so much of the bandwith. Of course this might not work for you, it works for me because a lot of what I shoot has a lot black in it anyway.

Bob.

blink3times wrote on 3/6/2009, 3:01 AM

"No but I'd suggest you try to wrangle whatever is causing the pixelation in the low lights before it gets to an encoder. "

There is no pixelation what so ever on the original footage and I'm not adding effects of any kind... just popping the sample on the time line and rendering. In other words the pixelation is being generated by the encoder itself.

farss wrote on 3/6/2009, 3:57 AM

"In other words the pixelation is being generated by the encoder itself. "

Yes, indeed. The question is what is making it do that.
I would bet on the cause of it being noise. Remove / reduce the noise and goodbye pixelation.
The HD palmcorders are notorious for being noisy in low light, out of the camera the image might look quite good but try encoding the video a second time and the noise will become much more noticeable.

Bob.

blink3times wrote on 3/6/2009, 4:20 AM

Interesting.

I try to add a guassian blur to try and blend some of the noise that may be causing the problem.... and it just crashes..... incomplete render

Working with this avc just simply sucks.

If I render the clip over to mpeg2... NONE of these problems seem to exist. I think that's the route I will go. I can only get just a wee bit less than 2 hours on a BD with mpeg.... but it's MUCH more solid to work with.

Xander wrote on 3/6/2009, 5:17 AM

The couple of times I have tried rendering to AVCDHD, Vegas has either crashed or I have see some undesirable artifacts. If I think about it, I saw these artifacts in a fade from black at the beginning of a video or crossfades between clips.

Anyways, I don't bother rendering to AVCDHD. Now that I have NeoScene, I will render to a Cineform AVI and then convert that to MPEG-2 or other formats. AVCHD just takes too long to render in general.

In terms of workflow, I will CC my Canon HF11 footage in AE and render to Cineform AVI and work with those in Vegas. Most, but not all of my problems, have been cleared up this way.

blink3times wrote on 3/6/2009, 6:22 AM

Yeah... The artifacting is really quite bad in lower light shots....Cineform is a definite fix to the problem. I'm not sure it's needed though. As I said if you render your avc time line over to mpeg2 as a final output the artifacting and crashing no longer exists. The only problem with that is that you won't get as much on a disk wth mpeg2.

I'll do some comparisons with cineform and mpeg2 later on this evening

tumbleweed7 wrote on 3/6/2009, 9:31 AM

I'm not seeing the issues that you're having....

1... using the Sony AVC template, you I don't see how you can get more than the 16Mbps it allows....

2... My render to the Sony AVC, with a light gausian blur, does not crash or pixelate...

3... I'm using an original Pana AVCHD 1920 x 1080 17Mbps file on the timeline... using the Pana software to import to PC....????

something else is probably going on... maybe how you're importing the file?....

blink3times wrote on 3/6/2009, 10:30 AM

"1... using the Sony AVC template, you I don't see how you can get more than the 16Mbps it allows..."
But that's what I saying...you can't go past 16 in 8c with 1920 (in 8.1 you can render to 50 and beyond....without issues.... but there are similar artifact problems with low light footage)

"3... I'm using an original Pana AVCHD 1920 x 1080 17Mbps file on the timeline... using the Pana software to import to PC....????"
I'm using original sony SR11 footage simply dragged to the time line. I'm seeing bad artifacts, xander sees it... as well as a another person on the AVS forum with a Canon cam

Brad C. wrote on 3/6/2009, 10:45 AM

I never had bad artifacting with my HF10 on the timeline whatsoever when dealing with the raw .mts files out of the camera.

teaktart wrote on 3/6/2009, 11:22 AM

I tried twice to render a 30 min CFDI project to AVCHD output and it crashed my V8c about half way thru the render both times. It just won't do it on my quad core.
Never got to see the quality....

blink3times wrote on 3/6/2009, 11:46 AM

I'm seeing no issues when converting over to cineform avi. No crashing... no artifacts. No issues either when render out as mpeg2 so this HAS to have something to to with the sony avc render codec

tumbleweed7 wrote on 3/6/2009, 3:17 PM

sounds as if you found a workflow that works for you.. good work...

blink3times wrote on 3/6/2009, 4:13 PM

"sounds as if you found a workflow that works for you.. good work..."

Yeah... a couple of them.

I'm just astounded over this entire avchd thing though. It's a real step BACKWARDS from what we have now in terms of quality, speed and ease (relative to the mpeg2 codec).

As I compare the footage coming out of my HV20, HC3 (both HDV) with that of my new SR11, the only advantages of the SR11 has to do with the hard drive and how handy that technology can be. The avchd codec/format.... what a leap back in time! Any savings in time that the easy off-loading of video from the cam presents is chewed up by the now bloated and complicated workflow as compared to HDV and mpeg.

As for the quality comparison between avchd (at 16Mb/s anyway) and HDV.... in full light the quality is almost even (which I think in itself is a little sad since I'm comparing 1920 to 1440). But as soon as you start panning with the SR11 it becomes a dead give-away... the avchd starts breaking up MUCH worse than HDV/mpeg ever did. When you pan with avchd it's almost like looking at the rather stuttery quality of 24p

Brad C. wrote on 3/6/2009, 5:10 PM

blink- what are your exact settings for the mpeg2 render (if I may ask)?

blink3times wrote on 3/6/2009, 7:02 PM

I'm using the standard mpeg2 blu ray template (1920x1080 60i), vbr encoding 20/25/30. The only change I'm making is bumping up the quality slider to full.

Brad C. wrote on 3/7/2009, 12:28 AM

Ah ok. So you just leave it as an .m2v then.

I've been rendering everything to 720p anyway, so that's why I'm not experiencing the issues. Any artifacting/pixelation (which I don't even see in .mts form on the timeline) is probably taken care of in the downconversion.

Most of my stuff hits the net or for wedding DVD's (which my clients thus far could care less about "1080p"). Heck most of them don't even care about HD period. Really great looking SD in 16:9 is fine with them, but if I cut anything HD for them, it will be 720p.
MainConcept AVC/AAC, Best, 1280x720, Constant 14-Mbps, 128kbps

blink3times wrote on 3/7/2009, 4:03 AM

Well I think to a certain extent Bob above is correct.

The artifacting is only occurring in the low light situations and this SR11 cam is just simply not as good as my HDV cams in low light. There is a lot more noise produced. The avc renders though seem to be amplifying the noise somehow whereas the mpeg2 renders don't. In full light shots the avc renders are NOT producing any artifacting/pixelation.

farss wrote on 3/7/2009, 5:12 AM

Even in full sunlight the EX1 produces noise however it's very fine grained and pretty much confined to the blue channel e.g. the sky. It doesn't seem to stress out any encoder that I've noticed so it doesn't appear to get any worse.

The problem with all the smaller cameras with single sensors is the noise blocks are bigger and that does seem to stress encoders and the noise gets more noticeable at every encoding step. I'd also imagine the smaller cameras lack the better signal processing of the bigger ones and that doesn't help either. Part of the reason for this is to keep battery drain at levels where smaller batteries can be used.

If you want stellar low light performance in HD you need very deep pockets. It starts with optics that suck in more photons and that alone costs big time.

Bob.

Brad C. wrote on 3/7/2009, 7:22 AM

Bob, it's funny you mention the noisy blue channel because I've noticed that about EVERY Sony cam that I've ever seen footage from. Everything from the TG1 to the FX1/Z1
I didn't think it would happen with a $6,000 Sony though.

Interesting. I think Sony's "blue" offers a much better, and truer hue than the others, but the graininess always confused me.

farss wrote on 3/7/2009, 12:21 PM

It's just the nature of silicon. It's most sensitive to infrared at around 1,000nm so the blue channel will always be the noisiest.
Perhaps Sony are using different dyes on their blue photosites meaning they need more gain in the blue channel compared to other cameras which would be how they achieve better looking blues. Noise in the blue channel is a common complaint even in non Sony cameras costing a lot more than $6,000.

Bob.

Brad C. wrote on 3/7/2009, 5:01 PM

Always a fountain of knowledge. Thanks Bob.