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

Alexis Ballier aballier at gentoo.org
Fri Nov 21 10:43:15 CET 2014

On Fri, 21 Nov 2014 10:15:29 +0100
Jean-Baptiste Kempf <jb at videolan.org> wrote:

> On 21 Nov, Alexis Ballier wrote :
> > > So you have a format outputted that is of no use, except if you
> > > use the filter.
> > 
> > On MFCv5 yes; I don't assume because I'm working on this that it is
> > the only one :)
> So, basically, noone can display it, reencode or do anything with it,
> without the filter.
> Therefore, you should not introduce a new fmt for this.

First, I fail to see how this differs from AV_PIX_FMT_VDPAU & friends.
Second, I don't understand all the drama of using _one_ member of an
enum to avoid cluttering the code.

Let me re-explain my other mail:

Current decoding code is:
  * open the decoder
  * feed it with some data
  * get the output format the decoder uses
  * advertise it in codec context
  * decoding loop is: get an avpacket, feed to decoder, obtain an avframe

Keeping it internal would mean, for the sole decoder:
  * open the decoder
  * feed it with some data
  * get the output format
  * if i dont like the format then:
    * probe and open another random device that may or may not
      exist for format conversion
    * look for an output format i like
  * advertise the output format i will give to codec context
  * decoding loop is:
    * get an avpacket, feed it to decoder, obtain an avframe
    * if conversion is needed:
      * feed frame to filter, obtain the converted frame

Now, if I want to use the fimc device to apply some effects I can't
because the decoder is magically using it behind my back.

If I want to use s5p-tv to display the decoded video over HDMI, then I
have post-processed the frame with fimc for nothing since NV12MT is

> > MFCv6 and newer don't even understand nv12mt and can output standard
> > nv12:
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#n35
> This is yet another good reason to NOT introduce a new weird pix-fmt
> that will stay in FFmpeg for the next 10 years.

It will be in kernel headers and kernel ABI for like forever, so I
don't understand why this is so much of a problem.


More information about the ffmpeg-devel mailing list