[linux-dvb] Re: V4 Video API Questions

[Johannes Stezenbach <js@convergence.de>]

Rob.McConnell@Zarlink.Com wrote:
> js@convergence.de wrote on 15/07/2004 15:15:29:
> 
> 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?

Yes.

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

Hm, le tme think some more about this. Maybe we shouldn't mix video
user data with the other event stuff?

Is there any other use for video user data besides AFD?
If yes, what would the processing look like, as opposed to AFD?
What data rate is to be expected for video user data, and
how many events per sec.?

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

The intention is that the decoder keeps running on FREEZE, just the
display won't get updated. Thus CONTINUE will work without further
delays. And FREEZE will stop instantly on any frame.

Johannes