| Bug ID |
9757
|
| Summary |
Add RTCP dissector for goog-remb (Receiver Estimated Maximum Bitrate)
|
| Classification |
Unclassified
|
| Product |
Wireshark
|
| Version |
1.11.x (Experimental)
|
| Hardware |
x86
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Enhancement
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Created attachment 12559 [details]
Contains two frames, the 2nd frame is an example that references two SSRCs
Build Information:
wireshark 1.11.3 (wireshark-1.11.3-rc1-1581-gd7edad3-dirty from master)
--
New feature to support goog-remb (Receiver Estimated Maximum Bitrate). I
intend to commit this feature today. I'm raising this bug largely so I can
attach a pcap so that the feature can be code reviewed.
This RTCP message is used by Chrome browser when performing WEB-RTC and is
defined in:
http://tools.ietf.org/html/draft-alvestrand-rmcat-remb-00
REMB is a payload-specific RTCP message (PT=206, FMT=15) which serves a near
identical function to TMMBR (PT=205, FMT=3).
It is a mechanism by which an endpoint can communicate what it thinks the max
bit rate the other end should be sending streams. Unlike TMMBR it is possible
for the endpoint to specify multiple streams i.e. "please ensure the combined
bitrate for SSRC1 (e.g VP8) and SSRC2 (e.g. opus) do not exceed value X bits
per second. The other end would then adjust its encoders based on REMB bitrate
values for the ssrcs listed.
You are receiving this mail because:
- You are watching all bug changes.