Hi all,
As Alex has explained, I have been reviewing the ICIP-submitted draft
and I have some comments regarding it. Let me provide a more details
about them:
On the original ietf draft, the first bit of the PT is used to carry the
information of the X bit on the original RTP packet but on your pdf, as
if len =0,1,2 it should behave like the old draft, that first bit is
still the X bit but if len>2, then it becomes a new "R" bit and the
meaning changes and the X bit is lost.
So you will not be able to signal the X bit anymore, I don't think that
is a problem in real world, but seems weird.
Preparing it for the future, when doing SVC spatial layer selection, the
MD will need to rewrite the M marker bit when down switching to a lower
spatial layer. Currently there is no way to signal the original value of
the marker bit.
Also, if we could signal the padding bit and the padding size, we could
check in the MD if it is a zero padded bwe packet and drop it without
having to change current chrome behavior. As a side note, if we are
going to propose an alternative approach for the probing packets, I
think that using Flex FEC redundant data is the best way to go.
May I propose a new format compatible which IMHO is better and also
cover more info?
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|M|X|P|S|Q|p| z |
+-+-+-+-+-+-+-+-+
M - mark bit
X - extension bit
P - Payload Type present (1 byte)
S - SSRC present (3 bytes)
Q - Seq Num present (2 bytes)
p - Padding present (1 byte)
z - zero fill padding (0,1 or 2 bytes)
it covers the missing info (extension, mark and padding bit) and it has
a easier parsing serialization. In order o have backward compatibility
with previous draft (if required) the zero fill padding is there to
ensure len>2. If backward compatibility with previous draft is not an
issue, those 2 bits would be zero and reserved for future use.
Best regards
Sergio
On 27/03/2017 14:35, Alexandre GOUAILLARD wrote:
Hi everyone,
Yesterday I used the hackathon time to sync our modification with libwebrtc 57. I need now to sync chromium. Sergio is at the same point on his side.
Waiting for emil and boris to join the mailing list, I put those items here for archive. Hopefully, they will join today (US time). Emil and I should write the slides today for wednesday PERC session.
Sergio has some concerns with the OHB structure in our ICIP-submitted draft:
- On the original PERC IETF draft, the first bit of the PT is used to carry the information of the X bit on the original RTP packet. In our draft, if len =0,1,2 it should behave like the old draft, that is: the first bit should still be the X bit. But if len>2, it then becomes a new "R" bit, the meaning changes and the X bit is lost. We would not be able to signal the X bit anymore.
- Moreover we cannot signal the M mark bit. this will be needed for SVC streams if doing spatial layer selection
He'd like to propose a new format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|M|X|P|S|Q|p| z |
+-+-+-+-+-+-+-+-+
M - mark bit
X - extension bit
P - Payload Type present (1 byte)
S - SSRC present (3 bytes)
Q - Seq Num present (2 bytes)
p - Padding present (1 byte)
z - zero fill padding (0,1 or 2 bytes)
This format has many improvements:
- it covers the missing info (extension, mark and padding bit)
- padding bit addition allows to support the empty bwe packets without modification
- it has a easier parsing serialisation
- the zero fill padding is there to ensure len>2 to be backward compatible with current draft
For discussion.
Alex, for sergio
--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard <http://sg.linkedin.com/agouaillard>
*
