- Posts: 9
- Joined: Mon Sep 21, 2015 2:01 pm
Wed Sep 23, 2015 2:45 pm
Hi,
I’m hoping I can get some help debugging an issue with the H.264 Pro Recorder. I have spent some time searching the forums but nothing seems to be related to my issue.
The issue exists in legacy code that I did not write (and that I admittedly don’t completely understand yet), so I can forward more details if needed.
We have a video recorder app which we’ve made for the South African Rugby Union to record games for analysis.
It’s a Windows Media Foundation app that implements a custom media source, which uses the decklink API (SDK 9.7) to capture data from an H.264 Pro recorder.
The issue is that we sometimes randomly stop receiving data from the recorder, sometimes after over an hour of successful recording.
In an effort to understand what's going on I've logged every call to and from the decklink API. The calls follow the example set in section 2.3.4.1 of the sdk documentation “Streaming Encoding Capture” i.e. I make calls to:
IBMDStreamingDeviceInput::GetVideoEncodingModePresetIterator
IBMDStreamingDeviceInput::DoesSupportVideoEncodingMode
IBMDStreamingDeviceInput::SetVideoEncodingMode
IBMDStreamingDeviceInput::SetCallback
IBMDStreamingDeviceInput::StartCapture
(I could forward a log of exactly which calls I make and in which order if that would help)
I then receive data on IBMDStreamingH264InputCallback::H264[NAL|Audio]PacketArrived. On the client’s setup, this data sometimes stops arriving, even though I don’t see any other callbacks (errors/state changes) in the logs.
I know this could well be a WMF threading issue or something else, but my questions are:
Are there any known issues/common mistakes which could cause recording to abort even after it has successfully started and run for an extended time?
Are there any known issues/suggestions for writing WMF media sources which use the API?
How can I confirm that the device/API is working properly and the problem lies in our code?
Should I perhaps update to the latest version of the SDK?
Any pointers as to where to start debugging this issue would be much appreciated.
I’m hoping I can get some help debugging an issue with the H.264 Pro Recorder. I have spent some time searching the forums but nothing seems to be related to my issue.
The issue exists in legacy code that I did not write (and that I admittedly don’t completely understand yet), so I can forward more details if needed.
We have a video recorder app which we’ve made for the South African Rugby Union to record games for analysis.
It’s a Windows Media Foundation app that implements a custom media source, which uses the decklink API (SDK 9.7) to capture data from an H.264 Pro recorder.
The issue is that we sometimes randomly stop receiving data from the recorder, sometimes after over an hour of successful recording.
In an effort to understand what's going on I've logged every call to and from the decklink API. The calls follow the example set in section 2.3.4.1 of the sdk documentation “Streaming Encoding Capture” i.e. I make calls to:
IBMDStreamingDeviceInput::GetVideoEncodingModePresetIterator
IBMDStreamingDeviceInput::DoesSupportVideoEncodingMode
IBMDStreamingDeviceInput::SetVideoEncodingMode
IBMDStreamingDeviceInput::SetCallback
IBMDStreamingDeviceInput::StartCapture
(I could forward a log of exactly which calls I make and in which order if that would help)
I then receive data on IBMDStreamingH264InputCallback::H264[NAL|Audio]PacketArrived. On the client’s setup, this data sometimes stops arriving, even though I don’t see any other callbacks (errors/state changes) in the logs.
I know this could well be a WMF threading issue or something else, but my questions are:
Are there any known issues/common mistakes which could cause recording to abort even after it has successfully started and run for an extended time?
Are there any known issues/suggestions for writing WMF media sources which use the API?
How can I confirm that the device/API is working properly and the problem lies in our code?
Should I perhaps update to the latest version of the SDK?
Any pointers as to where to start debugging this issue would be much appreciated.