BlackMagic Intensity pro Audio Crash VideoInputFrameArrived

Hi,
I am having a crash in the BlackMagic Code below. The code is crashing in when i try to access the audioFramePtr but it works 85% of the time. I only see crash randomly. My questions are
1) Is there something wrong I am doing in the code
2) Could the code be crashing because the function is taking too long? I do some analysis on each frame and that could take time.
3) Am i missing any other code that should be included in this code?

Please let me know.


void IDeckLinkInputCallback.VideoInputFrameArrived(IDeckLinkVideoInputFrame videoFrame, IDeckLinkAudioInputPacket audioPacket)
{

bool isVideoPresent = true;
if (videoFrame != null)
{
currentFrameWidth = videoFrame.GetWidth();
currentFrameHeight = videoFrame.GetHeight();
currentRowBytes = videoFrame.GetRowBytes();
frameBytesYUV = new byte[currentRowBytes * currentFrameHeight];
_BMDFrameFlags flags = videoFrame.GetFlags();
if (flags != _BMDFrameFlags.bmdFrameFlagDefault)
{
isVideoPresent = false;
}
videoFrame.GetBytes(out videoFramePtr);
Marshal.Copy(videoFramePtr, frameBytesYUV, 0, currentRowBytes * currentFrameHeight);

if (audioPacket != null)
{
currentAudioSampleCount = audioPacket.GetSampleFrameCount();
audioPacket.GetBytes(out audioFramePtr);
}
FrameArivedEvent(new FrameEventArgs(currentFrameWidth, currentFrameHeight, currentRowBytes, frameBytesYUV, videoFramePtr, audioFramePtr, currentAudioSampleCount, isVideoPresent));
Marshal.FinalReleaseComObject(videoFrame);
}


if (audioPacket != null)
{
Marshal.FinalReleaseComObject(audioPacket);
}
FrameCounter++;



}

[Nicholas Gill]

Hi Jobin,

Since the declaration for audioFramePtr is not shown as local to the function shown, I guess it may be a member variable of the class.

On that assumption, audioFramePtr will be left with an indeterminate value if the audioPacket is NULL.

It is recommended that processing in the context of the VideoInputFrameArrived callback should be kept to a minimum to avoid affecting the capture operation. The generally recommended approach is to push the captured video/audio onto a queue and use a worker thread to perform the processing. The depth of the queue can then be controlled by the application.

In this example, if the FrameArivedEvent method performs significant processing, it is expected that the capture operation would be affected, and video and audio will be dropped to compensate - the application will receive a NULL audioPacket in VideoInputFrameArrived, audioFramePtr remains pointing to invalid memory from a previous call, then I guess FrameArivedEvent will attempt to dereference audioFramePtr as it is non-NULL, resulting in undefined behaviour / crash.

Cheers,

-nick