[FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.
nfxjfg at googlemail.com
Fri Nov 21 11:23:49 CET 2014
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, 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
More information about the ffmpeg-devel