Updated VP8 RTP proposal

[Frank Galligan]

I updated the VP8 RTP proposal adding aggregation and fragmentation. I also added the SDP encoding name for the rtpmap. I made it as a Google Doc but I don't think I can share that with a group as a whole. I will paste the text into the email. If the formatting gets screwed up I will do something else.

1.0 RTP Payload format for VP8

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         | RTP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           | Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                                                               | RTP
|      VP8 stream (byte aligned)                                | Pay-
|                                                               | load
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 - An RTP packet for VP8 stream

1.1 Use of RTP header fields.
Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, if that is not done then a payload type in the dynamic range SHALL be chosen by means of an out of band signaling protocol (e.g., H.245,SIP, etc).

Extension (X) bit: Defined by the RTP profile used.

Sequence Number: Incremented by one for each RTP data packet sent, starting, for security reasons, with a random initial value.

Marker (M) bit: The Marker bit of the RTP header is set to 1 when the current packet carries the end of the current frame and is 0 otherwise.

Timestamp: The timestamp indicates the sampling instance of the media sample whose data begins within this RTP packet. A constant offset, which is random, is added for security reasons. - There is at most one media sample or partial media sample per RTP packet. - Media samples may be split across multiple RTP packets. - The resolution of the timestamp is set to its default value of 90kHz,unless specified by an out-of-band means (I.E. SDP parameter).

1.2 Format of VP8 payload descriptors.

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   RESV    |A|B|
+-+-+-+-+-+-+-+-+

RESV: 6 bits
  Reserved. MUST be set to zero. This space is reserved for                       
  future use.

A: 1 bit
  VP8 Aggregate Packet. When set to 1 this signals that the VP8
  payload will be an VP8 Aggregate Packet.

B: 1 bit
  Beginning VP8 frame. When set to 1 this signals that a new VP8
  frame starts in this RTP packet.

1.3 VP8 aggregate packets
VP8 aggregate units within the same RTP packet or same sequence of VP8 fragmented RTP packets MUST have the same timestamp. The payload format of a VP8 aggregate packet consists of one or more VP8 aggregate units. The payload format of a VP8 aggregate unit consists of a 2 byte VP8AU header preceding each VP8 block of data.

The VP8AU header has the following format:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   RESV  |        SIZE         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RESV: 5 bits
  Reserved. MUST be set to zero. This space is reserved for                       
  future use.

SIZE: 11 bits
  This is the size in bytes of the VP8 block of data following the
  VP8AU header.

Figure XX presents an example of an RTP packet containing two VP8 aggregate units.
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             RTP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VP8 Payload Dsc|          VP8AU Header         |  VP8 Data     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:                                                               :
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |          VP8AU Header         |  VP8 Data     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


1.4 Determining Key Frames
If an application needs to know if a VP8 frame is a key frame the application MUST get that information from the VP8 compressed data.

The first byte of a VP8 frame has the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|K|   XXXXXXX   |
+-+-+-+-+-+-+-+-+

K: 1 bit
  Key frame flag. When set to 0 the preceding frame is a key frame.
  When set to 1 the preceding frame is an interframe.

XXXXXXX: 7 bits
   The rest of the VP8 compressed data in the first byte.  

1.5 Lost VP8 RTP packets
If a lost packet is detected in the RTP stream, the application layer MUST decide how to handle the subsequent packets.

1.6 Examples of VP8 RTP Stream

1.6.1 1000 byte VP8 key frame in a single RTP packet. Note the first bit in the VP8 data is 0.
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP Header M=1                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0|0              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 0 to 999                                     :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


1.6.2 1000 byte VP8 interframe frame in a single RTP packet. Note the first bit in the VP8 data is 1.
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP Header M=1                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0|1              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 0 to 999                                     :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


1.6.3 1500 byte VP8 frame fragmented across two RTP packets. The first RTP packet contains the first 1000 bytes of VP8 data. The second RTP packet contains the next sequential 500 bytes of VP8 data.

RTP packet #1
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP Header M=0 SEQ=N                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 0 to 999                                     :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP packet #2
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP Header M=1 SEQ=N+1                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 1000 to 1499                                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


1.6.4 2500 byte VP8 frame fragmented across three RTP packets. The first RTP packet contains the first 1000 bytes of VP8 data. The second RTP packet contains the next sequential 1000 bytes of VP8 data. The third RTP packet contains the next sequential 500 bytes of VP8 data.

RTP packet #1
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP Header M=0 SEQ=N                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 0 to 999                                     :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP packet #2
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP Header M=0 SEQ=N+1                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 1000 to 1999                                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP packet #3
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        RTP Header M=1 SEQ=N+2                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 2000 to 2499                                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


1.6.5 1000 byte VP8 frame with one VP8 aggregation unit in a single RTP packet. The first VP8AU has size of 1000 bytes.
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             RTP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|0 0 0 0 0 0 1 1 1 1 1 0 1 0 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 0 to 999                                     :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


1.6.6 1000 byte VP8 frame split into two VP8 aggregation units in a single RTP packet.  The first VP8AU has size of 700 bytes. The second VP8AU has a size of 300 bytes.
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             RTP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|0 0 0 0 0 0 1 0 1 0 1 1 1 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 0 to 699                                     :
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |0 0 0 0 0 0 0 1 0 0 1 0 1 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 700 to 999                                   :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


1.6.7 3000 byte VP8 frame split into six VP8 fragmentation units of 500 bytes each fragmented across three RTP packets. The first RTP packet contains the first and second VP8AU. The first VP8AU has size of 500 bytes. The second VP8AU has a size of 500 bytes. The second RTP packet contains the third and forth VP8AU. The third VP8AU has size of 500 bytes. The forth VP8AU has a size of 500 bytes. The third RTP packet contains the fifth and sixth VP8AU. The fifth VP8AU has size of 500 bytes. The sixth VP8AU has a size of 500 bytes.

RTP packet #1
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       RTP Header M=0 SEQ=N                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 1|0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 0 to 499                                     :
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 500 to 999                                   :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP packet #2
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       RTP Header M=0 SEQ=N+1                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 1000 to 1499                                 :
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 1500 to 1999                                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RTP packet #3
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       RTP Header M=1 SEQ=N+2                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 2000 to 2499                                 :
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |0 0 0 0 0 0 0 1 1 1 1 1 0 1 0 0|               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
:   VP8 Data bytes 2500 to 2999                                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


2.0 SDP Parameters

• The encoding name in the "a=rtpmap" line of SDP MUST be VP8.
• The optional parameter "version", if included SHALL be in the "a=fmtp" line of SDP. This parameter matches the VP8 bitsream version. I.E. "a=fmtp:97 version=0"

[Tester]

Hi,

On Aug 5, 11:59 pm, Frank Galligan <fgalli...@google.com> wrote:
> I updated the VP8 RTP proposal adding aggregation and fragmentation. I also
> added the SDP encoding name for the rtpmap. I made it as a Google Doc but I
> don't think I can share that with a group as a whole. I will paste the text
> into the email. If the formatting gets screwed up I will do something else.

...

> 1.3 VP8 aggregate packets
> VP8 aggregate units within the same RTP packet or same sequence of VP8
> fragmented RTP packets MUST have the same timestamp. The payload format of a
> VP8 aggregate packet consists of one or more VP8 aggregate units. The
> payload format of a VP8 aggregate unit consists of a 2 byte VP8AU header
> preceding each VP8 block of data.

If I understand correctly, it means that you can only aggregate
packets from the same video frame ? If it is the case, it should be
clearer. That said, can't they be just merged ?

--
Olivier Crête
olivie...@collabora.co.uk

[Frank Galligan]

On Fri, Aug 6, 2010 at 7:49 AM, Tester <thet...@gmail.com> wrote:

Hi,

On Aug 5, 11:59 pm, Frank Galligan <fgalli...@google.com> wrote:
> I updated the VP8 RTP proposal adding aggregation and fragmentation. I also
> added the SDP encoding name for the rtpmap. I made it as a Google Doc but I
> don't think I can share that with a group as a whole. I will paste the text
> into the email. If the formatting gets screwed up I will do something else.

...

> 1.3 VP8 aggregate packets
> VP8 aggregate units within the same RTP packet or same sequence of VP8
> fragmented RTP packets MUST have the same timestamp. The payload format of a
> VP8 aggregate packet consists of one or more VP8 aggregate units. The
> payload format of a VP8 aggregate unit consists of a 2 byte VP8AU header
> preceding each VP8 block of data.

If I understand correctly, it means that you can only aggregate
packets from the same video frame ?

Yes. Some people who do RTC asked for this feature. 

 

If it is the case, it should be
clearer.

ok.

 

That said, can't they be just merged ?

Yes. When people asked for having the ability to aggregate VP8 data with same timestamp, I think they were looking to the future. For different applications it could be advantageous. 

Also this is not set in stone. I posted this so everyone can talk about what they want to see in or what they want to see out.

How does everyone do error correction? Do you use RFC 2733? or something else? Should error correction be in the RTP spec?

Frank

--
Olivier Crête
olivie...@collabora.co.uk

--

You received this message because you are subscribed to the Google Groups "WebM Discussion" group.
To post to this group, send email to webm-d...@webmproject.org.
To unsubscribe from this group, send email to webm-discuss...@webmproject.org.

For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.

[Jeffrey Koppi]

Frank,

Section 1.4 Determining Key Frames, says "When set to 0 the preceding

frame is a key frame".

Do you really mean "preceding" frame, ie the previous frame?
The examples in 1.6 show that 0 means current frame is a keyframe, (or
the following vp8 data is a key frame).

Jeff

> --
> You received this message because you are subscribed to the Google Groups
> "WebM Discussion" group.
> To post to this group, send email to webm-d...@webmproject.org.
> To unsubscribe from this group, send email to
> webm-discuss...@webmproject.org.
> For more options, visit this group at
> http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
>

--
Jeffrey Koppi
Google On2 | Clifton Park, NY

[Frank Galligan]

Good catch. That should be current frame.

Frank

[Sjoerd Simons]

Judging from the examples even non-aggregate packets seem to use the
VP8AU header, which seems unnecessary as it doesn't add any information
that isn't already available from the RTP/UDP headers.

One thing that it's not clear from the text (or at least confused me at
first) is that the header indicates the size of a block of data _inside_
one RTP packet, not the full size of the VP8 unit. Might be good to
clarify that

The other thing that i found confusing is that the first aggregate unit
of an RTP packets continues the VP8 unit implicitly, which means
payloaders need to have some special handling for the corner-case where
the split between two units falls exactly on the split between two RTP
packets. It's doable, but might be more clear to use a bit to explicitly
indicate the start of a VP8 unit.

And last but not least, using 11 bits for the size seems a bit low as it
only allows for a maximum of 2k per data block. It's fine on most
current networks which have an mtu of 1500 bytes, but some educational
networks are already using an mtu of 9000 (jumbo frames). To be
future-proof it would be good to allow the block size be big enough to
mostly/completely fill UDP/TCP/SCTP packets and thus use 16 bits for the
length.

Btw, are you planning to propose this as an RFC to the IETF after the
discussion on this list settled down a bit or?

Thanks for your work!
--
Sjoerd Simons <sjoerd...@collabora.co.uk>
Collabora Ltd.

[Josh Allmann]

I second this; additionally, if every RTP packet is required to have a
VP8AU header (as the examples imply), then I fail to see the need for
a VP8 Aggregate Packet bit in the payload descriptor.

> One thing that it's not clear from the text (or at least confused me at
> first) is that the header indicates the size of a block of data _inside_
> one RTP packet, not the full size of the VP8 unit. Might be good to
> clarify that
>
> The other thing that i found confusing is that the first aggregate unit
> of an RTP packets continues the VP8 unit implicitly, which means
> payloaders need to have some special handling for the corner-case where
> the split between two units falls exactly on the split between two RTP
> packets. It's doable, but might be more clear to use a bit to explicitly
> indicate the start of a VP8 unit.
>
> And last but not least, using 11 bits for the size seems a bit low as it
> only allows for a maximum of 2k per data block. It's fine on most
> current networks which have an mtu of 1500 bytes, but some educational
> networks are already using an mtu of 9000 (jumbo frames). To be
> future-proof it would be good to allow the block size be big enough to
> mostly/completely fill UDP/TCP/SCTP packets and thus use 16 bits for the
> length.
>

Currently there are a total of 11 reserved bits, in both the payload
descriptor and the VP8AU header. Any idea as to what those bits could
be used for in the future? I think only one or two bits would be
needed to version the VP8 rtp profile, that way it frees up bits for
the VP8AU length but allows future extensions the flexibility to
re-define the header structure if needed.

I suppose one could also fragment a media sample into mutiple VP8AUs
and stuff them into a jumbo frame.

Josh

[Frank Galligan]

Sorry I added the figures right before I posted and was copy and paste error. If the aggregation bit is not set there should not be a VP8AU header. 

One thing that it's not clear from the text (or at least confused me at
first) is that the header indicates the size of a block of data _inside_
one RTP packet, not the full size of the VP8 unit. Might be good to
clarify that

ok 

The other thing that i found confusing is that the first aggregate unit
of an RTP packets continues the VP8 unit implicitly, which means
payloaders need to have some special handling for the corner-case where
the split between two units falls exactly on the split between two RTP
packets. It's doable, but might be more clear to use a bit to explicitly
indicate the start of a VP8 unit.

Are you saying if you one VP8 aggregate unit split across 2 rtp packets? What if we added VP8 aggregate units must not be split across multiple RTP packets?

  

And last but not least, using 11 bits for the size seems a bit low as it
only allows for a maximum of 2k per data block. It's fine on most
current networks which have an mtu of 1500 bytes, but some educational
networks are already using an mtu of 9000 (jumbo frames). To be
future-proof it would be good to allow the block size be big enough to
mostly/completely fill UDP/TCP/SCTP packets and thus use 16 bits for the
length.

Sounds good to me.

 

Btw, are you planning to propose this as an RFC to the IETF after the
discussion on this list settled down a bit or?

Probably at some point.

I'm in the process of getting the spec hosted at webmproject.org which should be better than posting changes in email.

Frank

 

Thanks for your work!
--
Sjoerd Simons <sjoerd...@collabora.co.uk>
Collabora Ltd.

--

[Luca Barbato]

On Aug 11, 1:39 am, Frank Galligan <fgalli...@google.com> wrote:
> Are you saying if you one VP8 aggregate unit split across 2 rtp packets?
> What if we added VP8 aggregate units must not be split across multiple RTP
> packets?

I think it's correct and that's what most of the other packetization
system do.

lu

[Sjoerd Simons]

Sounds good to me. With that approach and using 16 bits for the size of
an aggregation unit VP8 aggregated units would be quite simpilar to
STAP-A packets in RFC3984 (h264 payloading).

It would leave us without reserved bits for describing the individual
units though (h264 uses the 8 bit NALU header for this), although i'm
not sure those would be needed as hopefully the VP8 data blocks would be
able to describe themselves in enough detail.

[Alex Eleftheriadis]

I think it would be very useful to review other RTP payload formats, such as the ones for H.264 AVC and SVC. A lot of the issues that are discussed here (e.g., fragmentation and aggregation), and more that will surely be discussed in the future (various flags), have already been the subject of extensive discussion in IETF's avt mailing list for other codecs. 

In the issue of aggregation and segmentation, the way to go is not to allow both at the same time. 

Along these lines, I think the work on SVC is relevant in the discussion here because VP8 can do temporal scalability, and is thus a scalable codec. Of course it does not have to be operated as such, but when it is, it would be advantageous if this was exposed at the RTP payload level. Looking at page 9 of the "VP8 Data Format and Decoding Guide" (rev. of July 26, 2010), this is hinted at in the discussion about videoconferencing. 

The SVC payload is described in http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-21. I would scan it taking notes on what may be relevant for VP8. AVC is at http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-11. (Note: I co-authored the SVC draft.) 

From the top of my head, and focusing on parameters that are not present yet in the design, I would consider optionally  exposing a temporal level indication, as well as related "arsenal" that is used for error robustness with temporal scalability. If I understand VP8's buffer management process correctly, VP8 can do up to 4 layers of temporal scalability, or 5 if you include key frames, so you need 3 bits for that. 

For error robustness, you need to include the start and end flags (S/E in the SVC payload) as well as the equivalent of TL0PICIDX mechanism to facilitate the loss detection and recovery mechanism (of key/golden frames). The "S" flag appears to be equivalent to the B bit, and in this case RTP's M bit should be functionally equivalent to the "E" flag. So you just need temporal level indication plus the index values.

I would also not neglect the possibility for extensions in the future, so some may to skip over unknown data could be a prudent step.

Finally, I think that it would be best if an internet-draft is created with this sort of basic information (for a -00 version), and the discussion is taken to IETF's avt mailing list. IMHO, this will ensure that the whole process will result in an IETF-approved payload format in the shortest possible time. 

And a correction: For the K flag in Section 1.4, it is set to 0 if the *current* frame is a key frame, not the preceding (per p. 28 of the spec).  Incidentally, all the data in the 3-byte frame tag should be exposed in the payload format (a matter of convenience for the reader -- they  don't necessarily have to read the coding spec to use them or figure out that they exist). 

 

Regards.

--Alex

[Frank Galligan]

I updated the spec and published on webmproject to make it easier for everyone to look at.

http://www.webmproject.org/code/specs/rtp/

Frank

--

[Alex Eleftheriadis]

As I was asked about this, I want to clarify that my previous email is not to be seen as a contribution in the sense of the WebM Project's Contributor License Agreement (Corporate or Individual). Neither myself nor Vidyo have signed these agreements. 

Regards.

--Alex

[Luca Barbato]

On Aug 12, 10:49 pm, Frank Galligan <fgalli...@google.com> wrote:
> I updated the spec and published on webmproject to make it easier for
> everyone to look at.
>
> http://www.webmproject.org/code/specs/rtp/

Nice formatting, the source is available somewhere to edit?

Here few considerations from a cursory look:

Extension Header
- The Aggregation Unit spans 2 bytes, the value has to be be or le?
(I'd suggest keep everything in network order)
- the key frame bit is 0b1, the A and B bits are 0b100000 and
0b1000000 ? Better if you make those part crystal clear.

SDP
- What the receiver should do about the version parameter? What
information would it deliver to it?
The rfc would use this version to discriminate optional features
that might be too complex to implement on constrained systems?
- an vp8 profile parameter could be an information that sender and
receiver would agree with during Offer/Answer exchange

lu

[Lou Quillio]

On Fri, Aug 13, 2010 at 5:59 AM, Luca Barbato <luca.b...@gmail.com> wrote:

>> http://www.webmproject.org/code/specs/rtp/

> Nice formatting, the source is available somewhere to edit?

If needed, we'll quickly make a project in our git forest for the RTP
draft. For now, raw text in Markdown (extra) format is linked from
here:

http://www.webmproject.org/code/specs/

LQ

--
Lou Quillio
Tech Writer
WebMProject.org
+1 518.285.0003   <= Mobile (gV)
+1 518.881.4256   <= Office