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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #10 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Mohammed Sameer from comment #9)
> (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.

I'm no jpeg expert but you should be looking for a sequence of 0xFFDX, where X
> 9 IIRC. Your code already does something similar.

> 
> > 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 :-(

I guess it makes sense to modify camerabin to plug a jpegparse, then. Making
sure that those extra padding stuff is removed.

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