Hi Johannes, Please see attached patch and comments below. : ) js@convergence.de wrote on 05/08/2004 13:29:36: > 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. Please see attached patch file (gzipped to prevent Notes from messing it up). > > > > > 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. OK, that's fine. The patch file still leaves this functionality present so that it is easy to delete the ioctl/functionality if need be. > > > > > 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. OK, I've updated the patch to make it all bitmasks. ;^) Cheers, Rob : ) (See attached file: video2.patch.gz)
Attachment:
video2.patch.gz
Description: Binary data