Re: [PATCH RFC 0/4] V4L2: Vendor specific media bus formats/ frame size control

[Nicolas THERY <nicolas.thery@st.com>]

Hello,

Thanks for your reply.  I overlooked this sensor packages multiple streams in a
single DT.  It seems indeed that Sakari's RFC would not help.

Best regards,

On 2012-08-29 23:51, Sylwester Nawrocki wrote:
> Hi Nicolas,
> 
> On 08/27/2012 05:48 PM, Nicolas THERY wrote:
>> Hello,
>>
>> On 2012-08-23 11:51, Sylwester Nawrocki wrote:
>>> This patch series introduces new image source class control - V4L2_CID_FRAMESIZE
>>> and vendor or device specific media bus format section.
>>>
>>> There was already a discussion WRT handling interleaved image data [1].
>>> I'm not terribly happy with those vendor specific media bus formats but I
>>> couldn't find better solution that would comply with the V4L2 API concepts
>>> and would work reliably.
>>
>> What about Sakari's "Frame format descriptors" RFC[1] that would allow to
>> describe arbitrary pixel code combinations and provide required information
>> (virtual channel and data type) to the CSI receiver driver for configuring the
>> hardware?
> 
> Thanks for reminding about this. The "Frame format descriptors" would not
> necessarily solve the main problem which I tried to address in this RFC.
> 
> The sensor in question uses single MIPI-CSI data type frame as a container
> for multiple data planes, e.g. JPEG compressed stream interleaved with YUV
> image data, some optional padding and a specific metadata describing the
> interleaved image data. There is no MIPI-CSI2 virtual channel or data type 
> interleaving. Everything is transferred on single VC and single DT.
> 
> Such a frames need sensor specific S/W algorithm do extract each component.
> 
> So it didn't look like the frame descriptors would be helpful here, since
> all this needs to be mapped to a single fourcc. Not sure if defining a
> "binary blob" fourcc and retrieving frame format information by some other
> means would have been a way to go.
> 
> I also had some patches adopting design from Sakari's RFC, for the case where
> in addition to the above frame format there was captured a copy of meta-data,
> (as in the frame footer) send on separate DT (Embedded Data). And this was
> mapped to 2-planar V4L2 pixel format. Even then I used a sensor specific
> media bus code.
> 
> In the end of the day I switched to a single-planar format as it had all 
> what's needed to decode the data. And the were some H/W limitations on using
> additional DT. 
> 
> The frame format descriptors might be worth to work on, but this doesn't 
> look like a solution to my problem and it is going to take some time to get 
> it right, as Sakari pointed out.
> 
> --
> 
> Regards,
> Sylwester
>