I’m using the GStreamer movie player in Linux. It works fine, except that it stutters when looping. The video file is 30mb, about 2000x2000 pixels resolution, encoded with h264 in Blender.
I tried enabling
sEnableAsyncStateChange, and playing the video from a ram disk, but nothing helped.
Any suggestions would be appreciated.
Edit: I have found an older issue on github (opened by me and totally forgot about it, sorry), in which @Petros suggested looking into GStreamer segment seeks, which is probably still required for seamless looping, isn’t it?
Indeed, segment seeks would still be the proper GStreamer way in order to handle seamless looping.
I just pushed an initial implementation of this here. It might have some rough edges if you try to combine looping with trick modes ( scrubbing, reversing rate etc. ) but should be a fair start.
Give it a try and let us know how it goes.
Thanks for the quick reply and implementation. I tried with a video loop and unfortunately I see no noticeable difference. I’m sharing the video here, maybe it helps with testing. I’m investigating it more and let you know if I find anything.
That’s strange… Are you sure that the patch was applied properly? Maybe a fresh build of Cinder and you app just to be sure?
Here is how looping looks on my 2012 MBP with GStreamer 1.14.4 with the patch applied and using your video file.
I tested it with up to 3840x2160 videos and I get pretty consistent results on my side so not sure what is happening here exactly.
EDIT: Updated the link with a longer recording that loops 2-3 times on your file.
Your results look great. I check it again. I’m trying it with GStreamer 1.14.4 on Fedora 29. Thanks.
Edit: I looked at your recording several times again and I can see a small jump at 0:19, 0:52 and 1:24. If I play the file with
mpv --loop-file it’s seamless. Although playing it with
vlc the stutter is much more noticeable.
I think this stems from the fact that my laptop is not decoding fast enough the video file in order to really have a true smooth/seamless experience at this resolution.
MPV is using
ffmpeg under the hood so not sure if there is some HW decoding support that might keep things a bit more performant.
VLC uses its own implementation I believe so if you would really like to compare the
GstPlayer with something, that would be the
Totem video player on Linux which utilizes
GStreamer as it’s backend.
All that said what HW are you using to test this on? I would still expect that on a proper desktop machine with a proper GPU you shouldn’t be experiencing this issue at this resolution and with the patch applied.
You could also try different resolutions in order to see what results you get just as a comparison.
Totem gives similar results to the patched GstPlayer. My hardware is an i7-8750H with GTX 1060 Max-Q and an ssd with 500mb/s read speed. I assumed it should work, but maybe GStreamer is not perfect for this task. Or I should change Gnome 3 to something lighter.
Thank you for your help. It is very much appreciated as always.
Yeah, I would also expect this to work with a HW setup like the one you describe.
Definitely try a more lightweight window manager since this could also be a compositing / VSync issue - I have been using OpenBox on *Ubuntu flavors for many years now and it has been giving me consistently the best results when compared with other WM’s( and their interop with OpenGL )
I noticed a possible issue with the segment seek patch. If you start the movie first, then use setLoop(), the app freezes.
Thanks for testing, thankfully this was something small and I have just pushed a fix for this.
Thanks for the quick fix. The freezing is gone.
I’m still seeing a small issue with it. If the movie is playing for a while and I call
setLoop( true ) the movie seems to jump backwards a bit.
I was afraid actually this might be the case. The problem is that in order to use the segment seek for seamless looping ( at least in theory ), one has to initiate the loop with a seek event configured with some specific flags. I suppose this seek event is what are you perceiving as a small jump backwards.
Not sure what is the best way to deal with this and all available resources ( for seamless looping ) that I have found do not really show any graceful way to handle this at runtime but rather assume that seamless looping is configured at video startup.
Looking at it a bit more, seems like this direction overcomplicates things a bit. Took a step back and gave a different approach a try which might fit better in this case. Its using the
about-to-finish signal from
playbin which is usually used for gapless playback in video playlists. On top of that I added an environment option for using
playbin3 instead of
playbin which seems to have better support for gapless playback. In my tests locally here, with
playbin3, it looks like I m getting better results with this.
You can find this work in this branch.
You can run:
before running your application with this branch if you want to activate the use of
Hope this gives you better results - Let me know!
The loop looks super smooth now! I see no difference with and without
export USE_PLAYBIN3=1, though.