Phonon/Akademy2012BoF: Difference between revisions

From KDE Community Wiki
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

  1. Drop as much as we can
  2. Don't break source compatability as much as possible