[linux-dvb] Re: V4 Video API Questions

[Johannes Stezenbach <js@convergence.de>]

Rob.McConnell@Zarlink.Com wrote:

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

Who's that?

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

I have no objections about YUV images. Please send a patch.

I think our current drivers clear the fram buffer as a side effect of
doing VIDEO_STOP/VIDEO_PLAY. We might as well offer this functionality
explicitly, but I#m not sure.

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

OK. I won't mind if you send a patch for that, too.

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

Please take a look at linux/dvb/vbi.h.


Johannes