Hi,
overall pretty good. Nice performance improvement. We typically note
performance improvement as a/b-1, not 1-b/a, so if runtime with 2 threads
is 6 seconds and with 1 thread is 10 seconds, the improvement is not
1-6/10=0.4=40%, but rather 10/6-1=0.67=67%.
On Tue, Aug 22, 2017 at 7:59 PM, Ilia Valiakhmetov <zakne...@gmail.com>
wrote:
> +void ff_thread_await_progress3(AVCodecContext *avctx, int field, int
> thread, int shift)
> +{
> + SliceThreadContext *p = avctx->internal->thread_ctx;
> + int *entries = p->entries;
> +
> + pthread_mutex_lock(&p->progress_mutex[thread]);
> + while ((entries[field]) != shift){
> + pthread_cond_wait(&p->progress_cond[thread],
> &p->progress_mutex[thread]);
> + }
> + pthread_mutex_unlock(&p->progress_mutex[thread]);
> +}
Hm... I think at this level (per-row processing), atomic integers are
better. See how report_progress and await_progress are implemented in
pthread_frame.c, and then implement something like that custom for vp9.c
only (i.e. probably located inside Vp9TileData). I don't think it needs to
be in generic code since it's unlikely to be reused in other codecs...
Most changes to vp9*.[ch] look good. I'll do a closer review tomorrow to
make sure I didn't miss anything.
Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
