summaryrefslogtreecommitdiffstats
path: root/remoting/proto/video.proto
diff options
context:
space:
mode:
authorsergeyu@chromium.org <sergeyu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-12-09 01:34:08 +0000
committersergeyu@chromium.org <sergeyu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2010-12-09 01:34:08 +0000
commit5bc7183a8a86f77d79187b545f4442c02b4b5da4 (patch)
tree5e8605f948381d4ee164ad3cf6b6c79fab37676f /remoting/proto/video.proto
parent5484722ea6f8b25aeca90ec2c7bd85b30143ee52 (diff)
downloadchromium_src-5bc7183a8a86f77d79187b545f4442c02b4b5da4.zip
chromium_src-5bc7183a8a86f77d79187b545f4442c02b4b5da4.tar.gz
chromium_src-5bc7183a8a86f77d79187b545f4442c02b4b5da4.tar.bz2
Simplified frame rate control in the chromoting host.
Insted of keeping semi-fixed frame rate, now capturing rate is controlled by how fast we can send data to the client. Capturing of frame n is started only after frame n-2 is sent (while n-1 is being encoded). This guarantees that we don't clog the video channel buffers, and that we start capturing only if we know that the frame will not need to wait for too long in the buffer. TEST=None BUG=None Review URL: http://codereview.chromium.org/5634002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68688 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'remoting/proto/video.proto')
-rw-r--r--remoting/proto/video.proto14
1 files changed, 9 insertions, 5 deletions
diff --git a/remoting/proto/video.proto b/remoting/proto/video.proto
index e1cf5cf..394f891 100644
--- a/remoting/proto/video.proto
+++ b/remoting/proto/video.proto
@@ -35,14 +35,17 @@ message VideoPacketFormat {
message VideoPacket {
// Bitmasks for use in the flags field below.
//
- // The encoder may fragment one update into multiple packets depending on
- // how the encoder outputs data. Thus, one update can logically consist of
- // multiple packets. The FIRST_PACKET and LAST_PACKET flags are used to
- // indicate the start and end of a logical update. Here are notable
- // consequences:
+ // The encoder may fragment one update into multiple partitions.
+ // Each partition may be divided into multiple packets depending on
+ // how the encoder outputs data. Thus, one update can logically
+ // consist of multiple packets. The FIRST_PACKET and LAST_PACKET
+ // flags are used to indicate the start and end of a partition. The
+ // LAST_PARTITION flag is set for the last packet in the last
+ // partition. Here are notable consequences:
// * Both FIRST_PACKET and LAST_PACKET may be set if an update is only
// one packet long.
// * The VideoPacketFormat is only supplied in a FIRST_PACKET.
+ // * LAST_PARTITION can be set only in packet that has LAST_PACKET set.
// * An local update cannot change format between a FIRST_PACKET and
// a LAST_PACKET.
// * All packets in one logical update must be processed in order, and
@@ -50,6 +53,7 @@ message VideoPacket {
enum Flags {
FIRST_PACKET = 1;
LAST_PACKET = 2;
+ LAST_PARTITION = 4;
}
optional int32 flags = 1 [default = 0];