Re: Proposal RTP for VP8
Josh Allmann
> There have been a few posts about RTP and VP8. I just wanted to get
> something up here quick so everyone can discuss what should go into the
> spec.
>
> 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).
>
The SDP rtpmap encoding name should still be specified here. How about "VP8"?
>
> 3.3 Lost VP8 RTP packets
> If a lost packet is detected in the RTP stream, the transport layer
> MUST throw out the current partial VP8 frame (if there is one) and
> all subsequent RTP packets until a VP8 payload descriptor with the
> key-frame bit is set.
>
I want to echo earlier concerns about the MUST here; dropping until
the next keyframe bit seems a bit excessive. Some data for the decoder
is better than no data. I think this should be a MAY drop until the
next start bit.
> As you can see this was intentionally kept very simple so we can start from
> a relatively clean slate. I also think as defined above will not work well
> for low bandwidth and trying to send the optimal packet size.
>
Any updates on when something more official will come out?
Implementations of VP8 in RTP are starting to pop up, and having a
spec for interop would be nice.
Josh
Luca Barbato
There are some discussions on the ffmpeg-devel ml regarding RTP
support,
Josh already prepared a packetizer and a depacketizer and I
implemented
a packetizer in feng to validate it independently.
As Josh said, the simple rfc as implemented seems to work more or less
well, would be
nice ratify it so we don't have fragmentation in the implementations
(not sure if gst updated their implementation to match this
specification).
lu