Difference between revisions of "SDI API"
| Line 9: | Line 9: | ||
* 10-bit capture (though this is easy to solve in V4L2) | * 10-bit capture (though this is easy to solve in V4L2) | ||
* Signals when frames are dropped (so alternative signals can be sent) | * Signals when frames are dropped (so alternative signals can be sent) | ||
| − | * An API for accessing VBI and HBI in 10-bit alongside the frame | + | * An API for accessing VBI and HBI in 10-bit alongside the frame for things like Closed captions |
| − | |||
Most of these issues are caused by the separation of Audio/Video/Blanking so the two solutions in that area could be accurate timestamps (using a 27mhz clock) or data returned multiplexed. Another way of solving the issue would be to have an SDI "pixel format" and userspace could parse the datastream itself as VLC does with the Computermodules SD-SDI driver. | Most of these issues are caused by the separation of Audio/Video/Blanking so the two solutions in that area could be accurate timestamps (using a 27mhz clock) or data returned multiplexed. Another way of solving the issue would be to have an SDI "pixel format" and userspace could parse the datastream itself as VLC does with the Computermodules SD-SDI driver. | ||
Revision as of 19:13, 26 September 2013
Thoughts about SDI API
There are a number of manufacturers using V4L2, sometimes alongside ALSA, to provide Linux drivers for their SDI cards. This causes a lot of issues for professional users. There are a number of proprietary APIs that provide a better interface for professional users. On the capture side they can be described as follows:
- Separate file descriptors for Audio/Video meaning sync must be performed with timestamps (if they exist; sometimes they don't). This is the most serious issue in a professional environment.
- Timestamps are sometimes generated with the system clock and do not reflect the way audio is transported in SDI, nor precise nature of NTSC timestamps.
- Impossible to select number of lines to capture per poll response (e.g x lines, one field, one frame)
- Impossible to keep NTSC audio samples per video frame cadence, nor line number where audio starts
- 10-bit capture (though this is easy to solve in V4L2)
- Signals when frames are dropped (so alternative signals can be sent)
- An API for accessing VBI and HBI in 10-bit alongside the frame for things like Closed captions
Most of these issues are caused by the separation of Audio/Video/Blanking so the two solutions in that area could be accurate timestamps (using a 27mhz clock) or data returned multiplexed. Another way of solving the issue would be to have an SDI "pixel format" and userspace could parse the datastream itself as VLC does with the Computermodules SD-SDI driver.
API thoughts
Single file descriptor. Open, setup options (pixel format etc), poll on descriptor with queued and dqueued mmapped buffers.
