Phonon/Akademy2012BoF: Difference between revisions
< Phonon
Casianandrei (talk | contribs) (→Agenda) |
No edit summary |
||
Line 13: | Line 13: | ||
** Phonon Encoder, formats, api | ** Phonon Encoder, formats, api | ||
** Capture issues | ** Capture issues | ||
= Notes = | |||
* Qt-project.org | |||
** Tabled for now, revisit in a few months if the CLA changes | |||
** Where to get Phonon for Qt5 | |||
*** Won't be part of 5.0, will be available soon after | |||
** Source code compatability | |||
== Current Issues == | |||
* State machine | |||
** Something linear like GStreamer's | |||
** Separate error reporting | |||
* KDELibs: Can't use phonon because when you press play, the decoding is done again, makes it impossible for small sound samples. | |||
** tdfischer's sample cache API | |||
* aboutToFinish Signal | |||
* Which level does phonon even live at? | |||
** Higher level: queue these things and play them | |||
** Lower level: mixer API? sound sample cache API? | |||
** Split the queueing stuff into a separate MediaQueue class, limiting the MediaObject to single playback only | |||
** Volume controls: exactly one application needs it, shouldn't have it | |||
*** Volume keys sometimes results in two volume OSDs: one from Phonon/Amarok, one from KMix. | |||
*** Quicktime: Only soft volume, DirecShow: Only soft volume | |||
*** Should only control the application volume, as players expect a volume control. '''No hardware mixers'''. | |||
**** todo: review volume control guidelines for gnome, windows, etc | |||
*** You should only want to change the volume you are outputting to the sink | |||
* Crossfading? Yes, but low priority. | |||
* Playback rate. Yes, it is trivial to implement. Maybe an option to keep the pitch. | |||
* Inserting/removing devices is pretty common. | |||
* Effects API? | |||
** Do we need a generic effects API? | |||
** Equalizer is needed. Perhaps thats all we need. | |||
* Graph structure is broken. Very broken. Stop laughing. Having an API to do a graph about frameworks that do graphs in different ways is dumb. Only GST seems to have a proper graph. Quicktime is weird, DirecShow is not a graph. | |||
** <j-b> Remove the graph. If you need it, phonon is not right. | |||
** What isn't using phonon and why? | |||
*** Telepathy, which is using GStreamer | |||
*** Games don't use it because it is pretty high latency | |||
*** Kamoso: No capture support | |||
*** k3b: Only used for previews, not transcoding | |||
*** kdenlive: very specialized | |||
*** WebKit: Replaced phonon with QtMMKit, then moved to GStreamer | |||
*** Lots of other apps actually do use it (KTorrent, Digikam, Gwenview) | |||
== On Windows == | |||
* They use the VLC backend, works great. | |||
* Building, distribution? DirectShow is dead. Don't need it - VLC works! ^^ | |||
* GStreamer is a pain to build on Windows and distribute due to the big GTK stack. VLC is just one neat package and statically built. | |||
== Capture API == | |||
* We don't have any encoders | |||
** You capture media but its useless. | |||
** Probably impossible to have an encoding API | |||
** Might be implemented after we have capturing, which itself would be implemented after the phonon 5 release. | |||
* DVB support will be needed | |||
** | |||
* Current API is acceptable, no really big modifications needed. | |||
=== Possible encoding API === | |||
* Capture will remain useless until we have an encoding API. | |||
** Mimetimes, lol. | |||
** Encoders stream into a Container device, which is a QIODevice (or streams into one) | |||
** Few encoder options as possible: bitrate, quality (0-100), | |||
* Only a handful of codecs: Maybe 4 audio, 3 useful video. Everything else is silly and useless. | |||
* "Play" or "Transcode" | |||
* Decoding, maybe, for finding fingerprints or visualizations | |||
We need a fluffy object. It outputs unicorns. | |||
= Phonon 5 Priorities = | |||
# Drop as much as we can | |||
# Don't break source compatability as much as possible |
Revision as of 11:33, 2 July 2012
We've planned a small BoF for Akademy 2012. You can view the schedule at Akademy/2012/Monday.
Agenda
- Qt5 and Phonon
- Integration with Qt5
- Discussion about qt-project.org
- Windows
- Phonon 5
- Current Issues
- Phonon 5 preliminary designing
- Capture, Recording
- Phonon Encoder, formats, api
- Capture issues
Notes
- Qt-project.org
- Tabled for now, revisit in a few months if the CLA changes
- Where to get Phonon for Qt5
- Won't be part of 5.0, will be available soon after
- Source code compatability
Current Issues
- State machine
- Something linear like GStreamer's
- Separate error reporting
- KDELibs: Can't use phonon because when you press play, the decoding is done again, makes it impossible for small sound samples.
- tdfischer's sample cache API
- aboutToFinish Signal
- Which level does phonon even live at?
- Higher level: queue these things and play them
- Lower level: mixer API? sound sample cache API?
- Split the queueing stuff into a separate MediaQueue class, limiting the MediaObject to single playback only
- Volume controls: exactly one application needs it, shouldn't have it
- Volume keys sometimes results in two volume OSDs: one from Phonon/Amarok, one from KMix.
- Quicktime: Only soft volume, DirecShow: Only soft volume
- Should only control the application volume, as players expect a volume control. No hardware mixers.
- todo: review volume control guidelines for gnome, windows, etc
- You should only want to change the volume you are outputting to the sink
- Crossfading? Yes, but low priority.
- Playback rate. Yes, it is trivial to implement. Maybe an option to keep the pitch.
- Inserting/removing devices is pretty common.
- Effects API?
- Do we need a generic effects API?
- Equalizer is needed. Perhaps thats all we need.
- Graph structure is broken. Very broken. Stop laughing. Having an API to do a graph about frameworks that do graphs in different ways is dumb. Only GST seems to have a proper graph. Quicktime is weird, DirecShow is not a graph.
- <j-b> Remove the graph. If you need it, phonon is not right.
- What isn't using phonon and why?
- Telepathy, which is using GStreamer
- Games don't use it because it is pretty high latency
- Kamoso: No capture support
- k3b: Only used for previews, not transcoding
- kdenlive: very specialized
- WebKit: Replaced phonon with QtMMKit, then moved to GStreamer
- Lots of other apps actually do use it (KTorrent, Digikam, Gwenview)
On Windows
- They use the VLC backend, works great.
- Building, distribution? DirectShow is dead. Don't need it - VLC works! ^^
- GStreamer is a pain to build on Windows and distribute due to the big GTK stack. VLC is just one neat package and statically built.
Capture API
- We don't have any encoders
- You capture media but its useless.
- Probably impossible to have an encoding API
- Might be implemented after we have capturing, which itself would be implemented after the phonon 5 release.
- DVB support will be needed
- Current API is acceptable, no really big modifications needed.
Possible encoding API
- Capture will remain useless until we have an encoding API.
- Mimetimes, lol.
- Encoders stream into a Container device, which is a QIODevice (or streams into one)
- Few encoder options as possible: bitrate, quality (0-100),
- Only a handful of codecs: Maybe 4 audio, 3 useful video. Everything else is silly and useless.
- "Play" or "Transcode"
- Decoding, maybe, for finding fingerprints or visualizations
We need a fluffy object. It outputs unicorns.
Phonon 5 Priorities
- Drop as much as we can
- Don't break source compatability as much as possible