On Fri, Aug 18, 2023 at 11:45 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > > On 04/07/2023 06:00, Hsia-Jun Li wrote: > > From: "Hsia-Jun(Randy) Li" <randy.li@xxxxxxxxxxxxx> > > > > The first patch is an old patch, I resend it again. > > I want to make the work thats parses the bitstream > > to extract the sequence information or video resolution > > as a part of V4L2 schedule. Such a work would also > > consume the device's resources likes remote CPU > > time. > > > > Although reuse a flag which no current driver may > > not be a good idea. I could add a new flag for that > > if people like that. > > > > The second is a patch offering a generic solution > > for tracking buffers which have been pushed to > > hardware(or firmware). It didn't record which buffer > > that hardware(firmware) still holds for future > > decoding(likes the reference buffer), while it > > has been sent to the user(dequeue). We may need > > a flag for this work. > > I am dropping this series from patchwork: clearly this generated > a lot of discussion, and I think that needs to come to a conclusion. > > BTW, I believe that at minimum the codec-specific parts in > v4l2-mem2mem.c should be split off in their own source (v4l2-m2m-codec.c?). I like the idea. This way we could possibly evolve the framework more towards the codec helpers, reusing as much code as possible, but also keeping the basic implementation simple. > > I agree with Tomasz that mem2mem.c was originally for simple m2m devices, > and adding all sorts of codec specific code to that source doesn't make > it easier to follow. > > Regards, > > Hans > > > > > Hsia-Jun(Randy) Li (1): > > media: v4l2-mem2mem: add a list for buf used by hw > > > > Randy Li (1): > > media: v4l2-mem2mem: allow device run without buf > > > > drivers/media/v4l2-core/v4l2-mem2mem.c | 30 +++++++++++++++++--------- > > include/media/v4l2-mem2mem.h | 10 ++++++++- > > 2 files changed, 29 insertions(+), 11 deletions(-) > > >
