GNOME Bugzilla – Bug 767844
gstopenjpegdec fails to decode jp2 image
Last modified: 2016-06-20 20:59:37 UTC
The following image fails to display https://github.com/uclouvain/openjpeg-data/blob/master/input/conformance/file1.jp2 using the following pipeline: uridecodebin uri=file:///path/to/file ! imagefreeze ! videoconvert ! ximagesink with error from gstopenjpegdec: Failed to decode openjpeg stream
Note: I am using openjpeg 2.1
The header is not being read.
Header is being read, but there is an error: Tile size read from header is much larger than the number of bytes in the openjpeg stream.
My bad: using an inappropriate pipeline. multifilesrc location=test.jp2 num-buffers=1 caps=image/jp2 ! openjpegdec ! imagefreeze ! videoconvert ! ximagesink works fine.
uridecodebin should be able to figure out the format and caps for you. It should work just like it works with your custom pipeline.
Is this a duplicate of #767512 ?
(In reply to Thiago Sousa Santos from comment #6) > Is this a duplicate of #767512 ? Nope. 767512 is for an enhancement to the new j2k parser.
(In reply to Thiago Sousa Santos from comment #5) > uridecodebin should be able to figure out the format and caps for you. It > should work just like it works with your custom pipeline. Thanks. The problem here is that openjpegdec assumes that the entire frame is available before it decodes. With the first pipeline, it looks like only 4096 bytes was available, and the decoder errored out.
I'm going to close this again. openjpegdec was designed with the assumption that it has the entire frame available. The fact that uridecodebin is not buffering the data in frame size chunks is not a bug.
yes, you can specify blocksize=99999999 or such or use multifilesrc to make it read the entire input file in one go (in absence of a parser).
(In reply to Tim-Philipp Müller from comment #10) > yes, you can specify blocksize=99999999 or such or use multifilesrc to make > it read the entire input file in one go (in absence of a parser). We now have a j2k parser: can uridecodebin be made to use this parser? Because then the pipeline would work.
it would work for raw codestream .j2k files
The parser will be plugged if typefind can determine the type to a suitable extent (including all fields listed for the source caps in the template, ie. colorspace or sampling field).