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

[Johannes Stezenbach <js@convergence.de>]

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?

> 2. Added extra option DVB_VIDEO_ERROR_COUNT to "dvb_video_status" to allow

OK

> 3. Added AFD (active format descriptor) field to the
> "dvb_video_sequence_header" struct with extensions flag to indicate the
> presence of this user-data.
> I have also added a flag DVB_VIDEO_SEQUENCE_HDR that signals whether the

OK

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


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

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

> 6) I have added a new option DVB_VIDEO_STILL_YUV that allows a YUV image to
> be displayed using the DVB_VIDEO_STILLPICTURE ioctl.

OK.

> 7) I have added an explicit ioctl "DVB_VIDEO_CLEAR_FRAME_BUF" that clears
> the frame buffer(s) to black.  This is quite useful when handling MHEG
> applications, on channel changes and starting/stopping the video decoder.

OK.

> 8) Finally, I have added a new enum "dvb_video_video_format" to the
> "dvb_video_sequence_header" struct. This allows the video format (e.g.
> PAL/NTSC/SECAM....) to be determined.

OK.


Regards,
Johannes