Re: Supporting 3D formats in V4L2

Re: Supporting 3D formats in V4L2

[Hans Verkuil]

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

Re: Supporting 3D formats in V4L2

[Soby Mathew]

Hi Hans
Thanks for your comments.

Best Regards
Soby Mathew

On Mon, Jul 23, 2012 at 6:14 PM, Hans Verkuil <hverkuil@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
//vger.kernel.org/majordomo-info.html

Re: Supporting 3D formats in V4L2

[Hans Verkuil]

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
> 

Re: Supporting 3D formats in V4L2

[Soby Mathew]

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

Re: Supporting 3D formats in V4L2

[Hans Verkuil]

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 <hverkuil@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 majordomo@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Supporting 3D formats in V4L2

[Soby Mathew]

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.

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 <hverkuil@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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: Supporting 3D formats in V4L2

[Hans Verkuil]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Supporting 3D formats in V4L2

[Hans Verkuil]

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

Supporting 3D formats in V4L2

[Soby Mathew]

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