We are working in a live environment where frames drops or signal loss may occur, for instance when cables get unplugged for any reason. We want to add some fault resistance on SDI and LTC signals in dvs_sdi.
Regarding SDI, looking into the code, I'm afraid that either a watchdog thread has to be added, or that FIFO reading must be changed to non-blocking, which would introduce some latency.
Can you give me some advice before I start implementing ?
Thanks,
Guhlda
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes but.. replacement is not real-time at all. We need to get black frame immediately. Problem is that the SDK does not handle this properly and returns no proper error code.
I have implemented a watchdog system which uses the timing between sv_fifo_getbuffer() to detect capture problems, and writes black frames to the shared memory.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No sv_fifo_getbuffer() does not indicate loss of video everytime (for instance when AES audio is not in sync with Video). Also the reaction time is too long (we need a frame of a black frame every 40ms), and finally I'm not sure dvs_sdi adds the proper number of black frames.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My observations: when SDI is unplugged, about 12 frames are returned by sv_fifo_getbuffer() before it returns SV_ERROR_INPUT_VIDEO_NOSIGNAL. These frames are returned with bad (unchanged) content, and notably too early, every 15-30ms instead of 40ms (25fps). My watchdog uses this characteristic to (hack) write black frames.
It is some time I have not synchronized my code with Ingex main branch, it might take me some time to reintegrate and send my contribution to Ingex.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The real fix should happen in DVS driver/library which doesn't raise the problem properly. Now to face this problem I have added a kind of watchdog thread to each channel. This channel checks the timing of arrival of each frames and writes black frames in case of problem.
My version of dvs_sdi.cpp has quite many other new features.
Guhlda
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We are working in a live environment where frames drops or signal loss may occur, for instance when cables get unplugged for any reason. We want to add some fault resistance on SDI and LTC signals in dvs_sdi.
Regarding SDI, looking into the code, I'm afraid that either a watchdog thread has to be added, or that FIFO reading must be changed to non-blocking, which would introduce some latency.
Can you give me some advice before I start implementing ?
Thanks,
Guhlda
dvs_sdi already handles interrupted SDI by replacing missed frames with "No video" caption.
See function wait_for_good_signal() etc.
Yes but.. replacement is not real-time at all. We need to get black frame immediately. Problem is that the SDK does not handle this properly and returns no proper error code.
I have implemented a watchdog system which uses the timing between sv_fifo_getbuffer() to detect capture problems, and writes black frames to the shared memory.
Could you explain further? The return code of sv_fifo_getbuffer() does indicate loss of video.
No sv_fifo_getbuffer() does not indicate loss of video everytime (for instance when AES audio is not in sync with Video). Also the reaction time is too long (we need a frame of a black frame every 40ms), and finally I'm not sure dvs_sdi adds the proper number of black frames.
My observations: when SDI is unplugged, about 12 frames are returned by sv_fifo_getbuffer() before it returns SV_ERROR_INPUT_VIDEO_NOSIGNAL. These frames are returned with bad (unchanged) content, and notably too early, every 15-30ms instead of 40ms (25fps). My watchdog uses this characteristic to (hack) write black frames.
It is some time I have not synchronized my code with Ingex main branch, it might take me some time to reintegrate and send my contribution to Ingex.
Any news about this problem already?
We have it too.
Yes,
The real fix should happen in DVS driver/library which doesn't raise the problem properly. Now to face this problem I have added a kind of watchdog thread to each channel. This channel checks the timing of arrival of each frames and writes black frames in case of problem.
My version of dvs_sdi.cpp has quite many other new features.
Guhlda