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 packetsIf I understand correctly, it means that you can only aggregate
> 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.
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
--
You received this message because you are subscribed to the Google Groups "WebM Discussion" group.For more options, visit this group at http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
To post to this group, send email to webm-d...@webmproject.org.
To unsubscribe from this group, send email to webm-discuss...@webmproject.org.
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
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.
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
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.
--
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.
--
>> 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