Thinking about MUD

Tim Joy

Veteran
I was out doing some steady-cam testing today with the cam and had a little inspiration.

Since I didn't want to bother shooting manually, I put the cam in Ai mode and let it do all the adjustments... well, it was VERY muddy. Granted, I was around lots of high detail trees and grass, and moving of course.. but it got me thinking-
how much processor power is it using to: Autofocus, Auto-expose, Auto WB, recognize faces, and whatever else it's doing? And- is that processing taking away horsepower from the processing of the video to AVCHD?

If so, maybe by turning off any feature that uses processor power, it would help the mud issue a little? ??

Hmmmm...:huh:
 
time for a test, tim. one pass on full auto and an identical pass on full manual. would love to see it.
 
Would that effect the bitrate the codec is recorded at? Would it show up in Final Cut Pro after log and transfer where it shows the bitrate in the clip info?
 
I was out doing some steady-cam testing today with the cam and had a little inspiration.

Since I didn't want to bother shooting manually, I put the cam in Ai mode and let it do all the adjustments... well, it was VERY muddy. Granted, I was around lots of high detail trees and grass, and moving of course.. but it got me thinking-
how much processor power is it using to: Autofocus, Auto-expose, Auto WB, recognize faces, and whatever else it's doing? And- is that processing taking away horsepower from the processing of the video to AVCHD?

If so, maybe by turning off any feature that uses processor power, it would help the mud issue a little? ??

Hmmmm...:huh:

Could also explain why the camera seems to perform better sans kit lens. Even with all of the controls off, the camera still communicates with the kit lens. So you'd have to add a third parameter to the test. All shooting the same exact shot, motion, at the same exact stop.

Kit Lens Auto
Kit Lens Non-Auto
Nikon Lens

I wonder what else you can turn off on the camera to make it look better? You think it takes more power to power the LCD versus the EVF?
 
I wonder what else you can turn off on the camera to make it look better? You think it takes more power to power the LCD versus the EVF?

I am sure the power being used tops out at some quality level and if it drops only drops when you're doing stuff, but doesn't get better past a certain point that is probably where we're at most of the time.

In any case I'd say the LCD uses more electrical power but less processing power (lower resolution than viewfinder.) if at all.

Set all film mode stuff to 0? That causes problems when looking at final image though because it affects the image.

Set sound recording levels to 0? OH WAIT! lol.
 
Could this explain why the 14-140 tests so well in static tests but does not look good on video tests? All the great footage i have seen was done with primes and they are better than the difference in lens quality would predict.
 
I was out doing some steady-cam testing today with the cam and had a little inspiration.

Since I didn't want to bother shooting manually, I put the cam in Ai mode and let it do all the adjustments... well, it was VERY muddy. Granted, I was around lots of high detail trees and grass, and moving of course.. but it got me thinking-
how much processor power is it using to: Autofocus, Auto-expose, Auto WB, recognize faces, and whatever else it's doing? And- is that processing taking away horsepower from the processing of the video to AVCHD?

If so, maybe by turning off any feature that uses processor power, it would help the mud issue a little? ??

Hmmmm...:huh:

I think you are onto something
 
As a programmer, but not a camera expert, I can guess it is very unlikely any of these things affect the encoding process in the way you are thinking of. Its not as if something is straining the cpu and taking time away from encoding, if that was the case then there would be total drop outs. The CPU does inherently have some limit to what it can encode, but that is known factor that is dealt with by the code in the firmware. Its conceivable that the CPU could handle encoding at 40mbps but the firmware says to only do 17.

Different lenses and everything else involved in different scenes could affect the amount of mud but that is another matter entirely.
 
Ilya Friedman (by way on Daniel Drasin on the CML-HD-Prosumer list) has said the following about the kit lens and its impact on the GH1's compression:

Illya points out that the kit lenses are constantly feeding data to the camera (involving processing for CA, barrel & pincushion distortion and so forth), which loads down the CPU, so the camera compensates by reducing its compression quality.

Use "dumb" lenses with an adaptor (Nikon, Leica, PL...) and the problem goes away.

You really have to watch the DCS video of Illya's talk. I shot and cut it, but will be handing it off to Simon Sommerfeld later in the week for some final touches and for posting on the DCS website. So hopefully it will be up by the end of the week or thereabouts. Two excellent presentations on the Canon 5DM2 (by Canon's Tim Smith and our very own Art Adams) will also be posted at about the same time.

I haven't been able to track down the DCS video of Ilya's talk yet but it sounds like we're discovering the same phenomenon here.
 
Only some level-playing-field tests would help with proving/disproving this theory. As I recall it there are two processors in the GH1 - for all we know one handles the encoding and the other the rest of the stuff and so there would be no effect by one on the other. Or not.
 
Then a simple firmware hack, or blocking the proper contacts, will boost bit rate
at the expense of uncorrected distortion and CA. Or just go Zeiss Prime if you have an inheritance.
 
This should be pretty easy to prove/disprove. Take the file size of a raw from the camera MTS file and divide by the length of time. Doing this on 9 MTS files I recorded this afternoon using Vegas's explorer to report both the file size (in megabytes) and the animation length I end up with an average of 1.813 mb/sec. Those are 1080p files, raw from the camera. Doing the same with 720p files I end up with an average of 1.793 mb/sec. This is all with the kit lens. The highest file was 1.86, the lowest 1.64.

If a non-kit lens really is doing a better job it will have a much larger file size to time ratio. Ideally you would want to record something heavy with motion and details with both a kit and non-kit lens. But if the theory has any weight it should be clear from just a sampling of files.
 
This should be pretty easy to prove/disprove. Take the file size of a raw from the camera MTS file and divide by the length of time. Doing this on 9 MTS files I recorded this afternoon using Vegas's explorer to report both the file size (in megabytes) and the animation length I end up with an average of 1.813 mb/sec. Those are 1080p files, raw from the camera. Doing the same with 720p files I end up with an average of 1.793 mb/sec. This is all with the kit lens. The highest file was 1.86, the lowest 1.64.

If a non-kit lens really is doing a better job it will have a much larger file size to time ratio. Ideally you would want to record something heavy with motion and details with both a kit and non-kit lens. But if the theory has any weight it should be clear from just a sampling of files.

I think bit rate isn't the whole story - it's what the camera is doing with those bits that counts.

Yes, i agree. Not all equal bit-rates are created equal. That's why they have multi-million dollar mpeg2 encoders for high-end DVD authoring. They might end up with the same bit-rate as you might with Compressor, but the resulting image is quite different.

Often times, I will see just a few frames of mud, as in, "whoops, I don't have time or the power to properly process this frame, so here's a little taste and we'll just move on.."

When I say power, I mean processor power, not electrical power. I don't think it's an issue of juice flowing to other things (like the LCD), but I'm still open to any possibility.

I'm not sure how a true scientific test could be done, because there would be so many variables. Also, if it's true that other processing affects mud, it might be at its worst in Ai mode, with all the bells and whistles running, but be imperceptibly different in a manual mode as to not be a factor.

Rawdod has a good point, from a programming POV. BUT, we don't have a live video out supposedly because of a lack of processor power. Could they have knowingly cut corners in other ways in order to have all the extra 'consumer' functions at the expense of video quality? Probably figuring the average Joe wouldn't notice this?
 
As a programmer, but not a camera expert, I can guess it is very unlikely any of these things affect the encoding process in the way you are thinking of. Its not as if something is straining the cpu and taking time away from encoding, if that was the case then there would be total drop outs. The CPU does inherently have some limit to what it can encode, but that is known factor that is dealt with by the code in the firmware. Its conceivable that the CPU could handle encoding at 40mbps but the firmware says to only do 17.

Different lenses and everything else involved in different scenes could affect the amount of mud but that is another matter entirely.

I would tend to agree. The camera may even use a separate processor for such calculations but even if it didn't, the calculations being performed by AI shouldn't be very processor intensive. One way to find out: test mud in full manual versus full AI.

Mike
 
Yes, i agree. Not all equal bit-rates are created equal. That's why they have multi-million dollar mpeg2 encoders for high-end DVD authoring. They might end up with the same bit-rate as you might with Compressor, but the resulting image is quite different.


Hello Tim,

I've never heard about such a thing as multi-million dollar mpeg2 encoders for high end DVD authoring.

Can you please post a link to such thing.
 
Back
Top