GNOME Bugzilla – Bug 606348
Gstreamer general stream error when using multiple tagged file
Last modified: 2010-07-05 23:13:56 UTC
When using gstreamer to play/encode/whatever a vorbis file that has more than one tag in it, gstreamer will usually give out a general stream error. Attachment has more than one tag in it, with the 2nd one occuring at 17s.
Attaching the file doesn't work, and it's not like I can reencode it to make it smaller, because gstreamer crashes.
You can upload it somewhere and give us the link.
If it's vorbis in an ogg container, you can try head --bytes=999k foo.ogg > head.ogg and see if that reproduces the problem and if yes attach that.
Created attachment 151008 [details] multiple tagged file
I This looks like a chained ogg file. How are you trying to play it? (Application and version) You will need an application that uses the more recent playbin2 instead of the old playbin. With the old playbin, you would get not-linked flow errors.
How do I know what apps use playbin2 vs old playbin? Exaile .3.0.1 has an error when it gets to tag. Banshee 1.6beta2 fails. Amarok 2.2.0 gives no error messages but gives up once 2nd tag is reached. VLC 1.0.4 plays it all but glitches at the tag. Converting it with soundconverter fails with general gstreamer error. Audacious svn plays it perfectly and even reads the 2nd tag. Do you know of where I can find documentation about this type of file, and/or how to remove the extra tags/ chain it together so it works?
> How do I know what apps use playbin2 vs old playbin? You'll have to ask the people who wrote the application :) > Exaile .3.0.1 has an error when it gets to tag. The latest downloadable Exaile source tarball (0.3.0.2) still seems to use the old playbin. > Banshee 1.6beta2 fails. Banshee git master seems to use the old playbin. > Amarok 2.2.0 gives no error messages but gives up once 2nd tag is reached. I don't think Amarok uses GStreamer (does it?). Last I checked the GStreamer backends were in a sorryful state and basically unmaintained. If it uses GStreamer, then maybe indirectly via Phonon? Last time I looked at the Phonon GStreamer playback engine it was all a bit makeshift. If that doesn't handle chained oggs, it's likely not our fault. > Converting it with soundconverter fails with general gstreamer error. Not entirely surprising, but an issue in soundconverter most likely (no one expects these things). > Do you know of where I can find documentation about this type of file, and/or > how to remove the extra tags/ chain it together so it works? It's not the tags per se that are the problem, but that it's technically two separate consecutive streams, with new tags, decoder setup etc. The easiest, if not only, way to merge the chains together is probably to re-encode the file (yes, I noticed soundconverter errors out). You should file bugs against these applications so they get updated to use playbin2. I think everything that needs to be done at the GStreamer level to support this kind of file has been done and seems to work at least in git. The old playbin element will never support this functionality, since it's really not been designed for that. Can I close this as OBSOLETE or do you want to move it over to your favourite app?
Hi, If I use the following pipeline: gst-launch-0.10 filesrc location=head.ogg ! decodebin2 ! audioconvert ! wavenc ! filesink location=test.wav All I get is a wav the same size as the first ogg stream, and gstreamer is stalled. Is there something special needed to transcode these files in soundconverter ? BTW, vorbisdec can convert it to wav, so for me the problem is solved.
> If I use the following pipeline: > gst-launch-0.10 filesrc location=head.ogg ! decodebin2 ! audioconvert ! wavenc > ! filesink location=test.wav > > All I get is a wav the same size as the first ogg stream, and gstreamer is > stalled. > Is there something special needed to transcode these files in soundconverter ? Well, it's a bit tricky if you do it like that. decodebin2 will create new pads for the second chain and remove the old ones, so you would need to hook that up to the encoding chain when that happens, possibly with an identity single-segment=true in there as well. Alternatively, try something like: gst-launch-0.10 playbin2 uri=head.ogg audio-sink='identity single-segment=true ! wavenc ! filesink location=foo.wav' which is abusing playbin2 a bit, but works just fine for me :) Closing bug, since there's nothing left for us to do really, it needs to be handled by the application if you want to support this.
>it needs to be handled by the application if you want to support this. So, is there no other way for gstreamer to react when encountering this without it crashing with an error? It can't just strip out any extraneous tag data, or just ignore it?
It's not about the tags changing at all, of course those could just be stripped out if that was all. It's about the logical structure of the underlying audio stream, which is technically a second audio stream completely separate from the first one. playbin2 handles this automagically without the application ever knowing about it, while decodebin does not. That's just how this kind of thing is exposed at the GStreamer level. It can't and shouldn't just be ignored GStreamer side (otherwise you'd end up with a partially transcoded audio file without realising). If the application doesn't want to handle this itself, maybe it should be using something like the playbin pipeline mentioned above. This is not a choice for GStreamer to make. We just provide the tools application developers can use, exposing things in various levels of detail.