[FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

wm4 nfxjfg at googlemail.com
Fri Nov 21 09:01:43 CET 2014


On Fri, 21 Nov 2014 08:45:47 +0100
Alexis Ballier <aballier at gentoo.org> wrote:

> On Thu, 20 Nov 2014 18:42:19 +0100
> wm4 <nfxjfg at 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 at 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.


More information about the ffmpeg-devel mailing list