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

Alexis Ballier aballier at gentoo.org
Fri Nov 21 09:22:42 CET 2014


On Fri, 21 Nov 2014 09:01:43 +0100
wm4 <nfxjfg at googlemail.com> wrote:

> 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.

It can be done but is ugly IMHO:

- I was under the impression that lavc decoder convention was to
  output non processed formats and let the application handle (or not)
  the conversions

- The decoder code would look like:
     * probe and open decoder
     * feed it with some frames / extradata to get the format from the
       decoder
     * if i dont like the format then:
         * probe and open another random device that may or may not
           exist for format conversion
         * copy/paste the m2m filter code in the decoder to postprocess
           the frames

- If you're thinking about manual conversion then it's a no go: this
  would break the zero copy chain I'm trying to obtain.

> > > 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.

It'd be hard to guess this from the other patches anyway, v4l2 driver
is the one that will tell the format, so you won't get much information
without looking at kernel driver code :)

> So this is a
> decoder. Why can't the decoder take care of this conversion too?

See above.

> 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.

I didn't take the time to write swscale support for this because the
format is a bit insane, the code would be ugly and it would be
useless in practice.

I probably missed something but I was under the impression
that av_image_copy & friends should work if frames have the correct
width & height alignment.

The command:
./ffmpeg_g -y -c:v mpeg4_v4l2m2m -i bli.mkv -vf v4l2_m2m -c:v
h264_v4l2m2m -pix_fmt nv12 -c:a ac3 bli.mp4

works like a charm here, no auto-inserted scaler, mpeg4_v4l2m2m
produces nv12mt that is fed to the m2m filter that produces standard
nv12 which is fed to the h264_v4l2m2m encoder

Alexis.


More information about the ffmpeg-devel mailing list