[Bug 745724] jpegparse: set framerate to 0/1 when duration is not known

[GStreamer (GNOME Bugzilla)]

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

--- Comment #16 from Guillermo Rodriguez <guillerodriguez.dev at gmail.com> ---
> Default is usually 25/1, but your server is too slow, the reason you get 1/1

I don't think this has anything to do with my server being too slow. From waht
I can see, jpegparse blindly sets the framerate to 1/1 if the src caps don't
explicitly set a framerate:

https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/gst/jpegformat/gstjpegparse.c#n745

> It's up to the application to select the framerates. All you have to do is specify what you want 0/1.

Yes, that works. But then we are basically undoing what jpegparse arbitrarily
decided to do. I mean: The src didn't set a framerate. The sink does not need a
framerate. It is just jpegparse that messes things up by forcing this to 1/1.

> Is there anything in this bug that cannot be solved at application lever by giving more information to the pipeline ?

Yes, certainly it can be "solved" at the application level. But then the
application is solving a problem that jpegparse created. For example take this
pipeline which uses multipartdemux instead of jpegparse. No need for such hacks
there:

gst-launch-1.0 souphttpsrc is-live=true location=... ! multipartdemux !
avdec_mjpeg ! autovideosink

So that's why I say that in my opinion, jpegparse should not try to make up a
framerate when the src does not specify one. But of course that's an opinion
only :-)

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