After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754773 - rtp: Implement VP9 payloader and depayloader
rtp: Implement VP9 payloader and depayloader
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
Other Linux
: Normal enhancement
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-09-09 11:53 UTC by Sebastian Dröge (slomo)
Modified: 2016-02-16 13:58 UTC
See Also:
GNOME target: ---
GNOME version: ---

rtpvp9pay: rtpvp9depay: Initial implementation of draft 01 (35.63 KB, patch)
2016-02-16 13:36 UTC, Stian Selnes (stianse)
committed Details | Review

Description Sebastian Dröge (slomo) 2015-09-09 11:53:54 UTC
See . Can probably be based on the VP8 ones after some copy & paste.
Comment 1 Nicolas Dufresne (ndufresne) 2015-09-09 12:37:19 UTC
(In reply to Sebastian Dröge (slomo) from comment #0)
> See . 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.
Comment 2 Sebastian Dröge (slomo) 2015-09-09 12:50:45 UTC
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.
Comment 3 Stian Selnes (stianse) 2016-01-04 14:44:33 UTC
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:

Comment 4 Sebastian Dröge (slomo) 2016-02-16 11:39:34 UTC
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.
Comment 5 Tim-Philipp Müller 2016-02-16 11:50:45 UTC
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 ;)
Comment 6 Sebastian Dröge (slomo) 2016-02-16 12:23:23 UTC
Ok, good it is then? Stian, what do you think? :)
Comment 7 Stian Selnes (stianse) 2016-02-16 12:44:27 UTC
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.

Comment 8 Sebastian Dröge (slomo) 2016-02-16 13:06:09 UTC
Sounds good, let's go with that then :)
Comment 9 Stian Selnes (stianse) 2016-02-16 13:36:40 UTC
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.
Comment 10 Sebastian Dröge (slomo) 2016-02-16 13:56:47 UTC
Attachment 321369 [details] pushed as 5faa9c1 - rtpvp9pay: rtpvp9depay: Initial implementation of draft 01