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

[Jean-Baptiste Kempf]

On 21 Nov, Alexis Ballier 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.

Because it's called NV12T, not AV_PIX_FMT_V4L_FMT. And because it's not
and HWAccel.

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

Because you don't use libav* libraries directly.

> 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

So what?
Your 2 cases are completly unfair, and you don't give the same level of details.

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

How is that relevant? Just block it.
And it seems really like a technical limitation of this chip.

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

Then maybe, in those cases, FFmpeg is not the right tool, and you should
do a HWAccel.

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

The linux kernel is not the only one around here.

With my kindest regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device