Please compare other cameras to the HMC40 here, Thanks.

So ... um ..... why would HDLink treat Canon's 30P-in-60i differently from Panasonic's 30P-in-60i?
 
GrahamH said:
So ... um ..... why would HDLink treat Canon's 30P-in-60i differently from Panasonic's 30P-in-60i?
Click to expand...

Not sure, you would have to ask their engineers

There is probably a slight difference in the transport stream and header, enought to make some decoders "think" that the contents are interlaced

Cranky mentioned earlier some issues with Panny GH1 and cineform possibly fixed; Do you have all updates?
 
Well I was mistaken. It turns out HDLink simply uses whatever decoder has priority on the system - and since I have CS4 installed that is ... drumroll .... Mainconcept presently. I'll redirect it to libavcodec this evening and report back.
 
That still doesn't explain it completely; because native 24p from HMC40 (or any other AVCHD or h.264 source) is decoded with interlaced chroma within Adobe Premiere and AE CS4. Your screenshots should have showed the same thing with the HMC40 (ie. interlaced chroma), but they didn't

It might have more to do with the source filter and splitter (by splitter , I mean the directshow splitter before it hits the decoder) , or how your NLE or HDLink interprets how the footage is wrapped (interlaced flag)

If I switch decoders to Divx h.264 (which is based on Mainconcept AVC decoder) instead of libavcodec, it still decodes fine (HF10/11, HMC40 samples , 24pN, 30P in 60i , etc...)
 
They both look fine


1zzgz21.png


k1rp69.png




For the 24p footage, I used avisynth and TIVTC to IVTC back to 24p. In the Adobe comparison for 24p, I used AE to IVTC

In your case, I suspect the issue is probably with HDLink. If it's using directshow for the conversion, the output pin is probably conveying an interlaced signal so it thinks the content is interlaced. Make sure your ffdshow build is fairly recent to rule out other possibilities

You can test this for yourself if you know how to use avisynth, just make simple script e.g. DirectShowSource("Canon_30P.MTS") , using ffdshow to decode, and encode that in vdub using anything, even cineform, you will see it looks fine

For the IVTC script:
DirectShowSource("Canon_24P.MTS")
TFM().TDecimate()

Cheers
 
I tried processing the Canon 30P footage via VDub/Avisynth as you suggested - I do get a better output, but there's still something wrong relative to your result (the levels are tweaked here to make the images a little clearer):

30p.jpg


When I go to Compression/ffdshow in VDub, it shows libavcodec as the choice for H264 decode. But when I drag the raw clip into graphedit it's not using ffdshow for the video. Confused...

graphedit.jpg
 
Did you see the ffdshow icons pop up when opening up the .avs script in vdub?

What splitter are you using? I am using haali media splitter in WinXP

In Win7 , direct show filters defaults to the MS decoder , you need a registry tweak to allow 3rd party filters. There is a tool here to do that:
http://www.videohelp.com/tools/Preferred_Filter_Tweaker

Another option is to use graphedit/graphstudio to construct a temporary graph to use in avisynth and specify your filter chain

Another option is to use a different source filter eg. ffmpegsource2 or dgavcindex, which would avoid all the directshow issues (but they have their own quirks)

When I go to Compression/ffdshow in VDub
Click to expand...

I'm confused by this statement ; you shouldn't be using ffdshow for compression (ie. video=>compression). You should be using something else for compression e.g. cineform or lagarith or huffyuv etc... (The compression menu in vdub specifies what compression to use upon export, not what decoder is being used)
 
Last edited:
Well PDR, you are exactly right. The Canon chroma interlace bug is eliminated with correct decoding, and seems to depend mainly on the host application (in my case HDlink). When I opened my 30P clips using Avisynth/VDub the bug is eliminated, regardless of which decoder I'm calling (Ffdshow, Microsoft or Mainconcept).

Thanks - it has been a learning experience, and Win7DSfilters is a good find. (By the way my reference to compression before was just that was the menu option I was using to access the ffdshow encode/decode GUI).

To the rest of you - sorry we hijacked this thread for so long!
 
Even decoded properly, the "interlaced chroma" encoding with the HF certainly appears to yield notably crappier color. That's sort of a real bummer. It would be nice to pick up one of the HF-S cams being discontinued, at clearance pricing, when the new ones come out, but I think I'll wait for the next generation being discontinued next year to grab one. The HV20 still suits me pretty well for a little fist size cam, even though I'd prefer recording AVCHD to flash memory. I've still got quite a few blank tapes to use up anyways.
 
Graham - since when does any thread here stay on topic :)

Besides, that discussion is relevant to this thread for preparing proper comparisons


Robert M Wright said:
Even decoded properly, the "interlaced chroma" encoding with the HF certainly appears to yield notably crappier color.
Click to expand...

What do you mean by "crappier color" and how are you making this assessment?
 
Comparing to the HMC40, the chroma from the HF is essentially softer. Presumably the HF 2x2 chroma blocks are recorded in "fields" and thus skip a horizontal line to make up the 2x2 blocks, and the HMC40 apparently doesn't do that.
 
Yes I agree it's softer

But we should be careful, as Graham never posted the native HMC40 video sample. The images he posted of HF10 used the wrong decoder, and levels/colors were tweaked (if you were comparing to those images of the properly decoded samples , which had no adjustments.)
 
I agree with you bigtime on that one. We really should be looking at source files from the camcorders, given the decoder issues, and also potential alterations by converting the output of the decoders yet again to a still image format (likely extremely minor, but another potential source of errors).
 
Robert M Wright said:
I agree with you bigtime on that one. We really should be looking at source files from the camcorders, given the decoder issues, and also potential alterations by converting the output of the decoders yet again to a still image format (likely extremely minor, but another potential source of errors).
Click to expand...


It's actually an important point.

When taking screenshots (not trying to "pick" on Graham here) , but he posted lossy .jpg's instead of .pngs. How do we know the noise in the HMC40 images were in the source, and not from jpg compression artifacts, for example?

Also when taking the video=>decoder=>.png or whatever image, there is a YUV=>RGB conversion. That conversion will look different depending on what coefficients and colormatrix you use. (eg. are you using rec.709 coefficients? or rec.601 coefficients or something else etc...). The levels can be completely different if you use PC vs. Rec levels, and how you map luminance levels. Thus dynamic range can be completely different as well.

I think it's important to eliminate confounding variables, and do the comparisons consistently (at least between sets of comparisons), and in an "open" fashion so anyone can replicate the results and critique/improve the methods. If the methodology isn't sound, then the comparisons are less useful
 
Robert M Wright said:
Sometimes, working with video almost makes flying the space shuttle sound pretty easy by comparison.
Click to expand...

You're going to have to go to Russia for that these days:)

But only for "pixel peepers" care about this stuff. Not everyone cares about the minutia...
 
Here are two short clips of raw 30P-in-60i from the Canon HF10 and HMC40 - I'll be interested to see what you guys come up with. The HMC clip is new - i.e not the one I was using earlier. The Canon clip is the one I refered to and linked to earlier:

http://wildlifehealth.tennessee.edu/video/Canon_30P.MTS

http://wildlifehealth.tennessee.edu/video/HMC40_30P.MTS

Oh ... I should say, this is auto everything on both cameras, except shutter which was 1/60 on both. The Panasonic was using zero gain - I'm guessing that would be true for the Canon also.
 
Last edited:
You must log in or register to reply here.
Back
Top