On Fri, 21 Nov 2014 08:45:47 +0100 Alexis Ballier <aball...@gentoo.org> wrote:
> On Thu, 20 Nov 2014 18:42:19 +0100 > wm4 <nfx...@googlemail.com> wrote: > > I think this should be rejected. It's far too special to be useful in > > general, and it's not even pixel- or line-addressable (Z-shaped tiles, > > seriously?). It's pretty much a raw codec, not a pixel format. > > How do you put this in an AVFrame then ? Preferably not at all. Is there a need to? Only the end result (nv12 I suppose) needs to be in an AVFrame. > > Also, doesn't libv4l2 handle converting this to something sane > > transparently? > > "transparently" yes, but in sw. A <10W arm soc wouldn't like to > "transparently" convert 1080p@25fps like that > > also, last time I checked, libv4l2 didnt support NV12MT > > > If this is needed for the m2m filter, then maybe it should be part of > > the v4l2 libavdevice. > > I don't understand this. > > This is needed for HW decoding on MFCv5: it is the only format decoders > can produce. To use it in your application, you send it to the m2m > filter to get something sane. Sorry, I didn't look too close at the other patches. So this is a decoder. Why can't the decoder take care of this conversion too? This macroblock format isn't really useful for anything other than the m2m filter, but breaks all AVFrame/pixfmt conventions. Additionally, it breaks libavfilter conventions: conversions between pixfmts are supposed to be handled by libswscale, not arbitrary filters. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
