maemo.org Bugzilla – Bug 176
Ogg Vorbis support out of the box
Last modified: 2010-01-13 14:29:18 UTC
You need to log in before you can comment on or make changes to this bug.
The audio player refuses to play ogg encoded audio. Please add an dsp-accelerated ogg codec.
Reassigning.
Claiming ownership.
Feature request has been forwarded to upstream maintainer.
I would greatly appreciate this being added. Many current OSS applications that supports Audio Streaming (Icecast+MPD, others) stream Ogg preferentially to MP3. Enabling Ogg Streaming makes setting up a compliant streaming server significantly easier. I would also like to be able to play my large music collection in OGG, but I'm sure you've heard that reasoning from several individuals already. Thanks.
*** Bug 682 has been marked as a duplicate of this bug. ***
*** Bug 683 has been marked as a duplicate of this bug. ***
Adding Theora to the summary as mentioned in bug 682 and bug 683
*** Bug 684 has been marked as a duplicate of this bug. ***
*** Bug 686 has been marked as a duplicate of this bug. ***
Just one more comment on the importance of this issue. Many games use ogg vorbis for background music as it does not have any patent problems and also mp3 format does not have any advantage over ogg vorbis for this purpose at least on dektop PC. Now when porting such games to Nokia 770 (I'm porting ufo2000 for example), we have troubles with playing ogg music because of heavy cpu usage. So I think having vorbis codec support is quite important and it is important to have it implemented by DSP to free ARM core for other game related tasks. Thanks.
I'd like to add my voice for this as well - AND I'd also like to add Speex to the mix, for VoIP applications.
why is this still not in it2006. I would love to see support by DSP code, however arm-only would be ok too, I just don't want to install players which don't work and suck out my battery just by not closing them.
Ogg support with the various codec support (vorbis/theora/speex) would be excellent so that it can be used in both the audio/video player but speex can also be used in the gtalk/sip applications for VoIP
should the keywords for this (that were just assigned) not be enhancement-it2006?
Sorry, I hate to do bug nagging, but as this one has been mis-keyworded enhancement-i2005 a couple of months ago and has not been touched since, so I would like to raise this issue again. This page (http://maemo.org/platform/docs/multimedia/getting_started.html) describes how to add ogg support to all native n770 media applications through osso-media-server. However, following the instructions given there does not work (as has been found out by several people). Could the guy who wrote up that please have a look at it again and correct them? If Nokia doesn't plan to look into this (sorry guys, I can't fix your code as this piece is not open :-)), could you at least clearly state that you don't have interests/resources for this?
(In reply to comment #15) > If Nokia doesn't plan to look into this (sorry guys, I can't fix your code as > this piece is not open :-)), could you at least clearly state that you don't > have interests/resources for this? indeed, I would say that the 770 is a good case study of the benefits of having an open source community around a project, since if not for this closed source dsp business, there would likely be proper support by now in a third party package. At least in this case I can understand that probably the only solution to this for Nokia would be to use a completely different chip for the device instead of the OMAP 1710. I held out for a whole year before deciding to buy a 770, partly because of the use of this chip, but in the end, I didn't see any competition for the sub $400 Linux PDA market. Anyway, this bug has my vote as well, vorbis is much more space efficient than mp3, and speex would be nice for SIP calling, which will be ported to maemo again, it's only a matter of time.
please ... when I bought my 770 I read that ogg-support was just not done because of time-contraints. but now we already have VoIP and tons of other stuff. Still ogg-playback is still missing :-/ The stand-alone player sucks out my battery and does not work well.
(In reply to comment #14) > should the keywords for this (that were just assigned) not be enhancement-it2006? OK, I took the initiative and updated the keyword to "enhancement-it2006". Anyone from Nokia want to comment?
Picking this one.
Do the Maemo Garage projects https://garage.maemo.org/projects/ogg/ and the earlier https://garage.maemo.org/projects/mogg/ resolve this to the satisfaction of Maemo upstream? In such a case, could they be integrated into an official firmware rather than as an poorly-publicized add-on?
I don't know for sure, but I'm guessing that those packages decode the Ogg files on the ARM core rather than the DSP core. I tried the standalone Ogg player on my device, and the result was noticeably different from playing mp3s. If I did anything with other applications while playing music, the music would frequently skip as the CPU tried to service both applications at once.
this is really a joke! still no ogg support for N800, whereat it has been said that it was not done for 770 just because of time. To be honest I don't buy this, I guess there are some agreements behind that which don't allow to push ogg further.
Perhaps Nokia is incapable of creating a C55x targeted Ogg codec in-house - if I understand correctly, the other DSP codecs are proprietary and licensed.
*** Bug 1035 has been marked as a duplicate of this bug. ***
Could this maybe be moved to another OS version (like OS 4.2007) now that bug 1035 which had been filed against an unspecified version has been closed as a duplicate of this bug?
(In reply to comment #26) > Could this maybe be moved to another OS version (like OS 4.2007) now that bug > 1035 which had been filed against an unspecified version has been closed as a > duplicate of this bug? It should be. I have no idea why 1035 was closed as duplicate of this, which is marked as a 770 bug. I'd really like to hear Nokia's official opinions on this. I find it absurd that a Linux-based tablet PC does not support Ogg-Vorbis.
I completly agree here. Its simply a joke. When the 770 arived they said its a matter of time, the update packages did _nothing_. The N800 still does not support it. I wonder whats the problem, all the people are asking for is at least software-decoded ogg-vorbis playback. Is it really so hard to incooperate??
I marked the other bug report as duplicated because the core issue is the same and so it was getting the discussion. Instead of having a duplicated thread I thought it was better to have everybody interested in ogg support looking at a single place. Moving this to product N800 and version unspecified just to show that the issue reported affects also the latest development and is not restricted to a specific version. Don't be bothered by the change of device since we will reorganize the products to make them software centric instead of device centric. Some comments in the hope of sharing a common understanding. The issue is not *getting* ogg support: - Users can play ogg files in the tablets downloading third party software. I haven't found a good place where this is documented, so here it is this new wiki page: http://maemo.org/community/wiki/playingoggfiles/ . Please improve it to make it more useful to tablet users. This will be even easier in the feature with the Automatic codec installer planned in our roadmap (http://maemo.org/intro/roadmap.html see Platform). We have no deadline/release assigned to this yet, sorry. - Developers have official documentation explaining how to enable ogg support in their applications: http://maemo.org/development/documentation/how-tos/3-x/getting_started_with_multimedia.html . If you are a developer and you need more information please ask. From a purely technical point of view this is an issue relatively simple to address in our platform. Having ogg support out of the box (literally) is a different story, though.
(In reply to comment #29) > From a purely technical point of view this is an issue relatively simple to > address in our platform. Having ogg support out of the box (literally) is a > different story, though. Can you tell us the story of Nokia's reasons why not to?
A solution that results in a halved battery life (over MP3) is not a solution at all. Why can Nokia not realise that many of the people likely to buy the N800 are inclined to support open formats? Just write a sodding dsp codec or release all the info for others to do it. The promise of this being available was a serious decision factor in my buying of an N800.
(In reply to comment #29) > I marked the other bug report as duplicated because the core issue is the same > and so it was getting the discussion. Instead of having a duplicated thread I > thought it was better to have everybody interested in ogg support looking at a > single place. Thanks for the explanations. It is clear now. > From a purely technical point of view this is an issue relatively simple to > address in our platform. Having ogg support out of the box (literally) is a > different story, though. That's exactly what I, like many others, am wondering about. What decision process was there to decide that Nokia would include built-in, DSP-assisted MP3 support while leaving out the same level of integration for OGG? I have read it up online and found some people who claim to be close to Nokia saying that it's a MP3 licensing issue. Is that so?
I can explain some of the things I have personally learned working at Nokia. Please don't take them as an official statement. The elements that most if not all the companies in this sector / with this size consider when including a feature in the official support guarantee and specially in the sales box, inside a physical device are more or less: - business reasons - competitors portfolio - feature available by third parties or not - intellectual property, licenses, patents - ongoing plans in other similar features - resourcing - strategy & roadmap of the own product - strategy & roadmap at a higher level (product portfolio, other business units) - technical feasibility Ogg (Vorbis) support is no exception, goes through all these filters and needs to take in account the whole context. mp3 went through the same filters and succeeded for obvious reasons. Maybe you can release a Linux distro asking users to add manually mp3 support, but this doesn't work in the consumer electronics industry where we operate. In general it's tricky to compare directly a stand-alone open source software distribution with an operating system preinstalled and certified in a device. Most of the code is similar, but the whole context is radically different. Yes, Nokia needs to understand the specific needs of the pro-open communities (I think in general it does), but we tablet owners active in these communities also need to understand better how things work in companies like Nokia and in the corporate & commercial context in general. Vorbis is not the only noticeable codec missing in the tablets sales box and this is why we want to improve in general the capability of users adding the codecs they want themselves. Of course we understand that official support is not the same than not official support, but we hope you also understand that what for a user implies installing some software herself for Nokia implies a much more complex move. Sometimes the move happens, sometimes it doesn't happen, sometimes happens later. > Just write a sodding dsp codec or release all the info for others to do it. You probably know that things don't work like this in commercial software development. > The promise of this being available was a serious decision factor Sorry but... who promised what?
I still can remember statements in the early pre-release phase where people said mp3 is supported, vorbis not because of time-constraints, but vorbis will be implemented - its just a matter of time. I don't remember who said this, nore wether it was an official nokia employee - however it wasn't an official statement. Its just floating still in our heads ;) lg Clemens
>I still can remember statements in the early pre-release phase where people >said mp3 is supported, vorbis not because of time-constraints, but vorbis will >be implemented - its just a matter of time. This was what I recall too. I tried looking for some evidence of this, but failed, so I may be mistaken. But I certainly got that impression. Re the development model. Its not an issue of the codec being included/supported/blessed. Commercial entities release "unsupported" software all the time. The real issue is that it is not easy for a third party to implement the necessary codec in a neat fashion. By this, I mean with use of the DSP.
I wasn't trying to challenge your memory, most of you have probably more and better memory about this project than myself. I just wanted to clarify that this promise wasn't made officially or in the N800 timeframe. In this case I should be aware, that's why I asked. There is no "unsupported" software preinstalled in Nokia devices. Different support levels can be assigned to software released to be installed by the own users, but still Nokia has a degree of responsibility there. Nokia is not responsible of third party software users install in their Nokia devices. DSP is part of the issue, I understand. But this is a totally different issue (that we are also aware and trying to solve somehow, sometime). Really, it's not that we don't understand your reasons. It's not about you convincing us. It's not about you/us being right/wrong. The message coming from this bug report (and all the calls in the same direction made out there) is clear and we are trying to solve the issue in the best way that is in our capacity. My aim is to help getting a common understanding of the situation and the plans. We will communicate here any progress.
>DSP is part of the issue, I understand. But this is a totally different issue >(that we are also aware and trying to solve somehow, sometime). Thanks for the clarification. Its good to know that all this is on your radar as something that needs sorting.
(In reply to comment #36) > My aim is to help getting a common understanding of the situation and > the plans. We will communicate here any progress. Are there any plans, aside from making 3rd party codec installation easier? This bug has remained open for nearly 22 months, leaving many people with the (now apparently false) impression that Nokia was not adverse to including ogg support out-of-box and that it was only a matter of time. If it is actually the case that this is a WONTFIX issue, please, say so! (In reply to comment #33) > The elements that most if not all the companies in this sector / with this size > consider when including a feature in the official support guarantee and > specially in the sales box, inside a physical device are more or less: > ... > - intellectual property, licenses, patents > ... Has Nokia agreed to a license which prevents them from supporting ogg out-of-box?
(In reply to comment #36) > Really, it's not that we don't understand your reasons. It's not about you > convincing us. It's not about you/us being right/wrong. The message coming from > this bug report (and all the calls in the same direction made out there) is > clear and we are trying to solve the issue in the best way that is in our > capacity. My aim is to help getting a common understanding of the situation and > the plans. We will communicate here any progress. From the purely technical standpoint, how big a project would it be to create DSP-enabled support for Ogg-Vorbis? That is, how many man-hours would be required to create and test the piece of code that achieves the goal? I am assuming no hardware modifications would be necessary. This is just my curiosity as a software developer myself.
> If it is actually the case that this is a WONTFIX issue, please, say so! Not a WONTFIX > Has Nokia agreed to a license which prevents them from supporting ogg out-of-box? For more questions please refer by now to my comment #36. As said, we will communicate here any progress.
Sorry, fast editing ate my "No": > Has Nokia agreed to a license which prevents them from supporting ogg out-of-box? No
There's updated documentation regarding this issue, but it's still not solved. http://maemo.org/development/documentation/how-tos/3-x/getting_started_with_multimedia.html
This bug gets my vote. Some of the newer open source programs REQUIRE ogg to even compile let alone run on the N800.
https://garage.maemo.org/tracker/index.php?func=detail&aid=1453&group_id=164&atid=681
while this might be just an enhancement on OS2006, it is a real bug on OS2007; osso-media-server refuses to play ogg files, even if you have the necessary gstreamer codecs(non DSP accelerated) installed. This is just a software error and should be easily fixable. Can someone comment on the state of this in OS2008? I would generally appericate if someone more technical than Quim could comment on this.
(In reply to comment #45) > while this might be just an enhancement on OS2006, it is a real bug on OS2007; > osso-media-server refuses to play ogg files, even if you have the necessary > gstreamer codecs(non DSP accelerated) installed. Are you sure? I didn't personally try it on OS 2007, but I received reports that https://garage.maemo.org/projects/mogg/ works with osso-media-server on OS 2007. Unfortunately, the built-in audio player won't list ogg files in its "open file" dialog, but playing oggs from the file manager should work. It also seems to work with kagu which uses osso-media-server.
Here it doesnt work yet with latest osso-media-server, but perhaps like Timan says, you can use the file manager to play ogg vorbis files. (In reply to comment #46) > (In reply to comment #45) > > while this might be just an enhancement on OS2006, it is a real bug on OS2007; > > osso-media-server refuses to play ogg files, even if you have the necessary > > gstreamer codecs(non DSP accelerated) installed. > > Are you sure? I didn't personally try it on OS 2007, but I received reports > that https://garage.maemo.org/projects/mogg/ works with osso-media-server on > OS 2007. Unfortunately, the built-in audio player won't list ogg files in its > "open file" dialog, but playing oggs from the file manager should work. It also > seems to work with kagu which uses osso-media-server. >
Apart from technical considerations which may or may not apply I feel that there are further problems. Nokia, simply speaking, is a MPEG company, using MPEG technology in a wide range of products and proposing usage of MPEG technology in all media related use cases. This goes as far as actively working against the usage of Ogg codecs as recommended baseline format for HTML5 in the W3C standardization process ( http://www.w3.org/2007/08/video/positions/Nokia.pdf ): "Considering our requirements, we believe the widespread use of technically competitive, but not necessarily “free” open standards, such as H.264 for video and AAC for audio, would serve the community best." "All these alternatives are, in our opinion, preferable over the recommendation of the Ogg technologies" Non-free standards are, of course, a serious problem for the free software community and thus Nokia is in the unfortunate position of a) using free software in its products and b) pushing standards which are not implementable as free software. Of course Nokia is free to make decisions guided by business reasons but it definately would be nice if Nokia could work together with the free software community to drive adoption of open and free formats instead of making such efforts harder. Maemo itself is a great thing and a wonderful step into the right direction, but perhaps Nokia is, at its core, issuing policies clashing with what users would expect from an open platform.
At least Nokia could proved specs. for how to implement 3rd party ogg-support in their soft (eg. Media Player tag reading).
Nokia This has now become a vital and critical issue to support the Ogg format. It is now time to make a stand. And there are standpoints that are necessary if the goodwill position gained in open source community should remain. This is one. This ...policy decision/ clarification will be highly welcome in the open source community. IF the hostile to OGG is true, rethink, what will gain Nokia in the long run..... and Maemo users want OGG on their Internet Tablets!!
The reason Nokia does not support (and never will) Ogg Theora is because they hold an 'essential patent' in the MPEG/H.264 specification. When fees are introduced in 8 years ALL internet H.264 software, hardware and distribution will incur a fee to be split between members of the MPEG LA (which include Nokia, Sony, Microsoft and others). As most of you may know Nokia is currently trying to strip Ogg from the HTML5 spec - claiming (falsely) that it's proprietry and pushing for h.264!
I have updated the documentation about how to add supplemental codecs: https://maemo.org/development/documentation/how-tos/4-x/getting_started_with_multimedia.html The reason why the documentation wasn't updated before is simply because a lack of resources (I didn't have the time).
I have to admit I am really disappointed. Its so typical for companies like nokia - they are as long open-source and especially open-standards friendly as long as they can safe money. In this case, they would maybe loose money, so they turn against the opensource movement. I know it sounds hard, but maybe its not enough to give decives away for free to statisfy the open-source community. Shame on Nokia :-/
I have no problem with Nokia seeking money. I'm just impressed that they haven't discovered who's paying their bills: the consumers. Nokia: Consumers don't want DRM. Get it? Here's what we should expect from more major players: http://arstechnica.com/news.ars/post/20071202-amazon-and-wal-mart-unwittingly-team-up-against-drm.html
I suggest leaving criticism and personal opinion out of these bug reports unless they contain useful information that will help to close it. Nokia has made their decision and being that these devices are open source, people have already come up with ways to support Ogg. Is there something wrong with that?
(In reply to comment #52) > I have updated the documentation about how to add supplemental codecs: > > https://maemo.org/development/documentation/how-tos/4-x/getting_started_with_multimedia.html > > The reason why the documentation wasn't updated before is simply because a lack > of resources (I didn't have the time). One need to be logged in to read the document. And does it apply to Maemo 3.x?
that works without logging in: http://maemo.org/development/documentation/how-tos/4-x/getting_started_with_multimedia.html
(In reply to comment #57) > that works without logging in: > http://maemo.org/development/documentation/how-tos/4-x/getting_started_with_multimedia.html This is useful to developer, however. Is there user info anywhere? I installed "Ogg Vorbis support for Maemo" <http://maemo.org/downloads/product/OS2007/mogg> and tried renaming .ogg files as .mp3, but the Media Player app does not find them.
(In reply to comment #58) > This is useful to developer, however. Is there user info anywhere? I installed > "Ogg Vorbis support for Maemo" <http://maemo.org/downloads/product/OS2007/mogg> > and tried renaming .ogg files as .mp3, but the Media Player app does not find > them. Please don't abuse this bug for support requests about mogg. Yes, the Media Player doesn't find them with "mogg" on OS2007. It works on OS2006, though. Either open the files using the File Manager or use a different player, like e.g. kagu.
(In reply to comment #56) /* removed for shorteness*/ > One need to be logged in to read the document. one can cut down url from https to http manually to get link http://maemo.org/development/documentation/how-tos/4-x/getting_started_with_multimedia.html > And does it apply to Maemo 3.x? for 3.x there is another doc, reviewed. http://maemo.org/development/documentation/how-tos/3-x/getting_started_with_multimedia.html
I was seriously considering buying N810 until I found this bug report. The battery life doesn't look good enough (as for me) even without OGG, but if playing OGGs would halve it just because Nokia refuses to implement support of an open source codec.. Well.. I'm afraid I'll better go look for a decent piece of hardware. This is really sad, N810 was #1 in my list.
My music is nearly 90% stored as OGG-Vorbis file. Only 10% are stored in MP3 format and no other formates are used. Especially proprietary formates can't really used under 100% OpenSource Linux (so as: ACC, WMV, RM, MOV, ...). The only other sound format what I use is FLAC (for lossles storing of very historic sound tracks - from old phono records). If I won't use (software-) patented MP3 codec, so only OGG-Vorbis is available!
Wow, I was literally just about ready to buy an n810 at Amazon. Then I found this bug. Oh well. The n810 is a really cool device, but to have a very sub-standard 3rd-party solution (OGG Vorbis playback processed via CPU, not DSP) as my only option for playing my music collection is a deal-breaker. Glad this bug was here.
What's the deal here? Why hasn't this been fixed? Is there a hardware issue?
Kyle: There's an inofficial fix at <https://garage.maemo.org/projects/mogg/>. not sure why it's not in the default image, maybe not enough demand? Maybe the Product Manager is swamped with requests? I've no idea.
Ah, there's an alternative package at <http://maemo.org/downloads/product/OS2008/ogg/> and I'm not sure why these aren't just integrated into one package. And I think it's not using the DSP (who on maemo-developers knows how to program for the DSP _and_ the OGG codec well enough, I wonder?).
Simon Pickering is trying: <https://garage.maemo.org/projects/dsp-tremor/> (*much* appreciated btw).
I wouldn't make the severity as enhancement, as it was a promised feature before launch. While Nokia has said that they didn't have time, they never did fully develop kernel patches and drivers for propr DSP usage. It is obvious they have all the tools needed and already have the TI CCStudio IDE to develop for it as evidenced in existing kernel patches with credits to Nokia devs written all over them. A monetary issue? It's already been spent on purchasing the IDE which includes all necessary tools and documentation to develop for the TMS320C55x DSP in its full capacity. Manpower? Don't kid yourselves. Especially now when they realized they twiddled their thumbs for three years while the competition is coming hard and strong with their sights set straight on their Maemo devices. Politics is the most likely answer, but I won't accuse them of that because I have no evidence to back it up other than their IP for components of the competing and propreitary AAC codec family.
*** Bug 1132 has been marked as a duplicate of this bug. ***
(In reply to comment #68) > I wouldn't make the severity as enhancement, as it was a promised feature > before launch. Please provide references, otherwise i consider this as FUD...
(In reply to comment #70) > (In reply to comment #68) > > I wouldn't make the severity as enhancement, as it was a promised feature > > before launch. > > Please provide references, otherwise i consider this as FUD... > Either way, the recent announcement[1] that Firefox 3.1 will have native support Ogg Vorbis and Ogg Theora makes for interesting reading - isn't the standard Maemo browser now based closely on Firefox/Gecko? What's the Nokia plan then, to ignore this HTML5 feature and continue to push closed, proprietary codec support? It's about time that Nokia accepted that their is or will be widespread support for Ogg audio and video formats sooner rather than later. 1. http://news.softpedia.com/news/Mozilla-Firefox-3-1-on-It-039-s-Way-to-Setting-Web-Video-Standard-91432.shtml
I haven't seen a link to https://wiki.maemo.org/Playing_OGG_files here yet. Just a reference to workarounds for the current situation. Please keep that wiki page *useful* and don't add flames, you already have this bug report. ;-) Thanks.
(In reply to comment #72) > I haven't seen a link to https://wiki.maemo.org/Playing_OGG_files here yet. > Just a reference to workarounds for the current situation. > Please keep that wiki page *useful* and don't add flames, you already have this > bug report. ;-) Thanks. > We all know that there are workarounds using implementations that use the main CPU instead of the DSP, the issue is that this method wastes battery life much more than is needed.
(In reply to comment #73) > We all know that there are workarounds using implementations that use the main > CPU instead of the DSP, the issue is that this method wastes battery life much > more than is needed. Do you have any numbers that can prove this statement? For example something like a battery drain test of mp3 decoder running on ARM vs. DSP decoder.
(In reply to comment #74) > Do you have any numbers that can prove this statement? For example something > like a battery drain test of mp3 decoder running on ARM vs. DSP decoder. > This is something I'm happy to test. Can someone write a DSP Vorbis decoder for the n800 so I can try it out? Cheers.
(In reply to comment #75) > (In reply to comment #74) > > Do you have any numbers that can prove this statement? For example something > > like a battery drain test of mp3 decoder running on ARM vs. DSP decoder. > > > > This is something I'm happy to test. Can someone write a DSP Vorbis decoder > for the n800 so I can try it out? Why don't you do this test with MP3 and other decoders that are available for both ARM and DSP? Or you think that your statement about much lower power consumption is valid only exclusively for yet to be developed vorbis DSP decoder? It would be very interesting to have some more or less realistic practical estimates for the potential battery life improvements.
I lost all my respect to Nokia. I bought N800 just to find out that after upgrading to OS2008 it still doesn't have ogg support out-of-the box. No Theora. No "camera" app for taking pictures and Skype without video (both features were present in OS2007). You only see the tip of your nose. I'm waiting for OpenMoko (or Android) to hit the shelves and my N800 hits the eBay. And no, CPU-driven ogg support is not an option. Soon it will be three year since this bug was posted. And third version of the OS. And still no support from Nokia. No, we are not gonna buy anything from you next time. Nice PR. This report should be a WONTFIX ater all, because Nokia literally won't fix it.
(In reply to comment #77) > No "camera" app for taking pictures and Skype without video (both > features were present in OS2007). > The Camera application is right in the repository, and Skype has _never_ had video. > And no, CPU-driven ogg support is not an option. Soon it will be three year > since this bug was posted. And third version of the OS. And still no support > from Nokia. No, we are not gonna buy anything from you next time. Nice PR. > Please refrain from using Bugzilla as a soapbox. If you have something useful to contribute to the bug, please do, but complaining is not that. If you want to bug fixed, vote for it.
(In reply to comment #78) > (In reply to comment #77) > > No "camera" app for taking pictures and Skype without video (both > > features were present in OS2007). > > > > The Camera application is right in the repository, and Skype has _never_ had > video. > > > And no, CPU-driven ogg support is not an option. Soon it will be three year > > since this bug was posted. And third version of the OS. And still no support > > from Nokia. No, we are not gonna buy anything from you next time. Nice PR. > > > > Please refrain from using Bugzilla as a soapbox. If you have something useful > to contribute to the bug, please do, but complaining is not that. If you want > to bug fixed, vote for it. > What about those users who bought a cool device with a camera and touts itself as an internet/multimedia device and no idea what the hell a repo is? Oh. Right. Who cares about 90% of the users who buy it to JUST USE IT. The missing camera software from shipping is downright pathetic. Lack of Ogg support is inexcusable. An AAC codec, which is very similar to Theora, which is even developed using the same toolkit, was introduced THREE YEARS AGO. THREE YEARS. Nokia's excuse? Oh, we are working on it. Yeah, we'll get to it. Uuh, what again? Theora? What's that? Oh. We are tinkering with it. We'll just keep saying we're working on it so the AAC codec can gain hold and get us some royalties, THEN we'll release that codec we developed alongside it a few years ago. That's horseshit. Pardon my language. There's no more fitting word for it. Stop dragging ass and GIVE US, THE PEOPLE WHO PAID FOR THE DEVICE, WHAT WE WANT. The customer is always right. So if I'm right in saying that Nokia is intentionally holding the Vorbis codec back and you shouldn't do that because you are increasingly making yourselves a less respectable company by the day. I want to hear a reason why. No, I DEMAND to know why you are not releasing the codec. Maybe this *IS* an issue that should go above Quim Gil's head and to Ari Jaaksi's attention, as even Quim doesn't seem to know why this hasn't been fixed for THREE PLUS YEARS.
Is there any way i can remove email notifications on this bug? I don't want to withdraw my vote for it (i think it's important), but i'm tired of all the noise from those who think that bugzilla is the place to flame.
(In reply to comment #77) > I lost all my respect to Nokia. I bought N800 just to find out that after > upgrading to OS2008 it still doesn't have ogg support out-of-the box. No > Theora. No "camera" app for taking pictures and Skype without video (both > features were present in OS2007). You only see the tip of your nose. I'm > waiting for OpenMoko (or Android) to hit the shelves and my N800 hits the eBay. > > And no, CPU-driven ogg support is not an option. Soon it will be three year > since this bug was posted. And third version of the OS. And still no support > from Nokia. No, we are not gonna buy anything from you next time. Nice PR. It should be possible to develop ogg vorbis support for the DSP, just like Simon Pickering is doing for the sbcenc. I'm digging into DSP development so I might be able to help. > This report should be a WONTFIX ater all, because Nokia literally won't fix it. We, Maemo engineers in Nokia, are working on it. By that I mean we are doing what we can internally, but the decision is not in us, it's high level management. Something you can do to help is to raise your voice, discussion in this bug report helps, but the more public the better. Maybe gather signatures for a petition, I don't know. I don't know if I'm making sense here, I can't explain the details, but if it helps think on Dilbert.
> We, Maemo engineers in Nokia, are working on it. By that I mean we are doing > what we can internally, but the decision is not in us, it's high level > management. And probably no one from the management is reading this bug report ;) But you guys in Nokia should have the DSP specs, right? I mean, who developed the code that uses the DSP? Or maybe you can't because of some licenses? AFAIK, Vorbis code is released under BSD, so this should't be an issue. Ok, this issue has been discussed previously. And you surely have other things to tinker with. Anyway, I cast my vote.
(In reply to comment #79) > I want to hear a reason why. No, I DEMAND to know why you are not releasing the > codec. Maybe this *IS* an issue that should go above Quim Gil's head and to Ari > Jaaksi's attention, as even Quim doesn't seem to know why this hasn't been > fixed for THREE PLUS YEARS. > Is Ari Jaaksi aware that we want a DSP-based solution? When he blogged on the issue, he seemed to point to the 3rd-party projects as a "solution". And that was before the HTML5 lobbying. PS please change target device to N800, as N770 is no longer officially supported.
Just an FYI, discussion about this bug has reached "mainstream internet media" http://arstechnica.com/news.ars/post/20080923-technical-overview-maemo-5-the-next-gen-nokia-tablet-os.html?comments=1 I honestly hope it will cost Nokia few sales, since until I have read that article I was myself considering buying such device based on its "openness"
I'd like to add that the problem of "battery drain" or "halved battery" when decoding ogg compared to decoding mp3 is the same for every player on the market, being nokia, iaudio, iriver, etc... Ogg simply needs more power to be decoded. The codec is better than mp3 for the size/quality ratio, but it has a cost.
(In reply to comment #84) > I honestly hope it will cost Nokia few sales, since until I have read that > article I was myself considering buying such device based on its "openness" It is because of the openness of the device you can install and use third-party codecs including vorbis which do the job (albeit with some problems, which are also reported in bugzilla). Would you prefer a device with out-of-the-box support of vorbis but without the possibility of using third-party software? Would it make the device more "open"? The logic "vorbis is open" -> "the device does not have vorbis preinstalled" -> "the device is not open" is completely flawed. Also keep in mind that the storage space on the device is limited. It is physically impossible to have all the open source software which exists in this world preinstalled. This is where application manager, http://garage.maemo.org and extras repository come into action
To anyone with any knowledge of multimedia codec licensing it must be clear that the issue here is not a technical one. I think it's safe to assume that Nokia don't want to pre-install Ogg codecs because they are not allowed to under the terms of their MP3 codec _patent_ license. I don't know that for sure, and I have no involvement in, or knowledge of, that part of Nokia/Maemo, but that's a very typical situation in the industry. So this bug report just be about how Nokia/Maemo could make it easier for the community to support Ogg as well as possible.
Siarhei Siamashka@#86 > The logic "vorbis is open" -> "the device does not have vorbis preinstalled" > -> "the device is not open" is completely flawed. Surely. But logic "lots of people asks for feature but Nokia ignores feature request" -> "development process is not-so-open" definitely will work, right? > Also keep in mind that the storage space on the device is limited I bet there is enough space to store just some small codec. Murray Cumming@#87 > because they are not allowed to under the terms of their MP3 codec _patent_ license. Then please explain: lots of "mp3 players" vendors today bundle their players with built-in OGG support, including several major brands on the market. Please explain, why these companies CAN sell players with built-in OGG and Nokia can not. These companies still not suffered neither from mythical "submarine patents" we'll probably never see, nor they seems to be bound by mp3 licensing conditions since they able to supply both MP3, OGG, AAC and sometimes other formats support in single device. So as for me this looks like simply not true or at very best, half-true.
I'm trying to address some of the issues here: http://felipec.wordpress.com/2008/09/24/ogg-vorbis-and-maemo-5-technical-standpoint/ Basically we are working towards better third-party plugins support. For audio codecs now NEON optimizations should make CPU consumption decent enough.
Felipe, that sounds excellent. However it doesn't help the owners of the current tablets.
Walther, the best thing that can be recommned to the owner of existing tablets is to add support for ARMv6 simd assembly to ivorbis. I would think that this is easier that porting to the DSP (as tools and docs are not avaible from the manufacturer).
I don't think that the theories about fear of submarine patents or conflicting licensing obligations can adequately explain Nokia's refusal to ship ogg support, after hearing that the N810's preinstalled map program brazenly includes its own oggvorbis-playing capability (and thousands of ogg files). The only theory I've heard which actually makes sense is that, because Nokia enjoys making money from their share of the MPEG4/AAC royalties, they would much rather see that format supplant mp3 than a free option like ogg. Can anyone from Nokia confirm or deny that this is the primary obstacle here?
(In reply to comment #92) > Can anyone from Nokia confirm or deny that this is the primary obstacle here? No. :) Roberto, Stefan & co are very good engineers and they can provide answers and advice at an engineering level. Your questions are related to business and only a Nokia speaker involved in business can answer them. Will a profile like this come to Bug 176 and answer? Probably not. Nokia is improving the open development practices but business discussions and decisions are out of scope and developed in the usual corporate way. At a smaller scale, the Maemo team is generally supportive with any cool ideas and projects willing to extend the capabilities of the platform. As an example the latest post from Roberto linked above. Those of you working on GStreamer, codecs, DSP and so on surely can recall more examples. Ogg support is not a technical issue now when a Maemo user wants to have it. Like MP3 support is not a technical issue for the average e.g. Ubuntu user. If you want to have it you can have it. As Roberto and Stefan have explained, there are ongoing works to improve the integration of third party provided codecs in the platform, so in the future Maemo users can even have them easier and better. So really, the issue remaining here that prevents closing this bug is to have Ogg codecs supported by default in the sales product. You want to see Nokia supporting officially those codecs. Which is a business request seeking a business decision that would create a business precedent at Nokia, if I'm not wrong the company shipping more multimedia players nowadays. This is something that probably no business representative at Nokia will come to discuss here. A recommendation: keep the discussion on the technical level and get the most from the excellent Maemo multimedia engineers. If you want more answers from the business side then ask the right representatives where they can be found. Putting more pressure on engineers about corporate issues doesn't help. Thank you for your understanding...
Thank you, Quim, for clarifying that the only obstacle preventing proper Ogg Vorbis audio support is a business decision. However, I'm not sure that you understand the technical issues completely. You stated: "Ogg support is not a technical issue now when a Maemo user wants to have it." However, if you refer to the initial entry for this bug, it says: "Please add an dsp-accelerated ogg codec." The is no DSP-accelerate Ogg Vorbis codec available for download. A DSP implementation is important as reduces power consumption (improving battery life) and reduced CPU load, facilitating playing music in the background. The community is requesting Ogg Vorbis support at the same technical level as the other audio codecs (MP3, AAC, etc.). I'm sure people are not too concerned that this may require a separate download. However, existing Ogg support downloads do not provide equivalent support. Simon Pickering is working on a DSP implementation for this codec: https://garage.maemo.org/forum/forum.php?forum_id=2096 However, it is not currently up and running. Perhaps Nokia could assist him in his efforts? Also, Tuomas Kulve's ogg support package has problems with metadata, and his work is hindered by the closed nature of the existing audio system. See https://bugs.maemo.org/show_bug.cgi?id=2836 Again, is it possible for Nokia to assist him with this? The is a strong business case for Ogg Vorbis support (either built-in, or as a separate download, but a full DSP implementation is needed). This lack is certainly causing many lost sales and bad PR for the Nokia tablets. Can you please direct us to the appropriate forum, so we can voice our concerns to the relevant people? Thanks for your understanding.
(In reply to comment #94) > However, if you refer to the initial entry for this bug, it says: > "Please add an dsp-accelerated ogg codec." > > The is no DSP-accelerate Ogg Vorbis codec available for download. A DSP > implementation is important as reduces power consumption (improving battery > life) and reduced CPU load, facilitating playing music in the background. > > The community is requesting Ogg Vorbis support at the same technical level as > the other audio codecs (MP3, AAC, etc.). I'm sure people are not too concerned > that this may require a separate download. However, existing Ogg support > downloads do not provide equivalent support. I would really prefer to have a bugreport like this: "The device provides X hours of audio playback with the built-in DSP based MP3 codec and Y hours with community provides ARM based OGG Vorbis codec. X is (much) better than Y therefore we need ...". As Vorbis is considered heavier than MP3, the statistics for AAC playback time on one battery charge could be also used. Should we add something like 'need more info' tag?
(In reply to comment #91) > Walther, the best thing that can be recommned to the owner of existing tablets > is to add support for ARMv6 simd assembly to ivorbis. I would think that this > is easier that porting to the DSP (as tools and docs are not avaible from the > manufacturer). A much better idea is to wrap ffvorbis decoder (which is part of ffmpeg) into a gstreamer sink and use it on the device. It is the fastest vorbis decoder in existence as far as I know. On x86 where it has most of the needed SIMD optimizations, it can run circles around both libvorbis and tremor (ivorbis) :) On N8x0 it is currently faster than tremor in normal configuration but still slower than tremor in low precision configuration. There is some activity improving ffvorbis in upstream, so it is going to become even better, especially for ARM with more VFP optimized code added. Amazingly enough, substituting "OMAP3" -> "OMAP2", "Cortex-A8 -> ARM11" and "NEON -> VFP" in Felipe's blog still keeps it valid :)
Siarhei, I wonder why such a development happens in ffvorbis and not upstream. Besides I agree that a arm version that makes proper uses of simd instruction would be the way to go. It would also be lot less pain to port that on ompa3 and make use of neon there.
(In reply to comment #97) > Siarhei, I wonder why such a development happens in ffvorbis and not upstream. Because ffmpeg *is* upstream. It contains a better alternative implementation of vorbis decoder based on xiph.org specification and not on the reference code. > Besides I agree that a arm version that makes proper uses of simd instruction > would be the way to go. It would also be lot less pain to port that on ompa3 > and make use of neon there. This is going to happen eventually. All the code in ffmpeg is designed with SIMD optimizations in mind so NEON code will fit it naturally. I'm also trying to occasionally contribute to ffvorbis development as part of my open source activities (by sending patches with some high level optimizations and ARM VFP assembly code).
re comment 71 fwiw, while mozilla.org has ogg upstream, it also has printing support, and disk cache and dozens of other things (including XUL), oh and a crash reporter. our device doesn't have printing support, so we disable this feature. for hysterical raisins (err/or historical reasons), we currently disable disk cache. there's also work to enable a gstreamer path for video: https://bugzilla.mozilla.org/show_bug.cgi?id=422540 and I expect that given our platform configuration we will enable that. I can't comment on which paths may be disabled in a future version or which future version of gecko we might ship (no one knows). But it's unlikely that we would ever enable every single imaginable feature from mozilla.org (about:kitchensink). in some cases Maemo Software has developed similar technologies and requests that the platform use them. As some of you know, there is a system wide crash reporter which should be available sometime (I had hoped it'd have been available last summer, but). As for DSP accelerated codecs, they're expensive, and yes, you typically have to pay for them. If a group of Nokia customers gets together and pays for someone to write, publish, develop, or otherwise create a DSP codec which does something, they can try to make that available however they wish. I'm pretty sure my annual pretax salary couldn't cover the cost of such a codec. - When you're making enhancement requests, you shouldn't specify implementation details (DSP, software, "lisp engine based") unless you're actually providing the implementation. As a reminder, bug reporting systems are for talking with engineers about technical problems. An hour ago, I had a problem (non technical: their software was crashing my software and I needed someone from their company to contact my customer), I called the vendor and informed them about the problem, and now they're signed up in my Bugzilla and talking to the customer. If your problem isn't technical, you probably should be using another channel (Nokia Care comes to mind, and yes, it does aggregate results and yes people really do read those results).
What a coincidence, I was also thinking of bumping this feature request one of these days. Let's see where are we now: (In reply to comment #7) > Adding Theora to the summary as mentioned in bug 682 and bug 683 Actually, would you mind if we keep this request for Vorbis only and then open one for Theora if you wish? Really, the situation for both codecs is different. I'm still putting some time to see if Vorbis support can be addressed but at the moment Theora is out of scope. Choose your battles, they say. Summarizing: - As Felipe and Stefan have been explaining, Maemo 5 handles codecs in the ARM side and third parties have the very same opportunities to offer optimized codecs to end users. - Problems in Diablo about Metalayer & Media Player not handling properly ogg files will be solved with the introduction of Meta Tracker (upstrem OSS project) and the Media Application Framework (Nokia open source). - A simple codec installer UI is planned for Harmattan, allowing users to get the right codecs when they try to open a file with no codecs available in the system. Vorbis and Theora support provided by third parties will benefit from this as well. These steps would be good enough to consider Vorbis/Theora unofficialy covered in the Maemo platform. If we _only_ do this we would resolve this request as WONTFIX, since the official support would be still missing. As explained above, the resons for not offering such official support are based on business criteria and not technical constraints. So I have a proposal: instead of having Nokians and third parties / community trying to convince each other here (where all are more or less in the same page), could you help building the business reasoning to support Vorbis out of the box? A wiki page summarizing the reasons, enumerating web services using Vorbis, providing competitors details (e.g. G1 sold with Vorbis support out of the box), offering links to more resources and data, listing blog posts and discussions of Nokia customers willing to have such support... If this wiki page gets in good shape it will be really helpful for those of us willing to push this feature. Campaigning to vote on this feature request can't harm either. Will all this bring Vorbis support to Maemo? No idea, but since this is the most requested feature I will do my best to get it, or discard it completely. A sign of hope for those of you following Bug 176 since... is that between the creation of this report and now Nokia has done significant changes in its open source strategy. Not only in Maemo, but also with the Symbian Foundation and the acquisition of Trolltech. Worth a try - at least this is what I honestly think.
(In reply to comment #100) > Will all this bring Vorbis support to Maemo? No idea, but since this is the > most requested feature I will do my best to get it, or discard it completely. "this is the most requested feature" ... Shouldn't this be enough?
MOST of my .ogg files are Vorbis only and that by itself would suffice, though I'm starting to worry that some of the "Fixed in Freemantle" might end up being supported in such a way that my existing n8x0 devices might break in some way in the upgrade and/or there is some other reason things won't be backported to "legacy hardware". I would consider it solved if: 1. the Ogg container is fully and correctly recognized. 2, Vorbis is supported "out of the box" or even as #3: 3. Theora has a "one-click" install. This might simply enable the extras repository or something. It also might be in a third party codecs repository or web page. Extra points if I when I download and play or start a stream using the uninstalled Theora, I'm offered the one-click install. Note Skype is not installed by default either, but there is a (rather sticky) install icon for it. Not supported by Nokia, lots of disclaimers, etc. but there is a one-click install. I'm trying to remember if Gizmo is the same way. If something like that could be done (without the stickyness) it would be even better.
So, Quim, what you're trying to say is that we should fight fire with fire. The G1 is a good example. Extrapolate that more; Google and now Canoniacal both have the IDE for the TI ARM chipset, DSP included, and Maemo isn't the only company in town that has people developing code for the Nokia Internet Tablet. It would kind-of embarassing and even negatively reflect on Nokia for one of these companies to develop or release a driver for the tablets. It, for one, would reflect on the bureaucracy of Nokia's management because Maemo's head of development has come out short of saying that not only can they easily implement a driver, they ALREADY HAVE developed it and management is deliberately barred the release of that driver to the public. Not to sound condescending, but I'm sure several tech sites would love to let their readers know how Nokia's management is deliberately trying to stifle innovation for their own corporate means. Idunno, kinda sounds a bit Apple-ish to me. But back to my point. Someone who is developing competingdistributions is going to release the driver (I'm going to bet on canoniacal) and make Nokia look really bad. Quim has basically absolved himself from being the culprit here, so that leaves, what, two people above him in the company's heirarchy to point the finger at. Or am I completely reading into it too much?
To be fair, Nokia is NOT a linux distribution company like Canonical/Ubuntu. They produce consumer electronics. In the division, things like phones and multimedia devices. There are many other "linux devices" like GPS units or Multimedia players (tomtom, archos) but none are even close to the oldest Nokia tablet. Even things like the Linux Netbooks are often limited or restricted as to support. Nokia is not 100% open, but they are more than open enough. And in fact because they are 90% open, the other 10% becomes a much larger controversy than it seems to be for any other device. They have my gratitude for taking a chance on the line of Tablets and allowing them to be so flexible and open enough that so many things can be developed for them and even integrated with them. I am annoyed over the Theora issue (I'll go back to calling it Ogg if/when Vorbis is rejected out of hand). But that is still a small part of of the overall Tablet infrastructure. The community COULD come up with a complete alternative media player. Does Canola support Theora? The Mplayer port? I think that is also part of the problem - the media player works and works well enough so no one is going to attempt to port something else, and there should be a plugin or way of adding codecs.
Actually, Nokia IS a distribution company, whether you know it or not. They develop a FreeBSD-downstream distribution called IPSO for their enterprise IP security devices. They also make a linux-based distribution of IPSO for the same IP security devices. I know those platforms well, as I used to work support for one of their largest VARs in the US. We used to have to submit bugs and RFEs to that dev team (not sure if they are connected with maemo). If this request was from one of their customers who had a large implementation of their insanely expensive IP devices (which aren't much more than glorified servers), they would eventually implement it. But my point is that Nokia develops at least THREE OSS distributions, so they are no stranger to how it works.
> "this is the most requested feature" ... > > Shouldn't this be enough? Not always, and not in this case, as you can see. Someone with a business approach could say that offering a basis for good 3rd party Vorbis support is enough and there are other priorities. Yes, 126 people have voted and it is clear that there is a militant sector willing to have this feature in the sales box. But would this drive more sales? Isn't "one click away" good enough? Now, the people active in this thread think that no, one click away is not good enough. Amd this is why I'm gathering business arguments including the sales approach but going further into other aspects. > Quim has basically absolved himself from being the culprit here, so that > leaves, what, two people above him in the company's heirarchy to point the > finger at. You overestimate my position. :) Really, it's not about pointing fingers. It's about finding out why supporting Vorbis makes more sense that not supporting it according to the current Maemo and Nokia strategies. The technical and moral aspects are more or less clear. It's in the business aspect where people like me would appreciate having more and refreshed reasons. Some of you are experts in this domain and all I'm saying is that instead of trying to convince Felipe/Stefan/myself you could think of convincing Nokia in its own game. Of course I also understand those thinking that the reasons explained in the comments above should be enough and it's our work to push the rationale internally. They are partially right, but I thought it was worth sharing the status and asking. Anyway I'm going to keep pushing this fature request until getting a clear resolution. And it doesn't matter whether Maemo is a distribution or not. The difference with e.g. Canonical is that Nokia is responsible of the software preinstalled in those devices sold for a price in the shops. (Which btw makes me wonder who is responsible of the Vorbis support in the G1: Google, T-Mobile, HTC, OHA...?)
> "Isn't "one click away" good enough?" For me it would be and I doubt this thread would be #1 if it were that way now. The problem is usually this thread only comes after trying to install one of the current multiple "ogg support" hacks that don't all quite work, so tapping on an OGG file brings up "I have no idea what to do with this", or the crawler adds every fragment of the navigation sentences for the Map program to the playlist or something else horrible. If by "one click away", you mean having to download a deb or install file, add or enable repositories, click a half-dozen times in the application manager (Those clicks to "add repository?" and get past "Install XYZ?" and "Nokia doesn't support this" count too!), and maybe fidget with a few other things - and then have to do it all over again because this app/codec/whatever isn't saved in the backup program, no, "one click away" would not be acceptable because it would not be "one click". I just would like a clarification of "one click", but if it is something like I described earlier, it would be acceptable.
About the one clicks (right, perhaps 2 sometimes): Fremantle: if Vorbis support is available in extras then a one-click install or a selection from the Application Manager will be enough. One "Ok" for the 3rd party disclaimer and you are done. The Media Player should handle properly those Ogg files. If not, the problem would be in Meta Tracker, Media Application Framework or the 2rt party package providing the support - all 3 components open source. Harmattan (according to current plans): same Fremantle situation + the easy codec installer would popup whenever the users tries to play a file the system has no codecs for. It should be as simple as informing the user of the situation and asking him permission to go find the community supported codec and install it.
How will the 1-click solution work with libsdl-mixer? Many open-source programs try to use it to play Ogg files. If I understand correctly, they will not play those sounds on Chinook or Diablo, because Ogg support was compiled out of the Nokia-supplied library.
Glen, we can't fix all problems at once. If sdl would have a plugin concept, it would be doable too. If you have good ideas, make them happen.
(In reply to comment #100) > could you help > building the business reasoning to support Vorbis out of the box? A wiki page > summarizing the reasons, enumerating web services using Vorbis, providing > competitors details (e.g. G1 sold with Vorbis support out of the box), offering > links to more resources and data, listing blog posts and discussions of Nokia > customers willing to have such support... Since no one else did, I started http://wiki.maemo.org/Ogg_Vorbis_justification. Any and all objective contributions welcome.
The recent update to Ogg support (0.9) seems to make everything work. Also, why should Vorbis be "one click" instead of included by default? And if it is going to be in Extras anyway as a unsupported 3rrd party app, why not Theora too? Same thing with the justification page - Is it going to include Theora justifications or just Vorbis?
(In reply to comment #111) > Since no one else did, I started > http://wiki.maemo.org/Ogg_Vorbis_justification. Any and all objective > contributions welcome. Thanks! It will be useful. I have modified the summary, removing Theora in order to concentrate here in Vorbis. They offer different features and should be treated separately. Also their chances are different: while there is a small possibility of having Vorbis supported, the case for Theora is basically a WONTFIX, leaving all the initiative for third parties. On the other hand, in relation to Comment #11 and Speex support, some of you might have noted that the Fremantle pre-alpha release came with it: http://repository.maemo.org/pool/fremantle/non-free/s/speex/
Nokia got finally mentioned on my blog (linked to several planets): http://linuxhippy.blogspot.com/2008/12/javafx-and-on2-video-codecs.html Its a pitty that Ogg is still not supported. Nobody can tell me it's only a time constraint, keeping in mind all the proprietary codecs are supported and accalerated by the DSP. It seems NOKIA IS NOT WILLED at all to support ogg, because they have AGREEMENTS. So please, close this bug report as WONT FIX instead of fooling your users.
(In reply to comment #114) > So please, close this bug report as WONT FIX instead of fooling your users. Thank you for your encouragement... Look, if this request is open is because it has still an open chance. Nobody here likes to waste their time and all of us may find better things to do than fooling others and even ourselves.
I bought a N810 and thought that ogg-vorbis would work perfectly because N810 uses Maemo, and Maemo is based on Linux. Please give us a functional ogg-vorbis support (based on dsp), so I and a lot of people can listen to music. It is important that ogg-vorbis is fast and gapless!
I just wanted to add that I have run some tests. On my device (N810) using the standard media player I have played mp3 continuously for 9 hours on a fully loaded battery. According to "top" the cpu-usage was around 2-3%. I ran the same test with ogg-vorbis-files and reached 8 hours before the the battery was reported low. The cpu-usage was around 20%. I also tried ogg-vorbis with gst-launch and reached a bit over 8 hours and a cpu-usage at 11%. Using mplayer I reached 7.5 hours and the cpu-usage reported as around 2%. So according to battery-life it looks like ogg-vorbis is running almost as good as mp3 even though the ogg-vorbis-plugin don't use the dsp. And according to cpu-usage it looks like we can't trust the reported values from "top". According to the playback quality the gstreamer plugin plays perfectly in the default media player, but it takes some 1-3 sec before the playback starts, while mp3 playback starts almost immediately. The playback is smooth even when starting some programs. By using another player (youamp) that uses the gstreamer plugin the playback is not smooth when starting some programs. Using gst-launch or mplayer makes the playback start almost immediately, but playback is not smooth when starting some programs. So if Nokia won't release a fully working ogg-vorbis plugin, I think it would be very good if Nokia could help the developers of the ogg-vorbis plugin in extra-devel. The only things missing is a fix for the 1-3 sec playback lack, and information to the developers of other media players about how Maemo's default media player makes the playback completely smooth - is it usage of realtime priority or something else?
(In reply to comment #117) > So according to battery-life it looks like ogg-vorbis is running almost as good > as mp3 even though the ogg-vorbis-plugin don't use the dsp. And according to > cpu-usage it looks like we can't trust the reported values from "top". That's very interesting. Finally somebody decided to don't speculate and do the job. Just because the software happens to run on the DSP doesn't mean it's efficient. And quite frankly I bet any decent open source development would beat the DSP codecs (for audio). > So if Nokia won't release a fully working ogg-vorbis plugin, I think it would > be very good if Nokia could help the developers of the ogg-vorbis plugin in > extra-devel. The only things missing is a fix for the 1-3 sec playback lack, > and information to the developers of other media players about how Maemo's > default media player makes the playback completely smooth - is it usage of > realtime priority or something else? 1-3 sec playback lack?
(In reply to comment #117) > I just wanted to add that I have run some tests. On my device (N810) using the > standard media player I have played mp3 continuously for 9 hours on a fully > loaded battery. According to "top" the cpu-usage was around 2-3%. I ran the > same test with ogg-vorbis-files and reached 8 hours before the the battery was > reported low. The cpu-usage was around 20%. I also tried ogg-vorbis with > gst-launch and reached a bit over 8 hours and a cpu-usage at 11%. Using mplayer > I reached 7.5 hours and the cpu-usage reported as around 2%. > The reason why vorbis decoding don't demands much processor power may be associated by the fact that Tremor ( http://en.wikipedia.org/wiki/Tremor_(software) ) implementation is fully fixed point instead of floating point such as in the regular libvorbis implementation. Good news it to know that it won't affect battery consumption that much.
I remember reading somewhere that Vorbis had a lower computational decoding cost than MP3 (but higher memory usage). Following that, I decided to test for myself using well used implementations... I encoded a wav file into a Vorbis and MP3 at 128 kbit/s ABR, I then decoded them without any output device using mpg123 and ogg123. Here are the results (for a single run, but the numbers are typical): time mpg123 -t test.wav.mp3 : real 0m2.336s user 0m2.312s sys 0m0.020s time ogg123 -q -d null test.ogg : real 0m2.105s user 0m2.040s sys 0m0.020s Ogg does indeed require about 10% less cpu time than MP3 to decode (using mainstream implementations). Should this not translate into a 10% saving in battery?
(In reply to comment #119) > The reason why vorbis decoding don't demands much processor power may be > associated by the fact that Tremor ( > http://en.wikipedia.org/wiki/Tremor_(software) ) implementation is fully fixed > point instead of floating point This is just one of the popular maemo myths > such as in the regular libvorbis implementation. Yes, regular libvorbis implementation is very slow, and this is not directly related to the fact that it is using floating point. See http://en.wikipedia.org/wiki/Vorbis and http://xiph.org/minutes/2006/10/200610_meeting.txt which is linked from it. > Good news it to know that it won't affect battery consumption that much. This is not surprising at all. It would be also interesting to test power consumption with ARM core forced to run at 165MHz. Additionally it may be interesting to test a setup with ARM side ALSA driver and DSP completely shut down (though it may be not so trivial and less usable in practice).
(In reply to comment #121) > Yes, regular libvorbis implementation is very slow, and this is not directly > related to the fact that it is using floating point. See > http://en.wikipedia.org/wiki/Vorbis and > http://xiph.org/minutes/2006/10/200610_meeting.txt which is linked from it. Here is the relevant quote to save time: "<xiphmont> There's a third thing that's not in there Vorbis related, ad that is replacing reference decode with Tremor, which is now the better decoder. <xiphmont> Item after: <jmworx> But isn't tremor fixed-point only? <xiphmont> Trac. <xiphmont> oops, popping back <xiphmont> Tremor is a different decode architecture. It is not wedded to fixed-point and in fact the reference replacement would go back to float. <jmworx> I assume it would be slower on a general-purpose CPU... or maybe I'm missing something <jmworx> Oh, I thought Tremor was just a fixed-point port of the reference decoder. <xiphmont> So, no, reference would not be replaced by a fixed-point version. It would be replaced by a float-version Tremor. <xiphmont> Tremor forked mightily."
(In reply to comment #121) > (In reply to comment #119) > > The reason why vorbis decoding don't demands much processor power may be > > associated by the fact that Tremor implementation is fully fixed > > point instead of floating point > > This is just one of the popular maemo myths All of the mentioned citations seem to say that yes, Tremor is fixed point, but it could be modified to use floating point if it were adopted as the reference decoder. There was nothing there to imply that this is a myth of some sort.
(In reply to comment #123) > (In reply to comment #121) > > (In reply to comment #119) > > > The reason why vorbis decoding don't demands much processor power may be > > > associated by the fact that Tremor implementation is fully fixed > > > point instead of floating point > > > > This is just one of the popular maemo myths > > All of the mentioned citations seem to say that yes, Tremor is fixed point, but > it could be modified to use floating point if it were adopted as the reference > decoder. There was nothing there to imply that this is a myth of some sort. The myth is that floating point unit is slow in N800/N810 tablets. Its origin AFAIK was the old comparison of tremor and libvorbis performance. This comparison is naturally invalid because tremor is not just a fixed point version of libvorbis, but a new improved implementation with many other changes. If one wants to benchmark a good floating point vorbis decoder, it is better to take ffvorbis.
Just a quick update. Maemo 5 and the N900 won't play Ogg codecs out of the box but All the related components are open source and there are enough interested upstream developers involved... that happen to have good access to the latest Maemo releases and hardware: GStreamer, Media Application Framework and Tracker running on the N900. We are helping the Ogg Support community project, that has started putting the pieces together. An experimental proof of concept exists, playing Ogg Vorbis properly with good integration with the Media Player. Done for fun in pure OSS R&D mode. With all this, it looks like Ogg Support will be available from maemo.org Extras by the time the N900 starts shipping. This shows progress compared to previous Maemo releases, thanks to the fact that all the technologies involved are now OSS and publicly released. And we still hope to improve this situation in Harmattan. Thanks again for the understanding in this bug report. As you see, the silence in the past months was not a problem to keep the ball rolling. Let's see how far it gets. :)
With regard to the N900 and Maemo5/Fremantle: "ogg-support 1.0.2" is now available in extras-testing repository.
(In reply to comment #126) > With regard to the N900 and Maemo5/Fremantle: > "ogg-support 1.0.2" is now available in extras-testing repository. It's not meant for extras yet.
Created an attachment (id=1519) [details] With current ogg support, this video won't play on the device (but plays on the desktop)
(In reply to comment #128) > Created an attachment (id=1519) [details] [details] > With current ogg support, this video won't play on the device (but plays on the > desktop) > This video won't be played by the device even if it was in other codec. Come on, it's a 1680x1040 video.
http://www.motorola.com/Consumers/US-EN/Consumer-Product-and-Services/Mobile-Phones/ci.Motorola-DROID-US-EN.alt PLAYABLE FORMATS: AAC, H.263, H.264, MP3, MPEG-4, WAV, WMA, eAAC+, OGG, AMR WB, AMR NB, AAC+, MIDI Although they don't say which codecs they support inside the Ogg container..
(In reply to comment #126) > With regard to the N900 and Maemo5/Fremantle: > "ogg-support 1.0.2" is now available in extras-testing repository. > Is it possible to add ogg support to SDL/pygame too? I am trying to get Frets-On-Fire running on n900. I can run it nicely when ogg music files are converted to WAV. But WAV files are insanely huge and take eternity to load. Today I converted the files to mp3 format, but pygame.mixer gives error with mp3 format too. In pygame's docs (http://www.pygame.org/docs/ref/music.html) I read the warning: "Be aware that MP3 support is limited". I can open a separate bug for it if necessary. Please let me know.
(In reply to comment #131) > (In reply to comment #126) > > With regard to the N900 and Maemo5/Fremantle: > > "ogg-support 1.0.2" is now available in extras-testing repository. > > > > Is it possible to add ogg support to SDL/pygame too? > > I am trying to get Frets-On-Fire running on n900. I can run it nicely when ogg > music files are converted to WAV. But WAV files are insanely huge and take > eternity to load. Today I converted the files to mp3 format, but pygame.mixer > gives error with mp3 format too. In pygame's docs > (http://www.pygame.org/docs/ref/music.html) I read the warning: "Be aware that > MP3 support is limited". > > I can open a separate bug for it if necessary. Please let me know. > I think you would need to rebuild the sdl libs after the ogg support has been installed. the gstreamer ogg plugins use normal libraries and hopfully sdl uses the same. Not sure if that is the case for the integer vorbis decoder.
A new bug report against something else should be filed for this. (In reply to comment #132) > I think you would need to rebuild the sdl libs after the ogg support has been > installed. the gstreamer ogg plugins use normal libraries and hopfully sdl uses > the same. Not sure if that is the case for the integer vorbis decoder. Currently ogg-support depends on the floating point libvorbis from xiph.org and a wild guess is that the sdl would use the same. I'm planning to change that dependency to ffmpeg later. And in anyway the sdl should depend on the exact library instead of ogg-support.
I installed ogg-support and it works just fine. Perhaps this bug should be renamed "Ogg Vorbis support out-of-the-box". And why not? Geez, just for supporting wikipedia alone is good enough reason. I can't imagine what kind of backlash you'd get from supporting something that probably all of your active users clearly want. Also, Version: could be updated to 5.0/(2009.42.11).
We need to clarify this. If the bug is "ogg vorbis support" then we already do this (as a 3rd party plugin), so this is FIXED. If the bug is "ogg vorbis support out of the box" then this is clearly WONTFIX, and should be cloned for Maemo 6.
Er, I didn't mean to change the version. But since we are already on it... updating to the latest Maemo5.
Here we don't clone to close bugs, so it's ok to leave this open. Over time the request and dciscussion has really gone around official support out of the box. Didn't happen in Fremantle, let's see Harmattan.
(In reply to comment #137) > Here we don't clone to close bugs, so it's ok to leave this open. Over time the > request and dciscussion has really gone around official support out of the box. > Didn't happen in Fremantle, let's see Harmattan. Too bad all the hard work done in Fremantle to support Vorbis properly as a third party plugin doesn't deserve a bug closed in maemo bugzilla. Oh well, updating bug metadata accordingly.
(In reply to comment #138) > Too bad all the hard work done in Fremantle to support Vorbis properly as a > third party plugin doesn't deserve a bug closed in maemo bugzilla. Oh well, > updating bug metadata accordingly. At least now there's a new product in bugs.maemo.org: "Extras" -> "Ogg Support"
(In reply to comment #138) > (In reply to comment #137) > > Here we don't clone to close bugs, so it's ok to leave this open. Over time the > > request and dciscussion has really gone around official support out of the box. > > Didn't happen in Fremantle, let's see Harmattan. > > Too bad all the hard work done in Fremantle to support Vorbis properly as a > third party plugin doesn't deserve a bug closed in maemo bugzilla. Oh well, > updating bug metadata accordingly. Do you really want to waste all the votes and publicity this bug got? ;-) >
(In reply to comment #140) > (In reply to comment #138) > > Too bad all the hard work done in Fremantle to support Vorbis properly as a > > third party plugin doesn't deserve a bug closed in maemo bugzilla. Oh well, > > updating bug metadata accordingly. > > Do you really want to waste all the votes and publicity this bug got? ;-) You can keep all the information in a clone, including the votes, no? Besides, some people voted for a "ogg vorbis support" and some people voted for "ogg vorbis support out of the box". Moreover, by saying "if we close this bug since ogg vorbis support works fine, then all the votes would be lost", you are dismissing all that the work into making ogg vorbis work seamlessly on Maemo 5.
Felipe, trust me when I tell you that I wish to close this bug just as much as you. :) If we close them thanks to a community app then people will get the conclusion that we won't fix "the root issue" ever, which most people CCed here probably think that is shipping Ogg Vorbis support out of the box. http://maemo.org/downloads/product/Maemo5/ogg-support/ is great and you or someone could explain somewhere the pieces that have been improved in order to offer such a good and well integrated solution. Still, we are working to see if we can offer Ogg Vorbis support out of the box in Harmattan. Keeping this bug open reminding us is useful.
(In reply to comment #142) > Felipe, trust me when I tell you that I wish to close this bug just as much as > you. :) If we close them thanks to a community app then people will get the > conclusion that we won't fix "the root issue" ever, which most people CCed here > probably think that is shipping Ogg Vorbis support out of the box. > > http://maemo.org/downloads/product/Maemo5/ogg-support/ is great and you or > someone could explain somewhere the pieces that have been improved in order to > offer such a good and well integrated solution. > > Still, we are working to see if we can offer Ogg Vorbis support out of the box > in Harmattan. Keeping this bug open reminding us is useful. Let me repeat my proposal; clone to bug so that we have: 1) Ogg vorbis support 2) Ogg vorbis support out of the box Both bugs would be identical (same number of votes), the first one would be closed as FIXED in Maemo 5, and the second one would be kept open for Maemo 6 (or later). Then we would have the best of both worlds: an important bug closed, and an important bug still open. AFAICS your reply doesn't apply to my proposal. Following this logic if we ship "Ogg Vorbis support out of the box" on Maemo 6 but it turns out the performance is much worst than MP3 then people would say, oh, wait, that's not what we meant, and the bug would mutate yet again to "Ogg Vorbis support out of the box with decent performance", and yet again all the work done in Maemo 6 will not be enough to close this bug. But in any case, it seems cloning bugs is frowned upon in bugs.maemo.org; which means we cannot have what is IMHO the ideal situation... whatever.
I'm happy to resolve this old request as FIXED. The Harmattan plans include Ogg Vorbis support and you can follow the progress at http://maemo.gitorious.org/maemo-multimedia Thank you very much to everybody involved!