GNOME Bugzilla – Bug 536849
[giosrc] Very slow doing any playback
Last modified: 2008-06-11 09:31:41 UTC
$ time gvfs-cat smb://192.168.1.7/movies/Sunshine.avi > /dev/null real 0m21.168s user 0m0.299s sys 0m0.864s gvfs is fast. But trying to play back the same file using giosrc never starts. Same problem with a WMV file. Playing the file back using gvfs' fuse mount works as well.
Created attachment 112225 [details] log file
Could you please also run gvfs-info on that file and paste the output? I guess this problem is caused by the very weird access behaviour of the downstream elements here... seek, read 8 bytes, seek, read 8 bytes, ... This must be very expensive as every operation goes over DBus. I hope there's just something wrong with reading the filesize and the weird access behaviour is caused by this.
$ gvfs-info smb://192.168.1.7/movies/Sunshine.avi display name: Sunshine.avi edit name: Sunshine.avi name: Sunshine.avi type: regular size: 735735808 attributes: standard::name: Sunshine.avi standard::display-name: Sunshine.avi standard::edit-name: Sunshine.avi standard::type: 1 standard::size: 735735808 standard::content-type: video/x-msvideo standard::icon: GThemedIcon:0xa53470 time::modified: 1186807044 time::modified-usec: 0 time::access: 1212620400 time::access-usec: 0 time::changed: 1186807044 time::changed-usec: 0 unix::device: 42553 unix::inode: 1799602 etag::value: 1186807044 id::filesystem: server='192.168.1.7',share='movies',type='smb-share',mount_prefix='/' dos::is-archive: TRUE Mind, the same thing happened when hard-coding the size in gst_gio_base_src_get_size().
Does this work better if you let gst_gio_base_src_check_get_range() return FALSE?
(In reply to comment #4) > Does this work better if you let gst_gio_base_src_check_get_range() return > FALSE? Yep, works nicely.
Created attachment 112421 [details] [review] gio.diff
Could you check with this patch? It a) adds some caching and reads in blocks of at least 4k, b) has your loop code to assure enough data is read and, c) has some logic to disable random access for some URI schemes. If nothing else works we will simply disable random access for smb :)
Works fine, although the changes to gst_gio_src_check_get_range() don't seem necessary to me...
I agree, the blacklisting stuff isn't strictly needed to fix this bug. If we're going to break freeze anyway though, it might as well go in. Is it OK for the basesrc _create() function to return a sub-buffer now? That'll mean the output buffers are no longer writeable, which is probably fine, but I wanted to check. This isn't a regression, but given that giosrc is still explicitly 'experimental', I'm inclined to push it into this release.
2008-06-11 Sebastian Dröge <slomo@circular-chaos.org> * ext/gio/gstgiobasesrc.c: (gst_gio_base_src_finalize), (gst_gio_base_src_create): * ext/gio/gstgiobasesrc.h: Try to read the requested number of bytes, even if the first read returns less than requested, until nothing is read anymore or we have the requested amount of bytes. This fixes playback of files via Samba as Samba only allows to read 64k at once. Implement a caching algorithm that makes sure that we read at least 4k of data every time. Some elements will try to read a few bytes, then seek, read again a few bytes and so on and this is painfully slow as every operation has to go over DBus if GVfs is used as backend. Fixes bug #536849 and #536848. * ext/gio/gstgiosrc.c: (gst_gio_src_class_init), (gst_gio_src_check_get_range): Override check_get_range() to blacklist http/https URIs and whitelist file URIs. More to be added on demand.