From: Hans Verkuil <hverkuil@xs4all.nl>
To: Hugues FRUCHET <hugues.fruchet@st.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>,
Oliver Schinagl <oliver+list@schinagl.nl>,
media-workshop <media-workshop@linuxtv.org>,
Benjamin Gaignard <benjamin.gaignard@linaro.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [media-workshop] Agenda for the Edinburgh mini-summit
Date: Mon, 09 Sep 2013 12:32:53 +0200 [thread overview]
Message-ID: <522DA3D5.100@xs4all.nl> (raw)
In-Reply-To: <7020EDD3BA6FF244B3C070FA4F02B1D8014BF87CBC46@SAFEX1MAIL2.st.com>
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
next prev parent reply other threads:[~2013-09-09 10:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-30 13:01 Agenda for the Edinburgh mini-summit Hans Verkuil
2013-08-30 13:21 ` Oliver Schinagl
2013-08-30 13:31 ` Mauro Carvalho Chehab
2013-08-30 16:54 ` [media-workshop] " Laurent Pinchart
[not found] ` <CACHYQ-qyuP+MjWNc7bVHhUa0xxzQHEmb3JFe+9n6C0GzOnj54A@mail.gmail.com>
2013-08-31 0:03 ` Laurent Pinchart
[not found] ` <CACHYQ-qDD5S5FJvzT-oUBe+Y+S=CB_ZN+QNQPpu+BFE-ZPr45g@mail.gmail.com>
2013-08-31 20:19 ` Laurent Pinchart
[not found] ` <CA+M3ks7whrGtkboVcstoEQBRTkiLGF7Hf9nEsYEkyUD6=QPG9w@mail.gmail.com>
2013-09-04 10:48 ` Mauro Carvalho Chehab
2013-09-05 11:37 ` Hugues FRUCHET
2013-09-06 13:45 ` Laurent Pinchart
2013-09-07 9:31 ` Pawel Osciak
2013-09-10 9:44 ` Laurent Pinchart
2013-09-09 10:32 ` Hans Verkuil [this message]
2013-09-10 7:36 ` Hugues FRUCHET
2013-09-10 7:54 ` Hans Verkuil
2013-08-30 13:54 ` Hans Verkuil
2013-08-31 6:43 ` Hans Verkuil
2013-08-31 18:38 ` [media-workshop] " Guennadi Liakhovetski
2013-08-31 20:25 ` Laurent Pinchart
2013-08-31 20:36 ` Guennadi Liakhovetski
2013-09-01 11:13 ` Hans Verkuil
2013-08-31 14:40 ` Sakari Ailus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=522DA3D5.100@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=benjamin.gaignard@linaro.org \
--cc=hugues.fruchet@st.com \
--cc=linux-media@vger.kernel.org \
--cc=m.chehab@samsung.com \
--cc=media-workshop@linuxtv.org \
--cc=oliver+list@schinagl.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox