RE: Fourcc for multiplanar formats

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

 



Hi,

I think all of the planar pix format defined in videodev2.h are contiguous in memory. So I would suggest adding some suffix to indicate this so that it is obvious to application users.

>What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.?

Not sure what Hans mean by the 2P or 3P extensions since NV16 has 2 planes. Why do we want to re-define NV12 and NV12_2P since it can cause backward compatibility issues. Why don't we keep existing naming convention for
contiguous formats and add a suffix for indicating the planes are not
contiguous. 

For example

V4L2_PIX_FMT_NV16 vs V4L2_PIX_FMT_NV16_NC where NC - Non Contiguous

Just my thoughts...

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-karicheri2@xxxxxx

>-----Original Message-----
>From: linux-media-owner@xxxxxxxxxxxxxxx [mailto:linux-media-
>owner@xxxxxxxxxxxxxxx] On Behalf Of Hans Verkuil
>Sent: Wednesday, February 17, 2010 1:22 PM
>To: Pawel Osciak
>Cc: linux-media@xxxxxxxxxxxxxxx; Sylwester Nawrocki; 'Kamil Debski'
>Subject: Re: Fourcc for multiplanar formats
>
>On Monday 15 February 2010 17:27:46 Pawel Osciak wrote:
>> Hello,
>>
>> we would like to ask for suggestions for new fourcc formats for
>multiplanar buffers.
>>
>> There are planar formats in V4L2 API, but for all of them, each plane X
>"immediately
>> follows Y plane in memory". We are in the process of testing formats and
>V4L2 extensions
>> that relax those requirements and allow each plane to reside in a
>separate area of
>> memory.
>>
>> I am not sure how we should name those formats though. In our example, we
>are focusing
>> on the following formats at the moment:
>> - YCbCr 422 2-planar (multiplanar version of V4L2_PIX_FMT_NV16)
>> - YCbCr 422 3-planar (multiplanar version of V4L2_PIX_FMT_YUV422P)
>> - YCbCr 420 2-planar (multiplanar version of V4L2_PIX_FMT_NV12)
>> - YCbCr 420 3-planar (multiplanar version of V4L2_PIX_FMT_YUV420)
>>
>>
>> Could anyone give any suggestions how we should name such formats and
>what to pass to
>> the v4l2_fourcc() macro?
>
>What about V4L2_PIX_FMT_NV16_2P, V4L2_PIX_FMT_YUV422P_3P, etc.?
>
>What we pass to the fourcc macro is not very important IMHO. As long as it
>is unique.
>
>Regards,
>
>	Hans
>
>>
>>
>> Best regards
>> --
>> Pawel Osciak
>> Linux Platform Group
>> Samsung Poland R&D Center
>>
>>
>> --
>> 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
>>
>>
>
>--
>Hans Verkuil - video4linux developer - sponsored by TANDBERG
>--
>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
--
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