[fixed] Problems with Camera II module and Decklink in HD

[Johan Lundberg]

During my tests with the Decklink HD cards I've noticed a problem with the Decklink and Camera II module when using HD resolutions.

If you set up Vidblaster global resolution to 1280x720 @ 25 fps and feeding the Decklink card with a 1280x720 signal (tried both 25 and 50fps). Using "Camera (II)" module results in a very choppy video (low frame rate, although both Camera module and Program module reports 50 or 25 fps). Using the exact same setup but using "Camera (I)" module results in a lot smoother video (see examples below).

I tried using the same setup but changed everything (VB global resolution, camera module and the source signal) to 1024x576 instead and everything became alot smoother (see example below).

Also, when in 720p, though almost the same duration, the size of the recordings (Cam I vs Cam II) differ alot in size, which seems to indicate the actual frame rate is alot lower in Cam II recording)?

You can download and see the original test recordings here:
http://www.techcrew.se/vidblaster/strobe/


Anyone else experience this or got any ideas?


Some additional info:

Vidblaster Broadcast v1.25
Global resolution set: 1280x720
Global framerate: 25 fps

Camera (I)-module: 1280x720@50fps
- Only Camera (I) module added: 6-7%
- Camera (I) + Program module added: 10-12%
- Camera (I) + Program + Recorder module added and recording: 50-55%
- Recorded file: 13s 13,6MB

Camera (II)-module: 1280x720@50fps
- Only Camera (II) module added: 0-1%
- Camera (II) + Program module added: 5-6%
- Camera (II) + Program + Recorder module added and recording: 27-30%
- Recorded file: 11s 2,36MB

[Johan Lundberg]

Results are the same if using 1920x1080 @ 25 fps as well.

[julianlee]

Results are the same if using 1920x1080 @ 25 fps as well.
hi, Johan
We also confusing because of this problem.
There are several projects related to 720p/1080, VidBlaster can not offer.
Mike says, fast CPU, RAM, SSD etc ..., but there is no exact guidelines.

[Johan Lundberg]

Julian,

well the interesting part here is that with Camera (I) module the video appears quite smooth, but using the Camera (II) module (which actually is more CPU-friendly), the video is not smooth at all. This leads me to think this problem is not about overloading the computer.

[weconverse]

Nice shoes Johan :)
But, just wanted to point out that you wrote Camera (I), when you probably meant (II) at the end of your first post.

[Johan Lundberg]

Ah, just noticed I uploaded the wrong clip for the 720p test. Correct clips are up now! It's alot easier to compare now. The one with the feet was an earlier test, though you can see the same problem!

Thanks Richard, corrected that as well! :)

[julianlee]

Ah, just noticed I uploaded the wrong clip for the 720p test. Correct clips are up now! It's alot easier to compare now. The one with the feet was an earlier test, though you can see the same problem!

Thanks Richard, corrected that as well! :)

Johan,

I understand the problem is computer's resources.
I checked the information of the test video playback,
Camera (I): frame-rate is 23 ~ 25,
Camera (II): frame-rate is 8-10.
Include 30 frame-rate, why do not test?
When we test, for 720p, Frame-rate is too variable.

[Johan Lundberg]

Julian, thanks for your reply.
Since it works fine in Camera (I) module and the Camera (II) module actually shows alot lower CPU load I'm quite sure the computer resources are not the problem. I think I've ran into something else here, don't know if it is a bug or not but it's very easy for me to reproduce every time. I only tested in 25 and 50 fps since that's what I'm producing in and that is also my source format.

Maybe Mike can shed some light regarding what differ from the two camera modules?

[Jakob]

I had the exact same issue. I was installing the BM card, and it took me 4 hours to understand that it worked in cam 1, but not in cam 2. Nice to hear that I am not the only one pulling out my last pice of hair :-)

[Johan Lundberg]

Jakob.
Glad to hear I'm not alone on this! Then I guess the next question is why does the Camera (II) module behave like this in HD? I really don't believe it's about computer power. Like I mentioned in my first post, adding only a Camera (II) module in 720p is hardly even noticed on the CPU meters. I think there is something else going on here... Mike?

[Monoscopio]

As I understand, the camera I module is based on a DirectShow SDK(?) and the cam II is built by Mike from scratch for performance and better control for the programmer. Probably something missing which I am sure Mike will fix.

[Johan Lundberg]

Mike, do you want to move this to the bug reports or do you have any input on this?

Thanks.

[Johan Lundberg]

This became an issue for us when trying to run a 3 cam production in 720p with 2 BM Decklink cards and one Lifecam Cinema.
Using Camera (I) modules for both BM cards increased CPU usage quite a bit and together with a bug in FMLE (3.0) forcing us to use only 8 cores instead of 12, made us hit the roof on a few cores even with our new production computer (Core i7 990x Extreme Edition).

I guess the problem now is that we are getting used to Mike´s much more efficient Camera (II) module! For 720p production we really need all the help we can get resource wise, so getting this module to work in HD would really help alot.

For future productions a fix of this is a high priority for us.

[owallen]

+1

2 x Decklink Duo
Experience exactly the same issues.

Örjan Wallén
----------------
Live webcast producer

[Mike]

I'll see if I can reproduce this. Meanwhile, did anyone check individual cores?

[Mike]

In addition to my previous (unanswered) question, is this a general problem with camera II, or only with DeckLink cards? I.e. did anyone test HD with a different capture device?

[Johan Lundberg]

I've only experienced it with Decklink cards, but then I haven't either had the chance to try with any other capture cards.

Regarding individual cores I have monitored all cores individually with Windows standard CPU monitor without noticing any spikes. In fact, running only one camera with Camera (II) module hardly uses any CPU at all.

[Mike]

I do not have other HD capture cards as well. My problem with this bug report is that I am seeing the hickups in both Camera I and II, it's just more often in II than in I. So I am seeing a relation to the DeckLink, not the camera module. And that DeckLink cards do not behave properly on some motherboards is already a given. In fact I am often seeing a BSOD, indicating a hardware conflict.

I have had several talks about this with BlackMagic and there does not seem to be a reliable way to use these cards. Trial & error.

I guess I have to build another PC to test these DeckLink cards.

[Mike]

So does everyone agree this is a specific DeckLink problem and it is not limited to Camera II? See my earlier posts above.

If anyone is still seeing this problem, I'd appreciate if you also check the lost frame counter (in the log). Is it a higher value then when using Camera I? This could be a very important clue. You can find the value when you close a profile (or VidBlaster) in the line that looks like this

hh:mm:ss TVideoSwitcher::Close (lost frames: x)

Thanks.

[Johan Lundberg]

I believe I now can confirm your last post Mike.
On yesterday's broadcast, due to recent problems with Camera (II), I used Camera (I) modules only for the Decklink inputs (used 4 inputs and 1 output). I experienced occasional lagging video on all of the inputs, but at different times. It was to me a inconsistent behavior, where I sometimes had all inputs running fine (could run for an hour or so without problem), and sometimes one or more of the sources lagging, often at different times and with no obvious causes. No increase in CPU usage either. I had both SDI and composite inputs.

Something seems weird with the decklinks...

[Johan Lundberg]

If anyone is still seeing this problem, I'd appreciate if you also check the lost frame counter (in the log). Is it a higher value then when using Camera I? This could be a very important clue. You can find the value when you close a profile (or VidBlaster) in the line that looks like this

hh:mm:ss TVideoSwitcher::Close (lost frames: x)

Thanks.

I'm going to run some tests on this during next week and will report back.

[Mike]

I've built a test system around a 6 core AMD, a DeckLink Duo and my new Sony nxcam. First of all, let me start by saying this is the first time I use this card and this camera and already love both the quality and easy and solid hookup of SDI. It is so crisp it's like I am looking at a mirror. Coming from a radio amateur background (I am PA3GPY), I also love the sturdy BNC connectors and coaxial cable.

Second, I am seeing this phenomenon where the exact same video is smooth in Camera I and not in II. So I can definitely call this a bug and now have a reliable setup to run tests on.

[Johan Lundberg]

Excellent Mike, and welcome to the world of SDI! It's great that you have a running setup and can see the problem! Have not had the chance to run any more tests yet, but will most likely have some time for it tomorrow if you still need it. Let me know if you need any additional help on this matter. I have a bunch of different BM cards in our rigs.

/Johan

[Mike]

Found the problem (I don't want to call it a bug as it is a compatibility problem in the Decklink driver for which I found a workaround) and fixed it in v1.34. (Unfortunately CPU usage in this particular case will go up as a result.)

[weconverse]

Usage in general, or for this card in cam II only?

[Mike]

For Decklink cards.