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 640660 - Jp2kdec capabilities not negotiated with 4:4:4 YUV
Jp2kdec capabilities not negotiated with 4:4:4 YUV
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-01-26 17:57 UTC by Steve
Modified: 2011-01-27 14:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
jp2kdec debug output (16.66 KB, text/plain)
2011-01-26 17:58 UTC, Steve
  Details
sample of source stream (900.43 KB, application/octet-stream)
2011-01-26 18:16 UTC, Steve
  Details
output.png (151.39 KB, image/png)
2011-01-26 18:44 UTC, Tim-Philipp Müller
  Details
jp2kdec: add v308 (packed YUV 4:4:4) to allowed output caps (1.04 KB, patch)
2011-01-26 18:47 UTC, Tim-Philipp Müller
none Details | Review

Description Steve 2011-01-26 17:57:09 UTC
Given a server chain of:

gst-launch -v videotestsrc ! videoscale ! video/x-raw-yuv, width=40, height=30 ! jp2kenc ! rtpj2kpay pt=96 ! udpsink port=5555

a client chain of:

gst-launch -v udpsrc caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG2000, payload=(int)96" port=5555 ! rtpj2kdepay ! jp2kdec ! videoscale ! ffmpegcolorspace ! autovideosink

However the same client chain with jp2kdec debugging fails against a custom generated stream and produces the attached output.
Comment 1 Steve 2011-01-26 17:58:30 UTC
Created attachment 179386 [details]
jp2kdec debug output
Comment 2 Steve 2011-01-26 18:16:07 UTC
Created attachment 179391 [details]
sample of source stream

less than one second, but captured with gst-launch -v udpsrc caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG2000, payload=(int)96" port=5555 ! rtpj2kdepay ! gdppay ! filesink location=jpeg2000.gdp
Comment 3 Tim-Philipp Müller 2011-01-26 18:44:11 UTC
Created attachment 179392 [details]
output.png

The problem seems to be that it's a YUV format that's not supported according to the decoder's output caps, ie. YUV 4:4:4 without alpha channel (no chroma subsampling).

Adding v308 to the yuv formats in the output caps gets us a picture, but it doesn't look right (or does it?)
Comment 4 Tim-Philipp Müller 2011-01-26 18:47:29 UTC
Created attachment 179393 [details] [review]
jp2kdec: add v308 (packed YUV 4:4:4) to allowed output caps
Comment 5 Tim-Philipp Müller 2011-01-27 10:32:16 UTC
> Adding v308 to the yuv formats in the output caps gets us a picture, but it
> doesn't look right (or does it?)

It actually looks more like the chroma planes are 4:2:0.

Can you play that stream with any players? If yes, which ones? What creates that stream?
Comment 6 Steve 2011-01-27 14:14:19 UTC
Stream originates from custom software that I develop on contract. I've been using gstreamer as a test client, as it appears to be one of the few options that supports jpeg2000 over rtp. However, the stream's frame content is yuv420 that was incorrectly encoded via openjpeg and represented as yuv444. So, the stream's incorrectly encoded, and hence this bug is not valid. I recommend closure and have updated the status accordingly. Thank you for the help.
Comment 7 Tim-Philipp Müller 2011-01-27 14:28:58 UTC
Ah, thanks for the update.