After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755725 - rtpj2kdepay: can't sync to a start code and never outputs
rtpj2kdepay: can't sync to a start code and never outputs
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.6.0
Other Windows
: Normal normal
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-28 12:12 UTC by electrostep
Modified: 2016-06-11 16:36 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description electrostep 2015-09-28 12:12:45 UTC
The following pipeline works fine:

gst-launch-1.0.exe -v videotestsrc ! openjpegenc ! openjpegdec ! autovideosink

But when I add rtpj2kpay/depay - nothing happens:

gst-launch-1.0.exe -v videotestsrc ! openjpegenc ! rtpj2kpay ! rtpj2kdepay ! openjpegdec ! autovideosink

__tim suggested that 'it looks like the depayloader can't sync to a start code and never outputs anything'

Thank you for this great project!
Comment 1 electrostep 2015-09-30 15:23:42 UTC
it still doesn't work, even if I use the filesrc as a source
Comment 2 Tim-Philipp Müller 2015-09-30 16:13:14 UTC
> even if I use the filesrc as a source

Please tell us exactly what you're doing. The source shouldn't really matter. The above is already a simple enough pipeline and should be good enough for testing purposes.
Comment 3 Amomum 2015-10-09 13:27:32 UTC
I confirm this bug. For me minimal working pipeline is:
gst-launch-1.0 videotestsrc  ! openjpegenc ! openjpegdec ! videoconvert ! autovideosink

It works, I see the video.

But if I put rtpj2kpay/depay - nothing happens:

Even if I make GST_DEBUG=4 I can see that last line is:
0:00:00.128237421  5362      0x103de80 INFO               GST_EVENT gstevent.c:760:gst_event_new_segment: creating segment event time segment start=0:00:00.000000000, offset=0:00:00.000000000, stop=99:99:99.999999999, rate=1,000000, applied_rate=1,000000, flags=0x00, time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.000000000, duration 99:99:99.999999999

And nothing happens after that.

I use gstreamer 1.6 built from sources. Please tell me if I can provide any more useful info.
Comment 4 Aaron Boxer 2016-06-11 01:50:54 UTC
From the original bug report:

gst-launch-1.0 -v videotestsrc ! openjpegenc ! openjpegdec ! autovideosink

does not seem to work with latest git master:

"videotestsrc0: 
streaming task paused. reason: not negotiated"

while

gst-launch-1.0 -v videotestsrc ! openjpegenc ! openjpegdec ! autovideosink

does work.


Good news is that :

gst-launch-1.0 -v videotestsrc ! openjpegenc ! openjpegdec ! autovideosink 

and 

gst-launch-1.0 videotestsrc  ! openjpegenc ! rtpj2kpay ! rtpj2kdepay ! openjpegdec ! videoconvert ! autovideosink

do work with latest git master
Comment 5 Aaron Boxer 2016-06-11 01:53:07 UTC
Correction in above :

gst-launch-1.0 -v videotestsrc ! autovideosink

does work.
Comment 6 Aaron Boxer 2016-06-11 01:56:10 UTC
Another correction:

...

Good news is that


gst-launch-1.0 videotestsrc  ! openjpegenc ! openjpegdec ! videoconvert ! autovideosink

and 

gst-launch-1.0 videotestsrc  ! openjpegenc ! rtpj2kpay ! rtpj2kdepay ! openjpegdec ! videoconvert ! autovideosink

do work with latest git master



.....
Comment 7 Aaron Boxer 2016-06-11 01:57:51 UTC
So, everything is working except for 

gst-launch-1.0 -v videotestsrc ! openjpegenc ! openjpegdec ! autovideosink
Comment 8 Sebastian Dröge (slomo) 2016-06-11 08:38:14 UTC
That should obviously be made to work though :)
Comment 9 Sebastian Dröge (slomo) 2016-06-11 08:38:34 UTC
Also a blocker because this definitely worked before.
Comment 10 Aaron Boxer 2016-06-11 12:30:59 UTC
looks like decoder's only option for upstream is raw video, which if can't handle.
Comment 11 Aaron Boxer 2016-06-11 12:53:39 UTC
correction: decoder is receiving j2c from upstream
Comment 12 Aaron Boxer 2016-06-11 12:57:15 UTC
why would

gst-launch-1.0 videotestsrc  ! openjpegenc ! openjpegdec ! videoconvert ! autovideosink


work but 

gst-launch-1.0 -v videotestsrc ! openjpegenc ! openjpegdec ! autovideosink

fail ?

Why would adding videoconvert fix the problem ?
Comment 13 Tim-Philipp Müller 2016-06-11 13:02:57 UTC
> why would .. work but 
> 
> gst-launch-1.0 -v videotestsrc ! openjpegenc ! openjpegdec ! autovideosink
> 
> fail ?
> 
> Why would adding videoconvert fix the problem ?

Because a videosink was chosen that does not accept the video format that is output by openjpegdec.
Comment 14 Aaron Boxer 2016-06-11 16:09:37 UTC
Thanks, Tim. The decoder outputs video in ARGB64 format.  

This doesn't sound like a problem with the openjpeg encoder/decoder, though.

Is this actually a bug ?
Comment 15 Sebastian Dröge (slomo) 2016-06-11 16:10:58 UTC
Seems like no bug then. If openjpegenc ! openjpegdec works with a videoconvert, all is good.
Comment 16 Aaron Boxer 2016-06-11 16:20:15 UTC
Great. So, since the other pipelines mentioned in this issue are now working, can this be closed ?
Comment 17 Sebastian Dröge (slomo) 2016-06-11 16:36:39 UTC
yes, let's close it (the original bug) as fixed as part of your changes :)