[Bug 766236] rtp j2k payload/depayload messes up colours in sample pattern

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=766236

--- Comment #70 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to boxerab at gmail.com from comment #69)
> (In reply to Sebastian Dröge (slomo) from comment #68)
> > You could use multifilesrc with jp2 files for example.
> 
> Thanks. I could use this for testing. Are there real work flows that involve
> jp2 ?

I don't know, wouldn't surprise me though :)

> > The other producers (and consumers) of j2c/j2k code streams should provide
> > the sampling and other things on the caps too. I think they can, it's mostly
> > demuxers.
> > 
> > Also the sampling should be possible to detect from the width/height
> > differences of the different planes, no? Just what the components are is
> > unknown?
> 
> sub-sampling and image dimensions are stored in the code stream, so there is
> no problem getting this info.  But, how to determine RGB vs YUV ? I was going
> to use the colour box, only available for jp2 streams.

All containers I'm aware of that handle JPEG2000 (MOV/MP4 and MXF) store the
colorspace, so that would be known. That doesn't help us with the component
order (RGB vs BGR) though, in case that matters.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.