GNOME Bugzilla – Bug 709352
jpegdec: Does not require width/height on caps or parsed input
Last modified: 2013-10-04 13:12:38 UTC
I've got some issue displaying jpeg images from an http source using the following command line: gst-launch-1.0 souphttpsrc location=http://91.121.134.112/sample.jpg ! decodebin ! videoconvert ! imagefreeze ! autovideosink First it seems that typefind is not receiving enough data to be able to find the width and height of the image, thus the resulting caps are just image/jpeg. If gst-libav is present, avdec_mjpeg is used resulting in a incomplete image displayed on screen (or no image at all), since it tries to decode an incomplete buffer. If gst-libav is not present, jpegdec is not used because its sink caps required width and heigh (even if the decoder seems to have some kind of parser). Removing the width/height caps from the jpegdec sink does the trick and the image is displayed on screen. My question is: is removing thoses caps be ok ? Why avdec_mjpeg is prefered over the jpegdec element ? This problem could possibly be solved by making the http src send a first buffer with the same size of the typefind recommanded buffer size (4096). I didn't try this actually. There is still an issue left with avdec_mjpeg decoder that requires the jpegparser inserted to work as an accumulator before the decoder. A common solution to those problems would be to auto insert the jpegparser element. As an experiment, I tried to set the rank of the current jpegparser to GST_RANK_PRIMARY but the element does not get auto inserted, is there a way to do this ? Is the new jpegparser (https://bugzilla.gnome.org/show_bug.cgi?id=673925) going to be automatically inserted ?
Created attachment 256394 [details] [review] jpegdec: Relax sink caps
Created attachment 256395 [details] [review] avcodecmap: Make avdec_mjppeg requires a parsed input
commit e5c443594fe6d58ff9d532c342dfa13387e997fa Author: Matthieu Bouron <matthieu.bouron@collabora.com> Date: Thu Oct 3 14:39:35 2013 +0100 jpegdec: Relax sink caps Since jpegdec already parse the jpeg stream, the sink caps could be relaxed. This will allow jpegdec to be selected in more case and in particular when the jpeg typefinder does not find the width and height. https://bugzilla.gnome.org/show_bug.cgi?id=709352 commit 4c93bffb213ee6a330c0a2e64fa757f46e6db951 Author: Matthieu Bouron <matthieu.bouron@collabora.com> Date: Thu Oct 3 15:25:30 2013 +0100 avcodecmap: Make avdec_mjpeg requires a parsed input Actually avdec_mjpeg does not deal well with incomplete buffers and try to decode incomplete frames. A parser which will also acts as an accumulator needs to be inserted before it. https://bugzilla.gnome.org/show_bug.cgi?id=709352
I have mentioned on IRC and in another bug the need and desirability to make avdec_mjpeg parse the input. Did you investigate if this is possible to enable in gst-libav? What was the outcome?
The parser code should be reintroduced first in the gst_ffmpegviddec_handle_frame function in order to have it enabled for the mjpeg decoder. I can give it a try but it will requires to accumulate data in gst_ffmpegviddec_handle_frame if i understand correctly. Is it possible ?
From what I see there is no (m)jpeg parser in libav. And you would need to implement GstVideoDecoder::parse() with that. I did it in some other bug, well started... but it was a mess and not generally useful :)
If it's not easy to enable, it's probably not worth it. Must be remembering 0.10 stuff that was removed, sorry.
(In reply to comment #6) > From what I see there is no (m)jpeg parser in libav. And you would need to > implement GstVideoDecoder::parse() with that. I did it in some other bug, well > started... but it was a mess and not generally useful :) There is a (m)jpeg_parser in libavcodec and it can be used through the AVCodecParser api (av_parser_* functions). I'll give it a try implementing the parse function.
Here's a patch you can use as starting point, good luck https://bugzilla.gnome.org/show_bug.cgi?id=689565#c7