MPEG Streamclip quality comparison

Lucas 7D

Lucas 7D

Active member
Hi guys

So i converted a clip with streamclip using DNxHD codec setting 1080p 23.97 10-bit and it seems to look a bit faded compared to the original. It still isn't smooth in Premiere CS4. I found that if you drop the 7D original clips on the premiere timeline and render timeline, the footage runs smooth on my Quad core 2.4 ghz. Can i just render time line and work with originals or am I getting a quality hit once i color grade?

The first photo is the original and second photo is the streamclip conversion.

original.JPG

compressed.JPG
 
I notice the same thing when I convert using MPEGstreamclip too. I'm editing in FCP and convert to either XDCAM EX or ProRes. Many times I think it helps the crushed look of the originals! It seems like a gamma shift.
 
Lucas, I went into detail on this over on the other forum. But your camera can record both color and luminance levels that are not legal for broadcast. Your computer montitor can display those levels, however a TV cannot.

Please do not judge color and luminance by looking at your computer monitor.
 
I can confirm this behaviour in PP CS4 on Windows, I believe it's the way PP decodes the clips

Open up the reference monitor, and look at the scopes, the YC Waveform. The native footage will read ~0-100 IRE , but the DNxHD footage will be clamped from ~7.5-90

It doesn't matter whether the DNxHD conversion was done in AME, or MPEGStreamClip, I tested them both. The DNxHD version I used was 2.1, and I tested both RGB and BT.709 variants
 
PDR, that's odd. When I did my conversions in Mpeg Streamclip from the 5D footage to DNxHD, I did not get the 7.5 IRE clamp. What I did get was blocky blacks as though the conversion was done at a very low bit rate. I've got some footage right here in front of me. I may give this a whirl real quick to verify.

[edit]

Yep, just did a short clip that ranged from -6 to +108 or so on the scopes. The DNxHD 175 transcode is locked from 0-100.
 
Last edited:
Perrone - I saw your other thread too
http://www.dvxuser.com/V6/showthread.php?t=193226

There's definitely some quirks happening here. And I want to figure out whats going on. What other application are you using to encode to DNxHD ? What version of DNxHD were you using?

PP seems to clamp superwhites & superdarks either way with anything wrapped in .mov container (at least on PC platform) . 0-100 IRE (or 16-235). Even re-wrapping the native .mov footage in .mp4 lets you recover those ranges <0 or >100 (or 0-255). This is one of those quirks. Some people like having the full range to color correct, then rescaling back down to legal range when exporting. Some cameras don't even shoot in those ranges, but the 7D definitely does
 
Adobe has several times in the past managed to mess up between 0-255 and 16-237 gamma ranges in both After Effects and Premiere on different codecs depending on Preference settings - especially with Colour Manglement.
 
I can confirm the luminance clamp is also present in DNxHD imported footage into After Effects. But no evidence of gamma shift

Martti - what preference settings specifically in PP? I'm aware of the color working spaces and color management in AE
 
PDR said:
Perrone - I saw your other thread too
http://www.dvxuser.com/V6/showthread.php?t=193226

There's definitely some quirks happening here. And I want to figure out whats going on. What other application are you using to encode to DNxHD ? What version of DNxHD were you using?

PP seems to clamp superwhites & superdarks either way with anything wrapped in .mov container (at least on PC platform) . 0-100 IRE (or 16-235). Even re-wrapping the native .mov footage in .mp4 lets you recover those ranges <0 or >100 (or 0-255). This is one of those quirks. Some people like having the full range to color correct, then rescaling back down to legal range when exporting. Some cameras don't even shoot in those ranges, but the 7D definitely does
Click to expand...

I am doing the normal conversion from inside Sony Vegas. When doing that, I get no shift at all, so it's not the codec that's at fault. I am using the latest version of DNxHD. The VC-3 compliant one.

The EX1 definitely shoots into the superblacks and the superwhites if you let it. And I do.
 
PerroneFord said:
I am doing the normal conversion from inside Sony Vegas. When doing that, I get no shift at all, so it's not the codec that's at fault. I am using the latest version of DNxHD. The VC-3 compliant one.

The EX1 definitely shoots into the superblacks and the superwhites if you let it. And I do.
Click to expand...


Perrone, if I'm not mistaken the VC-3 version from ffmpeg is 8-bit only?

Are you saying DNxHD encoded from Vegas also exhibit this behaviour in PP CS4?

What about DNxHD footage in Vegas? did you check the scopes/levels out there? (I can do this in a bit, but my computer that has vegas installed is rendering currently)
 
You are misunderstanding me. I downloaded the VC-3 compatible DNxHD codec from Avid. Their earlier public offerings were not VC-3 compliant.

DNxHD encoded from Vegas does not show the clamping. This leads me to believe that the fault lies elsewhere. I do not have PP CS4 so I cannot tell you what happens in that.
 
OK thx Perrone, that clarifies things

So when my other rig is done rendering, I will try a Vegas encoded DNxHD and test the scopes out in both PP and Vegas, but so far both AME and MPEGStreamClip encoded files exhibit this behaviour

The Avid DNxHD codec I'm using is v2.1, perhaps you are using a different build?
 
When you go to configure the DNxHD settings, the dialog box that pops up will tell you the version in the box heading . e.g. "AVID DNxHD Configuration Codec - v.2.1.0"
 
Also, what project settings are you using in vegas? e.g. 8-bit , 32-bit, linear 1.0 gamma etc... video levels vs. full range etc..

I think if you just lay the clips on the timeline, they will be interpreted by vegas by whatever settings you used and transfer those to the exported render
 
Last edited:
I always use 32bit full range, linear gamma.

The only exception to this is when I am going to render ONLY for computer use for progressive download. Then I change to video mode, apply a studio to computer RGB filter and render out.
 
Perrone - I'm encountering the same observations as you . It believe as you thought in the other thread, that it is indeed an issue with Adobe and MPEGStreamclip

Vegas views the native footage ~-5 to 110 as you said earlier, and views the vegas encoded footage unclamped. It views the AME and MPEGStreamclip encoded DNxHD files clamped 0-100

PP clamps everything, including the vegas encoded footage, and native footage. Re-wrapping the native footage in .mp4 can recover those superbrights/darks (you might use mp4box or yamb, and then interpret the footage in PP to PAR of 1.0 because it will assume 0.75 for some reason). Quirks.

Other decoders through avisynth and qtinput(), view the vegas encoded footage unclamped, but view the AME and MPEGStreamclip clamped. This suggests the issue is with Adobe and MPEGStreamclip. I cannot find hidden settings in either program that can "fix" this behaviour

Summary:
- Vegas is OK
- MPEGStreamclip clamps and passes this onto the encode
- PP CS4 clamps superdarks and superbrights, even footage that has proper levels and also passes this on

This is only for PC. No idea of MAC behaviour
 
k im really confused.
can someone just tell me what exactly i should be doing to get these conversions right? can i just drop the original files in the timeline and render timeline in Premiere Pro for smoother playback or do I really have to convert these files? I plan on color grading everything.

I'm lost with all the bit and number lingo.
 
Perrone when you say "In terms of a quality hit, yea, the difference between the DNx and the original files is massive." did you mean that if i use originals i'm just ending up with worse footage?
 
You must log in or register to reply here.
Back
Top