[linux-dvb] Re: [PATCH] Video V4 API

[Rob.McConnell@Zarlink.Com]

Hi Johannes,

js@convergence.de wrote on 05/08/2004 12:00:12:

> Hi Rob,
>
> Rob.McConnell@Zarlink.Com wrote:
> > 1. Added extra option DVB_VIDEO_CAP_PROFILE_LEVEL to capabilities to
allow
> > the decoder's profile@level upper operation to be determined using the
> > ioctl DVB_VIDEO_GET_CAPS.  Armed with this information, you can then
decide
> > whether the incoming bitstream can be fully, partially or not decoded.
>
> Shouldn't that be a bitset, or is it a requirement that a
> decoder that handles e.g. MP@ML can handle all profiles
> below it?

It might make more sense to have a bitmask as not all profile@levels are
scalable.  I just referred to the ISO/IEC13818-2 doccy Table 8-15 that
nicely refers to what decoder options are available. Shall I make a new
patch against your original source code?

> > Another point worth mentioning is that I use the DVB_VIDEO_GET_EVENT
ioctl
> > in a way in which I pass in what event I am interested in and go to
sleep
> > until that event becomes available.  For example, when I am looking for
a
> > change in AFD information in the bitstream, I will pass the
> > DVB_VIDEO_GET_EVENT ioctl "DVB_VIDEO_SEQUENCE_HEADER_CHANGED" to signal
> > that this process is only interested in looking for a change in the
> > sequence header structure.  When any sequence header change occurs,
then
> > the process is woken up and I then read the AFD information along with
the
> > aspect ratio from the sequence header (if available).
>
> Hm, I'm not sure about this. For once, it doesn't work with poll(),
> you'd need a thread that blocks waiting for the event. And what would
> happen if one thread blocks waiting for one type of event, and another
> thread poll()s for events? Messy...
>
> IMHO the whole thing works best when there's exactly one userspace
> consumer for all types of video events, and then the event filter
> capability is not needed.

OK, from this angle I agree. No problem here as there is no change to the
API.

>
>
> > 4. I have added new presentation formats to
"dvb_video_presentation_format"
> > to help follow the DTG recommended guidelines on aspect ratio
signalling.
> > They are as follows:
>
> Hm, that's directly from the AFD spec, isn't it?
> Well, OK, but doesn't it make the DVB_VIDEO_SET_SCREEN_ASPECT_RATIO
> ioctl superflous?

Good point.  Yes it does make this ioctl irrelevant now - shall we remove
it?  I guess we could also change the name from presentation format to dfc
(decoder format conversion) as this is what the decoder is doing to the
incoming image.

>
>
> > 5) I have also added the capability to determine what presentation
formats
> > the video decoder can support.  This is achieved by passing
> > DVB_VIDEO_CAP_PRESENTATION_FORMAT to the DVB_VIDEO_GET_CAPS ioctl.  The
> > "val" field will then have a bitmask of what presentation formats it
can
> > handle.  User-space applications can then determine the best method of
> > displaying images for a certain screen.
>
> OK, but why not drop enum dvb_video_cap_presentation_format and make
> enum dvb_video_presentation_format a bitset?

Could do.  I just didn't want to allow the user the option of setting more
than one presentation/dfc format at the same time and the driver having
additional sanity checks.  What do you think?

Cheers,

Rob ; )