tree aa98431941f109f50474458c7a324616ab150ea4
parent 835cbdaf70dd30a00e30998d17cbff53e92f93a5
author Mike Klein <mtklein@google.com> 1570721719 -0500
committer Skia Commit-Bot <skia-commit-bot@chromium.org> 1570725271 +0000

hand off frames to encoder as they come

Instead of rendering all .mp4 frames then encoding, we can kick off
rendering and have the encoder consume frames in order as they become
available.

This uses std::promise / std::future pairs to make the handoff: frame
producers fulfill thieir promise by moving their image into set_value(),
and the encoder (main thread) consumes them by moving those images out
of the paired std::future().  It may not be obvious, but the line

    sk_sp<SkImage> img = frame.get_future().get();

does move the image into `img`... gMP4Frames does not hold a ref once
.get_future().get() has returned.  (Though depending on when you look,
the surface still might.)

This lets us get going on encoding as soon as the first frame is ready,
and hypothetically means encoding should finish shortly after the last
frame draws.  But, different frames cost different time to draw, and we
can't control the order they'll return.  We _do_ have control over the
order they're started, and we're doing that exactly wrong using a LIFO
thread pool.  I've added .mp4 encoding starvation stats to show this...
when I run in LIFO order it looks typically something like

    starved min 0ms, med 0ms, avg 4.12333ms, max 2115ms, sum 2474ms
    frame time min 12ms, med 292ms, avg 307.208ms, max 711ms, sum 184325ms
    106.68user 57.27system 0:04.55elapsed 3601%CPU (0avgtext+0avgdata 3159748maxresident)k
    0inputs+1528outputs (0major+772790minor)pagefaults 0swaps

Mirroring the batch order with (i = frame_count - 1 - i) results in less
starvation, less memory usage, better scaling, and a quicker wall time.

    starved min 0ms, med 0ms, avg 0.896667ms, max 382ms, sum 538ms
    frame time min 13ms, med 374ms, avg 344.365ms, max 918ms, sum 206619ms
    111.64user 52.56system 0:03.62elapsed 4529%CPU (0avgtext+0avgdata 2660912maxresident)k
    0inputs+1528outputs (0major+649031minor)pagefaults 0swaps

Change-Id: Ic60e8eac856af238ef32e3383d86f6c24e5c7851
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/247674
Reviewed-by: Florin Malita <fmalita@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>