Hi Folks, I've finally got around to knocking up a patch for the video.h file that adds necessary functionality to the Linux DVB V4 API. The changes are listed below. This is in conjunction with the discussions I have had with JS of subject matter "V4 Video API Questions" in the middle of July. Please feel free to make relevant comments and changes. 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. 2. Added extra option DVB_VIDEO_ERROR_COUNT to "dvb_video_status" to allow an error count to be returned using the DVB_VIDEO_GET_STATUS ioctl. The count should automatically be reset in the driver after every read. User-space application(s) can then perform the necessary timing to determine whether the incoming bitstream is of good quality or not. This would typically be tied into a video h/w interrupt where each "error" interrupt (e.g. sequence header error) would then increment an internal counter. 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 basic sequence header data is available (e.g. H&W, aspect ratio). This is needed as the underlying hardware may (and mine does) setup the afd or other information prior to the sequence header data becoming available. 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). 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: a) DVB_VIDEO_UNSCALED: the video decoder should NOT perform any scaling/image manipulation on the transmitted image (other than necessary expansion for SIF material). b) DVB_VIDEO_LETTERBOX16_9: for a 16:9 transmitted image to be displayed on a 4:3 screen, the video decoder should scale to a 16:9 letterbox with black bars at the top/bottom of the frame. c) DVB_VIDEO_LETTERBOX14_9: for a 16:9 transmitted image to be displayed on a 4:3 screen, the video decoder should scale to a 14:9 letterbox. Here some of the original image will be lost (the left/right sides), but there will be smaller black bars at the top/bottom of the frame than in 16:9 letterbox mode. d) DVB_VIDEO_PAN_SCAN: for a 16:9 transmitted image to be displayed on a 4:3 screen, the video decoder will perform a cut-out using pan-scan vectors if available. If no pan-scan vectors are present in the bitstream, then a centre cut-out of the image will take place. e) DVB_VIDEO_CENTER_CUT_OUT: for a 16:9 transmitted image to be displayed on a 4:3 screen, the video decoder will perform a centre cut-out of the image. Any pan-scan vectors in the bitstream will be ignored. f) DVB_VIDEO_PILLARBOX: for a 4:3 transmitted image to be displayed on a 16:9 screen, black vertical bars will appear at the left/right sides of the viewed image. This is necessary as some display devices cannot properly reduce the width of the picture to accurately display a central 4:3 image. g) DVB_VIDEO_SCALE16_9: for a 16:9 letterbox image in a transmitted 4:3 frame, the video decoder should scale the image so that it appears as a full 16:9 image on a 16:9 screen (MPEG 4:3, AFD2). h) DVB_VIDEO_SCALE14_9: for a 16:9 letterbox image, shoot and protect 14:9 in a transmitted 4:3 frame, the video decoder should scale the image to 14:9 so that it appears correctly on a 4:3 screen (MPEG 4:3, AFD6). In this mode, some of the original image will be lost (the left/right sides), but there will be much smaller top/bottom black bars than if the video decoder had not performed any image manipulation at all. i) DVB_VIDEO_SCALE4_3: for a 16:9 letterbox image, shoot and protect 4:3 in a transmitted 4:3 frame, the video decoder should scale the image so that is appears correctly on a 4:3 screen. In this mode, some of the original image will be lost (the left/right sides), but there will not be any black bars present at the top/bottom of the viewed 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. 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. 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. 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. Any problems or comments, please let me know. Best Regards, Rob : ) (See attached file: patch_video.h.gz)
Attachment:
patch_video.h.gz
Description: Binary data