hi boris, welcome to the list.
here is the e-mail thread you might want to comment on.
cheers.
On Mon, Mar 27, 2017 at 7:43 AM, Sergio Garcia Murillo <
sergio.garcia.murillo@xxxxxxxxx> wrote:
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
-
