GNOME Bugzilla – Bug 745724
jpegparse: set framerate to 0/1 when duration is not known
Last modified: 2018-11-03 13:31:36 UTC
Created attachment 298690 [details] [review] proposed fix actually jpegparse set framerate to 1/1 when duration is not known, this seems wrong
Review of attachment 298690 [details] [review]: Without 0/1 and no duration, it's no longer possible to seek. Usually we pick a default that make sense, like 25/1.
(In reply to Nicolas Dufresne (stormer) from comment #1) > Review of attachment 298690 [details] [review] [review]: > > Without 0/1 and no duration, it's no longer possible to seek. Usually we > pick a default that make sense, like 25/1. ok, if you agree I'll use 30/1 as default, with 25/1 you can get wrong duration after remuxing with some file, see: https://bugzilla.gnome.org/show_bug.cgi?id=740130 please note that 1/1 break an application of mime with git master: xvimagesink render 1 frame per second, according with the given caps, even if there are more frames
however if someone want a seekable file that contains jpegs a videorate can be placed before the muxer, theorically 0/1 should be the right value if duration is not known or variable
s/duration/framerate
Created attachment 298726 [details] [review] proposed fix v2 I think the other patch is most correct, however this one set framerate to 30/1 when duration is not known and work in my use case too.
Any rational not to use 25, it seems 25 is what other elements do whenever we need a default (e.g. videorate). To me though, jpeg from a file, without any container is similar to raw images. If you look at videoparse, we do have a property to set the framerate, and it's configurable. The exception is that in this case we have the conflict that there might be valid information we want to keep while we also want the parser to get exif. That would need to be sorted out if a property is added.
because if you use an arbitrary framerate is must be the highest expected, think about if you have 30 fps source and you set 25 fps caps, effects are similar to the ones reported in 740130 and probably your video sink will not render all the frames
Instead of picking a random 25 or 30fps, it should default to the downstream caps, so you can do the following: filesrc location=passport.jpg ! jpegparse ! image/jpeg, framerate=30/1 ! fakesink That would be more consistent with how videoparse works. If there is nothing downstream, it should probably default to 0/1.
(In reply to Olivier Crête from comment #8) > Instead of picking a random 25 or 30fps, it should default to the downstream > caps, so you can do the following: > filesrc location=passport.jpg ! jpegparse ! image/jpeg, framerate=30/1 ! > fakesink > > That would be more consistent with how videoparse works. If there is nothing > downstream, it should probably default to 0/1. Good idea.
(In reply to Olivier Crête from comment #8) > Instead of picking a random 25 or 30fps, it should default to the downstream > caps, so you can do the following: > filesrc location=passport.jpg ! jpegparse ! image/jpeg, framerate=30/1 ! > fakesink > > That would be more consistent with how videoparse works. If there is nothing > downstream, it should probably default to 0/1. this is how it works if you apply the first proposed fix, only you have to add a videorate before the capsfilter. Please note that in my use case I don't have a single jpeg but a jpeg stream with variable framerate
(In reply to Nicola from comment #10) > (In reply to Olivier Crête from comment #8) > > Instead of picking a random 25 or 30fps, it should default to the downstream > > caps, so you can do the following: > > filesrc location=passport.jpg ! jpegparse ! image/jpeg, framerate=30/1 ! > > fakesink > > > > That would be more consistent with how videoparse works. If there is nothing > > downstream, it should probably default to 0/1. > > this is how it works if you apply the first proposed fix, only you have to > add a videorate before the capsfilter. the idea is that it should not require videorate to pick downstream proposed framerate. > > Please note that in my use case I don't have a single jpeg but a jpeg stream > with variable framerate In this case, you would have a downstream proposed caps of 0/1, and some element or probe to set duration on each buffer. If you have some index of each duration, you could probably create a cleaner solution by creating a new source (or appsrc if you don't want to write plugin).
let me explain with an example, suppose you save a stream with a pipeline like this: gst-launch-1.0 souphttpsrc do-timestamp=true location=... ! jpegparse ! matroskamux ! filesink location=/tmp/jpeg.mkv the resulting muxed file declare 1/1 as framerate in the caps, now try to play this file (ip is public) with this pipeline: gst-launch-1.0 souphttpsrc location="http://195.250.34.59/temp/jpeg.mkv" ! matroskademux ! jpegdec ! xvimagesink you'll see 1 frame per seconds but the file contain more than 1 fps: this happens with git master, works with 1.4.5 the suggested patch solve the problem and does not store fake informations inside the muxer
the patch here: https://bug745192.bugzilla-attachments.gnome.org/attachment.cgi?id=299131 fix the above pipeline too, remain the fact that the documented example pipeline for jpegparse produce a matroska file that declare 1/1 as framerate and this is not true
Just stumbled upon this one. The following pipeline results in a sluggish 1 fps playback (source stream is approx 10fps): gst-launch-1.0 souphttpsrc is-live=true location=... ! jpegparse ! avdec_mjpeg ! autovideosink This works fine: gst-launch-1.0 souphttpsrc is-live=true location=... ! image/jpeg,framerate=0/1 ! jpegparse ! avdec_mjpeg ! autovideosink I too believe that jpegparse should default to 0/1, and not 1/1, if the source does not set the framerate.
(In reply to Guillermo Rodriguez from comment #14) > Just stumbled upon this one. > > The following pipeline results in a sluggish 1 fps playback (source stream > is approx 10fps): > > gst-launch-1.0 souphttpsrc is-live=true location=... ! jpegparse ! > avdec_mjpeg ! autovideosink > > This works fine: > > gst-launch-1.0 souphttpsrc is-live=true location=... ! > image/jpeg,framerate=0/1 ! jpegparse ! avdec_mjpeg ! autovideosink > > I too believe that jpegparse should default to 0/1, and not 1/1, if the > source does not set the framerate. Default is usually 25/1, but your server is too slow, the reason you get 1/1. It's up to the application to select the framerates. All you have to do is specify what you want 0/1. gst-launch-1.0 souphttpsrc is-live=true location=... ! image/jpeg,framerate=0/1 ! ... Also, a 0/1 default only make sense for live pipeline, with timestamp (see do-timestamp), which is not even your case. What you basically endup with is the equivalent of "autovideosink sync=0". Is there anything in this bug that cannot be solved at application lever by giving more information to the pipeline ?
> 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 :-)
-- 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/217.