GNOME Bugzilla – Bug 587021
Support for MxPEG codec
Last modified: 2013-08-26 07:14:17 UTC
I've implemented support for the proprietary, open MxPEG codec from Mobotix: http://developer.mobotix.com/ Patch follows.
Created attachment 137406 [details] [review] Implementation and test of mxpegdec element This element is based on jpegdec. It also supports decoding of JPEG. The parsing functionality is stripped from it, since it is in jpegparse. The test only checks for decoding JPEG, since there is no MxPEG encoder element. The element is registered with rank SECONDARY, to avoid conflict with jpegdec. However, it could replace jpegdec completely (assuming jpegparse is there...).
Since this element doesn't do parsing internally anymore, I guess it depends on jpegparse.
Created attachment 137407 [details] [review] Parse MXF header and set timestamps based on it. The Mobotix headers also contain a timestamp, which is of course way better than the timestamps provided by the source element. I put it as a separate patch because I'm not 100% sure about how I subtract the offset from the timestamp (it is actually the absolute time that the image was taken, in microseconds since the Epoch).
By the way, you can test it with e.g. 85.15.152.10: gst-launch souphttpsrc location=http://85.15.152.10/control/faststream.jpg'?stream=MxPEG&fps=4' ! multipartdemux ! mxpegdec ! xvimagesink
Created attachment 137428 [details] [review] Revised implementation and test of mxpegdec element Found a bug in QoS handling (dropping buffer caused jpeg decoder to remain in wrong state). Here's a revised patch.
Created attachment 137429 [details] [review] Parse MXF header and set timestamps based on it.
Created attachment 137773 [details] [review] mxpegdec: unref the incoming buffer Oops, I forgot to unref the incoming buffer. There's also an unitialized memory warning that can be avoided.
I put this plugin in -good because it uses libjpeg and therefore goes together with jpegenc/jpegdec. If it is to be applied to -bad, the autotools should also be updated to include libjpeg. If there is some interest, I'm willing to recreate a patch against the current head, but since I've seen completely no activity on this bug...
tn Arnout. I'll have a look at activating this one in early 2011.
Created attachment 177646 [details] [review] Revised implementation and test of mxpegdec element: refresh against last good releases
Created attachment 177647 [details] [review] Parse MXF header and set timestamps based on it: refresh against last good releases
Created attachment 177648 [details] [review] mxpegdec: unref the incoming buffer: refresh against last good releases
Any reason that the decoder accepts image/jpeg on the sink pad next to video/x-mxpeg? If it would only to accept video/x-mxpeg; it would not get into conflict with image/jpeg and decodebin would word as usual. Adding a capssetter to set the falsely detected image/jpeg in uridecodebin to set it to video/x-mxpeg allows the rest of the chain to work as usual; while jpegde chokes on the mobotix stream in any case.
I am using this to force the correct autoplugging: $ gst-launch souphttpsrc location=http://10.3.0.42/control/faststream.jpg?stream=MxPEG\&fps=25 ! multipartdemux ! capssetter caps="video/x-mxpeg" replace=1 join=0 ! decodebin2 ! autovideosink
(In reply to comment #13) > Any reason that the decoder accepts image/jpeg on the sink pad next to > video/x-mxpeg? Since it's been more than two years ago, I can't be sure anymore. I _think_ it was because the typefinder doesn't/didn't distinguish between jpeg and mxpeg, and this decoder can anyway decode jpeg as well. The good solution is of course to support mxpeg in typefind. I also wrote a typefind extension for mxpeg back then, but I don't remember if I contributed it in the end...
I think this should be integrated into jpegdec if MxPEG is only an extension on top of JPEG, which seems to be the case because the MxPEG decoder supports normal JPEG too. This would likely reduce some of the code duplication. Could you provide a patch for that? And for a typefinder for MxPEG?
Integrating it with jpegdec was indeed the purpose. I made it a separate element to avoid breaking the existing jpeg functionality. It would also solve the autoplugging problem. Unfortunately I won't have the time to integrate it back into jpegdec anytime soon. I'll put it on my todo list.
Is someone planning to work on this? Should we keep this bug open?
I think the number of users of mxpeg is likely very small. All current Mobotix cameras support H.264 so why would anyone want to decode the MxPEG stream? So dropping it is OK for me.