Linux-Media Archive on
 help / color / Atom feed
From: Hans Verkuil <>
To: Linux Media Mailing List <>
Cc: Alexandre Courbot <>,
	Laurent Pinchart <>,
	Jacopo Mondi <>,
	Tomasz Figa <>
Subject: Re: [ANN] Topics for a media summit in Lyon in October
Date: Fri, 16 Aug 2019 10:10:47 +0200
Message-ID: <> (raw)
In-Reply-To: <>

On 8/16/19 10:06 AM, Hans Verkuil wrote:
> Rather then discussing topics for a meeting under the subject 'Lisbon'
> let's start a new thread referring to the right place :-)
> I will try to organize a room, either during the ELCE or (if that doesn't
> work) perhaps on the Thursday afterwards. If that's going to be a problem
> for someone, please let me know.
> I do need to know how many people I can expect. I have the following
> confirmed attendees (and please reply if you are not listed!):
> Alexandre Courbot <>
> Tomasz Figa <>
> Jacopo Mondi <>
> Laurent Pinchart <>
> Hans Verkuil <>
> I know there were more who mentioned on irc that they would attend,
> but it is easier to keep track if I have it in an email.
> Topics posted under the previous thread:
> Tomasz:
> I would want to discuss various v4l2_buffer improvements, e.g.
> - DMA-buf import with plane offsets,
> - unifying the buffer structs for M and non-M formats,
> - ability to import different FDs with offsets for non-M formats if the
> layout matches driver expectations, etc.
> Besides that, I would be interested in the general idea on handling
> complex cameras in the Linux kernel in spite of the remaining V4L2
> limitations, e.g.
> - combinatorial explosion of /dev/video nodes,
> - significant ioctl overhead,
> - huge amount of historical legacy making the driver and userspace
> implementations overly difficult and prone to repetitive mistakes,
> - the above also limiting the flexibility of the API - formats, frame
> rates, etc. set using distinct APIs, not covered by Request API, with
> non-failure "negotiation hell", etc.
> - lack of fences, etc.

Tomasz, I am not sure if this is suitable for a media summit: my feeling
is that this is much more suitable for a three day brainstorming session.

My 'roadmap' was to get the codec support sorted first, then start working
on this.



> Jacopo:
> Apart from discussing libcamera and hope we could kickstart a review of
> its API, I would like to re-start discussing multiplexed stream support,
> but that would require Sakari to be there, something I'm not certain
> about. Sakari?
> Alexandre:
> If Collabora/Bootlin is there, I'd certainly want to discuss stateless
> codecs, in particular m2m codec helpers and finalize the specification
> in general.
> Regards,
> 	Hans

  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  8:06 Hans Verkuil
2019-08-16  8:10 ` Hans Verkuil [this message]
2019-08-16  8:22   ` Tomasz Figa
2019-08-16  8:31     ` Hans Verkuil
2019-08-16  9:37 ` Mauro Carvalho Chehab
2019-08-19  7:44 ` Hans Verkuil
2019-08-19 14:43   ` Ezequiel Garcia
2019-08-19 15:04     ` Laurent Pinchart
2019-08-19 15:24       ` Eugen.Hristev
2019-08-19 15:51         ` Laurent Pinchart

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Media Archive on

Archives are clonable:
	git clone --mirror linux-media/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-media linux-media/ \
	public-inbox-index linux-media

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox