GNOME Bugzilla – Bug 351795
playbin: shows no-audio when it's unsupported audio and does not show tags
Last modified: 2018-11-03 11:13:03 UTC
http://www.hadess.net/tmp/unsupported-audio.asf (totem:10216): GStreamer-WARNING **: pad asfdemux0:audio_00 returned caps that are not a real subset of its template caps ** Message: don't know how to handle EMPTY EMPTY in this case actually contains "Voxware Metasound" audio, which can be played with the right win32 DLLs installed.
The warning and the EMPTY stuff is a bug in asfdemux, fixed in -ugly CVS. Also added the RIFF IDs for voxware to -base CVS: 2006-08-22 Tim-Philipp Müller <tim at centricular dot net> * gst-libs/gst/riff/riff-ids.h: * gst-libs/gst/riff/riff-media.c: (gst_riff_create_audio_caps): Add voxware audio IDs (even if we can't play it) (#351795). Support for that would probably need to be added to pitfdll. You should probably file a separate feature request bug in the pitfdll bug tracker for that. Other than that, are there special semantics to tell totem that there is audio but it's unsupported? Should the GStreamer backend be returning TRUE to HAVE_AUDIO if there is audio but it's unsupported?
(In reply to comment #1) > The warning and the EMPTY stuff is a bug in asfdemux, fixed in -ugly CVS. > > Also added the RIFF IDs for voxware to -base CVS: > > 2006-08-22 Tim-Philipp Müller <tim at centricular dot net> > > * gst-libs/gst/riff/riff-ids.h: > * gst-libs/gst/riff/riff-media.c: (gst_riff_create_audio_caps): > Add voxware audio IDs (even if we can't play it) (#351795). > > Support for that would probably need to be added to pitfdll. You should > probably file a separate feature request bug in the pitfdll bug tracker for > that. Might do, not that I'm that bothered about it :) > Other than that, are there special semantics to tell totem that there is audio > but it's unsupported? Should the GStreamer backend be returning TRUE to > HAVE_AUDIO if there is audio but it's unsupported? We do return TRUE to HAVE_AUDIO. The only interesting bit here is that, in the xine-lib backend, we fail the open() if there's only audio and the audio isn't supported.
Sample file: http://multimedia.cx/samples/A-codecs/VoxWare/Lucky.asf I'd like to have a way to still query tags about the audio stream, even if it's unsupported. Right now, playbin2 won't expose unsupported audio tracks as playable. I'd still have liked a way to get access to that data to show it in the properties tab of the movie player (as we already manage to do it in the nautilus properties tab, as we use gst-discoverer there).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/6.