The deps on media-video/totem seem to be a somewhat messed up. To help with cleaning them up I would like to suggest that the nsplugin should depend on media-plugins/gst-plugins-soup so someone who is not using the youtube plugin will still be able to play http sourced files while using nsplugin (and ofc the totem app) Reproducible: Always Steps to Reproduce: 1. emerge totem with -youtube +nsplugin 2. try to play a http sourced stream such as http://www.apple.com/trailers/ Actual Results: The player will return an error that http is not supported. Expected Results: The player should have access to media-plugins/gst-plugins-soup so that the http source will play.
What version of totem are you speaking of and how did you figure the missing gstreamer-plugins-soup plugin ?
The version of totem I have installed is media-video/totem-2.28.1. As for "how did you figure the missing gstreamer-plugins-soup plugin?" I got an error saying that totem could not playback HTTP streams after I removed the youtube useflag and ran a depclean, so I checked the dependancies for the youtube useflag, and saw media-plugins/gst-plugins-soup which as the description of "GStreamer plugin for HTTP client sources" so installed that and it worked playing http sources again.
Just wanted to add that in totem-2.26.4 it seems that media-plugins/gst-plugins-soup is pulled in by the python use flag, which again doesn't make much sense to me as I thought that libsoup was a c library and so was the plugin for totem.
(In reply to comment #3) > Just wanted to add that in totem-2.26.4 it seems that > media-plugins/gst-plugins-soup is pulled in by the python use flag, which again > doesn't make much sense to me as I thought that libsoup was a c library and so > was the plugin for totem. that's completely unrelated, pulling a plugin and the bindings making it useful by python stuff has nothing to do with the implementation of the lib being used at the end of the chain.
Also, could you list something else than apple trailers ? This source is just not reliable as they change how the damn thing works all the time.
(In reply to comment #5) > Also, could you list something else than apple trailers ? This source is just > not reliable as they change how the damn thing works all the time. > I don't see how me listing ANY source on the internet is relevant to a suggestion that people who are setting the "nsplugin" use flag on a package to install the web browser plug-in, might want to have that plug-in to be able to play streams sourced via http without having to "know" that gst-plugins-soup is infact the http source for it. All I suggesting is that when someone says they want web broswer support in totem, it would be a good idea to pull in the package that allows totem to play things off the internet. http://packages.gentoo.org/package/media-plugins/gst-plugins-soup says "GStreamer plugin for HTTP client sources", so surely thats the one to pull in.
It seems there is a misunderstanding here. I'm asking you another http video provider as apple trailers is just a moving target and doesn't work reliably. As for gst-plugins-soup looking like the right target for what you want, this is simply wrong, there are lots of ways to stream content on the internet, we just try to provide sane defaults (and soup is not the only candidate for what you want).
I understand that there are different sources for "internet" streaming video, for example rtsp, which I assume is installed via the media-libs/gst-plugins-good package. It all just seems a little messy as it stands, as the soup (http) plugin is also part of the gst-plugins-good package upstream but has been separated out into its own ebuild. As it stands, it is possible for someone to install the nsplugin and by default get some protocol support pulled in automatically (like rtsp) but not others (http). The only reason for this bug report was because I wanted to note to the maintainer that it seemed odd to me to have a situation where a pretty widespread protocol, in this case http, was not being installed by default when someone requesed that the web browser plugin be built. As I would assume that someone building the nsplugin would be wishing to view content via the web. Clearly it could be that someone does not want http support, but then surely if you wish to provide that level of control, then it would not also install other protocols by default. Is there another http streaming plug-in for gstreamer that I have missed, as it was my understanding that the "soap" plug-in provided the http streaming ability as noted at http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/ch02.html? In summary, I just wanted to note that it seemed messy that http streaming was being left out when someone was requesting that the web browser plug-in be built.
This is both the beauty and downside of gstreamer for us. There's a wide variety of plugins out there and we try to make sure gstreamer apps work, but (so far) we've decided against pulling in all plugins. We _know_ this will break some use cases, but since new plugins are only an emerge away (less than a minute for most plugins), we think it's best to only provide a minimal gstreamer setup. @herd, IMHO this is INVALID. Thanks
Since nothing is moving on the missing-plugins front for now, dependency added to 2.28.6. We shall however not add anything else than http or totem deps will just grow forever.
