The ideal solution would be for Nokia to actually ship the Vorbis decoding plugin from upstream. Or let kulve help them out with gstreamer?
Definitely! They should support Ogg out-of-the-box. Let's hope the new HTML5 specification (which recommends Ogg as baseline format) helps to change things. Please vote for maemo bug #176. Looks like they are working on the issue.
I wonder if a strategy similar to how the Livna repository (3rd party non-free for Fedora) packages xine's non-free plugins might work: build the entire modified gstreamer framework (with a single .dsc), and then just exclude or remove the files already packaged by Nokia.
This 3rd party (free and non-free) infrastructure is already there. I've worked together with Maemo's webmaster and only with that we could have Canola working on Diablo.
AFAIK, there is no problem in rebuilding a package which is already in the repositories. At least, this is not a problem for extras/extras-devel repositories, don't know if this applies to the official nokia packages. It's a good test case.
Even if it would succeed it might be a bit odd for those who would like to get source for the Nokia's version of the gstreamer and "apt-get source gstreamer-something" would fetch my sources if the extras/extras-devel repository is in the sources.list.
But that's a "problem" already if one has my repo in the sources.list..
Is there any reason why the scanner requires Ogg gstreamer playback support for just reading the tags? I think this is the real "bug" here, and is certainly a show-stopper for Canola on Diablo.
Lightmediascanner only needs libogg and libvorbisidec (a bit patched) to read the tags from ogg. The playback support is responsibility of either osso-media-server (thus the gst-plugins-*) or mplayer.
Even if it would succeed it might be a bit odd for those who would like to get source for the Nokia's version of the gstreamer and "apt-get source gstreamer-something" would fetch my sources if the extras/extras-devel repository is in the sources.list.
But that's a "problem" already if one has my repo in the sources.list..
I'm rather curious: why can't the gstreamer vorbisidec plugin be built against Nokia's stock gstreamer-base? Considering the binary package does not need the rest of the modified gstreamer stack?
I'm rather curious: why can't the gstreamer vorbisidec plugin be built against Nokia's stock gstreamer-base? Considering the binary package does not need the rest of the modified gstreamer stack?
The vorbisidec comes from the gst bad, so it could be built ok I guess, but the ogg-support packages provides also ogg demuxer (from base) speex (from good) and theora (from base).
And Nokia's base doesn't provide theora and Nokia's good doesn't provide speex nor ogg demuxer, so I need to modify those source packages to provide new binary packages for these plugins.
The vorbisidec comes from the gst bad, so it could be built ok I guess, but the ogg-support packages provides also ogg demuxer (from base) speex (from good) and theora (from base).
And Nokia's base doesn't provide theora and Nokia's good doesn't provide speex nor ogg demuxer, so I need to modify those source packages to provide new binary packages for these plugins.
So have your source package contain the tarballs for base, good and bad, and just compile the parts you need? If Debian's packaging system does not allow for multiple tarballs (still? RPM handles multiple sources fine), make your own composite tarball.
Now we have Ogg-support 0.8 for Diablo and does this mean that Canola will also benefit with this update? Hope so because I did install the ogg-support 0.8 but no oggs in Canola, what a suprise...
Oh well, I have MediaBox installed in my N810 and I think it will be my future choice for media if this is so complicated to even get oggs to play in Canola.
The good news is that we will have ogg support back in the beta10 version. We're still fixing the bugs for this release. Thank you all for understanding.
