Re: Supporting 3D formats in V4L2
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Supporting 3D formats in V4L2
Hi Hans Thanks for your comments. Best Regards Soby Mathew On Mon, Jul 23, 2012 at 6:14 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Mon July 23 2012 14:35:14 Soby Mathew wrote: Hi Hans, Thanks for the reply and I was going through the HDMI1.4 spec again. The 'active space' is part of the Vactive and Vactive is sum of active video and active space. No, as I understand it active_space is just part of the active video. So the timings struct is fine, it's just that the height parameter for e.g. 720p in frame pack format is 2*720 + vfrontporch + vsync + vbackporch. That's the height of the frame that will have to be DMAed from/to the receiver/transmitter. In this case (assuming frame packed) the total height should be 2*720 + 30 + vfrontporch + vsync + vbackporch. Sorry, but if I am understanding you correct, in case of 3D frame packed format, the height field can be 'active video + active space'. Right. So the application need to treat the buffers appropriately according to the 3D format detected. Would this be a good solution? Right. So the application will need to obtain the timings somehow (either from v4l2-dv-timings.h, or from VIDIOC_G/QUERY_DV_TIMINGS) so it knows how to interpret the captured data and how large the buffer size has to be in the first place. I think it will all work out, but you would have to actually implement it to be sure I haven't forgotten anything. Frankly, I'd say that the frame_packed format is something you want to avoid :-) It's pretty weird. Regards, Hans I think the only thing that needs to be done is that the appropriate timings are added to linux/v4l2-dv-timings.h. Yes , the standard 3 D timings need to be added to this file which can be taken up. Regards, Hans Best Regards Soby Mathew -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Supporting 3D formats in V4L2
Hi Hans, Thanks for the reply and I was going through the HDMI1.4 spec again. The 'active space' is part of the Vactive and Vactive is sum of active video and active space. No, as I understand it active_space is just part of the active video. So the timings struct is fine, it's just that the height parameter for e.g. 720p in frame pack format is 2*720 + vfrontporch + vsync + vbackporch. That's the height of the frame that will have to be DMAed from/to the receiver/transmitter. In this case (assuming frame packed) the total height should be 2*720 + 30 + vfrontporch + vsync + vbackporch. Sorry, but if I am understanding you correct, in case of 3D frame packed format, the height field can be 'active video + active space'. So the application need to treat the buffers appropriately according to the 3D format detected. Would this be a good solution? I think the only thing that needs to be done is that the appropriate timings are added to linux/v4l2-dv-timings.h. Yes , the standard 3 D timings need to be added to this file which can be taken up. Regards, Hans Best Regards Soby Mathew -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Supporting 3D formats in V4L2
On Mon July 23 2012 14:35:14 Soby Mathew wrote: Hi Hans, Thanks for the reply and I was going through the HDMI1.4 spec again. The 'active space' is part of the Vactive and Vactive is sum of active video and active space. No, as I understand it active_space is just part of the active video. So the timings struct is fine, it's just that the height parameter for e.g. 720p in frame pack format is 2*720 + vfrontporch + vsync + vbackporch. That's the height of the frame that will have to be DMAed from/to the receiver/transmitter. In this case (assuming frame packed) the total height should be 2*720 + 30 + vfrontporch + vsync + vbackporch. Sorry, but if I am understanding you correct, in case of 3D frame packed format, the height field can be 'active video + active space'. Right. So the application need to treat the buffers appropriately according to the 3D format detected. Would this be a good solution? Right. So the application will need to obtain the timings somehow (either from v4l2-dv-timings.h, or from VIDIOC_G/QUERY_DV_TIMINGS) so it knows how to interpret the captured data and how large the buffer size has to be in the first place. I think it will all work out, but you would have to actually implement it to be sure I haven't forgotten anything. Frankly, I'd say that the frame_packed format is something you want to avoid :-) It's pretty weird. Regards, Hans I think the only thing that needs to be done is that the appropriate timings are added to linux/v4l2-dv-timings.h. Yes , the standard 3 D timings need to be added to this file which can be taken up. Regards, Hans Best Regards Soby Mathew -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Supporting 3D formats in V4L2
On Fri July 20 2012 07:23:32 Soby Mathew wrote: Hi Hans, I think your solution is appropriate. I agree to your suggestions. Regarding the 'active space' issue for 3D formats, I was studying the currently the v4l2_bt_timings structure. The Vtotal is calculated for 2D timings as : tot_height = height + vfrontporch + vsync + vbackporch + il_vfrontporch + il_vsync + il_vbackporch In case of 3D, the Vtotal would be dependent on the 3D format. No, as I understand it active_space is just part of the active video. So the timings struct is fine, it's just that the height parameter for e.g. 720p in frame pack format is 2*720 + vfrontporch + vsync + vbackporch. That's the height of the frame that will have to be DMAed from/to the receiver/transmitter. I think the only thing that needs to be done is that the appropriate timings are added to linux/v4l2-dv-timings.h. Regards, Hans For FRAME PACK progressive tot_height = height + active_space + vfrontporch + vsync + vbackporch FRAME PACK interlace tot_height = height + active_space1 + active_space2 + vfrontporch + vsync + vbackporch FIELD_ALTERNATIVE tot_height = height + active_space1 + active_space2 + vfrontporch1 + vfrontporch2+ vsync1 + vsync2 + vbackporch1 + vbackporch2 All the other 3D formats would fall into one of the categories above. Either v4l2_bt_timings structure has to be expanded to accommodate for 3D timings, or a new structure can be defined for the same. Best Regards Soby Mathew On Thu, Jul 19, 2012 at 7:36 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Thu 19 July 2012 15:41:07 Hans Verkuil wrote: 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) BTW, I'm not really sure at the moment how to handle the 'active space'. I guess the application will have to use the DV_TIMINGS ioctls to discover the vertical blanking size and use that to interpret the captured data. We would also have to add new 3D timings to linux/v4l2-dv-timings.h. Regards, Hans 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Supporting 3D formats in V4L2
Hi everyone, Currently there is limitation in v4l2 for specifying the 3D formats . In HDMI 1.4 standard, the following 3D formats are specified: 1. FRAME_PACK, 2. FIELD_ALTERNATIVE, 3. LINE_ALTERNATIVE, 4. SIDE BY SIDE FULL, 5. SIDE BY SIDE HALF, 6. LEFT + DEPTH, 7. LEFT + DEPTH + GRAPHICS + GRAPHICS-DEPTH, 8. TOP AND BOTTOM In addition for some of the formats like Side-by-side-half there are some additional metadata (like type of horizontal sub-sampling) and parallax information which may be required for programming the display processing pipeline properly. 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 . Best Regards Soby Mathew -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Supporting 3D formats in V4L2
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Supporting 3D formats in V4L2
On Thu 19 July 2012 15:41:07 Hans Verkuil wrote: 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) BTW, I'm not really sure at the moment how to handle the 'active space'. I guess the application will have to use the DV_TIMINGS ioctls to discover the vertical blanking size and use that to interpret the captured data. We would also have to add new 3D timings to linux/v4l2-dv-timings.h. Regards, Hans 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
