OLD | NEW |
---|---|
1 syntax = "proto2"; | 1 syntax = "proto2"; |
2 option optimize_for = LITE_RUNTIME; | 2 option optimize_for = LITE_RUNTIME; |
3 package webrtc; | 3 package webrtc; |
4 | 4 |
5 // This is the main message to dump to a file, it can contain multiple event | 5 // This is the main message to dump to a file, it can contain multiple event |
6 // messages, but it is possible to append multiple EventStreams (each with a | 6 // messages, but it is possible to append multiple EventStreams (each with a |
7 // single event) to a file. | 7 // single event) to a file. |
8 // This has the benefit that there's no need to keep all data in memory. | 8 // This has the benefit that there's no need to keep all data in memory. |
9 message ACMDumpEventStream { | 9 message ACMDumpEventStream { |
10 repeated ACMDumpEvent stream = 1; | 10 repeated ACMDumpEvent stream = 1; |
11 } | 11 } |
12 | 12 |
13 | |
stefan-webrtc
2015/06/24 11:46:16
nit: Do we need multiple (2) empty lines between e
terelius
2015/06/26 11:20:26
Personally I think it improves readability since i
stefan-webrtc
2015/06/27 11:01:06
Acknowledged.
| |
13 message ACMDumpEvent { | 14 message ACMDumpEvent { |
14 // required - Elapsed wallclock time in us since the start of the log. | 15 // required - Elapsed wallclock time in us since the start of the log. |
15 optional int64 timestamp_us = 1; | 16 optional int64 timestamp_us = 1; |
16 | 17 |
17 // The different types of events that can occur, the UNKNOWN_EVENT entry | 18 // The different types of events that can occur, the UNKNOWN_EVENT entry |
18 // is added in case future EventTypes are added, in that case old code will | 19 // is added in case future EventTypes are added, in that case old code will |
19 // receive the new events as UNKNOWN_EVENT. | 20 // receive the new events as UNKNOWN_EVENT. |
20 enum EventType { | 21 enum EventType { |
21 UNKNOWN_EVENT = 0; | 22 UNKNOWN_EVENT = 0; |
22 RTP_EVENT = 1; | 23 RTP_EVENT = 1; |
23 DEBUG_EVENT = 2; | 24 DEBUG_EVENT = 2; |
25 CONFIG_EVENT = 3; | |
24 } | 26 } |
25 | 27 |
26 // required - Indicates the type of this event | 28 // required - Indicates the type of this event |
27 optional EventType type = 2; | 29 optional EventType type = 2; |
28 | 30 |
29 // optional - but required if type == RTP_EVENT | 31 // optional - but required if type == RTP_EVENT |
30 optional ACMDumpRTPPacket packet = 3; | 32 optional ACMDumpRTPPacket packet = 3; |
31 | 33 |
32 // optional - but required if type == DEBUG_EVENT | 34 // optional - but required if type == DEBUG_EVENT |
33 optional ACMDumpDebugEvent debug_event = 4; | 35 optional ACMDumpDebugEvent debug_event = 4; |
36 | |
37 // optional - but required if type == CONFIG_EVENT | |
38 optional ACMDumpConfigEvent config = 5; | |
34 } | 39 } |
35 | 40 |
41 | |
36 message ACMDumpRTPPacket { | 42 message ACMDumpRTPPacket { |
37 // Indicates if the packet is incoming or outgoing with respect to the user | 43 // Indicates if the packet is incoming or outgoing with respect to the user |
38 // that is logging the data. | 44 // that is logging the data. |
39 enum Direction { | 45 enum Direction { |
40 UNKNOWN_DIRECTION = 0; | 46 UNKNOWN_DIRECTION = 0; |
41 OUTGOING = 1; | 47 OUTGOING = 1; |
42 INCOMING = 2; | 48 INCOMING = 2; |
43 } | 49 } |
44 enum PayloadType { | 50 enum PayloadType { |
45 UNKNOWN_TYPE = 0; | 51 UNKNOWN_TYPE = 0; |
46 AUDIO = 1; | 52 AUDIO = 1; |
47 VIDEO = 2; | 53 VIDEO = 2; |
48 RTX = 3; | 54 RTX = 3; |
49 } | 55 } |
50 | 56 |
51 // required | 57 // required |
52 optional Direction direction = 1; | 58 optional Direction direction = 1; |
53 | 59 |
54 // required | 60 // required |
55 optional PayloadType type = 2; | 61 optional PayloadType type = 2; |
56 | 62 |
57 // required - Contains the whole RTP packet (header+payload). | 63 // required - Contains the whole RTP packet (header+payload). |
58 optional bytes RTP_data = 3; | 64 optional bytes RTP_data = 3; |
59 } | 65 } |
60 | 66 |
67 | |
61 message ACMDumpDebugEvent { | 68 message ACMDumpDebugEvent { |
62 // Indicates the type of the debug event. | 69 // Indicates the type of the debug event. |
63 // LOG_START and LOG_END indicate the start and end of the log respectively. | 70 // LOG_START and LOG_END indicate the start and end of the log respectively. |
64 // AUDIO_PLAYOUT indicates a call to the PlayoutData10Ms() function in ACM. | 71 // AUDIO_PLAYOUT indicates a call to the PlayoutData10Ms() function in ACM. |
65 enum EventType { | 72 enum EventType { |
66 UNKNOWN_EVENT = 0; | 73 UNKNOWN_EVENT = 0; |
67 LOG_START = 1; | 74 LOG_START = 1; |
68 LOG_END = 2; | 75 LOG_END = 2; |
69 AUDIO_PLAYOUT = 3; | 76 AUDIO_PLAYOUT = 3; |
70 } | 77 } |
71 | 78 |
72 // required | 79 // required |
73 optional EventType type = 1; | 80 optional EventType type = 1; |
74 | 81 |
75 // An optional message that can be used to store additional information about | 82 // An optional message that can be used to store additional information about |
76 // the debug event. | 83 // the debug event. |
77 optional string message = 2; | 84 optional string message = 2; |
78 } | 85 } |
86 | |
87 | |
88 | |
89 // TODO(terelius): Video and audiostreams could in principle share ssrc, | |
hlundin-webrtc
2015/06/24 11:07:55
Nit: Please, write SSRC capitalized in comments.
stefan-webrtc
2015/06/24 11:46:16
audio streams
terelius
2015/06/24 11:51:19
Done.
| |
90 // so identifying a stream based only on ssrc might not work. | |
91 // It might be better to use a combination of ssrc and media type | |
92 // or ssrc and port number, but for now we will rely on ssrc only. | |
93 message ACMDumpConfigEvent { | |
94 // Synchronization source (stream identifier) to be received. | |
95 optional uint32 remote_ssrc = 1; | |
96 | |
97 // RTX settings for incoming video payloads that may be received. RTX is | |
98 // disabled if there's no config present. | |
ivoc
2015/06/24 11:27:12
One of the experienced protobuf guys told me "Don’
terelius
2015/06/26 11:20:26
The presence/absence of RTX settings in the C++ co
| |
99 optional RtcpConfig rtcp_config = 3; | |
hlundin-webrtc
2015/06/24 11:07:55
I'm not a protobuf expert, but why is there no fie
terelius
2015/06/24 11:51:18
I (mostly) modeled the config fields on the VideoR
hlundin-webrtc
2015/06/29 08:56:17
Acknowledged.
| |
100 | |
101 // Map from video RTP payload type -> RTX config. | |
102 repeated RtxMap rtx_map = 4; | |
ivoc
2015/06/24 11:27:12
Maybe we can use a map here instead of a seperate
terelius
2015/06/26 11:20:26
I've changed to use the map feature instead of an
| |
103 | |
104 // RTP header extensions used for the received stream. | |
105 repeated RtpHeaderExtension header_extensions = 5; | |
ivoc
2015/06/24 11:27:12
This could be another candidate to use the Map fea
terelius
2015/06/26 11:20:26
I've changed to use map instead of explicit list o
| |
106 | |
107 // List of decoders associated with the stream; | |
hlundin-webrtc
2015/06/24 11:07:55
End sentence with '.', not ';'
terelius
2015/06/24 11:51:19
Done.
| |
108 repeated DecoderConfig decoders = 6; | |
ivoc
2015/06/24 11:27:12
Maybe another map?
terelius
2015/06/26 11:20:26
Changed, but see previous comment on maps.
| |
109 } | |
110 | |
111 | |
112 // Maps decoder names to payload types. | |
113 message DecoderConfig { | |
114 optional string name = 1; // required | |
ivoc
2015/06/24 11:27:12
I think it would be good to keep comments on a sep
stefan-webrtc
2015/06/24 11:46:16
And start with a capital letter and end with a per
terelius
2015/06/26 11:20:26
For now I made my comments consistent with previou
stefan-webrtc
2015/06/27 11:01:06
sgtm
| |
115 optional sint32 payload_type = 2; // required | |
116 } | |
117 | |
118 // Maps RTP header extension names to numerical ids. | |
119 message RtpHeaderExtension { | |
120 optional string name = 1; // required | |
121 optional sint32 id = 2; // required | |
122 } | |
123 | |
124 | |
125 // RTX settings for incoming video payloads that may be received. RTX is | |
126 // disabled if there's no config present. | |
127 message RtxConfig { | |
128 // SSRCs to use for the RTX streams. | |
hlundin-webrtc
2015/06/24 11:07:55
The comment says SSRCs (in plural). But the field
terelius
2015/06/24 11:51:19
You're right. I'll consider a complete rewrite of
| |
129 optional uint32 ssrc = 1; // required | |
130 | |
131 // Payload type to use for the RTX stream. | |
132 optional sint32 payload_type = 2; // required | |
133 } | |
134 | |
135 | |
136 message RtxMap { | |
137 optional sint32 payload_type = 1; // required | |
138 optional RtxConfig config = 2; // required | |
139 } | |
140 | |
141 | |
142 // The interesting Rtcp packets are the ones that the sender receives | |
hlundin-webrtc
2015/06/24 11:07:55
Nit: Rtcp -> RTCP, when written in comments.
terelius
2015/06/24 11:51:19
Done.
| |
143 // Ergo, incoming Rtcp should be logged at the 'send'-side | |
144 message RtcpConfig { | |
145 // Sender SSRC used for sending RTCP (such as receiver reports). | |
146 optional uint32 local_ssrc = 1; | |
147 | |
148 // RTCP mode to use. Compound mode is described by RFC 4585 and reduced-size | |
149 // RTCP mode is described by RFC 5506. | |
150 enum RtcpMode {KRTCPCOMPOUND = 1; KRTCPREDUCEDSIZE = 2;} | |
stefan-webrtc
2015/06/24 11:46:16
Not knowing the style guide for protobufs, is this
terelius
2015/06/26 11:20:26
You're right. I'll change to RTCP_COMPOUND, etc.
| |
151 optional RtcpMode rtcp_mode = 2; | |
152 | |
153 // Extended RTCP settings. | |
154 optional bool receiver_reference_time_report = 3; | |
155 | |
156 // Receiver estimated maximum bandwidth. | |
157 optional bool remb = 4; | |
158 } | |
OLD | NEW |