Re: [RFC] Resolution change support in video codecs in v4l2

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

 



Hi Kamil,

On Tuesday 06 December 2011 16:03:33 Kamil Debski wrote:
> On 06 December 2011 15:36 Sakari Ailus wrote:
> > On Fri, Dec 02, 2011 at 02:50:17PM -0200, Mauro Carvalho Chehab wrote:
> > > On 02-12-2011 11:57, Sakari Ailus wrote:
> > > > Some codecs need to be able to access buffers which have already been
> > > > decoded to decode more buffers. Key frames, simply.
> > > 
> > > Ok, but let's not add unneeded things at the API if you're not sure. If
> > > we have such need for a given hardware, then add it. Otherwise, keep it
> > > simple.
> >
> > This is not so much dependent on hardware but on the standards which the
> > cdoecs implement.
> > 
> > > > The user space still wants to be able to show these buffers, so a new
> > > > flag would likely be required --- V4L2_BUF_FLAG_READ_ONLY, for
> > > > example.
> > > 
> > > Huh? Assuming a capture device, when kernel makes a buffer available to
> > > userspace, kernel should not touch on it anymore (not even for read -
> > > although reading from it probably won't cause any issues, as video
> > > applications in general don't write into those buffers). The opposite is
> > > true for output devices: once userspace fills it, and queues, it should
> > > not touch that buffer again.
> > > 
> > > This is part of the queue/dequeue logic. I can't see any need for an
> > > extra flag to explicitly say that.
> > 
> > There is a reason to do so. An example of this is below. The
> > memory-to-memory device has two queues, output can capture. A video
> > decoder memory-to-memory device's output queue handles compressed video
> > and the capture queue provides the application decoded frames.
> > 
> > Certain frames in the stream are key frames, meaning that the decoding of
> > the following non-key frames requires access to the key frame. The number
> > of non-key frame can be relatively large, say 16, depending on the
> > codec.
> > 
> > If the user should wait for all the frames to be decoded before the key
> > frame can be shown, then either the key frame is to be skipped or
> > delayed. Both of the options are highly undesirable.
> 
> I don't think that such a delay is worrisome. This is only initial delay.
> The hw will process these N buffers and after that it works exactly the
> same as it would without the delay in terms of processing time.

For offline video decoding (such as playing a movie for instance) that's 
probably not a big issue. For online video decoding (video conferencing) where 
you want to minimize latency it can be.

> > Alternatively one could allocate the double number of buffers required.
> > At 1080p and 16 buffers this could be roughly 66 MB. Additionally,
> > starting the playback is delayed for the duration for the decoding of
> > those frames. I think we should not force users to do so.
> 
> I really don't think it is necessary to allocate twice as many buffers.
> Assuming that hw needs K buffers you may alloc N (= K + L) and the
> application may use all these L buffers at a time.

-- 
Regards,

Laurent Pinchart
--
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