(In reply to Sebastian Dröge (slomo) from comment #0)
> See https://tools.ietf.org/html/draft-ietf-payload-vp9-00 . Can probably be
> based on the VP8 ones after some copy & paste.

Well, would be nice not to copy paste (unless really trivial), we already have enough copy & paste in the VP8/9 area.

Sure, just like with H26X. The problem with the (de)payloader will be that the actual processing is different enough that you need to write that in separate code anyway (or have one function with lots of ifs that does both) and can't really do it in a base class... and what is left then is boilerplate.


For vpXenc/dec it definitely makes sense to create a base class.

I've pushed a quick and dirty implementation of rtpvp9pay and rtpvp9depay to our repo[1]. We will implement more of the latest draft over time. Currently I've only implemented what's needed to work with Chrome 48 (draft version 01). Some header fields are assumed to be set / not set, and temporal and spatial scalability is ignored.

Hopefully it's useful for others as well in its current state. I'm planning to submit a patch when tests are added and more of the draft is implemented.

Also note that the draft linked to in the opening comment is expired. The latest draft is found at: https://tools.ietf.org/html/draft-ietf-payload-vp9

[1]: https://github.com/pexip/gst-plugins-good/tree/master/gst/rtp

Stian, can you provide a patch against gst-plugins-bad for this that adds a new rtpbad plugin with this code? I think then it would be good to be merged at this point already.

The rtpbad plugin was just removed :P

If the implemented parts of the spec are stable and/or interoperability with another implementation (chrome?) has been tested, we should just put it in -good and fix it up as needed. Many of our other payloaders/depayloaders probably had less testing ;)

Ok, good it is then? Stian, what do you think? :)

I can provide a patch against -good. The state of the plugin is the same as before. It worked great in a webrtc call with Chrome 48, but that's the only thing I've tested.

But I would not rely on the implemented parts of the spec to be stable. I initially by mistake looked at version 00 of the draft instead of version 01 when implementing the elements. They were significantly different and was not interoperable. At the moment it's speculation whether future drafts will be interoperable or not. But currently the WebRTC project[1] has not made any changes to this code that suggests the draft will change significantly.

I'll submit a patch in any case so that it's available.

[1]: https://chromium.googlesource.com/external/webrtc/+/master/webrtc/modules/rtp_rtcp/source/rtp_format_vp9.cc

Sounds good, let's go with that then :)

Created attachment 321369 [details] [review]
rtpvp9pay: rtpvp9depay: Initial implementation of draft 01

Quick and dirty implementation of an RTP payloader and depayloader
for VP9. In particalur it assumes no spatial or temporal layering,
non-flexible mode, and some other bits and pieces.

Attachment 321369 [details] pushed as 5faa9c1 - rtpvp9pay: rtpvp9depay: Initial implementation of draft 01