I have an Asterisk based solution using pjsip where most endpoints are H264 video capable.
Unfortunately, some older display devices are only capable of doing mjpeg playback.
While the newer (camera) devices are only offering H.264 in their SDP.
I’m looking for a solution to offer a (transcoded) mjpeg stream to the older devices.
Can I modify the SDP in the SIP INVITE to add a mjpeg stream source from within Asterisk ?
Since Asterisk is not capable of doing video-transcoding, anyone can advise on an OSS solution that provides video transcoding which integrates with Asterisk ?
There is no capability to modify the SDP, and there is no support for mjpeg in Asterisk. You would need to modify code and figure out how to make it work.
Asterisk would not be the right program for that. Asterisk basically has to fit into a more or less standardized telephony environment, if not into an NGN network.
I would not consider implementing MJPEG given the features that should ultimately be supported and are far more important. One of the really stupid things about telephoning is that the other end has to support something like that too. I’d recommend having a look at Kamailio/rtpengine, but be prepared for a longer learning path.
Thanks all for the replies. I’ll try to find-out what the devices expect SDP-wise.
And then make a trade-off if it’s worth modding Asterisk
Hypothetical question in the same area:
Asterisk supports both VP8 and H.264.
What if I’d had a H.264 only camera and a VP8 only video-display?
Would there be an approach that works with Asterisk, or would I end-up in the same (nearly) dead end for a solution ?
There is no video transcoding support in Asterisk, 'nor has the transcoding core been tested for such a thing, or things really developed for such - so video would not flow, things would fail.
You don’t even want transcoding with audio. To and from slin is not a problem, but having more complex codecs guarantees immediate angry phone calls from customers if any of the audio streams is of bad quality due to WiFi problems or whatever. Transcoding is something for telcos with proper hardware, imo.
Telcos aren’t generally interested in general case transcoding. They may transcode G.711 A to G.711 µ, when crossing the Atlantic, or G.711 to GSM in a mobile base station, but they won’t have special hardware for the wide range of codecs used in private VoIP networks. I suspect ITSPs transcode in software.
I see the AMR codecs in the SDP payloads on my systems for many calls from mobile networks. G.711 must be offered in my provider’s landlines, but I’m not sure if this is generally the case in mobile networks. G.711 would require 3 to 10 times the bandwidth compared to the AMR class and therefore makes less sense for mobile networks. This would imply that transcoding must definitely take place in between.