mollyim/webrtc
1
0
Fork 0
mirror of https://github.com/mollyim/webrtc.git synced 2025-05-12 21:30:45 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Document purpose and wire format of extension http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00

Browse source 
Bug: webrtc:12000
Change-Id: Ia069665d7952c186fb9ba386d7e69fc7580eed7d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194960
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32674}
This commit is contained in:
Per Kjellander 2020-11-23 14:26:54 +01:00 committed by Commit Bot
parent 91e4156a8c
commit 8d526cd5c9
2 changed files with 83 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
docs/native-code/rtp-hdrext/index.md
View file

@ -10,3 +10,4 @@ The following subpages define experiemental RTP header extensions:
* [video-content-type](video-content-type/README.md)
* [video-timing](video-timing/README.md)
* [inband-cn](inband-cn/README.md)
* [video-layers-allocation00](video-layes-allocation00/README.md)

82
docs/native-code/rtp-hdrext/video-layers-allocation00/README.md Normal file
View file

@ -0,0 +1,82 @@
# Video Layers Allocation
The goal of this extension is for a video sender to provide information about
the target bitrate, resolution and frame rate of each scalability layer in order
to aid a middle box to decide which layer to relay.
**Name:** "Video layers allocation version 0"
**Formal name:**
<http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00>
**Status:** This extension is defined here to allow for experimentation.
In a conference scenario, a video from a single sender may be received by
several recipients with different downlink bandwidth constraints and UI
requirements. To allow this, a sender can send video with several scalability
layers and a middle box can choose a layer to relay for each receiver.
This extension support temporal layers, multiple spatial layers sent on a single
rtp stream (SVC), or independent spatial layers sent on multiple rtp streams
(Simulcast).
## RTP header extension format
### Data layout
```
// +-+-+-+-+-+-+-+-+
// |RID| NS| sl_bm |
// +-+-+-+-+-+-+-+-+
// Spatial layer bitmask |sl0_bm |sl1_bm |
// up to 2 bytes |---------------|
// when sl_bm == 0 |sl2_bm |sl3_bm |
// +-+-+-+-+-+-+-+-+
// Number of temporal |#tl|#tl|#tl|#tl|
// layers per spatial layer :---------------:
// up to 4 bytes | ... |
// +-+-+-+-+-+-+-+-+
// Target bitrate in kpbs | |
// per temporal layer : ... :
// leb128 encoded | |
// +-+-+-+-+-+-+-+-+
// Resolution and framerate | |
// 5 bytes per spatial layer + width-1 for +
// (optional) | rid=0, sid=0 |
// +---------------+
// | |
// + height-1 for +
// | rid=0, sid=0 |
// +---------------+
// | max framerate |
// +-+-+-+-+-+-+-+-+
// : ... :
// +-+-+-+-+-+-+-+-+
```
RID: RTP stream index this allocation is sent on, numbered from 0. 2 bits.
NS: Number of RTP streams - 1. 2 bits, thus allowing up-to 4 RTP streams.
sl_bm: BitMask of the active Spatial Layers when same for all RTP streams or 0
otherwise. 4 bits thus allows up to 4 spatial layers per RTP streams.
slX_bm: BitMask of the active Spatial Layers for RTP stream with index=X.
byte-aligned. When NS < 2, takes one byte, otherwise uses two bytes.
\#tl: 2-bit value of number of temporal layers-1, thus allowing up-to 4 temporal
layer per spatial layer. One per spatial layer per RTP stream. values are stored
in (RTP stream id, spatial id) ascending order. zero-padded to byte alignment.
Target bitrate in kbps. Values are stored using leb128 encoding. one value per
temporal layer. values are stored in (RTP stream id, spatial id, temporal id)
ascending order. All bitrates are total required bitrate to receive the
corresponding layer, i.e. in simulcast mode they include only corresponding
spatial layer, in full-svc all lower spatial layers are included. All lower
temporal layers are also included.
Resolution and framerate. Optional. Presence is inferred from the rtp header
extension size. Encoded (width - 1), 16-bit, (height - 1), 16-bit, max frame
rate 8-bit per spatial layer per RTP stream. Values are stored in (RTP stream
id, spatial id) ascending order.