GNOME Bugzilla – Bug 728716
Videos plays a video very slowly, while gst-launch plays it properly
Last modified: 2017-06-21 17:48:59 UTC
When I try to play any video in totem (even non HD videos), the framerate is really low which means it's pretty much unwatchable. I ran gst-launch playbin uri=file:///path/to/video video-sink=ximagesink And it played the video perfectly (I used video-sink=ximagesink because xvimagesink results in artifacts in the video display). Then I opened it in Videos, and it played it very, very slowly. So, is it a Videos bug? Or a bug in gstreamer? fwiw when playing the same video with gst-launch, the cpu usage of it was 5%, when playing it with Videos, the cpu usage of Videos was 15%.
Totem doesn't use ximagesink, it uses cluttersink. Which graphics driver are you using, and does it support OpenGL?
I use the radeonsi mesa driver. It supports OpenGL and I can run the shell and various videogames with high framerates. I tried running gst-launch-1.0 playbin uri=file:///path/to/video video-sink=cluttersink It worked too, in reasonable framerate.
Trying to debug this I noticed that after ~20 seconds of watching the video playing in low framerate (sometimes less) it will suddenly "catch up" and become watchable. If after that I switch to another video (without closing the app), the other video will play fine from the beginning.
Can you reproduce the problem with the bvw-test binary in the totem sources?
With a freshly built git master, I get this [elad@weatherwax backend]$ ./bvw-test ** ERROR:bacon-video-controls-actor.c:102:bacon_video_controls_actor_init: code should not be reached Aborted (core dumped)
(In reply to comment #5) > With a freshly built git master, I get this > > [elad@weatherwax backend]$ ./bvw-test > ** > ERROR:bacon-video-controls-actor.c:102:bacon_video_controls_actor_init: code > should not be reached > Aborted (core dumped) It expects the controls.ui to be installed.
I get this output, the window appears, video doesn't play [elad@weatherwax backend]$ ./bvw-test /path/to/video (bvw-test:10627): Gtk-WARNING **: Toplevel size doesn't seem to directly depend on the size of the geometry widget from gtk_window_set_geometry_hints(). The geometry widget might not be in the window, or it might not be packed into the window appropriately (bvw-test:10627): Gtk-WARNING **: Toplevel size doesn't seem to directly depend on the size of the geometry widget from gtk_window_set_geometry_hints(). The geometry widget might not be in the window, or it might not be packed into the window appropriately (bvw-test:10627): Clutter-WARNING **: ./clutter-actor.c:9834: Actor 'controls' tried to allocate a size of -63.00 x -31.00 bvw-test-Message: Error: The specified movie could not be found., playback stopped: 1, fatal: 0 (bvw-test:10627): Clutter-WARNING **: ./clutter-actor.c:9834: Actor 'controls' tried to allocate a size of -63.00 x -31.00
Needs a full URI.
Ah, I should have guessed. Thanks. So, with this thing the video works as expected from the beginning, and the window responds to size changes faster and more responsively than the app itself.
Hi Bastien, Gave 3.12 a spin today on my laptop and Totem 3.12 is much slower than 3.10 (and older cluttersink-based 3.x releases, IIRC). mplayer and VLC play the same file fine, while Totem 3.12 drops a huge amount of frames and its UI (overlay controls etc.) lags. My sample file is http://jeff.ecchi.ca/public/sample-pitivi-projects/m%c3%a9tro%201.MOV The CPU is an Intel U4100 @ 1.30GHz × 2, with the GM45 Express Chipset for graphics. Do we consider this the same issue, or should I file a separate bug?
AFAICT comment #9 answered the NEEDINFO, so resetting to UNCONFIRMED. Also, FWIW, Sushi (aka "press spacebar in Nautilus") plays the thing fine, and it seems like it uses the same sort of playback widgets (in a clutter interface?) than Totem.
Is it possible that this bug is actually the same issue I'm seeing in bug #725063?
Same problem on debian/sid with any avi file.
So, after discussing with Bastien at GUADEC, and testing a little bit for myself, this is caused by Totem's use of Tracker - it tries to index/query some stuff in the background even if you're not in the "browse" mode, which is not a good idea.
(In reply to comment #14) > So, after discussing with Bastien at GUADEC, and testing a little bit for > myself, this is caused by Totem's use of Tracker - it tries to index/query some > stuff in the background even if you're not in the "browse" mode, which is not a > good idea. Seems weird to me that using tracker would make everything THAT slow. The window is slow to re-size, the menu is slow to draw and the video playback is extremely choppy. This also doesn't explain why sometimes it's suddenly fast after few seconds of video, and sometimes it isn't. Also, using perf top, the topmost functions when everything is slow are: 13.40% libgdk-3.so.0.1306.0 [.] gdk_cairo_surface_paint_pixbuf 5.81% libgtk-3.so.0.1306.0 [.] blur_xspan Which are not related to tracker.
(In reply to comment #15) > (In reply to comment #14) > > So, after discussing with Bastien at GUADEC, and testing a little bit for > > myself, this is caused by Totem's use of Tracker - it tries to index/query some > > stuff in the background even if you're not in the "browse" mode, which is not a > > good idea. > > Seems weird to me that using tracker would make everything THAT slow. The > window is slow to re-size, the menu is slow to draw and the video playback is > extremely choppy. This also doesn't explain why sometimes it's suddenly fast > after few seconds of video, and sometimes it isn't. > > Also, using perf top, the topmost functions when everything is slow are: > 13.40% libgdk-3.so.0.1306.0 [.] gdk_cairo_surface_paint_pixbuf > 5.81% libgtk-3.so.0.1306.0 [.] blur_xspan > > Which are not related to tracker. It's related to us filling in the recent view synchronously from tracker. If you wait long enough, does the video actually play back OK? If not, then the problem is something else...
Oh! yes, that's it! if I open the main view (as opposed to just opening what I want to watch from Files) and wait for everything to get rendered and THEN open a video, it plays back fine!
Created attachment 283666 [details] [review] main: Postpone loading library after playback
I can confirm this patch fixes the issue for me.
Now in further testing I see that for some specific video files the window doesn't show at all. I attached gdb to the process when it's running and the window is invisible (and, judging by the lack of audio, it's not playing) and got this backtrace:
+ Trace 233968
From this backtrace I assumed the issue is subtitles, so I deleted the .srt file that video had, and opened it again. This caused the window to show, but the video is still not playing. I attached strace to the process and got a lot of these recvmsg(9, 0x7fff2f643570, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}, {fd=13, events=POLLIN}], 4, 0) = 0 (Timeout) recvmsg(9, 0x7fff2f643570, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}, {fd=13, events=POLLIN}], 4, 9991) = 0 (Timeout) open("/home/elad/.config/totem/session_state.xspf", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1 EEXIST (File exists) open("/home/elad/.config/totem/session_state.xspf", O_WRONLY|O_CREAT|O_NOFOLLOW, 0666) = 20 fstat(20, {st_mode=S_IFREG|0664, st_size=334, ...}) = 0 open("/home/elad/.config/totem/.goutputstream-214XKX", O_WRONLY|O_CREAT|O_EXCL, 0666) = 21 fchown(21, 1000, 1000) = 0 fchmod(21, 0100664) = 0 close(20) = 0 write(21, "<?xml version=\"1.0\" encoding=\"UT"..., 105) = 105 write(21, " <track>\n <location>file:///h"..., 98) = 98 write(21, " <extension application=\"http:"..., 79) = 79 write(21, " </extension>\n", 16) = 16 write(21, " </track>\n", 11) = 11 write(21, " </trackList>\n</playlist>", 25) = 25 fsync(21) = 0 rename("/home/elad/.config/totem/.goutputstream-214XKX", "/home/elad/.config/totem/session_state.xspf") = 0 fstat(21, {st_mode=S_IFREG|0664, st_size=334, ...}) = 0 close(21) = 0 recvmsg(9, 0x7fff2f643570, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}, {fd=13, events=POLLIN}], 4, 9967) = 0 (Timeout) open("/home/elad/.config/totem/session_state.xspf", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1 EEXIST (File exists) open("/home/elad/.config/totem/session_state.xspf", O_WRONLY|O_CREAT|O_NOFOLLOW, 0666) = 20 fstat(20, {st_mode=S_IFREG|0664, st_size=334, ...}) = 0 open("/home/elad/.config/totem/.goutputstream-SYBYKX", O_WRONLY|O_CREAT|O_EXCL, 0666) = 21 fchown(21, 1000, 1000) = 0 fchmod(21, 0100664) = 0 close(20) = 0 write(21, "<?xml version=\"1.0\" encoding=\"UT"..., 105) = 105 write(21, " <track>\n <location>file:///h"..., 98) = 98 write(21, " <extension application=\"http:"..., 79) = 79 write(21, " </extension>\n", 16) = 16 write(21, " </track>\n", 11) = 11 write(21, " </trackList>\n</playlist>", 25) = 25 fsync(21) = 0 rename("/home/elad/.config/totem/.goutputstream-SYBYKX", "/home/elad/.config/totem/session_state.xspf") = 0 fstat(21, {st_mode=S_IFREG|0664, st_size=334, ...}) = 0 close(21) = 0 recvmsg(9, 0x7fff2f643570, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}, {fd=13, events=POLLIN}], 4, 0) = 0 (Timeout) recvmsg(9, 0x7fff2f643570, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}, {fd=13, events=POLLIN}], 4, 9979 but I have no idea why it would affect some video files and not others.
Ah, scratch that comment. It's not relevant to this patch, it happens with totem from git master regardless if the patch is applied. I'll open a separate bug, sorry for the spam :(
(In reply to comment #21) > Ah, scratch that comment. It's not relevant to this patch, it happens with > totem from git master regardless if the patch is applied. I'll open a separate > bug, sorry for the spam :( Maybe bug 733780 ?
Fixed in master and gnome-3-12 Attachment 283666 [details] pushed as 11af158 - main: Postpone loading library after playback
*** Bug 733182 has been marked as a duplicate of this bug. ***