GNOME Bugzilla – Bug 555260
multifilesrc: fix seeking support
Last modified: 2018-11-03 14:38:51 UTC
I build a pipeline like this: multifilesrc ! jpegdec ! ffmpegcolorspace !videosink (where multifilesrc has a "image/jpeg,framerate=15/1" cap for correct playing) I can make it play/pause/stop, but it won't seek nor allow query for a position. Using from pyhton: pos = self.player.pipeline.query_position(gst.FORMAT_DEFAULT, None)[0] returns the following error: gst.QueryError: query failed And doing self.player.pipeline.seek_simple(gst.FORMAT_DEFAULT, gst.SEEK_FLAG_FLUSH, 3) does nothing (nor error, nor seeking). From trying stuff it seems as if multifilesrc only respects it's "index" property.
You're right, multifilesrc should probably accept seeks and position queries in DEFAULT format.
Not really interesting but here's a start: * gst/multifile/gstmultifilesrc.c: (gst_multi_file_src_class_init), (gst_multi_file_src_query): Implement DEFAULT and BUFFER position queries. See #555260. For proper position querying that works over queues, jpegdec or videosink should convert the time to buffers (or query upstream to convert time to buffers first).
Marking as enhancement. Anything else that needs to be done in multifilesrc - if so what? I'm not really sure how this should work / what the semantics should be like?
When i reported this i was trying to do a stop-motion application. I had a sequence of jpgs, captured with a webcam, and wanted to visualize the animation (each jpg a frame). From there the semantics would be the usual. The seek was to be used for stepping trough the animation frame by frame, or looping a few frames to check the flow (forwards and backwards). That kind of stuff.
Ok this subject is getting resurected by GES folks, Wim, I think the position query implemented with DEFAULT will not work well if you have jpeg file containing multiple jpegs (and not always that same amount). Can't we just implement this in bytes like other sources ? If we have a stop index, we can just stats and populate an index.
The seeking part has been merged as part of: https://bugzilla.gnome.org/show_bug.cgi?id=712254 I do not think the position query is handled though.
(In reply to comment #6) > The seeking part has been merged as part of: > https://bugzilla.gnome.org/show_bug.cgi?id=712254 > > I do not think the position query is handled though. Ok, but seek does not work cause we don't handle the format: basesrc gstbasesrc.c:1394:gst_base_src_default_prepare_seek_segment:<multifilesrc0> undefined format given, seek aborted.
Created attachment 277424 [details] [review] video-info: Fail cleanly if convertion cannot be made This allow using video-info format converter with non raw formats like image/jpeg.
Created attachment 277425 [details] [review] multifilesrc: Fix seeking for the video case This fixes seeking for the video case
Created attachment 277428 [details] [review] multifilesrc v2: Fix seeking for the video case If fixed a warning of use, uninitialized, also fixed the duration query, to set -1 instead of failing if position cannot be known. I didn't know it existed, but I think it would be good to implement prepare_seek_segment(), as we can seek in multiple format depending on the caps, not just time. I also notice that start/stop should be implemented, so we can clear the state when stopped. I'd like some input on that.
Now we're adding video-specific code to multifilesrc? Not convinced that's great, perhaps we should just wait for that imagesequencewhateversrc instead?
(In reply to comment #11) > Now we're adding video-specific code to multifilesrc? Not convinced that's > great, perhaps we should just wait for that imagesequencewhateversrc instead? Right, I was just trying to fix something that was there. So my reflection was more like, let's fix it, and we can do the same with audio later. The fact is that imagesequencesrc would need to re-implemented everything as it is. As for playback (outside playing from start to end) multifilesrc is pretty useless. I'm still seeking for input on the other proposed solution. Would it be possible to implement seeking the same way other filesrc do ?
So I suppose this is a dead end, may I close/reject this ?
-- 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-good/issues/8.