Hello Hendrik, Monday, August 3, 2015, 12:45:36 AM, you wrote:
HL> The decoder should depend on the header in configure directly already, HL> so its not built at all when the header is not available. In general I do not understanding why it necessary at all. All necessary headers currently available into the mfx_dispatch Now we try to account some kind of retrospective case which will never can appear of real life. By the way when Michael merged HEVC support from libva he did not add any checks into config although there is much more high probability that HEVC component is absent into mfx. The support of jpeg existing into libmfx for years so complex checks looks quite strange here. HL> Secondly, why is there a AVHWAccel in there? It doesn't have any HL> callable functions, nor do we support AVHWAccel for mjpeg. HL> For some reason the other QSV codecs also have this, but also without HL> any functions in them - those serve no purpose and are likely to even HL> cause problems if a user accidentally tries to use it. I'll send a HL> patch to remove them, unless you can name a reason for them to exist. Please do not make such patch you will break qsv opaque surfaces. The AVHWAccel is necessary for all QSV-based components to support opaque surfaces (AV_PIX_FMT_QSV). The opaque surfaces exists inside GPU and it allow to route data from decoder to vpp, from vpp to encoder etc without using system memory. -- Best regards, Ivan mailto:ivan.us...@nablet.com _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
