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

[wm4]

On Fri, 21 Nov 2014 10:43:15 +0100
Alexis Ballier <aballier at gentoo.org> wrote:

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

AV_PIX_FMT_VDPAU is marked as hwaccel format, and thus completely opaque.
It can't be cropped, copied, etc. - just passed around. It also means
the generic AVFrame code can't allocate frames of such a format.

Personally I'd have much less of a problem with this if it were to be
marked as opaque.

> Second, I don't understand all the drama of using _one_ member of an
> enum to avoid cluttering the code.

Every addition is something the API user has to care about, since there
is no automatic conversion between libavcodec and the API user.

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

It also means that _every_ software which wants to use this new decocer
has to know how to insert the filter etc. - what's the point? If it's
so special, it might as well be outside of libavcodec and libavfilter.

But if it just works without requiring the API user to jump through
hoops, I see at least some value in it.

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