Alternate media client for UNE ARM
The current video media client, totem, does not take effective advantage of ARM media processing capabilities or resize video well for presentation on netbook screens, and hence may detract from the overall ARM smartbook media experience. There have been several alternate media streaming applications proposed, which need to be investigated. Some are not in our repository currently. Related to this are problems with f-spot and Mono consuming battery life on ARM devices, and at least one of the options proposed may allow elimination of that application as well.
Blueprint information
- Status:
- Not started
- Approver:
- David Mandala
- Priority:
- Medium
- Drafter:
- David Sugar
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Approved
- Series goal:
- Accepted for lucid
- Implementation:
- Deferred
- Milestone target:
- lucid-alpha-3
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
[JamieBennett 10-02-02]: The decision has been made to stay with the media client we have as no other alternative will be available in time for Lucid. In regards to Mono power usage on ARM. Investigations reveal that the Mono garbage collector is run every 8ms thus negating the power-saving features of the ARM architecture.
[dyfet 10-01-20]: it does not appear Canola will be ready in time for Lucid. For this reason, I am, from the perspective of this blueprint, moving all pending Canola items to "POSTPONED". However, I am adding a new task to get canola archived for Lucid, with the intent that we will revisit it again for Lucid+1, as the reasons for choosing Canola remain valid. Canola depends on enlightenment libraries which have to also be archived, but this task would also have existed if we had gone ahead with Canola.
.
With respect to Banshee on arm; it still crashes in Lucid A2, though gdb now provides more meaningful stack traces. However, there remains several additional practical issues including mono runtime issues that effect battery life, which also have not been addressed. My suggestion is to use Rhythmbox for Lucid, mark Banshee as postponed, and move the mono issues to B1, if f-spot is retained. My best recommendation, especially given performance constraints, would be to remove mono entirely and use either gthumb (or the new shotwell package) for photo management, and gnote for note taking for Lucid.
[dyfet 09-12-22]: my own impression with Canola, at least in desktop testing, is rather positive, especially on video playback, and I think users will like it a lot. I do not know if OEM has tried it on arm yet, but I was going to try this if it builds on arm.
[asac 09-12-09]: targeting alpha-3 as this might involve some effort getting canola done; if we drop canola2 from lucid, we can probably move this to alpha-2
[asac 09-12-09]: approved.
Status: To archive canola, but not use in Lucid for this blueprint
Work items lucid-alpha-2:
Estimate effort and expand work items to use Canola2: DONE
[ulissesf] Package Canola2 and deps for Karmic and push into Canola PPA (use new *EFL packages that will be used by netbook-
[ulissesf] Test on Karmic and make sure it launches and works as expected: DONE
[ulissesf] Will make a bzr branch for the snapshot of Canola and upload to Canola LP project: DONE
[jamiebennett] Evaluate Canola2 on a desktop system to get a feel for how it works and what work items below should be addressed: DONE
[jamiebennett] Evaluate Moblin Media Player: DONE
Work items lucid-alpha-3:
[oem-solutions-
[oem-solutions-
[oem-solutions-
[oem-solutions-
[oem-solutions-
[jamiebennett] Decide media player: DONE
Change and Package Selected Player: POSTPONED
[jamiebennett] Investigate Mono Runtime Power Use: DONE
[dyfet] Banshee on ARM: POSTPONED
Update UNE Seed: POSTPONED
Work items ubuntu-
Package and archive etk, python-etk, evas, eina, lightmediascanner, edbus for Canola: DONE
Package and maintain Canola and deps in a ppa: DONE
Status:
Final packaging for canola2 in ppa: https:/
Work Items
Dependency tree
* Blueprints in grey have been implemented.