On Tue 10 September 2013 09:36:00 Hugues FRUCHET wrote: > Thanks Hans, > > Have you some implementation based on meta that we can check to see code details ? Not as such. Basically you just add another pixelformat define for a multiplanar format. And you define this format as having X video planes and Y planes containing meta data. > It would be nice to have one with noticeable amount of code/processing made on user-land side. > I'm wondering also how libv4l is selecting each driver specific user-land plugin and how they are loaded. libv4l-mplane in v4l-utils.git is an example of a plugin. Documentation on the plugin API seems to be sparse, but Hans de Goede, Sakari Ailus or Laurent Pinchart know a lot more about it. There are (to my knowledge) no plugins that do exactly what you want, so you're the first. But it has been designed with your use-case in mind. Regards, Hans > > BR. > -----Original Message----- > From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx] > Sent: lundi 9 septembre 2013 12:33 > To: Hugues FRUCHET > Cc: Mauro Carvalho Chehab; Oliver Schinagl; media-workshop; Benjamin Gaignard; linux-media@xxxxxxxxxxxxxxx > Subject: Re: [media-workshop] Agenda for the Edinburgh mini-summit > > Hi Hugues, > > On 09/05/2013 01:37 PM, Hugues FRUCHET wrote: > > Hi Mauro, > > > > For floating point issue, we have not encountered such issue while > > integrating various codec (currently H264, MPEG4, VP8 of both Google > > G1 IP & ST IPs), could you precise which codec you experienced which > > required FP support ? > > > > For user-space library, problem we encountered is that interface > > between parsing side (for ex. H264 SPS/PPS decoding, slice header > > decoding, references frame list management, ...moreover all that is > > needed to prepare hardware IPs call) and decoder side (hardware IPs > > handling) is not standardized and differs largely regarding IPs or > > CPU/copro partitioning. This means that even if we use the standard > > V4L2 capture interface to inject video bitstream (H264 access units > > for ex), some proprietary meta are needed to be attached to each > > buffers, making de facto "un-standard" the V4L2 interface for this > > driver. > > There are lots of drivers (mostly camera drivers) that have non-standard > video formats. That's perfectly fine, as long as libv4l plugins/conversions > exist to convert it to something that's standardized. > > Any application using libv4l doesn't notice the work going on under the > hood and it will look like a standard v4l2 driver. > > The multiplanar API seems to me to be very suitable for these sort of devices. > > > Exynos S5P MFC is not attaching any meta to capture input > > buffers, keeping a standard video bitstream injection interface (what > > is output naturally by well-known standard demuxers such as gstreamer > > ones or Android Stagefright ones). This is the way we want to go, we > > will so keep hardware details at kernel driver side. On the other > > hand, this simplify drastically the integration of our video drivers > > on user-land multimedia middleware, reducing the time to market and > > support needed when reaching our end-customers. Our target is to > > create a unified gstreamer V4L2 decoder(encoder) plugin and a unified > > OMX V4L2 decoder(encoder) to fit Android, based on a single V4L2 M2M > > API whatever hardware IP is. > > > > About mini summit, Benjamin and I are checking internally how to > > attend to discuss this topic. We think that about half a day is > > needed to discuss this, we can so share our code and discuss about > > other codebase you know dealing with video codecs.> > > We are getting a lot of topics for the agenda and half a day for one topic > seems problematic to me. > > One option is to discuss this in a smaller group a day earlier (October 22). > We might be able to get a room, or we can discuss it in the hotel lounge or > pub :-) or something. > > Another option is that ST organizes a separate brainstorm session with a > few core developers. We done that in the past quite successfully. > > 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
