Re: [ANN] Media sessions in Lyon in October: codecs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

(CC'ing Maxime)

On Mon, Sep 23, 2019 at 05:02:13PM +0200, Jacopo Mondi wrote:
> 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. I think that Maxime Ripard, who isn't in the above list,
would be able to contribute more than I could.

> If there are free seats I might flock in, but without contributing too
> much to the discussions :)
> 
> > 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,

Laurent Pinchart



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux