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

[Johannes Stezenbach <js@convergence.de>]

Rob.McConnell@Zarlink.Com wrote:
> js@convergence.de wrote on 05/08/2004 12:00:12:
> > 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?

Yes, that would be great.

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

I have no objections, but I'd like to wait on input from the
toshiba guys on this topic.

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

I think the implementation will already be implemented using
switch() or similar, so sanity checks come for free. It might
be confusing if something which looks as a bitset cannot be
used that way, but we already do the same with other enums.

Johannes