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

[Johannes Stezenbach <js@linuxtv.org>]

On Mon, Sep 27, 2004 at 03:29:56PM +0000, Rob.McConnell@Zarlink.Com wrote:
> 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.

STB hardware I know has more than one MPEG decoder, and more than one
scaler, and certain restrictions on the scalers that makes you want
to be flexible wrt which decoder uses which scaler. Also, it is not
uncommon for scalers to support arbitrary scaling ratios.

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

IMHO it is more flexible to set the source rectangle (cut out from the
decoded stream) and the destination rectangle (position and size
on screen), and perhaps a clipping rectangle (adding black borders
inside the destination rectangle). DirectFB handles this.

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

DirectFB handles this.

Anyway, if it turns out that we add scaler control to the DVB API
I'd prefer to seperate it from the video decoder API.

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

That sounds totally bogus to me. If a thread blocking in some ioctl
prevents you from doing a close() in another thread (which could then
wake up the other thread) then our or your locking is broken.
Or maybe I didn't understand what you mean...

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

Hm, usually you sync to the STC for live decoding, and use video
or audio master (or async) for playback. You are right in that
the API does not allow you to chose video or audio master, however
I thought it is an implementation detail. Why would an application
want to switch the sync mode?

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

DVB_VIDEO_SET_REF_STC is for STB hw which can decode two complete
streams in parallel (i.e. two video, two audio, two PCR). E.g.
one for live TV, one for an analog VCR output. But supposedly
it is possible to decode and sync thwo videos to the same STC
(PIP with multi angle sports stuff), or have one video with two audio
channels (one normal, plus one with descriptive content/soudn effects
for visually impaired people). More theory than reality AFAIK, but that's
where the requirement comes from...

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

An event might be handy, but I guess in the normal use case
for DVB_VIDEO_STEP you don't really care...

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

I will have to look into that.

Regards,
Johannes