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

[wm4]

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

> On Fri, 21 Nov 2014 10:51:52 +0100
> wm4 <nfxjfg at googlemail.com> wrote:
> 
> > 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.
> 
> I didn't know such "opaque" things existed; it probably makes more
> sense with it indeed.
> 
> How should I do it ? add .flags = AV_PIX_FMT_FLAG_HWACCEL and be done ?
> I would like to keep 'av_pix_fmt_count_planes()' working for it at least

No, this would imply that the pointer to the opaque data is in
AVFrame.data[3], and all other pointers are ignored. So you have only 1
pointer. AVFrame.linesize has no meaning either in this case.

> [...]
> > 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?
> 
> This could be "fixed" by adding support in swscale for it, but I see
> little to no point to it.
> 
> I think you have to specifically ask for v4l2m2m codecs if you want to
> use them do hw (de/en)code; so why not do everything in hw and also
> setup the filter ?

Well, if the filter copies to system RAM anyway (if that chip
distinguishes between GPU and system RAM at all), then why do you need
such a filter as user-visible thing at all?

Where exactly is the problem in putting this code into libavcodec?

> (note: I shall write some doc about all this once this has settled)
> 
> > But if it just works without requiring the API user to jump through
> > hoops, I see at least some value in it.
> 
> 
> Would AV_PIX_FMT_FLAG_HWACCEL be enough ?

I can't speak for others whether this approach is acceptable.

But I think this is all too messy, and the decoder should just output a
useful format.