On 21 Nov, Alexis Ballier 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.
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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
