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. > 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel