[linux-dvb] More V4 Video API Q's

[Rob.McConnell@Zarlink.Com]

Hi Folks,

Been looking at the video driver a bit more and have the following points
to make:

1) Most STB hardware has a video decoder and video scaler (either in one
block or two).  Now, the current V4 API doesn't handle requests to size the
screen to say 1/4 size, or 1/16 size or 2x size _and_ to position it.  I
think we should add these to the existing video.h header file and add a
capabilities flag to check whether the underlying hardware can scale and
position the video.  This would be preferred over having a separate video
scaler API and device node.

Could we extend dvb_video_presentation_format?

DVB_VIDEO_SCALE_1_2 to mean scale the video to 1/2 the horizontal width and
1/2 the vertical height (i.e. quarter screen)
DVB_VIDEO_SCALE_1_4 to mean scale the video to 1/4 the horizontal width and
1/4 the vertical height (i.e. sixteenth sized screen).
DVB_VIDEO_SCALE_2     to mean scale the video to 2 times the horizontal
width and 2 times the vertical height.

We would also need a DVB_VIDEO_SET_POSITION ioctl to position the small
scaled video correctly or to depict what area of the original picture
should be scaled to 2 x the size.  Horizontal units in pixels and vertical
units in lines starting at the top left-hand corner of the screen.

By doing this, we would also allow them to appear in the capabilities
check.  We could also assume that if we can scale the video to a small
picture or zoom in, then we can position it correctly on the screen,
without the need for an extra capability flag.  Does this sound reasonable?


2) The video decoder/scaler can usually blank the video so that on channel
changes you get a clean switch.  Usually the OSD is still enabled so that
you get some indication of what channel you are changing from/to.  The
video.h file does not currently have an ioctl to allow the video to be
blanked/unblanked.  I propose we add an ioctl such as

"DVB_VIDEO_SET_BLANK"

passing an enum for either blanking the video (1) or unblanking it (0).  Is
this OK?

3) I would like to see a DVB_VIDEO_EXIT or DVB_VIDEO_DEINIT ioctl that
unblocks all processes sleeping on wait queues so that they can be woken up
prior to the driver being closed.  For example,  if you have multiple
threads that access the video device and one is blocked on the
DVB_VIDEO_GET_EVENT ioctl, then when the user-space application calls
"close", the actual close function will NOT be called until all threads
have exited.  By calling DVB_VIDEO_EXIT or DVB_VIDEO_DEINIT first, all
threads can be terminated in a controlled fashion and the close syscall can
then complete.  I have used this method on current drivers and works very
well indeed.  Maybe we should reflect this ioctl in other drivers as well?

4) I noticed that we have a DVB_AUDIO_SET_SYNC ioctl but not one for the
video.  The current h/w that I am working with can have either the video or
the audio decoder as master with the other decoder slaving to it.
Shouldn't we have a DVB_VIDEO_SET_SYNC ioctl to enable/disable sync if
video is the master?

5) What is the purpose of the DVB_VIDEO_SET_REF_STC ioctl?  Does it simply
provide a link between the demux device that extract the PCR values to
update an internal STC and the video device that looks at these STC values
to know when to present the video frames (STC/PTS comparison)?  Most STB
hardware I know automatically forwards the internal STC values on to the
associated decoders after filtering on the PCR pid.  Is this ioctl really
only needed for PC DVB cards that don't have an on-board MPEG decoder(s)
and thus require a handle to get the PCR/STC values?

6) Should the ioctl "DVB_VIDEO_STEP" block until the next frame is
available, or should an event be set to indicate this?   If an event is to
be signalled, then this should be added to "dvb_video_event_type".

7) In the enum "dvb_video_status", we have a DVB_VIDEO_SCREEN_ASPECT_RATIO
reference which is no longer needed.  Can we delete this please?

8) In the enum "dvb_video_status" we have a DVB_VIDEO_ASPECT_RATIO and
DVB_VIDEO_SIZE enums.  If we can read back this information anyway by using
the ioctl "DVB_VIDEO_GET_SEQHDR", then should these enums be deprecated or
should the DVB_VIDEO_GET_SEQHDR ioctl be removed?

9) Can we add a type DVB_VIDEO_PRESENTATION_FORMAT enum to
"dvb_video_status" so that we can read back the current presentation
format?


That's all for now.  Any comments/suggestions would be great and I
certainly don't mind generating a new patch.

Cheers,

Rob : )