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 145163 - Pipeline with id3demux and mad doesn't work for some songs
Pipeline with id3demux and mad doesn't work for some songs
Status: VERIFIED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: dont know
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-06-30 00:11 UTC by Richard Hult
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case (2.64 KB, text/plain)
2004-06-30 00:11 UTC, Richard Hult
Details

Description Richard Hult 2004-06-30 00:11:17 UTC
For 6 out of about 2000 mp3s, the pipeline:

filesrc ! id3demux ! mad ! fakesink

doesn't work. I'm linking mad + the sink in the new_tag callback from id3demux.

gst-launch appears to be working although as far as I can see, it does some
workarounds in case of errors. Attaching my test case.

The output is:

** (process:30616): WARNING **: error scheduling group 0x845cb10
ERROR (1088553316:262432)       scheduler(30616)
gstoptimalscheduler.c(2392):gst_opt_scheduler_iterate:<GstOptScheduler@0x84440f0>
in error state

This files fails:

http://people.imendio.com/richard/05_cranberries-waltzing_back.mp3

And this one works:

http://people.imendio.com/richard/04_cranberries-pretty.mp3
Comment 1 Richard Hult 2004-06-30 00:11:52 UTC
Created attachment 29100 [details]
Test case
Comment 2 Richard Hult 2004-07-05 00:03:50 UTC
Actually, I think I missed the real error message:

** (process:22597): WARNING **: error scheduling group 0x9ee3c98
ERROR (1088985719:697832)       scheduler(22597)
gstoptimalscheduler.c(2392):gst_opt_scheduler_iterate:<GstOptScheduler@0x9ecb228>
in error state

(process:22597): GStreamer-CRITICAL **: file gstpad.c: line 4328
(gst_pad_get_formats): assertion `GST_IS_PAD (pad)' failed


when I run with another scheduler (entrygthread) I get a similar output:

(process:22598): GStreamer-CRITICAL **: file gstpad.c: line 4328
(gst_pad_get_formats): assertion `GST_IS_PAD (pad)' failed


Comment 3 Ronald Bultje 2004-10-29 17:37:46 UTC
This is probably related to the fact that id3's typefinding fails. It will fail
any further action. Can you please verify that? I'll mark this as a bug of that
pile-up bug then (we'll fix that at some point; the pile-up bug has some
interesting ideas on how to fix this).
Comment 4 Richard Hult 2004-11-03 10:55:13 UTC
Btw, the test case behaves differently with recent gstreamer, it just sits
forever with 100% cpu load.

I'll take a look at the typefinding as soon as I can. What's that other bug number?
Comment 5 Ronald Bultje 2004-11-03 11:43:54 UTC
152688
Comment 6 Richard Hult 2004-11-10 12:04:22 UTC
Thanks.

Silly question maybe, but how do I check if the typefinding fails?
Comment 7 Ronald Bultje 2004-11-10 12:49:44 UTC
Provide me one such file that fails to work. :).
Comment 8 Richard Hult 2004-11-10 13:01:31 UTC
I've put back the file mentioned above (05_...), I had accidentally removed it.
Comment 9 Ronald Bultje 2004-11-10 15:27:20 UTC
Interesting file. It starts with an ID3v2 header, then a few 100 byte of zeroes,
then (at pos 0x2E2) a WAVE header (!) and then at 0x32A the MP3 data (including,
as far as I can see, a valid MPEG audio header).

For me, it works fine with both playbin and spider. Can you please recheck? If
you have any other failing files, I'll be happy to have a look at them.
Comment 10 Richard Hult 2004-11-10 19:48:26 UTC
Since it works with gst-launch, I guess we can close this (my test-case is
probably busted).