diff options
| author | posciak@chromium.org <posciak@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-05-31 06:52:41 +0000 |
|---|---|---|
| committer | posciak@chromium.org <posciak@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-05-31 06:52:41 +0000 |
| commit | fd99f1faeb1bd8395523ed7bc0f25888e74fbf67 (patch) | |
| tree | 427f5878e81e9a8f9ac52e61343d118389b69d3a /content/content_common.gypi | |
| parent | 197cf4acb790277fcf9fb835b86730a8c7a41c94 (diff) | |
| download | chromium_src-fd99f1faeb1bd8395523ed7bc0f25888e74fbf67.zip chromium_src-fd99f1faeb1bd8395523ed7bc0f25888e74fbf67.tar.gz chromium_src-fd99f1faeb1bd8395523ed7bc0f25888e74fbf67.tar.bz2 | |
VAVDA: Redesign stage 1.
This is the first stage of VAVDA VaapiH264Decoder redesigns, aimed at
simplifying code, improving and clarifying resource management and lifecycles,
reducing dependencies and unnecessary complexity, removing locking, simplifying
state machines and reducing threading dependencies, as well as to prepare for
new features, including missing frame concealment and dynamic resolution
changes.
The second stage will involve simplification and hopefully removal of locking
in VAVDA itself.
Main changes:
- Introduce VaapiDelegate class to handle all VAAPI calls and libva locking,
as well as manage VA resources.
- VaapiH264Decoder now runs entirely on one thread. No more confusing rules
which methods need to be run on the ChildThread.
- VaapiH264Decoder is now oblivious to GLX, textures, pixmaps, etc. and
only uses VA surfaces. VAVDA now manages the rest.
- VA surfaces used for decoding are decoupled from TFP pictures. Also,
otuput buffers passed to/from client are no longer tied to VA surfaces and
don't go to Decoder, simplifying things and squeezing some more parallelism.
- Most resources are now automatically managed instead of having to manage them
explicitly.
- Remove confusing decode surface states in favor of automatic refcounting
and releasing.
- Perform texture to pixmap binding on each frame to conform with the TFP
spec (this is a no-op on our CrOS platforms, so it didn't matter
correctness-wise, neither does this affect performance)
- Simplify VaapiH264Decoder in many places, including a simpler state
machine.
- Extracted some more parallelism in places.
- And more...
Performance is comparable (within measurement error) to old VAVDA, although
I have seen FPS gains of ~10-20% in some situations on specific streams and
during multiple simultaneous decodes.
BUG=222427,177422,151045
TEST=vda unittest, videotestmatrix, vimeo, youtube, timescapes, seek tests,
memory leak tests
Review URL: https://chromiumcodereview.appspot.com/14914009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@203343 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'content/content_common.gypi')
| -rw-r--r-- | content/content_common.gypi | 3 |
1 files changed, 3 insertions, 0 deletions
diff --git a/content/content_common.gypi b/content/content_common.gypi index 9e3be02..0075ff6 100644 --- a/content/content_common.gypi +++ b/content/content_common.gypi @@ -501,10 +501,13 @@ 'sources': [ 'common/gpu/media/h264_dpb.cc', 'common/gpu/media/h264_dpb.h', + 'common/gpu/media/va_surface.h', 'common/gpu/media/vaapi_h264_decoder.cc', 'common/gpu/media/vaapi_h264_decoder.h', 'common/gpu/media/vaapi_video_decode_accelerator.cc', 'common/gpu/media/vaapi_video_decode_accelerator.h', + 'common/gpu/media/vaapi_wrapper.cc', + 'common/gpu/media/vaapi_wrapper.h', ], 'include_dirs': [ '<(DEPTH)/third_party/libva', |