Re: [RFC PATCH v3] [media] mem2mem: add support for hardware buffered queue

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

 



Hi Sylwester,

Am Freitag, den 31.05.2013, 10:52 +0200 schrieb Sylwester Nawrocki:
> Hi Philipp,
> 
> On 05/31/2013 10:33 AM, Philipp Zabel wrote:
> > +void v4l2_m2m_queue_set_buffered(struct vb2_queue *vq, bool buffered)
> 
> How about making it a 'static inline' function in include/media/v4l2-mem2mem.h
> instead ?

Thanks, I'll change this.

> > +{
> > +	struct v4l2_m2m_queue_ctx *q_ctx = container_of(vq, struct v4l2_m2m_queue_ctx, q);
> > +
> > +	q_ctx->buffered = buffered;
> > +}
> > +EXPORT_SYMBOL_GPL(v4l2_m2m_queue_set_buffered);
> 
> 
> Also, I was wondering how do you handle now in the coda driver a situation
> when, e.g. during normal stream decoding more than one buffer is produced
> by the decoder from one compressed data buffer on its input side ?

I didn't properly test it yet. In principle it should just work because
the compressed OUTPUT source buffer is always copied into the internal
bitstream ringbuffer, and then device_run can be scheduled multiple
times as long as there is enough bitstream data available, each run
producing a single CAPTURE destination buffer.

But I'm counting input buffers to send the EOS signal with the last
CAPTURE buffer DQBUF, assuming that there is one compressed frame per
OUTPUT source buffer.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[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