[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 #146 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to boxerab at gmail.com from comment #145)
> Thanks. Let me summarize how I see things regarding sampling:
> 
> Parser
> 
> 1. j2k parser does not require either sampling or colorspace. If sampling is
> present, we will still work out the subsampling from the stream and do a
> sanity check on sampling from caps, and we will also work out the
> colorspace. If only colorspace is present, we will generate the sampling
> field (assume RGB channel order for sRGB). 

It should require one of the two, because otherwise we know nothing (unless the
input is JP2 which is not supported yet). If both are given, sampling takes
preference.

If sampling is given, we need to sanity check that against what is in the
stream and correct it otherwise (and complain). If no sampling is given (but
colorspace is), we should give a warning and guess a sampling.

The parser should always set both on its srcpad caps.

> 2. j2k parser source caps always sets the sampling field

... and colorspace :)

> Payloader
> 
> j2k rtp payloader requires the sampling field in the sink caps. i.e. we
> always send out RFC-compliant streams.

ACK

> Depayloader
> 
> j2k rtp depayloader requires either sampling or colorspace, for legacy
> reasons.
> An older gstreamer instance may not be setting the sampling field.

Yes, and sampling takes preference if both are given

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