GNOME Bugzilla – Bug 332864
[gnomevfssrc] playing files from tar.gz archives fails
Last modified: 2009-09-10 07:41:24 UTC
fails: gst-launch gnomevfssrc location=file:///home/ensonic/buzztard/bin/melo3.ogg ! oggdemux ! vorbisdec ! audioconvert ! alsasink works: gst-launch gnomevfssrc location=file:///home/ensonic/temp/songs.tar.gz#gzip:#tar:melo3.ogg ! filesink location=test.ogg works: gnomevfssrc ! mad ! audioconvert ! alsasink fails: gnomevfssrc ! id3demux ! mad ! audioconvert ! alsasink
works: gst-launch gnomevfssrc location=file:///home/ensonic/temp/songs.tar.gz#gzip:#tar:melo3.ogg ! queue ! oggdemux ! vorbisdec ! audioconvert ! alsasink so ogg needs a queue element to decouple with playbin I can't play neither ogg nor mp3
I guess this might turn out to be caused by some funniness with gnomevfssrc providing getrange 'random access' to tar.gz files. Debug output from gnomevfssrc and oggdemux would probably help pinpoint where it's failing.
Basically, gnomevfssrc can't give a filesize for this stream when used like this, which makes oggdemux-activated-in-pull-mode fail like this: gstoggdemux.c(2372):gst_ogg_demux_find_chains: can't get file length gstoggdemux.c(2599):gst_ogg_demux_loop:<oggdemux0> error: could not read chains Two possible solutions: (a) in gnome_vfs_src_start(), add something like: if (src->seekable && src->size == (GnomeVFSFileSize) -1) { src->seekable = FALSE; } which will make basesrc return FALSE when trying to activate in pull mode, so it falls back to push mode then. (b) fix oggdemux to fall back to push mode when it can't get the upstream size Probably even both changes should be made.
+1 for both changes - although I wonder why gnome-vfs should not be able to give us the size: > gnomevfs-info file:///home/ensonic/temp/shot.tar.gz#gzip:#tar:./shot01.ogg Name : shot01.ogg Type : Regular MIME type : application/ogg Default app : realplay.desktop Size : 197115 Permissions : 0644 UID : 500 GID : 100 Access time : Thu Jan 1 01:00:00 1970 Modification time : Mon Feb 20 19:45:27 2006 Change time : Thu Jan 1 01:00:00 1970
Created attachment 62114 [details] [review] makes it work, but there's still something dodgy Looks like gnome_vfs_get_file_info_from_handle() doesn't give us that information, while gnome_vfs_get_file_info_uri() does. Not sure if that's a gnome-vfs bug or intended behaviour. If I add a fallback to the code so that it tries to get the size from _info_uri() if _info_from_handle() didn't provide it, things start working, but not really correctly. I get a weird GStreamer-CRITICAL **: Padname serial_419801c3 is not unique in element oggdemux0, not adding message and things crash in oggdemux when seeking heavily
+ Trace 67271
probably the same issue as the first.
beh, the seeking in these "files" does not work very well, gnomevfssrc returns like a piece of the tar header or so with the second seek. Trying to make oggdemux a little more resistant to bad data. the gnomevfssrc patch itself seems to be fine.
Retested with seek test app. It plays fine, also with different rates. When seeking it prints a bunch of "seek failed" and goes to ts=0. Not sure if its easily fixable at all. I fine if this gets closed at wont-fix.
Let's close this as WONTFIX then... apart from all other problems gnomevfs is deprecated in favor of gio anyway.