From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from perceval.ideasonboard.com ([95.142.166.194]:53562 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751574Ab2ACOAH (ORCPT ); Tue, 3 Jan 2012 09:00:07 -0500 From: Laurent Pinchart To: javier Martin Subject: Re: MEM2MEM devices: how to handle sequence number? Date: Tue, 3 Jan 2012 15:00:22 +0100 Cc: Sylwester Nawrocki , Marek Szyprowski , linux-media@vger.kernel.org, hverkuil@xs4all.nl, kyungmin.park@samsung.com, shawn.guo@linaro.org, richard.zhao@linaro.org, fabio.estevam@freescale.com, kernel@pengutronix.de, s.hauer@pengutronix.de, r.schwebel@pengutronix.de, Pawel Osciak References: <201201021206.06397.laurent.pinchart@ideasonboard.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201031500.23732.laurent.pinchart@ideasonboard.com> Sender: linux-media-owner@vger.kernel.org List-ID: Hi Javier, On Monday 02 January 2012 12:44:08 javier Martin wrote: > Just one more question about this. > > The v4l2 encoder, which is the last element in my processing chain, is > an H.264 encoder that has to know about previous frames to encode. > For these kind of devices it is very useful to know whether a frame > has been lost to introduce a skip frame and improve the encoding > process. > > But, with the current approach we don't have any way to communicate > this to the device. > > One option would be that the user specified a sequence number when > issuing VIDIOC_QBUF at the output queue so that the device could > detect any discontinuity and introduce a skip frame. But this would > break your rule that sequence number introduced at the output queue > has to be ignored by the driver. That's a use case I haven't thought about. Using sequence numbers could indeed help in that case. My concern is that most (if not all) applications don't set the sequence number before queuing a buffer, so requiring them to do so could introduce breakages. This could be limited to H.264 encoders (or more generally codecs) though. Another option would be to queue a 0-bytes frame. That might be a bit hackish though. -- Regards, Laurent Pinchart