From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Hans de Goede <hdegoede@redhat.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: LibV4L2 and CREATE_BUFS issues
Date: Sun, 14 Dec 2014 09:24:19 -0500 [thread overview]
Message-ID: <548D9D93.1080301@collabora.com> (raw)
In-Reply-To: <548D5D26.5080504@redhat.com>
Le 2014-12-14 04:49, Hans de Goede a écrit :
> Ah yes I see, so I assume that if libv4l where to return a failure for
> CREATE_BUFS when conversion is used, that gstreamer will then fallback to
> a regular REQUEST_BUFS call ?
>
> Then that indeed seems the best solution, can you submit patch for this ?
Exactly, that should work. My concern with application side workaround
would that the day someone implements CREATE_BUF support in v4l2 this
application won't benefit without patching. I'll see if I can find time,
disabling it seems faster then implementing support for it, specially
that current experiment show that the jpeg code is really fragile.
Current state is that libv4l2 is causing a buffer overflow, so it is
harmful library in that sense.
This raise a concern, it would mean that USERPTR, DMABUF, CREATE_BUFS
will now be lost (in most cases) when enabling libv4l2. This is getting
a bit annoying. Specially that we are pushing forward having m2m
decoders to only be usable through libv4l2 (HW specific parsers). Is
there a long term plan or are we simply pushing the dust toward libv4l2 ?
cheers,
Nicolas
next prev parent reply other threads:[~2014-12-14 14:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-10 16:27 LibV4L2 and CREATE_BUFS issues Nicolas Dufresne
2014-12-13 10:41 ` Hans de Goede
2014-12-13 16:15 ` Nicolas Dufresne
2014-12-14 9:49 ` Hans de Goede
2014-12-14 14:24 ` Nicolas Dufresne [this message]
2014-12-15 15:58 ` Hans de Goede
2014-12-15 16:35 ` Nicolas Dufresne
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=548D9D93.1080301@collabora.com \
--to=nicolas.dufresne@collabora.com \
--cc=hdegoede@redhat.com \
--cc=linux-media@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.