I'm trying to incorporate frame-by-frame playback a playbin based python
software, following this documentation https://gstreamer.freedesktop.org/documentation/tutorials/basic/playback-speed.html?gi-language=c I encountered some problems. First if I try to do self.pipeline.send_event(Gst.Event.new_seek(0.0, Gst.Format.TIME, Gst.SeekFlags.FLUSH, Gst.SeekType.SET, position, Gst.SeekType.NONE, 0)) and then self.pipeline.send_event(Gst.Event.new_step(Gst.Format.BUFFERS, 1, 1, True, False)) It doesn't work, the video just freezes. But it starts to work perfectly if i change the seek to self.pipeline.send_event(Gst.Event.new_seek(0.00000001, Gst.Format.TIME, Gst.SeekFlags.FLUSH, Gst.SeekType.SET, position, Gst.SeekType.NONE, 0)) This seems to me some type conversion problem. But I don't have the expertise on GI/Gobject/C to track it down. More important, I can't seem to get reverse playback working. pos = self.player.pipeline.query_position(Gst.Format.TIME)[1] self.pipeline.send_event(Gst.Event.new_seek(-1.0, Gst.Format.TIME, Gst.SeekFlags.FLUSH, Gst.SeekType.SET, 0, Gst.SeekType.NONE, pos)) This should work, but the video just freezes and i get this error message: 0:00:20.992670044 6144 0x7f6f380165e0 WARN videodecoder gstvideodecoder.c:1140:gst_video_decoder_sink_event_default:<avdec_huffyuv0> error: No valid frames decoded before end of stream 0:00:20.992697014 6144 0x7f6f380165e0 WARN videodecoder gstvideodecoder.c:1140:gst_video_decoder_sink_event_default:<avdec_huffyuv0> error: no valid frames found -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
I kind of solved the second problem by sending the events to the videosink
instead that to the pipeline and changing the video from a motion jpeg to a h264. Problem is that in frame-by-frame reverse playback, it jumps from keyframe to keyframe. Which... makes sense, but it's not what I need. I need to "go back" actual frame by actual frame, that's why I was trying to use motion jpeg. I also tried prores and raw video formats to no avail. Is there any way to achieve this? -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Have you tried using the step API ([1], [2]) ?
[1]: https://gstreamer.freedesktop.org/documentation/gstreamer/gstevent.html?gi-language=c#gst_event_new_step [2]: https://gstreamer.freedesktop.org/documentation/tutorials/basic/playback-speed.html?gi-language=c#a-trick-mode-player On 6/25/19 12:17 AM, RiccardoCagnasso wrote: > I kind of solved the second problem by sending the events to the videosink > instead that to the pipeline and changing the video from a motion jpeg to a > h264. > > Problem is that in frame-by-frame reverse playback, it jumps from keyframe > to keyframe. Which... makes sense, but it's not what I need. I need to "go > back" actual frame by actual frame, that's why I was trying to use motion > jpeg. I also tried prores and raw video formats to no avail. > > Is there any way to achieve this? > > > > -- > Sent from: http://gstreamer-devel.966125.n4.nabble.com/ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Yes, I'm using the step api for reverse playback also. Every step jumps from
one keyframe to the other. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Tue, 25 Jun 2019 at 06:04, RiccardoCagnasso wrote:
> Yes, I'm using the step api for reverse playback also. Every step jumps from > one keyframe to the other. Are you using gstreamer-vaapi? Because, as the decoder's context is bound to the number of surfaces in dpb, and the reverse playback is based on holding a complete dpb it runs into a surface exhaustion, thus in gstreamer-vaapi all non keyframe are discarded to avoid the exhaustion. We are discussing how to improve this increasing dynamically the context bounded surfaces, but that might not be supported in other drivers. vmjl _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by RiccardoCagnasso
I changed computer and here it worked just fine. This workstation has a
quadro and no gstreamer-vaapi. I guess that the reverse step playback doesn't work well with something in vaapi. The first behavior is still strange though. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |