Phonon/Akademy2012BoF: Difference between revisions

From KDE Community Wiki
No edit summary
No edit summary
 
Line 83: Line 83:
# Drop as much as we can
# Drop as much as we can
# Don't break source compatability as much as possible
# 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
*

Latest revision as of 11:46, 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
  3. * Replace some things with dummy functions, and mark them deprecated (to be removed later?)
  4. Simple playback
  5. * Remove the connect stuff, in the MediaObject, something like setOutput(). The connect() function redirects to that.
  6. QML!!!!1!
  7. Playback rate
  8. Volume on outputs
  9. Eq. API, directly on the MO.
  10. Sound sample API
  11. AudioDataOutput
  12. VideoDataOutput
  13. Capture
  14. # Audio capture
  15. # Video
  16. Encoding
  17. Crossfading

KDEMM Banter

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