Gerd Knorr wrote:
Oh, and speaking of digital things, will there be V4L2_STD #defines for
the various digital broadcast standards? Or should we create a new ioctl
for that?
What exactly do you have in mind?
Mostly I was just confused by the "ANALOG VIDEO STANDARD" comment above
the V4L2_STD #defines. Maybe "MODULATION STANDARDS" would be better.
HDTV? Probably. Which ones we need?
V4L2_STD_ATSC_8_VSB
V4L2_STD_ATSC_16_VSB
Those don't imply any particular frame rate, resolution, or
interlaced/progressive, BTW; just the modulation.
DVB? Don't think so, there is a API for dvb already.
OK, found it. It looks like some of that could be merged into V4L2
(except for the demux and conditional access stuff), but it's probably
not be worth the effort. It doesn't look like ATSC could be supported by
the DVB API, so I think we should make V4L2 the API for that.
Others?
I did some research and it looks like we have most of ATSC/HDTV covered
already. The remaining issues are:
- Support for the different frame rates (23.976, 24, 29.97, 30, 59.94,
60). I mentioned this in the message I just addressed to Michael.
- Query/selection of subchannels. That only applies to hardware that
demuxes the MPEG transport stream itself. We can add ioctls for that later.
- Selection of AC3 substreams. Same deal.
- A way to query signal strength (is v4l2_tuner.signal boolean, like
v4l2_input.signal?) and demodulator status (PLL lock, EQU lock, etc...).
Important since ATSC terrestrial reception is so flaky :)
--
Mark McClelland
mark@xxxxxxxxxxxxxxxx
