After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 332864 - [gnomevfssrc] playing files from tar.gz archives fails
[gnomevfssrc] playing files from tar.gz archives fails
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: Wim Taymans
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-28 17:22 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2009-09-10 07:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
makes it work, but there's still something dodgy (2.40 KB, patch)
2006-03-27 12:54 UTC, Tim-Philipp Müller
committed Details | Review

Description Stefan Sauer (gstreamer, gtkdoc dev) 2006-02-28 17:22:52 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
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2006-03-09 17:52:24 UTC
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
Comment 2 Jan Schmidt 2006-03-10 12:02:07 UTC
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.
Comment 3 Tim-Philipp Müller 2006-03-16 16:41:02 UTC
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.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2006-03-16 18:13:00 UTC
+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


Comment 5 Tim-Philipp Müller 2006-03-27 12:54:32 UTC
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

  • #0 gst_element_remove_pad
    at gstelement.c line 743
  • #1 gst_ogg_demux_deactivate_current_chain
    at gstoggdemux.c line 1541
  • #2 gst_ogg_demux_activate_chain
    at gstoggdemux.c line 1565
  • #3 gst_ogg_demux_perform_seek
    at gstoggdemux.c line 1916

probably the same issue as the first.
Comment 6 Wim Taymans 2006-08-14 09:33:49 UTC
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. 
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2008-06-22 18:35:19 UTC
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.
Comment 8 Sebastian Dröge (slomo) 2009-09-10 07:41:24 UTC
Let's close this as WONTFIX then... apart from all other problems gnomevfs is deprecated in favor of gio anyway.