[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 #50 from boxerab at gmail.com <boxerab at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #49)

> 
> > Regarding different bit depths, the code stream itself will store this
> > information.
> 
> So the RFC cares about subsampling and stuff, but not about the component
> depths? That seems weird, it's as important for negotiating a compatible
> format :) Maybe they assume 8 bit and don't allow anything else?


My guess is that the RFC assumes that bit depth is taken care of by the J2K
design: JPEG 2000 images are encoded bit plane by bit plane, so if an image is
12 bits, but the decoder only supports 8, then it can easily decode the most
significant 8 bit planes, and ignore the rest. 


> 
> The subsampling is also stored in the stream itself, no?

Yes.

> 
> (In reply to boxerab at gmail.com from comment #48)
> > I think this bug has been fixed ! :)
> 
> I think to really consider it fixed we should also have a jpeg2000 parsers.
> Otherwise the payloader won't work very well anymore in many pipelines and
> there's no easy fix for that.

Well, I don't believe the parser can generally determine the sampling field
from the code stream alone. There are cases where the JP2 file format stores a
colour box, so this combined with the subsampling could determine it. But this
box is optional.

Can you tell me about the pipelines that will not work if we don't have a
parser ?  i.e. we don't have a gstreamer encoder in the pipeline, but we are
streaming J2K images ?

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