On Mon, 25 Jul 2016, Diego Biurrun wrote:
On Fri, Jul 15, 2016 at 01:43:16PM +0300, Martin Storsjö wrote:
This simplifies use of the patent license, simplifying use with a
library that has been downloaded at runtime (making it possible
to actually load and run libavcodec before the correspondin
On Fri, Jul 15, 2016 at 01:43:16PM +0300, Martin Storsjö wrote:
> This simplifies use of the patent license, simplifying use with a
> library that has been downloaded at runtime (making it possible
> to actually load and run libavcodec before the corresponding
> OpenH264 library exists).
> ---
> Th
This simplifies use of the patent license, simplifying use with a
library that has been downloaded at runtime (making it possible
to actually load and run libavcodec before the corresponding
OpenH264 library exists).
---
This patch was sent for review earlier, and got some feedback, but it was
defe
On 31/12/14 18:34, Derek Buitenhuis wrote:
On 12/31/2014 5:25 PM, Luca Barbato wrote:
I had those in my wishlist since a while (actually something a little
more gory) since sometimes I feel the need of it =p
I am liekly never going to accept to a patch to libx265.c to dynamically load
arbitrar
Le 2014-12-31 20:34, Derek Buitenhuis a écrit :
On 12/31/2014 5:25 PM, Luca Barbato wrote:
I had those in my wishlist since a while (actually something a
little
more gory) since sometimes I feel the need of it =p
I am liekly never going to accept to a patch to libx265.c to
dynamically load
a
On 12/31/2014 5:25 PM, Luca Barbato wrote:
> I had those in my wishlist since a while (actually something a little
> more gory) since sometimes I feel the need of it =p
I am liekly never going to accept to a patch to libx265.c to dynamically load
arbitrary libs, and *especially* not to load both
On 31/12/14 17:51, Derek Buitenhuis wrote:
On 12/31/2014 3:21 PM, Martin Storsjö wrote:
I'm not sure if this is worthwhile doing though. It does make the
code (and configure) quite a bit more messy.
I am sort of inclined to agree.
It's not that this patch is bad per se, but it kinda sets the
On Wed, Dec 31, 2014 at 9:03 AM, Martin Storsjö wrote:
> It would probably indeed make sense to add a separate enable-item (so you
> don't need to check individually for dlopen and LoadLibrary, but just for
> the generic dynamic-loading feature) and a separate header that does this.
+1. Wanted t
On Wed, 31 Dec 2014, Derek Buitenhuis wrote:
On 12/31/2014 3:21 PM, Martin Storsjö wrote:
I'm not sure if this is worthwhile doing though. It does make the
code (and configure) quite a bit more messy.
I am sort of inclined to agree.
It's not that this patch is bad per se, but it kinda sets t
On 12/31/2014 3:21 PM, Martin Storsjö wrote:
> I'm not sure if this is worthwhile doing though. It does make the
> code (and configure) quite a bit more messy.
I am sort of inclined to agree.
It's not that this patch is bad per se, but it kinda sets the
precedent for much worse things like dynami
On 31/12/14 16:21, Martin Storsjö wrote:
This simplifies use of the patent license, simplifying use with a
library that has been downloaded at runtime (making it possible
to actually load and run libavcodec before the corresponding
OpenH264 library exists).
I'm not sure if this is worthwhile doi
This simplifies use of the patent license, simplifying use with a
library that has been downloaded at runtime (making it possible
to actually load and run libavcodec before the corresponding
OpenH264 library exists).
I'm not sure if this is worthwhile doing though. It does make the
code (and confi
12 matches
Mail list logo