diff options
author | nick@chromium.org <nick@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-10-23 01:36:24 +0000 |
---|---|---|
committer | nick@chromium.org <nick@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-10-23 01:36:24 +0000 |
commit | 6ff80ce77fb34adecf96ffb1604cf328649801a7 (patch) | |
tree | 182fd0b7fdbb77eb4db38ce2964fe74b659c1d17 /cc/PRESUBMIT.py | |
parent | 3e81ddb205d7c3162bdc7f845ba8769939f94567 (diff) | |
download | chromium_src-6ff80ce77fb34adecf96ffb1604cf328649801a7.zip chromium_src-6ff80ce77fb34adecf96ffb1604cf328649801a7.tar.gz chromium_src-6ff80ce77fb34adecf96ffb1604cf328649801a7.tar.bz2 |
VideoCapture: abolish OnFrameInfo almost everywhere.
Historically OnFrameInfo was a one-time message that gave the
resolution of all subsequent frames. This patch eliminates that, to
allow the resolution to be specified on a frame-by-frame basis, at the
device's discretion.
At the IPC layer two changes were necessary, with the rest of the code
falling in line: [1] Resolution/layout info (in the form of a
VideoCaptureFormat) is sent with each frame delivery. [2] Shared-
memory buffers need to be reallocated, so it was necessary to add a
message to drop a buffer.
A significant rework of VideoCaptureBufferPool handles a shift to a
world where buffers are allocated/re-allocated on demand, and where
the buffers in the pool may not all be the same size at any given
moment. This allows the buffer pool to be allocated earlier, at the
start of the lifetime of the controller.
OnFrameInfo methods are gone everywhere but the very beginning of the
pipeline (between the Device and its Client) and the very end (an
OnFrameInfo event is synthesized in the renderer process for the
benefit of the pepper video capture host).
BUG=266082
Review URL: https://codereview.chromium.org/23551011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@230276 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'cc/PRESUBMIT.py')
0 files changed, 0 insertions, 0 deletions