Hi Javier, Sakari, > From: Sakari Ailus [mailto:sakari.ailus@xxxxxx] > Sent: 15 March 2012 12:04 > > Hi Javier, > > (Cc Kamil.) > > On Wed, Mar 14, 2012 at 12:22:43PM +0100, javier Martin wrote: > > Hi, > > I'm developing a V4L2 mem2mem driver for the codadx6 IP video codec > > which is included in the i.MX27 chip. > > > > The capture interface of this driver can therefore return h.264 or > > mpeg4 video frames. > > > > Provided that the size of each frame varies and is unknown to the > > user, how is the driver supposed to react to a S_FMT when it comes to > > parameters such as the following? > > > > pix->width > > pix->height > > pix->bytesperline > > pix->sizeimage > > > > According to the documentation [1] I understand that the driver can > > just ignore 'bytesperline' and should return in 'sizeimage' the > > maximum buffer size to store a compressed frame. However, it does not > > mention anything special about width and height. Does it make sense > > setting width and height for h.264/mpeg4 formats? > Yes, in case of the compressed side (capture) the width, height and bytesperline is ignored. The MFC driver sets bytesperline to 0 and leaves width and height intact during S_FMT. I suggest you do the same or set all of them (width, height, bytesperline) to 0. > It does. This has been recently discussed, and there were a few ideas how > to > do this. But no final conclusion AFAIR. > > <URL:http://www.spinics.net/lists/linux-media/msg40905.html> In this RFC we have discussed the decoding and resolution change while decoding. Here the question is about encoding. > > Kamil: do you have plans to update the RFC? > As Javier is now working on a codec driver then it might the right time to bring the discussion back to life. Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland R&D Center -- 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
