GNOME Bugzilla – Bug 147315
[PATCH] h.263 encoder that supports RTP mode
Last modified: 2011-05-20 14:40:18 UTC
I wrote a h.263 encoder plugin to replace the buggy one from ffmpeg. The encoder of ffmpeg even can't work with its own decoder! But my encoder can work with it :) This encoder, named r263, is based on libr263 written by Roalt Aalmoes (aalmoes@huygens.nl). I also modified it to support RTP mode. In RTP mode, an extra h.263 payload header is required. By default RTP support is disable. There is an option to turn it on. Currently this plugin works well with ffdec_h263 if the image size is 176x144. Other sizes are not supported. (I think it is a problem of ffmpeg).
Created attachment 29432 [details] h.263 encoder plugin
Created attachment 29433 [details] corrected version sorry, please use this one. some bugs fixed.
Comment on attachment 29433 [details] corrected version it now supports other image sizes.
This plugin is excellent, however the licencing of libr263 seems a bit dubious. Is there any chance u can come on irc (irc.freenode.net #gstreamer) to discuss this plugin further....
I mailed Roalt today asking for the code to be LGPL licensed. If he says no or don't reply within a couple of weeks I guess we have to close this as WONTFIX or similar.
Hi All, I'm Roalt, the original developer of the r263 library. I've written it in 1995-1996, but it seems it's still popular. My e-mail address for H-263 related is h263 (at) roalt (dot) com. I cannot remember I ever had an e-mail called aalmoes@huygens.nl (maybe huygens.org) but this is already strongly outdated. The code I have written was based upon LGPL code from someone at Telenor wrote. I improved it signicantly (read:completely rewrote it) so it was useful for real-time encoding/decoding. The code is 100% GPL so feel free to use it in any (L)GPL way you like it. The software patents is another thing. But to be frank: I do not know anything about them: in the 8 years I have the code available, not a single company complained about it. It might be different if you put it in a commercial product, just like with mp3-codecs probably. I think there are now lot of improved codecs and H.263 is not used much. I don't think anyone will complain about it when you put it in GStreamer. See my homepage www.roalt.com, then click on H.263. I do not actively support the code anymore, but I'm always willing to answer some of your questions.
confirm bug, add PATCH keyword and prefix, set milestone to 0.8.7 as licencing issue is fixed, set severity to ehnancement, put Zaheer Merali in Cc as it seems he would be the one that would integrate/evaluate it.
DON'T milestone to next release without a possible resolution
Hrmm, stumbled upon this old bug post. This element is now in Farsight's gst-plugins-farsight repo. I guess I will move it to gstreamer one of these days. Just as a note this element has the encoder lib statically linked to it, since the lib has been hard modified to support RTP. I don't know how you guys feel about that. Let me know before I move this element to gst-plugins-good.
Looks potentially interesting. It would have to go into gst-plugins-ugly, though, due to licensing issues surrounding the H.263 format.
Is the 'hard modified' to support RTP a problem for anyone? or can this plugin be moved to gst-plugins-ugly when Philippe is ready?
if it supports everything that the regular RTP payloaders do (and preferably more), I don't have any problems.
I guess ffmpeg does all we need now? If there is still some reason to support r263, please re-open the bug