On 3/23/23 18:05, Hans Verkuil wrote:
On 03/03/2023 15:44, Hans Verkuil wrote:
Hi all,
I am planning to organize another Media Summit on June 26th, co-located
with the Embedded Open Source Summit in Prague:
https://events.linuxfoundation.org/embedded-open-source-summit/
I've put in a request for a room with the Linux Foundation and I am waiting
for the result of that. For once I was early with my request, so I have good
hope we'll get a room. Expect the format to be similar to what we did in
Dublin last year.
I'm a bit early with this 'Request for Topics' as well, but this allows
everyone who plans to be in Prague to take this into account.
So if you have a topic that you want to discuss, just reply. It would be
very much appreciated if you can also add a guesstimate of the time you
need for your topic.
Once I have the details of the room and how many people it can hold, then
I will send out a second email asking people to register with me if you
want to join.
Regarding remote participation: only if there is really no other way.
Meeting face-to-face once a year is important IMHO, and attending remotely
is a poor substitute. That said, if it is really necessary to set something
up, then I can do the same I did in Dublin, setting up a Webex meeting.
That worked reasonably well, except that I will need to bring a better
speaker since I learned that the laptop speaker was pretty bad.
So, if you have topics for the meeting, just reply!
Regards,
Hans
Discuss the "media: v4l2: Add extended fmt and buffer" patch series:
https://patchwork.linuxtv.org/project/linux-media/cover/20230206043308.28365-1-ayaka@xxxxxxxxxxx/
We've been postponing the work on this, but I think we need to decide how to
proceed since pixel formats and single vs multi planar is getting to be a nightmare.
Thank you for promoting this topic.
I may not be able to join there physically, I am sure I would be there
in virtual.
I would leave my outline here:
1. v4l2 header would only maintain the codec format and pixel format in bus.
2. the pixel formats would be maintained by the DirectRender, those M
variant would not be supported in the new extend pixel format API.
3. The number of plane for a pixel format would also responds for its
data layout. Ex. NV12 = 2 planes(luma, chroma), I420 = 3 planes(Y, U, V).
4. Userspace that supports new extend API could access those driver
didn't adapt the new API, kernel would have a backward compatible layer.
While the opposite backward compatible is not offered(old API userspace
can't access the driver support the new API).
[optional part]
5. An alloc flag would be introduced for allocating those M variant buf.
https://lore.kernel.org/lkml/20230322105226.122467-1-randy.li@xxxxxxxxxxxxx/
6. stateless codec format would be a modifier to the stateful codec
format. We could support different packing mode here.
I have some other topics for v4l2 which were less important than this
pain in the ass. I would discuss those in IRC(linux-media or gstreamer),
which have been sent to the mail list before.
1. separate buf queue for encoder reference bufs or decoder post
processing bufs.
DELETE_BUF or extend API
2. timestamp for tracking field or slices input bufs.
I would send the outline of those topics if people think any of them is
important.
Regards,
Hans
--
Hsia-Jun(Randy) Li
