[linux-dvb] Re: V4 Video API Questions

[Rob.McConnell@Zarlink.Com]

Hi yet again,

Time for another chat to myself again ; ^ )

I was doing some more thinking about the different presentation formats
i.e. "dvb_video_presentation_format".  Now we are assuming that for
"DVB_VIDEO_LETTER_BOX" that this will only provide a 16:9 letter-box image.
However, we should also support the option of a 14:9 letter-box image as
per the DTG recommendations on AFD handling.  I therefore recommend we have
the options:

"DVB_VIDEO_LETTER_BOX_16_9" and "DVB_VIDEO_LETTER_BOX_14_9" to distinguish
between these 2 formats.

Also with regards to "DVB_VIDEO_CENTER_CUT_OUT" this is assuming that are
taking a 4:3 central cut-out from the frame.  You can of course have a 14:9
cut-out if you refer to the DTG spec.  So again I recommend we have:

"DVB_VIDEO_CENTER_CUT_OUT_4_3" and "DVB_VIDEO_CENTER_CUT_OUT_14_9".

Could you also let me know why you have an exclusive option called
"DVB_VIDEO_PAN_SCAN".  Personally I would have this as a flag to indicate
whether cut-outs follow the pan/scan vectors in the bitstream or not.  So
this would complement the 4:3 and 14:9 cut-outs rather than being an
exclusive option which I believe is incorrect.

As always, its nice to hear from you DVBers.

Cheers,

Rob :  )






                                                                           
             rob.mcconnell@Zar                                             
             link.Com                                                      
             Sent by:                                                   To 
             linux-dvb-bounce@         rob.mcconnell@Zarlink.Com           
             linuxtv.org                                                cc 
                                       linux-dvb@linuxtv.org               
                                                                   Subject 
             14/07/04 17:02            [linux-dvb] Re: V4 Video API        
                                       Questions                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           








Hi Again,

Thinking through a bit  more I think Q3 should probably use
"DVB_VIDEO_GET_EVENT" instead of "DVB_VIDEO_GET_STATUS" to obtain a count
of errors in a fixed time interval (say 1s).  This could BLOCK until the
time interval had elapsed (time between calling the ioctl and 1s elapsed).

Rob : )





             rob.mcconnell@Zar
             link.Com
             Sent by:                                                   To
             linux-dvb-bounce@         linux-dvb@linuxtv.org
             linuxtv.org                                                cc

                                                                   Subject
             14/07/04 16:22            [linux-dvb] V4 Video API Questions














Hi ML,

Had a quick look through the latest V4 API header files for the video
driver and have a few questions to ask.

Q1: Do we have a capability ioctl that allows us to query what "Profiles
and levels" the decoder can support?  For example, it would be useful to
know whether various Chrominance formats (e.g. 4:2:0, 4:2:2 and 4:4:4)
could be decoded and whether HDTV could be decoded.

Q2: Does the ioctl "DVB_VIDEO_CLEAR_BUFFER" clear out the rate-buffer or
the frame buffers or both?  When handling MHEG applications that can
display I-frames, it is necessary to clear out the frame buffer(s) to
prevent the I-frame from continuously being displayed when you change to a
channel that does NOT have a video PID.  The ability to clear out the
rate-buffer is necessary on manual channel change to prevent the last
program's data being left in the buffer/pipeline and being decoded before
the data from the new program has arrived at the input to the decoder.

It might be useful to have a couple of ioctls here.  One to clear out the
rate-buffer and another to clear out the frame buffer(s).

Q3: Could we extend the "DVB_VIDEO_GET_STATUS" ioctl to provide information
about the quality of the incoming PES in terms of the number of errors per
time interval?  For example, it would be useful to know how many sequence
header errors were obtained in a fixed time interval to provide some
indication back to user-space.  If this is too restrictive of the
underlying hardware, then could we couple this with a generic error/quality
measurement maybe with a capability ioctl that describes whether we can
actually obtain this measurement?

Q4: We require the ability to extract the user-data from the PES/ES.  This
usually contains the AFD (active format descriptor) that is used in the UK
to determine what is the format of a region of interest within the frame.
For example, you might have a 4:3 pillarbox active area of interest within
a 16:9 frame.  All the hardware I know "dumps" the user-data into memory
for later retrieval by a process (with an interrupt to signify the write).
Could we add a new ioctl "DVB_VIDEO_GET_USER_DATA" that allows this data to
be retrieved?  We would also need to add a "dvb_video_event" flag to
indicate the presence of new user_data.

Please refer to the DTG document at "
http://www.dtg.org.uk/publications/books/afd.pdf";  for more details on AFD
recommendations.

Q5: Looking at the "dvb_video_presentation_format" enum, what is the
difference between "DVB_VIDEO_PAN_SCAN" and "DVB_VIDEO_CENTER_CUT_OUT"?  Is
"DVB_VIDEO_PAN_SCAN" a centre cut-out with pan/scan vectors applied?

Q6: There seems to be no capability of telling the decoder to perform 14:9
scaling.  This again is a recommendation by the DTG in conjunction with AFD
handling.  It is a "half-way house" means of optimally displaying an active
area of interest suitably on either a 4:3 or 16:9 tube.  Please refer to
the DTG document in Q4 for more details.

Look forward to hearing your response.

Cheers,

Rob :  )