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 334681 - Can't handle application/zip
Can't handle application/zip
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: dont know
0.10.3
Other All
: Normal major
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-03-15 19:40 UTC by Vitaliy Ischenko
Modified: 2006-03-17 21:07 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
log with --gst-debug-level=3 (58.28 KB, text/plain)
2006-03-15 19:41 UTC, Vitaliy Ischenko
Details
hexcat of bad file (35.16 KB, text/plain)
2006-03-16 14:56 UTC, Vitaliy Ischenko
Details
& tail (42.97 KB, text/plain)
2006-03-16 14:57 UTC, Vitaliy Ischenko
Details
--gst-debug-level=5 (177.38 KB, application/x-gzip)
2006-03-16 15:00 UTC, Vitaliy Ischenko
Details

Description Vitaliy Ischenko 2006-03-15 19:40:53 UTC
Please describe the problem:
I can't play some mp3 files with gstreamer with followin pipeline:
 gst-launch-0.10 playbin uri="file:///path/to/absolute/uri.mp3"

I get the following output:

-----------------------------------------------------------
Setting pipeline to PAUSED ...
** Message: don't know how to handle application/zip
Pipeline is PREROLLING ...
ERROR: из элемента /playbin0: This is not a media file
Additional debug info:
gstplaybasebin.c(1459): prepare_output (): /playbin0
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...
-----------------------------------------------------------

But it is all ok with:
gst-launch-0.10 filesrc location="01 - Galvanize.mp3" ! mad ! audioconvert !
audioresample ! alsasink (or ossink)

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Vitaliy Ischenko 2006-03-15 19:41:39 UTC
Created attachment 61313 [details]
log with --gst-debug-level=3
Comment 2 Aaron Bockover 2006-03-15 19:55:40 UTC
Try the second pipeline, but in place of filesrc, use a gnomevfsfilesrc with the uri parameter, similar to the playbin pipeline.
Comment 3 Michael Smith 2006-03-15 20:51:00 UTC
Can you attach a level 5 debug log? Thanks.
Comment 4 Tim-Philipp Müller 2006-03-15 22:06:41 UTC
The fact that it plays fine with an explicit filesrc ! mad ! sink pipeline doesn't mean that it is not really a .zip file (mad will just regard the zip archive data as 'garbage' and skip it). If the typefind function returns application/zip chances are pretty good that it really is a .zip file, the thing it checks for is not the kind of thing you just find by coincidence at the start of the data.

What does:

  file foo.mp3

say?
Comment 5 Michael Smith 2006-03-15 22:44:01 UTC
I'm just a bit suspicious of what I can see in that log: it's clearly identified it as ID3, then when id3demux does its internal typefinding, we see that the mpeg-audio typefind function said '99' fo probability, but the zip typefinder is only registered as GST_TYPE_FIND_LIKELY (which is less than 99).

So either I'm misreading the log, or something really weird is going on.

Also, finding an uncompressed mp3 inside a zip file inside id3 strains the bounds of my credibility (although much involving id3 does that!)
Comment 6 Vitaliy Ischenko 2006-03-16 14:52:44 UTC
Ok, some additional info as requested:

`file foo.mp3` says:
  foo.mp3: MP3 file with ID3 version 2.3.0 tag

The following pipeline works:
gst-launch-0.10 gnomevfssrc location="file:///path/to/foo.mp3" ! mad ! audioconvert ! audioresample ! alsasink

Here is the output of mp3info:
------------------------------------------------------
Emphasis: none
CRC error protection: No
MPEG Layer III
Original material flag: Yes
Stereo/mono mode: joint stereo
Padding: No
MPEG Version: 1.000000
Number of good audio frames: 15079
Number of corrupt audio frames: 1
Sampling frequency in Hz: 44100
Bit Rate in kbps: 192.840378
Total playing time: 393
------------------------------------------------------

Allso I should say that I can't play all album, all files from this albums unplayable with playbin
and all of them have "Number of corrupt audio frames: 1"
Comment 7 Vitaliy Ischenko 2006-03-16 14:56:34 UTC
Created attachment 61364 [details]
hexcat of bad file

Hmmm, it seems not so good as should be :)

I don't remember where i've got it so i can't say wgich options were used to encode this file...
Comment 8 Vitaliy Ischenko 2006-03-16 14:57:07 UTC
Created attachment 61365 [details]
& tail
Comment 9 Vitaliy Ischenko 2006-03-16 15:00:52 UTC
Created attachment 61366 [details]
--gst-debug-level=5
Comment 10 Tim-Philipp Müller 2006-03-17 21:07:18 UTC
This does really look like a .zip file which contains one single ID3v1-tagged mp3 file, plus a padded ID3v2 tag in fron of the .zip file. It is possible to play this file in this case if one ignores the fact that it is a .zip file. However, GStreamer doesn't do that. It (correctly) recognises that this is a .zip file and thus errors out.

I think this is perfectly reasonable behaviour on GStreamer's part and I don't really see much point in changing this (and it would lead to weird/broken behaviour in case of a .zip archive containing multiple files or files of different types). You'll just have to unzip those files first (or write a plugin that unzips zip archives).

Here's how you should be able to do that:

  % gst-launch-0.10 filesrc location="foobar.mp3" ! id3demux ! filesink location="foobar.zip"
  % unzip foobar.zip