On Sun, Aug 2, 2015 at 11:52 PM, wm4 <nfx...@googlemail.com> wrote: > On Sun, 2 Aug 2015 23:45:36 +0200 > Hendrik Leppkes <h.lepp...@gmail.com> wrote: > >> On Sun, Aug 2, 2015 at 11:27 PM, Ivan Uskov <ivan.us...@nablet.com> wrote: >> > Hello Michael, >> > >> > Sunday, August 2, 2015, 9:46:23 PM, you wrote: >> >>> MN> it appears the file was not in mfx_dispatch previously >> >>> MN> so a check in confgure might be needed >> >>> As I can see here >> >>> https://github.com/lu-zero/mfx_dispatch/tree/master/mfx >> >>> The mfxjpeg.h was added 17 days ago and marked part of API 1.16. >> >>> But really mfxjpeg.h was introduced by Intel at old-old API 1.3 (decoder) >> >>> I do not use mfx_dispatch by myself at all, only native Intel Media >> >>> SDK and patch compiles fine at my side. >> >>> Looks like here some mess from mfx_dispatch side. >> >>> >> > >> >>> Is there any similar case existing in ffpeg which I can use as >> >>> template to implement own check in configure? >> > >> > MN> its very simple, see any code using check_header and related functions >> > MN> in configure >> > MN> and HAVE_*_H defines >> > >> > MN> [...] >> > >> > I have added simple check for mfxjpeg.h to configure, please review >> > the attached update. >> > >> > >> >> The decoder should depend on the header in configure directly already, >> so its not built at all when the header is not available. >> >> Secondly, why is there a AVHWAccel in there? It doesn't have any >> callable functions, nor do we support AVHWAccel for mjpeg. >> For some reason the other QSV codecs also have this, but also without >> any functions in them - those serve no purpose and are likely to even >> cause problems if a user accidentally tries to use it. I'll send a >> patch to remove them, unless you can name a reason for them to exist. > > Because if it's missing, ff_get_format() refuses to return the QSV > opaque format. I think. So you need AVHWAccels for every codec/decoder > combination.
But if you use the normal h264 decoder and select the QSV format in get_format (because you don't know any better), it will probably end up in unhappiness of all. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
