Hi Jean-Marc, On 01/09/2015 05:38 PM, Jean-Marc VOLLE wrote: > Hello Hans! > Best wishes! You too. > > In reply to the below mail (sorry I do not know how to reply to mails I did not get but only found on the mail archive). > I think (reading the HDMI spec 1.4b) that in fact any of the V4L2_FIELD_3D_FRAME_PACK, V4L2_FIELD_3D_SBS_HALF, V4L2_FIELD_3D_TAB > may all be passed with interlaced or progressive content. > > Figure 8-5 3D structure (Side-by-Side (Half) ) states: "For interlaced formats, Vactive is number of active lines per field" > > p148 also lists primary 3D video format timings that show eg 1920 x 1080i @50Hz Side by Side > > Since you proposed initially to pass all 3D information in the enum > v4l2_field I think that at least SbS, TAB and FP shall be duplicated > with TB or BT attributes or a dedicated 3D only enum would have to be > created to reused interlaced/progressive information from enum > v4l2_field. What is your view on this? > Thanks for your comments. > JM A second field just for 3D information is not a good idea for two reasons: 1) The v4l2_buffer struct is very full, and adding another field there should only be done if there is no alternative. 2) I think it makes sense to extend v4l2_field: after all it describes how fields are stored in a buffer, and that fits very well with the 3D extension. In practice the FIELD_INTERLACED, FIELD_SEQ_TB/BT and FIELD_INTERLACED_TB/BT values will never be used with 3D formats. Those field values are specific to SDTV. For the new 3D field values you need to add two sets: one for progressive 3D (the equivalent to FIELD_NONE for normal 2D) and one for interlaced 3D (the equivalent to FIELD_ALTERNATE for normal 2D). Regards, Hans > > > > > > > Hi Soby! > > On Thu 19 July 2012 14:18:13 Soby Mathew wrote: >> Hi everyone, >> Currently there is limitation in v4l2 for specifying the 3D >> formats . In HDMI 1.4 standard, the following 3D formats are >> specified: > > > I think that this is ideal for adding to enum v4l2_field. > I've made some proposals below: > >> >> 1. FRAME_PACK, > > V4L2_FIELD_3D_FRAME_PACK (progressive) > V4L2_FIELD_3D_FRAME_PACK_TB (interlaced, odd == top comes first) > >> 2. FIELD_ALTERNATIVE, > > V4L2_FIELD_3D_FIELD_ALTERNATIVE > >> 3. LINE_ALTERNATIVE, > > V4L2_FIELD_3D_LINE_ALTERNATIVE > >> 4. SIDE BY SIDE FULL, > > V4L2_FIELD_3D_SBS_FULL > >> 5. SIDE BY SIDE HALF, > > V4L2_FIELD_3D_SBS_HALF > >> 6. LEFT + DEPTH, > > V4L2_FIELD_3D_L_DEPTH > >> 7. LEFT + DEPTH + GRAPHICS + GRAPHICS-DEPTH, > > V4L2_FIELD_3D_L_DEPTH_GFX_DEPTH > >> 8. TOP AND BOTTOM > > V4L2_FIELD_3D_TAB > > You would also need defines that describe which field is received for the field > alternative mode (it's put in struct v4l2_buffer): > > V4L2_FIELD_3D_LEFT_TOP > V4L2_FIELD_3D_LEFT_BOTTOM > V4L2_FIELD_3D_RIGHT_TOP > V4L2_FIELD_3D_RIGHT_BOTTOM > >> >> >> In addition for some of the formats like Side-by-side-half there are >> some additional metadata (like type of horizontal sub-sampling) > > A control seems to be the most appropriate method of exposing the > horizontal subsampling. > >> and >> parallax information which may be required for programming the display >> processing pipeline properly. > > This would be a new ioctl, but I think this should only be implemented if > someone can actually test it with real hardware. The same is true for the > more exotic 3D formats above. > > It seems SBS is by far the most common format. > >> >> I am not very sure on how to expose this to the userspace. This is an >> inherent property of video signal , hence it would be appropriate to >> have an additional field in v4l_format to specify 3D format. Currently >> this is a requirement for HDMI 1.4 Rx / Tx but in the future it would >> be applicable to broadcast sources also. >> >> In our implementation we have temporarily defined a Private Control to >> expose this . >> >> Please let me know of your suggestions . > > I hope this helps! > > Regards, > > Hans > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
