possible optimization for ffmpeg decoding (reuse last_frame)?
Needs ReviewPublic
Actions

Authored by David M (erwin94) on Aug 31 2015, 12:53 AM.

Details

Reviewers

Sergey Sharybin (sergey)

Summary

Hi,

this patch tries to optimize playback performance in the sequencer.
I have no idea whether it is valid to skip this allocation,
but this gives me about 6-7fps more on 1080p ProRes footage,
so even if this isn't valid as is, it seems worthy to look into not
reallocating this buffer every frame.

(Tested on a MacBook, going from about 22fps to a much more constant
28-29fps)

Hope this helps,
David.

Diff Detail

Event Timeline

David M (erwin94) updated this revision to Diff 4977.Aug 31 2015, 12:53 AM

David M (erwin94) retitled this revision from to possible optimization for ffmpeg decoding (reuse last_frame)?.

David M (erwin94) updated this object.

David M (erwin94) set the repository for this revision to rB Blender.

David M (erwin94) added a project: BF Blender.

David M (erwin94) mentioned this in T45960: possible optimization for ffmpeg decoding (reuse last_frame)?.Aug 31 2015, 1:12 AM

Seems like this should work, though this part of the code is using refcounting, this should check there are no other references as well. (ibuf->refcounter <= 1)

Aaron Carlisle (Blendify) added a subscriber: Aaron Carlisle (Blendify).Aug 31 2015, 3:24 AM

Okay, so this checks the refcount now, but looking at
the values it seems a little unpredictable when the refcount
will actually be <= 1... whether the clip was loaded in the
sequencer or the movie clip editor seems to make a difference?
Anyways, this shouldn't hurt now, but these allocations seem to
be the thing that hurts performance the most during "normal"
playback, without effects, scaling or other compositing. Maybe
this could use some more refactoring to use a small pool of
already allocated frames?

The patch isn't thread safe actually. Check for refcounter should happen only from inside refcounter_spin spin lock, otherwsie you might easily run into memory corruption and memory leaks.

source/blender/imbuf/intern/anim_movie.c
1125	Code style.

This revision now requires changes to proceed.Sep 2 2015, 11:20 AM

Alright, updated diff, hopefully threadsafe check for refcounter added.
I added a generic check function to the ImBuf interface, since the spinlock
is static in that module, and this could be useful elsewhere. Also the correct
value to check seems to be refcounter==0 instead of refcounter <=1?
At least IMB_makeSingleUser() does that, but it also does that without
the lock?

Redid the performance tests, I might have overestimated the impact,
cpu usage in the main thread drops maybe 12-15% (as measured by
Instruments.app), so I should gain maybe 3fps, but this seems to be
right at the edge of making 1080p25 realtime on my system.