Re: Supporting 3D formats in V4L2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux