We've planned a small BoF for Akademy 2012. You can view the schedule at Akademy/2012/Monday.
- Qt5 and Phonon
- Integration with Qt5
- Discussion about qt-project.org
- Phonon 5
- Current Issues
- Phonon 5 preliminary designing
- Capture, Recording
- Phonon Encoder, formats, api
- Capture issues
- 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
- 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)
- 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.
- 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
- * Replace some things with dummy functions, and mark them deprecated (to be removed later?)
- Simple playback
- * Remove the connect stuff, in the MediaObject, something like setOutput(). The connect() function redirects to that.
- Playback rate
- Volume on outputs
- Eq. API, directly on the MO.
- Sound sample API
- # Audio capture
- # Video
- KIO input for VLC
- KIO input for GStreamer
- Our apps are really nice already
This page was last edited on 2 July 2012, at 11:46. Content is available under Creative Commons License SA 4.0 unless otherwise noted.