[linux-dvb] Re: V4 Video API Questions

[Rob.McConnell@Zarlink.Com]

js@convergence.de wrote on 15/07/2004 15:15:29:

> Rob.McConnell@Zarlink.Com wrote:
>
> > linux-dvb-bounce@linuxtv.org wrote on 15/07/2004 13:42:40:
>
> Who's that?

Don't know. ;^) Stupid Lotus Notes strikes again!

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

Will do.

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

Sounds good to me. I currently do the same on a STOP.

BTW, I noticed that the "video_format" field of the "sequence display
extension" data is not stored in the "dvb_video_sequence_header" structure.
Should we add this so that we know whether we are in PAL/SECAM/NTSC/etc
modes?

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

Looks like this one is "sewn-up" : )

I also have another question with regards to the operation of the
"DVB_VIDEO_GET_EVENT" ioctl. Does the call take into account the event
"type" and a process then blocks waiting for just that event type to occur?
Does it block waiting for any event type to occur?  Can multiple
calls/processes waiting on _different_ event types be allowed (i.e.
separate wait queue for each event type)?

The reason why I ask this is because it would be useful to allow waiting on
a change of user-data in the bitstream (to obtain a change in AFD for
example).  However, the user-data's length is not defined so you don't know
the amount of user-data until it arrives.  What I was intending on
providing (of course if you agree), was an extra event
"DVB_VIDEO_USER_DATA_HEADER_CHANGED" flag and a new user-data event
structure
such as this:

struct dvb_video_user_data_header {
    uint8_t byte_count;
    uint8_t *data;
};

In this way you can specify the number of bytes of user-data to compare in
the ioctl call with the data returned where *data points to (obviously with
appropriate "copy_from_user" and "copy_to_user" functions).  The ioctl
would also return with "byte_count" being updated with the actual number of
bytes received by the hardware (for use in later calls perhaps). This of
course relies on the fact that the ioctl call _looks_ at the event type
field to determine the appropriate action.  Is this the intention? If not,
can we have it work this way?

Oh, yeah there's yet another question I need to ask ;^)

Does the "DVB_VIDEO_FREEZE" ioctl stop on a reference frame (I or P) or
does it stop on a B-frame?  If it can stop on a B-frame, then what is the
difference between this ioctl and "DVB_VIDEO_STOP"?  Does
"DVB_VIDEO_FREEZE" just freeze the display frame but the video decoder
keeps running in the background?

Does "DVB_VIDEO_CONTINUE" start playing back immediately or should it wait
until you have received say 2 reference frames first to ensure that no
artifacts are generated?  I guess these questions are related to how we
describe/comment the ioctl functions, as they are probably h/w dependent.

Thanks Again,

Rob : )