Let me explain our user scenario. Libavcodec will be distributed with our application.
When the application starts to play a video, it will check the availability of libva. If libva is possible to use, the application uses hardware acceleration feature. Otherwise, it will use non-hwaccel feature. -----Original Message----- From: libav-devel [mailto:[email protected]] On Behalf Of Luca Barbato Sent: Friday, January 16, 2015 3:59 AM To: [email protected] Subject: Re: [libav-devel] [PATCH] vaapi: check the libva availability during the execution. On 15/01/15 19:35, Rémi Denis-Courmont wrote: > Le 2015-01-15 18:06, Luca Barbato a écrit : >> Personally I'm not against that assuming we can make it not >> completely brittle. > > The calling application and libavcodec must agree on the instance and > SO version of libva in use. How do you make that not brittle? > You pointed out one of the most annoying problems since hwaccel1 forces the caller to implement 1/2 of the hwaccel on its side, making library mismatch quite likely. Even my plan to wrap way the use of the hardware acceleration library so it gets nearly transparent to the user (hwaccel2 and avscale) wouldn't prevent the issue since users would still able to access the wrapped structures for further advanced processing. Kim Gunsoo, could be possible to know more about the use-case? I'm afraid Rémi is totally right regarding the fact even wrapping dlopen to not be thread unsafe would leave a quite brittle solution, but maybe there are other means to achieve a solution to your problem. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
