On Mon, 28 Aug 2017 12:33:38 +0200
Jorge Ramirez <jorge.ramirez-or...@linaro.org> wrote:
> On 08/28/2017 12:04 PM, wm4 wrote:
> >> yes in response to your previous comment on the subject, I am trying to
> >> address that in v7 not releasing the context while there are buffers on
> >> the fly....
> >> This is what I came up with (if you can suggest something better - ie, a
> >> way to block until the AVBufferRefs are unref- please let me know)
> >>
> >> void avpriv_v4l2_context_release(V4L2Context* ctx)
> >> {
> >> int i, ret;
> >>
> >> if (!ctx->buffers)
> >> return;
> >>
> >> /* wait until all buffers are no longer in use */
> >> for (i = 0; i < ctx->num_buffers; i++) {
> >>
> >> if (ctx->buffers[i].status & (V4L2BUF_IN_DRIVER |
> >> V4L2BUF_AVAILABLE))
> >> continue;
> >>
> >> while (ctx->buffers[i].status & V4L2BUF_RET_USER)
> >> usleep(100);
> >> }
> >>
> >> ret = ctx->ops.release_buffers(ctx);
> >> if (ret)
> >> av_log(ctx->log_ctx, AV_LOG_WARNING, "V4L2 failed to unmap the
> >> %s buffers\n", ctx->name);
> >> else
> >> av_log(ctx->log_ctx, AV_LOG_DEBUG, "%s buffers unmapped\n",
> >> ctx->name);
> >>
> >> av_free(ctx->buffers);
> >> ctx->buffers = NULL;
> >> ctx->num_queued = 0;
> >> }
> >>
> > No, this is not possible.
> ok
>
> > You must make the V4L state reference
> > counted, and AVBufferRefs must implicitly reference this context.
> that is what we tried to do: the AVBufferRefs "free" callback changes
> the state to AVAILABLE thus implicitly referencing the context.
> maybe I am misunderstanding what you are trying to say?
>
> >
> > AVHWFramesContext does this in a more elegant way - it's a frame pool
> > specifically made for hw decoders. I suspect the V4L code should be
> > ported to that. I hope Mark Thompson has some helpful remarks on this.
>
> I guess that instead of polling for the AVBufferRef to be unreferenced,
> I can associate a sync (ie a sempahore) to each buffer, take it on
> release and post the semaphore on the AVBufferRefs being unreferenced.
> that is actually pretty clean in terms of cpu usage.
That would just freeze an API user calling avcodec_close(), when it
keeps around decoded AVFrames for later use.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
