On Fri, 21 Nov 2014 09:01:43 +0100 wm4 <nfx...@googlemail.com> wrote:
> On Fri, 21 Nov 2014 08:45:47 +0100 > Alexis Ballier <aball...@gentoo.org> wrote: > > > On Thu, 20 Nov 2014 18:42:19 +0100 > > wm4 <nfx...@googlemail.com> wrote: > > > I think this should be rejected. It's far too special to be > > > useful in general, and it's not even pixel- or line-addressable > > > (Z-shaped tiles, seriously?). It's pretty much a raw codec, not a > > > pixel format. > > > > How do you put this in an AVFrame then ? > > Preferably not at all. Is there a need to? Only the end result (nv12 I > suppose) needs to be in an AVFrame. It can be done but is ugly IMHO: - I was under the impression that lavc decoder convention was to output non processed formats and let the application handle (or not) the conversions - The decoder code would look like: * probe and open decoder * feed it with some frames / extradata to get the format from the decoder * if i dont like the format then: * probe and open another random device that may or may not exist for format conversion * copy/paste the m2m filter code in the decoder to postprocess the frames - If you're thinking about manual conversion then it's a no go: this would break the zero copy chain I'm trying to obtain. > > > Also, doesn't libv4l2 handle converting this to something sane > > > transparently? > > > > "transparently" yes, but in sw. A <10W arm soc wouldn't like to > > "transparently" convert 1080p@25fps like that > > > > also, last time I checked, libv4l2 didnt support NV12MT > > > > > If this is needed for the m2m filter, then maybe it should be > > > part of the v4l2 libavdevice. > > > > I don't understand this. > > > > This is needed for HW decoding on MFCv5: it is the only format > > decoders can produce. To use it in your application, you send it to > > the m2m filter to get something sane. > > Sorry, I didn't look too close at the other patches. It'd be hard to guess this from the other patches anyway, v4l2 driver is the one that will tell the format, so you won't get much information without looking at kernel driver code :) > So this is a > decoder. Why can't the decoder take care of this conversion too? See above. > This > macroblock format isn't really useful for anything other than the m2m > filter, but breaks all AVFrame/pixfmt conventions. Additionally, it > breaks libavfilter conventions: conversions between pixfmts are > supposed to be handled by libswscale, not arbitrary filters. I didn't take the time to write swscale support for this because the format is a bit insane, the code would be ugly and it would be useless in practice. I probably missed something but I was under the impression that av_image_copy & friends should work if frames have the correct width & height alignment. The command: ./ffmpeg_g -y -c:v mpeg4_v4l2m2m -i bli.mkv -vf v4l2_m2m -c:v h264_v4l2m2m -pix_fmt nv12 -c:a ac3 bli.mp4 works like a charm here, no auto-inserted scaler, mpeg4_v4l2m2m produces nv12mt that is fed to the m2m filter that produces standard nv12 which is fed to the h264_v4l2m2m encoder Alexis. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel