diff options
author | sergeyu@chromium.org <sergeyu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-12-09 01:34:08 +0000 |
---|---|---|
committer | sergeyu@chromium.org <sergeyu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-12-09 01:34:08 +0000 |
commit | 5bc7183a8a86f77d79187b545f4442c02b4b5da4 (patch) | |
tree | 5e8605f948381d4ee164ad3cf6b6c79fab37676f /remoting/proto/video.proto | |
parent | 5484722ea6f8b25aeca90ec2c7bd85b30143ee52 (diff) | |
download | chromium_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.proto | 14 |
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]; |