BMDStreamingServer.exe leaking memory?

I'm capturing video using the Decklink SDK and an ATEM Television Studio. Most of the time this works fine, but then (seemingly randomly) I will start a capture but not receive any video or audio packets. When this happens, I have found that if I look at the task manager in windows, there is a process called BMDStreamingServer.exe, and usually it's memory footprint is increasing. If I shutdown my process, kill the BMDStreamingServer.exe and relaunch everything, things start working again. Until it randomly goes off the rails again...

It *feels* like I am installing the IBMDStreamingH264InputCallback using the SetCallback method (on IBMDStreamingDeviceInput) successfully (as evidenced by the fact I am receiving packets) but when I call SetCallback(null) to uninstall the callback, something goes off the rails and all further callbacks go somewhere unexpected?

Has anyone else experienced this, or similar, behavior?

[Nicholas Gill]

Hi George,

Could you please advise the version of Desktop Video installed?

An issue similar to this was resolved in Desktop Video 10.4.3, if not already using 10.4.3 could you please try in that version?

Cheers,

-nick

Nick,

Thanks for the reply. Yea, I'm usually pretty good about trying the 'latest version' for 3rd party sdk's or api's or whatever, but for some reason that never occurred to me with the ATEM/Decklink stuff.

After examining my system, I was still running my original version of the Switcher software which was version 6.0, with the Desktop Video back at 10.1.4. However, I was writing code using the 6.4 SDK; so there was a mismatch there. I'm not sure if that could contribute to my problem.

I thought now would be a perfect time to get everything up to date, so I downloaded the Switcher 6.5 and Desktop Video 10.4.3. After uninstalling the old Switcher software, I rebooted and installed the Switcher 6.5 without any problem. The first time I ran the software, I had to update the firmware in my ATEM Television Studio, which also worked just fine. I noticed the Switcher 6.5 installed Desktop Video 10.4.2, which is a version behind your recommendation.

At this point I tried to capture video using the ATEM Switcher Software but the software reports I have no capture devices. I also tried my own code, but that also failed due to the fact it never received a "DevicedArrived" callback.

Now this could be a configuration problem that I was too thick to pick up on, but I decided to try backing up a version to the Switcher 6.4.1 install. After several reboots, and updating (downgrading?) my firmware, I was able to get the Switcher Software 6.4.1 to recognize my ATEM Television Studio as a valid capture device. My own code also woke up and started working again as I now receive the "DeviceArrived" callback.

Firmly back on terra-firma, I next installed the Desktop Video 10.4.3. At this point, the switcher software can see I have a capture device again. So I am going to try to replicate my problem with 6.4.1 and 10.4.3.

Thanks for the input, I'll post my results.

No luck.

With some twiddling, I can still get the BMDStreamingServer to freakout. Once I have it wigged out, it will never fire another packet but it's memory footprint grows steadily larger and larger. The only thing I can do is kill the process and relaunch it. It's weird.

[Nicholas Gill]

Hi George,

Thanks for trying 10.4.3, sorry it wasn't resolved, this must be a distinct issue.

If you have some sample code or steps which can reproduce the issue, please send it through to developer support (the email address is on page 13 of the Desktop Video SDK Manual).

The issue can then be identified and addressed.

Cheers,

-nick

Replicating this in a fashion that I could send to the development guys would be almost impossible. When I test my code discretely each 'piece' appears to work fine. It's only when the whole thing is assembled that I can manage to get this leak to occurr. (I recognize that would seem to point the finger at my code rather than Blackmagic, but I'll be darned if I can figure out what is causing this.)

As an added bonus to my mystery problem:

After my recent update to 6.4.1, my COM3 (USB to Serial) stopped working. So I casually uninstalled and re-installed the drivers (which must be a 'certain version' or it stops working). No problem, my COM3 came right back to life. Of course, ATEM now reports I have no capture devices.

So I re-install the ATEM software, and now my COM3 no longer works. Arrrrgh.

Nicholas,

After some installing and uninstalling and re-installing... I was able to deduce that the newer versions of the ATEM software (6.4/6.5) seem to conflict with my USBtoSerial adapter. Since using the newer versions did not seem to impact my original problem one way or another, I decided to drop back to my originally installed version of 6.0 (with Desktop Video 10.1.4).

I then spent some time combing through my code and experimenting looking for details that might give me some idea of why I could randomly get the BMDStreamingServer.exe to start leaking memory. I finally had a eureka moment and am now able to replicate the issue on demand. Even better, I was able to isolate the issue is external to my code, as I can get the same thing to happen using the ATEM Software Control.

I prepared two short youtube videos that demonstrate how to get the ATEM software control to trigger the BMDStreamingServer.exe to start leaking. Basically, the short version is this: if the capture is stopped during a period of high CPU utilization, the leak will exhibit itself.

My development environment may be more susceptible to this problem as I am running within a Windows 8.1 virtual machine on my MacBook Pro. The VM (hosted by Fusion 6) is an i7 but only a single core. I'm not sure if Intel ever manufactured a single core i7 (I kind of doubt it), so it may be the developers have made some threading assumptions that should be OK in the 'real world' but do not hold up when virtualizing. Unfortunately, I do not currently have physical hardware available to test this on real iron.

To see a demonstration of the leak and how to replicate it, visit:

Thanks for you help!

PS.

I will also put the above into an email for developer support as you suggested.