[Bug 766010] jifmux fails to find EOI if it's not within the last 5 bytes

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Thu May 5 20:16:00 UTC 2016


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

--- Comment #9 from Mohammed Sameer <msameer at foolab.org> ---
(In reply to Thiago Sousa Santos from comment #8)
> (In reply to Mohammed Sameer from comment #7)
> > Do we know what kind of data is present if we scan backwards? It is in
> > theory more efficient but I have no idea what kind of byte values I should
> > be watching for.
> 
> What do you mean? jifmux was made to deal with jpeg buffers, one jpeg frame
> per buffer. What other type of data could be present?

jifmux is as good as its code is :)

If I write the code to scan the stream backwards, I will have to make sure that
I do it correctly. I don't know what markers or bytes will follow so the code I
write might cause issues. This is what I meant.

> Let's take a look at this bug from another angle, did you consider using
> jpegparse before the jifmux? It should be able to strip that extra padding
> data and seems like a more appropriate element to do it instead of having it
> in jifmux.

camerabin picks the needed elements. I don't know how to force jpegparse :-(

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


More information about the gstreamer-bugs mailing list