Implement video frame acknowledgements in the chromoting protocol.

remoting/protocol/video_sender.h

Index: remoting/protocol/video_sender.h
diff --git a/remoting/protocol/video_sender.h b/remoting/protocol/video_sender.h
new file mode 100644
index 0000000000000000000000000000000000000000..cbe57339ad4671a45cee8fb39cc306b8cbd21ce0
--- /dev/null
+++ b/remoting/protocol/video_sender.h
@@ -0,0 +1,33 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef REMOTING_PROTOCOL_VIDEO_SENDER_H_
+#define REMOTING_PROTOCOL_VIDEO_SENDER_H_
+
+#include "remoting/protocol/video_stub.h"
+
+namespace remoting {
+namespace protocol {
+
+// Version of VideoStub used on the sending side.
+class VideoSender : public VideoStub {

[Wez, 2015/01/21 01:35:40]

This name is confusing - classes that implement this interface are not senders,
per-se, but receivers/sinks.

Given that the VideoStub::ProcessVideoPacket() interface already has |done| as a
parameter, why not add the SupportsAck() there? Even though we don't care about
the |done| callback behaviour at the client right now, in principle this
indicator is just as valid there. e.g. it could be used to throttle if the
client has a slow decoder.

[Sergey Ulanov, 2015/01/29 01:33:29]

Done.

+ public:
+  // Indicates that the connection supports video packet acknowledgments, which
+  // means that VideoStub::ProcessVideoPacket() doesn't call |done| callback
+  // until a notification is received from the client that the frame has been
+  // rendered.
+  virtual bool SupportsAcks() = 0;
+
+ protected:
+  VideoSender() {}
+  virtual ~VideoSender() {}
+
+ private:
+  DISALLOW_COPY_AND_ASSIGN(VideoSender);
+};
+
+}  // namespace protocol
+}  // namespace remoting
+
+#endif  // REMOTING_PROTOCOL_VIDEO_SENDER_H_