[linux-dvb] V4 Video API Questions

[Rob.McConnell@Zarlink.Com]

Hi ML,

Had a quick look through the latest V4 API header files for the video
driver and have a few questions to ask.

Q1: Do we have a capability ioctl that allows us to query what "Profiles
and levels" the decoder can support?  For example, it would be useful to
know whether various Chrominance formats (e.g. 4:2:0, 4:2:2 and 4:4:4)
could be decoded and whether HDTV could be decoded.

Q2: Does the ioctl "DVB_VIDEO_CLEAR_BUFFER" clear out the rate-buffer or
the frame buffers or both?  When handling MHEG applications that can
display I-frames, it is necessary to clear out the frame buffer(s) to
prevent the I-frame from continuously being displayed when you change to a
channel that does NOT have a video PID.  The ability to clear out the
rate-buffer is necessary on manual channel change to prevent the last
program's data being left in the buffer/pipeline and being decoded before
the data from the new program has arrived at the input to the decoder.

It might be useful to have a couple of ioctls here.  One to clear out the
rate-buffer and another to clear out the frame buffer(s).

Q3: Could we extend the "DVB_VIDEO_GET_STATUS" ioctl to provide information
about the quality of the incoming PES in terms of the number of errors per
time interval?  For example, it would be useful to know how many sequence
header errors were obtained in a fixed time interval to provide some
indication back to user-space.  If this is too restrictive of the
underlying hardware, then could we couple this with a generic error/quality
measurement maybe with a capability ioctl that describes whether we can
actually obtain this measurement?

Q4: We require the ability to extract the user-data from the PES/ES.  This
usually contains the AFD (active format descriptor) that is used in the UK
to determine what is the format of a region of interest within the frame.
For example, you might have a 4:3 pillarbox active area of interest within
a 16:9 frame.  All the hardware I know "dumps" the user-data into memory
for later retrieval by a process (with an interrupt to signify the write).
Could we add a new ioctl "DVB_VIDEO_GET_USER_DATA" that allows this data to
be retrieved?  We would also need to add a "dvb_video_event" flag to
indicate the presence of new user_data.

Please refer to the DTG document at "
http://www.dtg.org.uk/publications/books/afd.pdf";  for more details on AFD
recommendations.

Q5: Looking at the "dvb_video_presentation_format" enum, what is the
difference between "DVB_VIDEO_PAN_SCAN" and "DVB_VIDEO_CENTER_CUT_OUT"?  Is
"DVB_VIDEO_PAN_SCAN" a centre cut-out with pan/scan vectors applied?

Q6: There seems to be no capability of telling the decoder to perform 14:9
scaling.  This again is a recommendation by the DTG in conjunction with AFD
handling.  It is a "half-way house" means of optimally displaying an active
area of interest suitably on either a 4:3 or 16:9 tube.  Please refer to
the DTG document in Q4 for more details.

Look forward to hearing your response.

Cheers,

Rob :  )