On 9/23/19 12:02 PM, Jacopo Mondi wrote: > Hi Hans, > > On Mon, Sep 23, 2019 at 04:12:55PM +0200, 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 (tentative, might change) to 12:00 (we have to vacate the room at that >> 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> >> Daniel Gomez <daniel@xxxxxxxx> >> Dafna Hirschfeld <dafna.hirschfeld@xxxxxxxxxxxxx> >> Eugen Hristev <Eugen.Hristev@xxxxxxxxxxxxx> >> Paul Kocialkowski <paul.kocialkowski@xxxxxxxxxxx> >> Helen Koike <helen.koike@xxxxxxxxxxxxx> >> Michael Tretter <m.tretter@xxxxxxxxxxxxxx> >> Hans Verkuil <hverkuil@xxxxxxxxx> >> >> Tentative: >> >> Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> >> Jacopo Mondi <jacopo@xxxxxxxxxx> >> >> Jacopo, please confirm if you want to attend this session. I didn't find >> an email with explicit confirmation, so it was probably done via irc. But since >> this session is getting close to capacity I would prefer to keep attendance to >> those are actually working with codecs (or will work with it in the near future). > > I'm not really working on codecs, so if you're running almost at full > capacity please feel free to re-assign my seat. Same here, feel free to re-assign my seat. Thanks, Helen > > If there are free seats I might flock in, but without contributing too > much to the discussions :) > > Thanks > j > >> >> If I missed someone, or you are on the list but won't attend after all, then >> please let me know. >> >> >> >> Agenda: >> >> - Status of any pending patches related to codec support. >> >> - 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 and S_PARM support, or we just add a new control for this. >> E.g. V4L2_CID_MPEG_VIDEO_FRAME_INTERVAL (or perhaps FRAME_RATE). If we >> go for a control, then we need to consider the unit. We can use a >> fraction as well. See this series that puts in the foundation for that: >> https://patchwork.linuxtv.org/cover/58857/ >> >> 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) are used to >> calculate a minimum sizeimage (app may request more). This is >> driver-specific. (Is it? Or is this codec-specific?) >> >> V4L2_FMT_FLAG_FIXED_RESOLUTION is always set 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. See https://patchwork.linuxtv.org/patch/56478/ for >> the patch adding this flag. >> >> 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 dropped 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_FIXED_RESOLUTION is set (i.e. that should >> be 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 rate) supports. >> >> - Stateless encoders? >> >> - Anything else? (I have a feeling I missed a codec-related topic, but >> I can't find it in my mailbox) >> >> Regards, >> >> Hans
