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
* 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.
QML!!!!1!
Playback rate
Volume on outputs
Eq. API, directly on the MO.
Sound sample API
AudioDataOutput
VideoDataOutput
Capture
# Audio capture
# Video
Encoding
Crossfading

KDEMM Banter

KIO input for VLC
KIO input for GStreamer
Our apps are really nice already