Maybe we're not talking about the same thing. I downloaded the raw clip of the girl closing the slate, and ran it through avisynth. It looks fine. No glitch around 6 seconds. Only a stall just before the camera goes out of record.
HDMI Capture Problem SOLVED - AviSynth RULES!
- Thread starter Ralph B
- Start date
Maybe we're not talking about the same thing. I downloaded the raw clip of the girl closing the slate, and ran it through avisynth. It looks fine. No glitch around 6 seconds. Only a stall just before the camera goes out of record.
Amadeus5D2
Member
I have excited news findings
I have the same issue like you and all others when I attached panasonic own lens 14-40mm, I can't get a proper 25p from 50i !!!! Strange that should be some electronical problems between Cam and Lens!
With the Kipon and my Canon 24-70mm attached I have not these issues
Can somebody test that?
Martin, here the testvideo captured via HDMI BM Intensity Shuttle with KIPON and Canon 24-70mm, GH2 settings Video 24P (out 50i), the content is not interesting but look at the red color around 30 sec . looks very clean to me and to the length of video ( 50sec.) without problem concerning sync. frames.
http://www.megaupload.com/?d=NC4PLESB
cheers
I have the same issue like you and all others when I attached panasonic own lens 14-40mm, I can't get a proper 25p from 50i !!!! Strange that should be some electronical problems between Cam and Lens!
With the Kipon and my Canon 24-70mm attached I have not these issues
Can somebody test that?
Martin, here the testvideo captured via HDMI BM Intensity Shuttle with KIPON and Canon 24-70mm, GH2 settings Video 24P (out 50i), the content is not interesting but look at the red color around 30 sec . looks very clean to me and to the length of video ( 50sec.) without problem concerning sync. frames.
http://www.megaupload.com/?d=NC4PLESB
cheers
Last edited:
martinbeek
Active member
But you did see the glitch in the side by side movie? I can try running it through avisynth again.
Mmmmm... I assume you and i use the same script. Maybe a critical setting on the edge of falling over?
We're almost there, but this worries me a bit.
It's 11 pm here and i'm going to sleep on it ;-)
Martin.
Hi there, the cadence is fine ; it is 25p content without inserted fields or deleted fields (unlike the other samples). But I'm guessing the "liveview" drops the resolution
What you are seeing is essentially upscaled incorrectly, probably from low resolution . It's probably taken the 50i signal, dropped 1/2 the fields and used a point resize on the remaining fields, so you get aliasing (jaggy edges)
This is a 1:1 crop from a static portion of the video (frame 800)
Was the sample processed in AE? or straight from BM ?
You can use avisynth filters for antialiasing, or deinterlace it, but resolution is low (it wasn't scanned progressive)
Last edited:
Amadeus5D2
Member
Hi PDR,
no, this is the interlaced unprocessed sample, load it in AE and disable footage settings upper/ lowerfield first and you will have a perfect free of aliasing sample and don't use smoothing in the timeline btw. the sample does not change resolution when you switch to smooth!
But captured with Pana lenses there is a difference if smooth is selected/deselectet....deselectet has lower resolution and selected seems to me upscaled!!! But not with this settings GH2 and KIPON/ Canonlens. The next days I can upload a short comparison. Strange but true.
here frame 800 with upperfield first vs. disabled ( movie is 1:1 res. )
http://www.megaupload.com/?d=WRC1ZG09
I think the red "line" has lower aliasing as yours
See here which workflow:
http://www.megaupload.com/?d=NC4PLESB
I upload the file as is so you can switch from 50i to 25P. Probably you need BM codec, I captured with the lowest BM MJPG.
The codecs comes with the drivers: http://www.blackmagic-design.com/support/software/ download e.g. latest Intensity driver Mac/Win and install to get the codecs.
The workflow is simple : camera video settings 24P, ( KIPON adapter with my 24-70 Cannon lens is fitted to GH2).
First I turned on the GH2 then I attached the HDMI cable who is connected to my Intensity shuttle. Don't press the camera rec. button..it's liveview capture, record liveview to HD with BM Media Express.
Blackmagic capture settings:
AE settings:
no, this is the interlaced unprocessed sample, load it in AE and disable footage settings upper/ lowerfield first and you will have a perfect free of aliasing sample and don't use smoothing in the timeline btw. the sample does not change resolution when you switch to smooth!
But captured with Pana lenses there is a difference if smooth is selected/deselectet....deselectet has lower resolution and selected seems to me upscaled!!! But not with this settings GH2 and KIPON/ Canonlens. The next days I can upload a short comparison. Strange but true.
here frame 800 with upperfield first vs. disabled ( movie is 1:1 res. )
http://www.megaupload.com/?d=WRC1ZG09
I think the red "line" has lower aliasing as yours
See here which workflow:
http://www.megaupload.com/?d=NC4PLESB
I upload the file as is so you can switch from 50i to 25P. Probably you need BM codec, I captured with the lowest BM MJPG.
The codecs comes with the drivers: http://www.blackmagic-design.com/support/software/ download e.g. latest Intensity driver Mac/Win and install to get the codecs.
The workflow is simple : camera video settings 24P, ( KIPON adapter with my 24-70 Cannon lens is fitted to GH2).
First I turned on the GH2 then I attached the HDMI cable who is connected to my Intensity shuttle. Don't press the camera rec. button..it's liveview capture, record liveview to HD with BM Media Express.
Blackmagic capture settings:
AE settings:
Last edited:
Earlier you said you got 24p out of this ? The live view?
The only way I think you can do that (cleanly) is to do a PAL slowdown (slow everything down, including audio to 24000/1001, keeping the same framecount)
50i => 25p is very easy , you just bob-deinterlace it (50i => 50p) and discard 1/2 the frames.
But this sample is interlaced scan , with progressive content (every consecutive field is duplicated, not unique) .
You might as well record true 50i instead (this way you get 2x the temporal information). I believe 50i and 60i are clean signals (truly interlaced) from GH2 HDMI
I don't see any benefit to recording "liveview" ?
EDIT: sorry, 50i and 60i are not clean signals ... so there may be a benefit to recording "liveview" then....
What you're saying about the different lenses is interesting. If they affect the cadence or scaling.... I can't see how (very strange) but please demonstrate the comparision
The only way I think you can do that (cleanly) is to do a PAL slowdown (slow everything down, including audio to 24000/1001, keeping the same framecount)
50i => 25p is very easy , you just bob-deinterlace it (50i => 50p) and discard 1/2 the frames.
But this sample is interlaced scan , with progressive content (every consecutive field is duplicated, not unique) .
You might as well record true 50i instead (this way you get 2x the temporal information). I believe 50i and 60i are clean signals (truly interlaced) from GH2 HDMI
I don't see any benefit to recording "liveview" ?
EDIT: sorry, 50i and 60i are not clean signals ... so there may be a benefit to recording "liveview" then....
What you're saying about the different lenses is interesting. If they affect the cadence or scaling.... I can't see how (very strange) but please demonstrate the comparision
Last edited:
Amadeus5D2
Member
I have this results only with GH2 settings 24p ( out is 50i) it don't work with 1080/50i! I never tried to capture while GH2 is recording. Yes I make a comparison...I think too it's very strange. cheers
Last edited:
Amadeus5D2
Member
I can send you a private video: a comparison it's a short screen movie of AE with the two lenses but not so good because they have different subjects, so i will make later one with the same subjects. But take a look what happens when I set smooth on/of the video, made with the Panasonic lens, you don't believe that here is a difference.
Last edited:
Amadeus5D2
Member
Hi PDR,
strange concerning lenses, today I tried too reproduce the issue with the lens, but so far I haven't the same result, the good one is that Panasonic's 14-40 looks now o.k.
Strange because I made yesterday 2x the same test with the same result, sorry. Who knows, if I can find the matter. Anyway I will take care on that.
strange concerning lenses, today I tried too reproduce the issue with the lens, but so far I haven't the same result, the good one is that Panasonic's 14-40 looks now o.k.
Strange because I made yesterday 2x the same test with the same result, sorry. Who knows, if I can find the matter. Anyway I will take care on that.
Are you sure it's at ~6 seconds ? I'm not seeing the problem in either the side by side encoding, or when looking at the native Ninja recording with script processing?
There are some problems at the end , after ~9.5 seconds maybe it was a typo and you meant 9 seconds ?
by "hickup" i assume you mean a discrepancy between AVCHD and aviysnth processed HDMI footage ?
There is a way to get it perfectly matched up (even after 9.5 seconds , all the way to the end of the AVCHD clip) - but not automatically. It's a long winded explanation. The short version is you have a missing field at ~9.5 seconds, and that screws everything up. It's replaced by another field of the wrong frame. Getting rid of inserted duplicate fields is usually no problem; but fixing something that doesn't have the information there in the first place is more difficult. This probably isn't something that an Atomos update will fix, it can only record the signal that is given to it. The fix would have to be issued by Panny. If this pattern occurs only at the beginning & end of recordings (before you hit stop), it shouldn't matter, but if this pattern occurs in the middle, then it's a bigger problem
RE: levels/gamma issues
Did you realize there is a levels issue before encoding to DNxHD ?
There is a discrepancy between your HDMI recorded and AVCHD footage with respect to saturation and levels. But this has been documented before. The GH2 HDMI output is different to begin with. This is in addition to the quicktime/DNxHD gamma issues mentioned earlier. I've included screenshots with a waveform
http://www.mediafire.com/?1mf63qxlx6ghn9y#1
But you have converted the AVCHD to ProRes - this complicates and introduces other variables. In the future I would suggest uploading the native AVCHD files - not only because they are smaller, but also because it's easier to debug when/how problems are introduced . For example, black level is elevated in the Prores converted AVCHD clip, and it has lower contrast. The Ninja clip has Y=16, proper black level, but AVCHD prores clip is higher. Did that occur because of the ProRes conversion? or something else? How did you convert to ProRes? Log & Transfer? or is this the "normal" screwed up levels of GH2 HDMI signal?
martinbeek
Active member
SORRY SORRY SORRY - despicable me! You are right, it's a typo! That was meant to read 9 seconds indeed!
I understand your explanation and will Start the Ninja after the camera and stop it again before the camera is stopped.
Btw. the AVCHD footage was fed into 5DtoRGB - it does a nice job converting AVCHD to prores444 if you don't need sound; but that was just a quick and dirty solution to get it into FCP fluidly.
Martin.
martinbeek
Active member
Ralp.
I have noticed another difference between the page 1 and page 33 code.
After "AssumeTFF()" it says on page 33: converttoyuy2()
Is that meant to stay there for ProRes PAL footage ?
Martin
I have noticed another difference between the page 1 and page 33 code.
After "AssumeTFF()" it says on page 33: converttoyuy2()
Is that meant to stay there for ProRes PAL footage ?
Martin
martinbeek
Active member
PDR
You mentioned a slightly different approach for preventing color shifting that didn't impose a shift of the whole image. You said "a dozen pages earlier", but can you point me to that post, can't find it myself.
When i take screengrabs from the Ninja footage and the corresponding processed AviSynth footage, and zoom in 200% in photoshop, i see a blurring of fine detail that i'd like to keep - such as facial hair, patterns on small leaves, ... I gather that that's part of the shifting/restoring?
Sorry for all the questions guys, but i want to get this perfect and i'm for 99% there!
Thanks,
Martin
You mentioned a slightly different approach for preventing color shifting that didn't impose a shift of the whole image. You said "a dozen pages earlier", but can you point me to that post, can't find it myself.
When i take screengrabs from the Ninja footage and the corresponding processed AviSynth footage, and zoom in 200% in photoshop, i see a blurring of fine detail that i'd like to keep - such as facial hair, patterns on small leaves, ... I gather that that's part of the shifting/restoring?
Sorry for all the questions guys, but i want to get this perfect and i'm for 99% there!
Thanks,
Martin
martinbeek
Active member
No. converttoyuy2() is necessary if you use directshowsource() for the input. If you use qtinput, converttoyuy2() is not needed.
The blurring might be from compression (DNxHD is not lossless) , or you might be percieving chroma artifacts and aliasing as "detail". It is not true detail.
But the shifting (whole image shifted vertically up) is likely from that version of the chroma fix. Note your samples also show the interlaced chroma issues as well (this is a different problem than the shift) . I don't know if you can look at CbCr in FCP, but you can convert to RGB and look at the blue channel for example - you will see notching in the leaf sample (actully everywhere). If you don't know how to do this , this I can post some examples.
BUT I would hold off on any chroma related testing - it's possible the green border stripes and metadata might be partially responsible for those shifting and chroma issues (but not the notching issues) . So the end result might change. If chroma planes aren't aligned properly, you can get something like this. The only reason I looked at your last uploaded samples was there seemed to be a discrepancy between what you and ralph were "seeing". But we know that was a typo now.
If you want to look at earlier chroma testing the links are below. But I would hold off until a firmware update, and you (or someone with a ninja) shoot a better chroma test sample. You need objects with sharp color edges, preferably red on green or red on blue. Color charts are fine. The script using avisynth 2.6 still needs a shift (0.5 vertical up) to look "perfect" IMO, but I would wait from the firmware fix and better chroma tests with ninja.
post 106 - Ralph's chroma testing sample
http://www.dvxuser.com/V6/showthread.php?237584-HDMI-Capture-Problem-SOLVED-AviSynth-RULES!/page11
post 143 - Barry's "wringer" test chart
http://www.dvxuser.com/V6/showthread.php?237584-HDMI-Capture-Problem-SOLVED-AviSynth-RULES!/page15
Sorry for long post:
what do you mean by "as good"? as good performance editing? as good quality? as good compression ? avoids gamma issues (or retains screwed up gamma)?
Quicktime messes up the gamma on almost everything. I think quicktime X has some other gamma options and maybe the new version of FCP X. These gamma issues have plagued FCP/quicktime for years. See if you can play with the settings or interpretation settings.
BUT what do you want it to look like ? The AVCHD or the Ninja footage ? Which one is "correct" ? I would say the AVCHD footage should be the goal, but your starting footage (before processing or DNxHD) is already mismatched. Do you see the problem here ?? How did 5DtoRGB do the conversion ? Does it go through RGB intermediate ? Also how did you control exposure ? The waveform monitor shows the black level too high in the AVCHD sample - was that because of the conversion? or was original AVCHD like that ? Note the waveform tracings I posted earlier measures Y' in Y'CbCr - this looks at the actual Y' data, not the RGB converted representation.
*I should clarify - you might be seeing something different than me because QT embeds a color profile in PNG's - depending on what program you are using and how you have it set up - it may or may not ignore the "flag". Some of the earlier examples might have been confusing - I should have explained this earlier:
To confuse you some more, what you are "seeing" in screenshots or in a media player is the RGB converted representation of Y'CbCr . You're NOT viewing the original Y'CbCr data. How that conversion is done (how the screenshot is taken), or what color profile is embedded affects how you see the final RGB image.
You have to be aware of HOW your application handles Y'CbCr => RGB conversions and what color model you are working in. QT uses ~1.8 gamma, but everything else in the industry uses a 2.2 gamma. All hardware, displays, broadcast monitors use 2.2 gamma. That's why everything is screwed up in quicktime. The industry standard for HD material is using ITU Rec.709 for Y'CbCr <=> RGB conversions. This is official spec, and covers everything from blu-ray to broadcast industry, both NTSC and PAL regions. Some programs have color management - you can use and assign color profiles or working spaces, and can control how that Y'CbCr <=> RGB conversions are handled. I think QT X and maybe the new FCP gives you some more control.
Keeping everything in Y'CbCr allows you the most options because that is the original recording format - both AVCHD and ProRes are in Y'CbCr (provided your downstream program can access it as Y'CbCr and has color management options). You can access full luminace range , even "illegal" ranges Y' <16, Y'>235 . BUT if it has been converted to RGB using ITU Rec.709 , that dynamic range is lost (you will clip shadows and highlight details) . By the strictest definition, you can access the highest dynamic range possible of the recorded format.
Summary: embedded color profile limits your options in grading , conversion to RGB limits your options, using quicktime limits your options.
To pass Y'CbCr in QT (at least on windows), you need uncompressed fourcc "IYUV" AVI as input. The plane arrangement is important. QT will NOT treat other forms of uncompressed AVI (e.g. YV12 , which has Cb Cr channel order reversed) as uncompressed Y'CbCr; it will convert to RGB using the screwed up gamma . This is the entire basis for QT gamma issues (RGB conversion).
Uncompressed IYUV (huge filesizes) will pass through Y'CbCr and you should get the same gamma (the preview , which has been converted to RGB for display might look different, but the end result should be the same) . This is the same gamma shift workaround that works when encoding h264 through quicktime - there is no h264/mov gamma shift, because Y'CbCr is preserved (at least on windows). So please test the IYUV sample in FCP to see if it's compatbile. I also included a cut version of the original 2nd sample 009.mov Ninja ProRes with the leaves)
http://www.mediafire.com/?kmaszm70so074jb
In this example , both tiff screenshots have been processed in QT (so both have the same gamma, and should look the same in every application regardless of color profile settings). If you use a difference mask, you will see there are horizontal notching differences - even on this frame that has no apparent combing at quick glance. This is because they have been fixed in the IYUV sample with the chroma fix. If you look at the original 009.mov sample or 009.tif image and look at the blue channel photoshop or AE, you will see this interlaced notching and aliasing as well - these are the HDMI chroma issues outlined earlier. (it's easier to see in earlier examples, like Barry's wringer test). If you can look at Cb and Cr in the 009.mov sample (not sure if you can do that on a MAC) , you will see how these artifacts transfer over to RGB (They already exist in the Y'CbCr original - and that's the basis for using the chroma fix in the first place)