HDMI Capture Problem SOLVED - AviSynth RULES!

perhaps there is something wrong with martin's particular model or his particular GH2 ?

With the green stripe from the GH2 footage, we think this is is likely to be a timing error with the HDMI output from the Panasonic. We are hopeful that we can compensate for this in our HDMI input software.

We haven't seen this stripe from any other camera.

Dave Shapton
Atomos
 
Dave, all.

Dave, your'e right - it's all certified. Can't be the codec. And it isn't.
I have checked the original file and there is no green stripe. Downloaded the file: stripe! So it has something to do with the transfer (ftp or other). Sorry about that. Please forget the green stripe.

READ UPDATE ON LAST LINE

I have now overwritten the file with one that is different and absolutely stripe free. Checked the FTP file and it is in good order.

Recorded with the GH2 in record mode. Untouched, uploaded from the Ninja's harddisk.
This time a plant in my garden waving in the wind. Lot's of detail, moderate motion.

http://mediatube.marvelsfilm.com/009.mov 305 MB

Indeed, metadata is incorrect, saying: 1888x1062 pixels...

Can you powerful wizards please run this one again?

Many thanks.

Martin.

UPDATE: no green stripes, until i open the clip in MPEG Streamclip and there it is again, only much thinner!!! I am getting crazy i think... Does this have to do with the meta data?!
It's invisible in Quicktime, but immediately apparent in FCP - #STRANGE !
 
Last edited:
If it helps to debug the issue, "aemonk" posted ProRes422 clips recorded from AJA IoPro from a Pal GH2 HDMI that did not exhibit this issue, but the links are down. I deleted the clips a long time ago, and I can't recall if the metadata was different on those
http://www.dvxuser.com/V6/showthread.php?231315-Any-GH2-news-on-the-HDMI-output-front/page24

I asked this earlier , but can some mac users have a look Martin's clip to rule out PC QT ProRes decoder issues

I have checked the original file and there is no green stripe. Downloaded the file: stripe! So it has something to do with the transfer (ftp or other). Sorry about that. Please forget the green stripe.

sorry I didn't see this before posting. Are you saying the file was corrupted somewhere along the line from the file storage service ?


UPDATE: no green stripes, until i open the clip in MPEG Streamclip and there is again, only much thinner!!! I am getting crazy i think... Does this have to do with the meta data?!
It's invisible in FCP and Quicktime!

This would suggest mpegstreamclip is causing the issue

Is the new file you uploaded directly from the ninja? or processed in some other program first ?
 
PDR.

Sorry, our messages crossed over. I was updating it while you were commenting.

The green stripe is indeed still there, maybe a bit thinner. Not visible in Quicktime (that i used to check), but is IS there in FCP too. BUGGER!

Martin
 
martin - what about the simultaneous AVCHD recording? is the stripe there ?

(there are actually stripes on the right side as well if you look closely)


Not visible in Quicktime (that i used to check), but is IS there in FCP too

If it's NOT visible in quicktime player, what player version are you using (quicktime x ?)



If you recall what Diego said:
When you export for quicktime, mind that for some strange reasons After Effects and Premiere are not able to open these files. Actually all files being recorded on the ninja cannot be opened in AE and PP without previously exporting them to ProresHQ from quicktime. I don't know why and any help on this is really welcome.

This suggests that quicktime can decode it properly and transform it into a "proper"? Prores file . His sample ALSO exhibits the stripe (at least on PC), but I'm not sure what he did. Apparently he deinterlaced it, I'm not sure if he shot in 24p mode. The meta data looks "normal" in his sample
Width : 1 920 pixels
Height : 1 080 pixels

But Quicktime on PC does exhibit the stripe issue



Stripe issues aside, Ralph's script works fine cadence wise on that new sample

EDIT: sorry Diego's sample does have the stripe
 
Last edited:
It's crazy indeed. The quicktime version is 10.0 (118). It's absolutely NOT visible in QT, even zoomed in 200%.
The AVCHD footage does not show the stripes. Now i'd like to see some GH2 PAL Ninja footage from other people!

Martin
 
Sorry I looked again at Diego's GH2 PAL Ninja "sky" sample, even though the metadata looks "normal" , it too has the stripe . I'm unclear as to how he processed it, I think he shot 50i and deinterlaced to 25p using jes deinterlacer. It's definitely not the native clip
 
PDR. That is a bit more assuring; telling me that it's not my particular GH2.
How bizarre! But i'm happy that the Avisynth scripting works. I'll install VirtualBox, Win XP and Avisynth tonight and see for myself!
Great stuff guys!

Dave: let us know if your contact with Panasonic can say more about this issue.

Martin
 
If you open it in quicktime (which seems to decode without the stripe for you) and export (force a re-encode) of another prores file for import into FCP, is the stipe visible in FCP ?
 
Yes sir!
Save-As to "HD 1080 P" in quicktime (resulting in a H.264 deinterlaced file) does indeed make the stripes disappear!

Martin.
 
I don't know enough about macs - but that suggests that the decoding pathway used by that particular quicktime version for decoding the prores ninja files is different than the one used by fcp, mpegstreamclip and other programs, including the quicktime version used on PC's . At least that's a workaround for now for mac users until the issue gets sorted out
 
PDR.

The weird thing is, that Apple claims that the Quicktime version is system-wide. All components and applications use the same installed quicktime version to do their work.
I'll dive into FCP to see if i can find another backdoor. The resulting conversion is not that great in respect to the codec and bitrate.


Martin
 
Yes, that was my understanding too, that all Prores gets decoded through the QT Prores decoder API (that's the way it works on windows)

Can't you export Prores from Quicktime?

You can use lossless options as well like png in mov, or animation codec (huge filesizes) . These are RGB options, so there will be a Y'CbCr=>RGB conversion
 
Yes, it's quicktime 7.x on PC... There is no quicktime 10.x option available on PC

I still think it has to do with the metadata; just a hunch
 
Wasn't there a tool on the Mac to set which version of quicktime is used by FCP? Can vaguely remember that such setting exists. It seems to me that FCP still uses QT 7 instead of 10.
Maybe have it all wrong here...

Martin
 
PDR.

Taking your remarks below in account, what would the ideal GH2 PAL script look like?

Thanks,

Martin


I think there is a mistake with the encoding, as the file has duplicates , and is 29.97 (the encoding program used might be inserting the dupes to achieve 29.97, you probably entered the wrong fps, the script is fine) . Compare it to the one I posted earlier, as you will see there are too many frames for 23.976.

A better option to directshowsource is QTInput using QTSource. DSS isn't necessarily frame accurate and you can "lose your place" with non linear seeks. This can cause errors in the field matching. Also, QTInput decodes Prores422 to YUY2 (422) by default, directshowshource will go usually go through a color space converter to RGB (more quality loss incurred with unecessary colorspace conversions)

Are you guys seeing the green left border mentioned earlier? Is this PAL GH2 HDMI issue or Ninja issue ? or something else ? Other PAL GH2 HDMI samples recorded by intensity pro didn't have this problem
 
Ralph's script works great. The only thing I would change is change the first line to QTInput("video.mov") . You need qtsource.dll because the input filter doesn't come with the default avisynth install (it's an external plugin)

I've used FCP before, but I'm primarily a PC user, so I don't know how to get FCP to use QT X components
 
Ralph's script works great. The only thing I would change is change the first line to QTInput("video.mov") . You need qtsource.dll because the input filter doesn't come with the default avisynth install (it's an external plugin)

I used both QTinput() and directshowsource() and I prefered directshowsource because of gamma issues. QTinput resulted in crushed blacks, whereas directshowsource looked correct, at least on a PC. Don't know how this will translate to a Mac. This isssue requires careful testing. We're in new territory with Prores.
 
Back
Top