[linux-dvb] Re: V4 Video API Questions

[Johannes Stezenbach <js@convergence.de>]

Rob.McConnell@Zarlink.Com wrote:
> 
> 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.

Probably not a bad idea. Do you care to send a patch?

> 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).

The intention for DVB_VIDEO_CLEAR_BUFFER is to clear the rate buffer,
and reset the decoder state so it waits for the next sequence header
before continuing, but not to clear the frame buffer. So that the
current frame is displayed until the next frame has succesfully
been decoded. If you want to hide the last frame, simply disable
the video scaler (using DirectFB or some other API).

> 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?

Might be useful. However I suppose most hardware just offers an error
irq and one has to do the counting oneself, so I would just add a
call to read the counter, and let userspace do the timing/calculation.
Do you care to send a patch for the API?

> 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.

I don't care about AFD atm, but as you seem to do: Do you care
to send a patch with an API proposal?

> 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.

The presentation/scaling stuff is a legacy API, mainly intended
for av7110 based cards together with v4l/v4l2.
For STBs stuff we use DirectFB to set the scaler, giving us full control.
(Scaler control is not part of the DVB API; I suppose a simple
character device could be used instead of DirectFB for scaler control.)

Regards,
johannes