On Fri, 21 Nov 2014 11:15:08 +0100 Alexis Ballier <aball...@gentoo.org> wrote:
> On Fri, 21 Nov 2014 10:51:52 +0100 > wm4 <nfx...@googlemail.com> wrote: > > > On Fri, 21 Nov 2014 10:43:15 +0100 > > Alexis Ballier <aball...@gentoo.org> wrote: > > > > > On Fri, 21 Nov 2014 10:15:29 +0100 > > > Jean-Baptiste Kempf <j...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel