< Phonon
Difference between revisions of "Phonon/Akademy2012BoF"
Casianandrei (talk | contribs) (→Agenda) |
|||
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
This page was last edited on 2 July 2012, at 11:33. Content is available under Creative Commons License SA 4.0 unless otherwise noted.