[gstreamer-bugs] [Bug 583098] Add jpegparse element

[GStreamer (bugzilla.gnome.org)]

http://bugzilla.gnome.org/show_bug.cgi?id=583098



--- Comment #6 from Arnout Vandecappelle <arnout at mind.be> 2009-08-25 09:58:37 UTC ---
It's a pity that the test had to be removed.  Anyway, I would like the element
to still work even if the jpegs are not 100% OK (e.g. don't contain header
information).  That way, there's a bigger chance that it also works for JPEG
derivatives (like e.g. MxPEG from Mobotix).

If the image is not according to standard (or it is somehow corrupted), then
gst_jpeg_parse_read_header can do illegal memory reads - it doesn't check
position against the buffer size.  I also don't see while the number of
sections should be limited to 19 - it's allowed to insert as much comments as
you like according to the standard!

Also, there's a small bug on line :
parse->height != parse->height

And probably caps should also be updated when fourcc or progressive changes.

For the timestamps, I used the first incoming buffer, you now use the last one.
 In my use case (parsing the jpegs coming from a live http stream) it makes
more sense to use the first one - that timestamp already has some network
delay, so it's better to not add the additional delay of subsequent network
packets.

Setting 'packetized' based on the framerate of the sink pad caps is also not a
good idea, I think.  I realize that jpegdec does it like that, but I don't
agree.  When you know the framerate of a jpeg stream, you could add with a
capsfilter even if the stream isn't parsed.

Instead of 'packetized', I'd like to see the 'parsed' property like in e.g.
mpeg4videoparse.  This enables autoplugging.  I realize that that means you
can't use this element anymore to extract the detailed caps from an
already-parsed stream, but I don't know a solution for that...  In fact, is
there a reason not to split it into two elements, one for parsing and one for
caps?

-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.