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

> > ::: gst/videoparsers/gstjpeg2000parse.c
> > @@ +41,3 @@
> > +GST_STATIC_PAD_TEMPLATE ("src", GST_PAD_SRC,
> > +    GST_PAD_ALWAYS,
> > +    GST_STATIC_CAPS ("image/x-jpc,"
> > 
> > It should also handle j2c and jp2 later, that's on your list?
> > 
> 
> I don't think our payloader will handle jp2.

But the parser could easily handle it to extract various information from an
JPEG2000 image stream without decoding them :)

> > @@ +274,3 @@
> > +    ret =
> > +        gst_base_parse_finish_frame (parse, frame,
> > +        gst_byte_reader_get_remaining (&reader));
> > 
> > The second argument is the number of bytes that you finish (that is: how
> > much you consumed, not necessarily how much you forward), not the number of
> > bytes that are still leftover
> > 
> 
> How do I know how much I consumed? What if the handle_frame method was
> called multiple times: do I need to track how much I consumed over these
> multiple method calls ?

Unless you store data yourself somewhere, the whole buffer you have at each
call is what you have available and with every call new data will be appended
to the end of that buffer (unless you skip obviously, in which case data is
dropped at the front). Once you call finish_frame(), this much data is removed
from that buffer and on the next call you get the following data (i.e. the
start of the next frame in your case).

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