- Posts: 13
- Joined: Thu Feb 13, 2020 7:32 pm
- Real Name: Reuven Wachtfogel
This bug has been very elusive but I think I finally tracked it down and can properly describe it. It does not happen for 1080i50. I've reproduced it with small changes to the SDK sample programs and these changes are described below.
SDK 11.5
Ubuntu 18.04.4
Decklink Monitor Mini <--> Decklink Recorder Mini
1) Firstly, I need to point out the following small bug in the RP188VitcOutput.cpp sample program.
scheduleNextFrame() takes the completed frame, sets the new timecode, and schedules the same frame again. So if the last frame had a RP188VITC1 timecode on it, and now I set the RP188VITC2, the new frame will actually have both. In fact every frame has both VITC1 and VITC2 because of this bug. (This is actually correct behaviour for interlaced modes but not for other modes)
I only mention this bug because it hid the main bug - the Capture sample program seemed to be working but was in fact just printing out RP188VITC1 - not RP188VITC2.
2) I modified RP188VitcOutput.cpp to work in 720p50 mode as follows.
3) I modified Capture.cpp so that it explicitly prints out RP188VITC1 and RP188VITC2 instead of just RP188VITCAny as follows.
4) Result:
As you can see, even though RP188VITC1, RP188VITC2 are actually requested on every frame (as I explained in #1), it only ever sees the RP188VITC1 timecodes.
5) BTW, in my own code I do create a new frame each time and alternate between RP188VITC1 and RP188VITC2 as per spec but still no RP188VITC2 values arrive at the other side - only RP188VITC1.
SDK 11.5
Ubuntu 18.04.4
Decklink Monitor Mini <--> Decklink Recorder Mini
1) Firstly, I need to point out the following small bug in the RP188VitcOutput.cpp sample program.
scheduleNextFrame() takes the completed frame, sets the new timecode, and schedules the same frame again. So if the last frame had a RP188VITC1 timecode on it, and now I set the RP188VITC2, the new frame will actually have both. In fact every frame has both VITC1 and VITC2 because of this bug. (This is actually correct behaviour for interlaced modes but not for other modes)
I only mention this bug because it hid the main bug - the Capture sample program seemed to be working but was in fact just printing out RP188VITC1 - not RP188VITC2.
2) I modified RP188VitcOutput.cpp to work in 720p50 mode as follows.
- Code: Select all
// Video mode parameters
// const BMDDisplayMode kDisplayMode = bmdModeHD1080i50;
// const BMDVideoOutputFlags kOutputFlags = bmdVideoOutputRP188;
// const BMDPixelFormat kPixelFormat = bmdFormat10BitYUV;
// // Frame parameters
// const INT32_UNSIGNED kRowBytes = 5120;
// Video mode parameters
const BMDDisplayMode kDisplayMode = bmdModeHD720p50;
const BMDVideoOutputFlags kOutputFlags = bmdVideoOutputRP188;
const BMDPixelFormat kPixelFormat = bmdFormat10BitYUV;
// Frame parameters
const INT32_UNSIGNED kRowBytes = ((1280 + 47) / 48) * 128;
3) I modified Capture.cpp so that it explicitly prints out RP188VITC1 and RP188VITC2 instead of just RP188VITCAny as follows.
- Code: Select all
const char *timecodeString_bmdTimecodeRP188VITC1 = NULL;
const char *timecodeString_bmdTimecodeRP188VITC2 = NULL;
if (g_config.m_timecodeFormat != 0) {
IDeckLinkTimecode *timecode;
if (videoFrame->GetTimecode(bmdTimecodeRP188VITC1, &timecode) == S_OK {
timecode->GetString(&timecodeString_bmdTimecodeRP188VITC1);
}
if (videoFrame->GetTimecode(bmdTimecodeRP188VITC2, &timecode) == S_OK {
timecode->GetString(&timecodeString_bmdTimecodeRP188VITC2);
}
}
printf("Frame received (#%lu) [%s:%s] - %s - Size: %li bytes\n",
g_frameCount,
timecodeString_bmdTimecodeRP188VITC1 != NULL ? timecodeString_bmdTimecodeRP188VITC1 : "No vitc1 timecode",
timecodeString_bmdTimecodeRP188VITC2 != NULL ? timecodeString_bmdTimecodeRP188VITC2 : "No vitc2 timecode",
rightEyeFrame != NULL ? "Valid Frame (3D left/right)" : "Valid Frame",
videoFrame->GetRowBytes() * videoFrame->GetHeight());
if (timecodeString_bmdTimecodeRP188VITC1)
free((void*)timecodeString_bmdTimecodeRP188VITC1);
if (timecodeString_bmdTimecodeRP188VITC2)
free((void*)timecodeString_bmdTimecodeRP188VITC2);
4) Result:
- Code: Select all
./Capture -d 0 -m -1 -p 1 -t rp188
...
Frame received (#207) [00:00:08:10:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
Frame received (#208) [00:00:08:10:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
Frame received (#209) [00:00:08:11:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
Frame received (#210) [00:00:08:11:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
Frame received (#211) [00:00:08:12:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
Frame received (#212) [00:00:08:12:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
Frame received (#213) [00:00:08:13:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
Frame received (#214) [00:00:08:13:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
Frame received (#215) [00:00:08:14:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
Frame received (#216) [00:00:08:14:No vitc2 timecode] - Valid Frame - Size: 2488320 bytes
As you can see, even though RP188VITC1, RP188VITC2 are actually requested on every frame (as I explained in #1), it only ever sees the RP188VITC1 timecodes.
5) BTW, in my own code I do create a new frame each time and alternate between RP188VITC1 and RP188VITC2 as per spec but still no RP188VITC2 values arrive at the other side - only RP188VITC1.