[EMAIL PROTECTED] wrote: > [EMAIL PROTECTED] wrote on 15/07/2004 13:42:40:
Who's that? > > [EMAIL PROTECTED] 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
