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

[Rob.McConnell@Zarlink.Com]

Hi Johannes,

Your keeping me busy bashing this keyb today!   ; ^ )

Johannes Stezenbach <js@linuxtv.org> wrote on 05/10/2004 23:42:39:

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

I'm happy with having a separate video scaler device that can be attached
to the output of any video decoder or rec-656 input, etc.  Each video
scaler device could have it's own set of capabilities.  I don't mind having
an API that allows any arbitrary source->destination window sizes.
However, this would make the current video ioctl
"DVB_VIDEO_SET_PRESENTATION_FORMAT" redundant in video.h and should really
be moved to this new scaler API instead.

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

Totally agree!  Allow it flexibility to choose it's input source and
capabilities.

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

The close() syscall will not actually call the code (release method) to
close the device down until the usage count in the "file" structure reaches
0.  This means if you either opened the device multiple times or called
clone()/fork() on the fd, then the usage count will be incremented.  Now in
you have called clone() (by calling "pthread_create" say), then the usage
count will have been incremented.  If the thread is blocking on an event,
then a close() syscall in the parent process will not evoke the release
method until the thread has exited.

There's no good putting code in the release method to unblock all threads
if you can't get to this code anyway.  That's why I've added an extra ioctl
to unblock any threads first so that when the close() syscall is evoked,
the actual release method will be run.

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

An app wouldn't want to swap between audio and video as masters.  However,
it seems symmetrical to have a video sync on/off ioctl.

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

OK, that's fine.

A few other comments to make on the video API:

(i) We have the ioctl "DVB_VIDEO_SET_SOURCE" that takes a structure
"dvb_video_source".  However, the desired format type is only relevant to
memory inputs, not demux.  Wouldn't it be cleaner to have the format and fd
as a union?

e.g. struct dvb_video_source {
        enum dvb_video_source_type type;
        union {
            enum dvb_video_source_format format;
            int fd;
        }u;
     }

(ii) Shouldn't the play state "enum dvb_video_play_state" have another
entry for when the decoder is in still picture mode?

That's all 4 now,

Rob : )