On Thu, Oct 02, 2014 at 09:50:12PM +0200, Michael Niedermayer wrote:
> On Thu, Oct 02, 2014 at 11:54:31AM -0700, Manfred Georg wrote:
> > On Wed, Oct 1, 2014 at 5:40 PM, Michael Niedermayer
> > wrote:
> >
> > > On Wed, Oct 01, 2014 at 04:37:21PM -0700, Manfred Georg wrote:
> > > > [snip]
> > > >
On Thu, Oct 02, 2014 at 11:54:31AM -0700, Manfred Georg wrote:
> On Wed, Oct 1, 2014 at 5:40 PM, Michael Niedermayer
> wrote:
>
> > On Wed, Oct 01, 2014 at 04:37:21PM -0700, Manfred Georg wrote:
> > > [snip]
> > >
> > > > @@ -3457,22 +3457,53 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel
> > > >
On Wed, Oct 1, 2014 at 5:40 PM, Michael Niedermayer
wrote:
> On Wed, Oct 01, 2014 at 04:37:21PM -0700, Manfred Georg wrote:
> > [snip]
> >
> > > @@ -3457,22 +3457,53 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel
> > > *hwaccel)
> > > > int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockO
On Wed, Oct 01, 2014 at 04:37:21PM -0700, Manfred Georg wrote:
> [snip]
>
> > @@ -3457,22 +3457,53 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel
> > *hwaccel)
> > > int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
> > > {
> > > if (lockmgr_cb) {
> > > -if (lockmgr_
[snip]
> @@ -3457,22 +3457,53 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel
> *hwaccel)
> > int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
> > {
> > if (lockmgr_cb) {
> > -if (lockmgr_cb(&codec_mutex, AV_LOCK_DESTROY))
> > -return -1;
> > -if
On Wed, Oct 01, 2014 at 01:01:33PM -0700, Manfred Georg wrote:
> On Tue, Sep 30, 2014 at 8:16 PM, Michael Niedermayer
> wrote:
>
> > On Tue, Sep 30, 2014 at 07:34:28PM -0700, Manfred Georg wrote:
> > > Yeah, that seemed a bit odd to meI guess I get to go correct some
> > > calling code.
> > >
As a further note. I'm pretty sure that none of the tests make use of
av_lockmgr_register...so there's very little guarantee that this function
is working correctly (particularly now that it has gotten so complicated).
Manfred
___
ffmpeg-devel mailing l
On Tue, Sep 30, 2014 at 8:16 PM, Michael Niedermayer
wrote:
> On Tue, Sep 30, 2014 at 07:34:28PM -0700, Manfred Georg wrote:
> > Yeah, that seemed a bit odd to meI guess I get to go correct some
> > calling code.
> >
> > Here is yet another update with a comment which tells you not to use a
>
On Tue, Sep 30, 2014 at 07:34:28PM -0700, Manfred Georg wrote:
> Yeah, that seemed a bit odd to meI guess I get to go correct some
> calling code.
>
> Here is yet another update with a comment which tells you not to use a
> static mutex.
>
> Subject: [PATCH] av_lockmgr_register defines behavi
On Tue, Sep 30, 2014 at 07:00:19PM -0700, Manfred Georg wrote:
> Here's the updated patch. Of note is the fact that I'm not sure it's
> actually legal to have a mutex manager which uses a single
> static mutex (and hence has all created mutex backed by the
> same underlying locking mechanism).
i
Here's the updated patch. Of note is the fact that I'm not sure it's
actually legal to have a mutex manager which uses a single
static mutex (and hence has all created mutex backed by the
same underlying locking mechanism).
Hopefully this patch is legible:
Subject: [PATCH] av_lockmgr_register de
On 30/09/14 10:46 PM, Manfred Georg wrote:
> Sure, I've made the change to the comment within my local code. I'm sorry,
> but I'm not familiar with FFmpeg development cycle: how would you like me
> to post it?
> 1) A patch on top of the patch that is already in this thread (i.e.
> something that w
Sure, I've made the change to the comment within my local code. I'm sorry,
but I'm not familiar with FFmpeg development cycle: how would you like me
to post it?
1) A patch on top of the patch that is already in this thread (i.e.
something that will be squished into this patch).
2) A new patch in a
On Tue, Sep 30, 2014 at 03:20:43PM -0700, Manfred Georg wrote:
> The register function now specifies that the user callback should
> leave things in the same state that it found them on failure but
> that failure to destroy is ignored by ffmpeg. The register
> function is also now explicit about i
14 matches
Mail list logo
