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

[GStreamer (bugzilla.gnome.org)]

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


Víctor Manuel Jáquez Leal <vjaquez> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vjaquez at igalia.com


--- Comment #7 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> 2009-08-25 11:21:39 UTC ---
Thanks for your comments Arnout.

(In reply to comment #6)
> 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).

Ahh.. now it makes sense to me :)

> Also, there's a small bug on line :
> parse->height != parse->height
> 
> And probably caps should also be updated when fourcc or progressive changes.

Thanks!

> 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.

Again, now it makes sense...

> 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...  

Aha... Thanks a lot for your input. Let me rework the code.

> In fact, is
> there a reason not to split it into two elements, one for parsing and one for
> caps?

I don't know. I don't get why it should be split. A gstpjpegpacketize and a
gstjpegparse ??

Btw, what are your feelings about using gstbaseparse (bug 518857) ??

-- 
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.