Intel QSV Codecs

[mohamedmoanis]

Ffmpeg 2.7.2 was released with the support of Intel's libmfx
which provide h264/h265/mpeg2 codecs that are accelerated on Intels GPUs

can you please enable it in your build?

its used by --enable-libmfx

[Decer]

Yes please, pls make some builds per month\release with intel qsv encoder support.

I beg you!

Propably you would not believe me Mr. Kyle Schwarz, but I WILL donate if that motivates you better. PM me if you dont believe, will discuss it in further details.

[Zeranoe]

QSVMFX breaks Windows XP support.

As much as I would like to drop XP support, there are still more users using XP than there are users interested in QSV.

Build 20150610-git-913685f has MFX support built in, so perhaps you could use that until there is something provided to maintain XP support.

[Decer]

Zeranoe: Im just suggesting, to make 1 --enable-libmfx build each month. Of course, that build wont be good for XP, but will contain all the new stuff for Win7+ users, for example
Build 20150610-git-913685f has MFX support , but qsv part got since then new fixes and improvements.

Btw, I want to thank you for your work, since I would be in deep s++t if zeranoe windows builds would not exist.

[rogerdpack]

Ffmpeg 2.7.2 was released with the support of Intel's libmfx
which provide h264/h265/mpeg2 codecs that are accelerated on Intels GPUs

can you please enable it in your build?

its used by --enable-libmfx

You can build your own with libmfx support by modifying this:
https://github.com/rdp/ffmpeg-windows-build-helpers

by modifyng the script so this line isn't commented out:
#build_intel_quicksync_mfx
and uncommenting this line.
# --enable-libmfx [not windows xp friendly]
GL!

[rkan]

I too are requesting a single monthly QSV -build.. With the advent of x5-z8300 CPUs , Core Ms and the upcoming Willow Trail CPUs/SoCs etc I'm eager to get to building my own portable h264&h265 encoder. First trying to do it on Windows with intel compute stick / Asus QM1.


Maybe we need another effort for this? I can provide hosting..


Crosscompiling with https://github.com/rdp/ffmpeg-windows-build-helpers didn't work for because of some complicated looking issue with mfx dispatch... It looks like either a bug in current mfx git or the compiling tools from Ubuntu 14.04..

Code: Select all

     ^
In file included from /home/rkan/ffmpeg/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/include/stdio.h:991:0,
                 from src/mfx_plugin_hive.h:39,
                 from src/mfx_load_plugin.h:34,
                 from src/mfx_dispatcher.h:39,
                 from src/main.cpp:34:
/home/rkan/ffmpeg/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/include/sec_api/stdio_s.h:32:72: error: conflicting declaration of 'int sscanf(const char*, const char*, ...)' with 'C' linkage
   _CRTIMP int __cdecl sscanf_s(const char *_Src,const char *_Format,...);
                                                                        ^
In file included from src/mfx_plugin_hive.h:39:0,
                 from src/mfx_load_plugin.h:34,
                 from src/mfx_dispatcher.h:39,
                 from src/main.cpp:34:
/home/rkan/ffmpeg/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/include/stdio.h:227:5: note: previous declaration with 'C++' linkage
 int sscanf(const char *__source, const char *__format, ...)
     ^
Makefile:620: recipe for target 'src/mfx_load_plugin.lo' failed
make: *** [src/mfx_load_plugin.lo] Error 1
make: *** Odotetaan keskeneräisiä töitä....
Makefile:620: recipe for target 'src/main.lo' failed
make: *** [src/main.lo] Error 1
In file included from /home/rkan/ffmpeg/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/include/stdio.h:991:0,
                 from src/mfx_plugin_hive.h:39,
                 from src/mfx_load_plugin.h:34,
                 from src/mfx_dispatcher.h:39,
                 from src/mfx_dispatcher.cpp:31:
/home/rkan/ffmpeg/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/include/sec_api/stdio_s.h:32:72: error: conflicting declaration of 'int sscanf(const char*, const char*, ...)' with 'C' linkage
   _CRTIMP int __cdecl sscanf_s(const char *_Src,const char *_Format,...);
                                                                        ^
In file included from src/mfx_plugin_hive.h:39:0,
                 from src/mfx_load_plugin.h:34,
                 from src/mfx_dispatcher.h:39,
                 from src/mfx_dispatcher.cpp:31:
/home/rkan/ffmpeg/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/include/stdio.h:227:5: note: previous declaration with 'C++' linkage
 int sscanf(const char *__source, const char *__format, ...)
     ^
Makefile:620: recipe for target 'src/mfx_dispatcher.lo' failed
make: *** [src/mfx_dispatcher.lo] Error 1

[lew]

Add me to the group who'd like to see a qsv build. Put one up and see how many downloads you get. Maybe you're right and we're wrong. I don't even care about monthly. One per build and as often as you think is necessary based on changes.

[Silvertrophy]

I second that and line up with those who are seeking for a downloadable version of ffmpeg supporting QSV out of the box.

[mikeversteeg]

First of all thanks to Kyle for your service to the community.

I just downloaded v3 enthusiastic to give QuickSync a try as I read it is now officially supported. Alas, not included in the build. Huh? I then found this thread. HUH? I cannot image why we're supporting XP, which is not even supported by M$. Who feels it necessary to hamper progress in such a big way? Where is the wisdom in supporting old (dangerous) technology over "new" (not really)?

Anyway, apparently it is a matter of votes, so here's mine:

+1

Thanks.

[lew]

I didn't mean to suggest the issue is literally up for votes. Zeranoe (obviously) casts the only vote which counts.

I'm not suggesting dropping XP support, although that might make a lot of sense.

I don't know how much work it would take to release one additional static binary, with qsv support. Interest, based on the number of downloads, would determine how often a new build would be posted.

Alternately include qsv and have the additional build be for XP.

I have no idea how much work is involved in producing a build. I have no idea if our request would take minutes or hours.

I don't know if it's as easy as changing one line then letting it go.

I'd be happy if the additional build, either qsv or XP, isn't updated monthly. Once per build, or more often if Zeranoe thinks the number of changes warrants it.

Handbrake dropped XP support. Relegating XP support to a build intended for XP users, updated quarterly (or semi-annually or even annually) would be more then reasonable. Would be a lot more then what Microsoft is offering old customers.