It has been working nicely for me in the past weeks I've been working with it.

Stefan? Do you have any pending issues you know about jpegparse?

We could do this after the upcoming -bad release.

+1 from my side as well. Next step would be to go though the plugin-moving list and try to get it into good even.

Any news on this?

We should decide on bug #626618 before. There is a RFE also, but that can be done later. I'll take a look at the plugin moving list ...

I run over the check-list. The coding style is okay. The plugins have docs and tests. The tests pass normally and under valgrind.

Bug #626618 is fixed now.

Having the same caps on the src and sinkpad is no problem with decodebin2 anymore, it might still make sense to add something like "parsed=true" to the srcpad caps though but there's no reason why jpegparse shouldn't accept the jpegparse output again ;)

Make sure to give it a rank higher than all jpeg decoders

-1 from me, last time I looked at the code I wasn't too keen on getting it autoplugged, and I don't think much has changes since. Needs more review. Also needs to be ported to GstBaseParse.

Might be best to just throw it away, and add a jpeg parser to the codec parser libs (see bug # 673925), then write a new jpegparse based on that and put it into videoparsers.

Bug #676542 , which has discussion, seems to be relevant.

*** Bug 688823 has been marked as a duplicate of this bug. ***

I think the plan here should be to write a new jpegparse based on baseparse and includes all these features

Hey guys, we got a regression from .10 to 1.0 because we not longer parse the jpegs at all, the result is that we got nothing out when reading a jpeg from an http source. I know maybe the style of jpegparse is not satisfying, but the thing is not working at all, so why do we keep waiting on this ? A element has no API, we can rewor it later.

It's not just a "code style" issue.

I suspect it depends on the decoder that gets plugged. jpegdec should do parsing already in this case. If that doesn't work, that needs to be fixed in any case, since people expect src ! jpegdec ! ... to work. If another decoder like avdec_mjpeg gets plugged, that should be fixed to do parsing as well.

Should also merge this with videoparsers, have it use the jpegparser code in the codecparsers library and move it all over to -good.

Seems like this this is porterd to GstBaseParse since middle 2014. (https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst/jpegformat/gstjpegparse.c?id=2bfd106ef603f2888b634a2be0cd62a30c6a87d3)

As said Sebastian, gst-plugins-bad/gst/jpegformat/gstjpegparse.c needs to be moved and splitted into:

gst-plugins-bad/gst-libs/gst/codecparsers
gst-plugins-bad/gst/videoparsers/

Maybe as an immediate solution for the autoplug issue, we can bump the rank for from NONE to SECONDARY at least until someone do the above.

(In reply to Julien Isorce from comment #15)
> Seems like this this is porterd to GstBaseParse since middle 2014.
> (https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/gst/
> jpegformat/gstjpegparse.c?id=2bfd106ef603f2888b634a2be0cd62a30c6a87d3)
> 
> As said Sebastian, gst-plugins-bad/gst/jpegformat/gstjpegparse.c needs to be
> moved and splitted into:
> 
> gst-plugins-bad/gst-libs/gst/codecparsers

There is already a jpeg parser there, with pretty clean code. It's missing couple of bits currently used in the element, but I think we should just ignore what is in the element and re-implement on top of that codec parser.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/22.