Hi Hans, On Mon, 28 Oct 2019 at 19:55, Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx> wrote: > > Hi Hans, > > On 10/17/19 1:25 PM, Hans Verkuil wrote: > > Hi all, > > > > Since we have three separate half-day sessions for different topics I decided > > to split the announcement for this in three emails as well, so these things > > can be discussed in separate threads. > > > > All sessions are in room Terreaux VIP Lounge - Level 0. > > There is a maximum of 15 people. > > > > The first session deals with the codec API and is on Tuesday morning from > > 8:30 to 12:00 (we have to vacate the room at that time). Note that 8:30 > > start time! > > > > Confirmed attendees for this session: > > > > Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> > > Alexandre Courbot <acourbot@xxxxxxxxxxxx> > > Nicolas Dufresne <nicolas@xxxxxxxxxxxx> > > Tomasz Figa <tfiga@xxxxxxxxxxxx> > > Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> > > Dafna Hirschfeld <dafna.hirschfeld@xxxxxxxxxxxxx> > > Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx> > > Maxime Ripard <mripard@xxxxxxxxxx> > > Dave Stevenson <dave.stevenson@xxxxxxxxxxxxxxx> > > Michael Tretter <m.tretter@xxxxxxxxxxxxxx> > > Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx> > > Hans Verkuil <hverkuil@xxxxxxxxx> > > > > Please let me know asap if I missed someone, or if you are listed, but > > can't join for some reason. > > I'll late for this session for unforeseen reasons (I stuck at Frankfurt > airport), please feel free to reallocate my seat for someone who > interested. Sorry for inconvenience. > > > > > There are three seats left, and I have five on the 'just interested' > > list: > > > > Daniel Gomez <daniel@xxxxxxxx> > > Eugen Hristev <Eugen.Hristev@xxxxxxxxxxxxx> > > Helen Koike <helen.koike@xxxxxxxxxxxxx> > > Jacopo Mondi <jacopo@xxxxxxxxxx> > > Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > > > If you still want to join, please mail me. First come, first served :-) > > > > Agenda: > > > > Note: I didn't assign start times, we'll just go through these items one-by-one. > > > > - Status of any pending patches related to codec support. > > I'll provide a list of those patches by the end of next week so we > > can go through them. > > > > - Requirements of moving codec drivers out of staging. > > > > - Finalize the stateful encoder API. There are two pieces that need > > to be defined: > > > > 1) Setting the frame rate so bitrate control can make sense, since > > they need to know this information. This is also relevant for the > > stateless codec (and this may have to change on a per-frame basis > > for stateless codecs!). > > > > This can either be implemented via ENUM_FRAMEINTERVALS for the coded > > pixelformats plus S_PARM support, or we just add a new control for this. > > E.g. V4L2_CID_MPEG_VIDEO_FRAME_INTERVAL using struct v4l2_fract. > > > > I am inclined to go with a control, since the semantics don't really > > match ENUM_FRAMEINTERVALS/S_PARM. These ioctls still need to be supported > > for legacy drivers. Open question: some drivers (mediatek, hva, coda) > > require S_PARM(OUTPUT), some (venus) allow both S_PARM(CAPTURE) and > > S_PARM(OUTPUT). I am inclined to allow both since this is not a CAPTURE > > vs OUTPUT thing, it is global to both queues. > > > > 2) Interactions between OUTPUT and CAPTURE formats. > > > > The main problem is what to do if the capture sizeimage is too small > > for the OUTPUT resolution when streaming starts. > > > > Proposal: width and height of S_FMT(OUTPUT) plus max-bitrate plus frame > > interval plus key frame interval info are used to calculate a minimum > > CAPTURE sizeimage (app may request more). This is codec-specific, I think, > > so it should be possible to provide helper functions for this. > > > > However, it may be quite difficult to make a good calculation. I just > > don't know enough to determine this. > > > > V4L2_FMT_FLAG_DYN_RESOLUTION is always cleared for codec formats > > for the encoder (i.e. we don't support mid-stream resolution > > changes for now) and V4L2_EVENT_SOURCE_CHANGE is not > > supported. > > > > Of course, if we start to support mid-stream resolution > > changes (or other changes that require a source change event), > > then this flag should be set by the encoder driver and > > documentation on how to handle the source change event should > > be documented in the encoder spec. I prefer to postpone this > > until we have an encoder than can actually do mid-stream > > resolution changes. > > > > If sizeimage of the OUTPUT is too small for the CAPTURE > > resolution and V4L2_EVENT_SOURCE_CHANGE is not supported, > > then the second STREAMON (either CAPTURE or OUTPUT) will > > return -ENOMEM since there is not enough memory to do the > > encode. > > > > If V4L2_FMT_FLAG_DYN_RESOLUTION is cleared (i.e. that is > > the case for all current encoders), then any bitrate controls > > will be limited in range to what the current state (CAPTURE and > > OUTPUT formats and frame interval) supports. > > > > - Stateless encoder support > > > > Overall goals: > > > > - Find out if there is a common set of per frame encoding parameters > > - Find out if bitrate control can be reused for multiple HW > > - Decide if we do in-kernel bitrate control or not > > - Decide if we keep bitstream header crafting external (unlike Hantro > > JPEG encoder, but like VAAPI) > > - Decide if we provide (and maintain) a libv4l2 plugin like ChromeOS > > folks opted for. > > > > I hope Nicolas and Tomasz can prepare for this. > > > > The one requirement that Cisco would have for these devices is that > > we must be able to do per-frame bitrate control from userspace. > > > > Regards, > > > > Hans > > > > -- > regards, > Stan Same here, I would like to know if there is more people you plan to add to the attendee's list. If not, I would like to be there. Thanks, Daniel
