[linux-dvb] Re: V4 Video API Questions

[Rob.McConnell@Zarlink.Com]

linux-dvb-bounce@linuxtv.org wrote on 15/07/2004 13:42:40:

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

OK, the clearing of the video rate buffer is fine.  However, with MHEG
applications we find that the last frame can be displayed before the new
one has been decoded and displayed.  How about we add a new type to
"dvb_video_still_format" called "DVB_VIDEO_STILL_YUV" that will allow any
YUV image to be displayed (common on STB hardware rather than JPEG)?  We
could then use this to display splash screens as well as blanking the
current display frame buffer.

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

This is an area that probably needs a look at if DirectFB is not to be used
(we don't currently use DirectFB).  Currently our h/w automatically
performs the required scaling and with a little prod it can perform the
centre cut-out (4:3 and 14:9) and letter-box modes quite happily.  So I
would be quite happy to keep the presentation/legacy scaling ioctl for the
moment as it allows MHEG applications to specify what "decoder format
conversion" to take as well as the user's preference for displaying 4:3
content in a 16:9 frame.  It also allows a hook for us to take the
appropriate action depending on the received AFDs.  For example, we can
read back the AFD information and then decide what presentation format to
display.

BTW, would it be useful to have an ioctl somewhere in the API to setup the
WSS in the CVBS line 23?  This would allow an MHEG application or AFD to
set the appropriate WSS for a connected analogue chassis.

Cheers,

Rob : )