phonon5 and the media sources

[Harald Sitter]

On Thu, Oct 24, 2013 at 3:07 PM, Casian Andrei <skeletk13 at gmail.com> wrote:
>
> Proposal draft 2
>
> About the Source class and control units:
> A. Source has control units
> B. Can attach control unit to Source
> A or B?

B IMO. Though B can be implemented through A inside the library/backend.

The thing is... from a frontend API POV the difference between A and B is

A:
  Source s;
  foreach (control, s.controls())
     if (qobject_cast<FooControl *>(control))
       qDebug() << "got what we want"

B:
  Source s;
  FooControl control(s); // attached to source now

So B is much nicer. However this has no impact on what is going on
internally, since in either case there needs to be a backing object
implementing the FooControlInterface to make an instance do anything.
But due to the backend separation the backend can be A or B if the
backend lifetime expires the active property simply switches state and
all calls to the control end in

  if (!active)
   return;

Not sure if that made sense, as I had only one cup of coffee, if not
have a look at backendinterface.h

virtual QObject *createObject(Class c, QObject *parent, const
QList<QVariant> &args = QList<QVariant>()) = 0;

In terms of a Source(Control) the createObject function could return a
new object or an existing object or when wanting a SourceControl it
could even return the Source itself (assuming Source : public
FooControl - which probably would be the case for pvlc).

> List of SourceControl classes (pick your preferred names):
> class AbstractSourceControl OR SourceControlUnit OR SourceControl OR
> ControlUnit

SourceControl unless there are going to be pure virtuals.

>  - property (R): bool active
>  - property (R): source maybe?

What would that be?

>  - parented by source?

^ as mentioned above this has no impact on the frontend API. Generally
speaking though whoever controls the lifetime of the backendObject
*must* notify the frontend object (i.e. SourceControl) when the
backendObject is deleted, also see Frontend::isValid.

> class VideoSourceControl
>  - property (R ): QList<enum> availableMenus
>  - property (RW): int currentMenu
>
>  - property (R ): int chapterCount
>  - property (RW): int currentChapter
>
>  - property (R ): int angleCount
>  - property (RW): int currentAngle
>
>  - property (RW): bool autoplayTitlesEnabled
>  - property (RW): bool currentTitle
>  - method: void previousTitle()
>  - method: void nextTitle()

^ missing int titleCount?
Why is there previous/next? There is no such facility to iter through
angles or channels...

>  - property (RW): bool subtitleAutodetectionEnabled
>  - property (R ): QList<Subtitle> availableSubtitles
>  - property (R ): Subtitle currentSubtitle
>  - property (RW): QString subtitleEncoding
>  - property (RW): QFont subtitleFont

May be moving into an effect as mentioned in some other mail.

>  - property (R ): QList<AudioChannel> availableAudioChannels
>  - property (RW): AudioChannel audioChannel

I am wondering if audio only content can have channels too, j-b probably knows.

> class AudioSourceControl
>  - property (RW): int trackNumber
>  - property (R ): int trackCount

For the time being I'd only implement this bugger or a limited version
of the VideoSourceControl as I am not done with replacing
ObjectDescriptions so there is quite some subject to change WRT return
types.

> class VideoDeviceSourceControl
>  - property (RW): VideoCaptureDevice device
>  - property (R ): bool audio
>  - property (RW): VideoRes resolution
>  - ...
>
> class AudioDeviceSourceControl
>  - property (RW): AudioCaptureDevice device
>  - ...

^ Daring thought.. how about *one* DeviceSourceControl?
class DeviceSourceControl
- property (RW): DeviceDescription device
- property(R): QFlags<Content> content /* flags for Audio | Video */

You are the specialist here, but I am wondering if we really need to
split Audio and Video (how often do you actually get to or need to
control the resolution of the input Video?).

> class AbstractMediaStreamSourceControl OR MediaStreamSourceControl OR
> StreamSourceControl (does this make sense?)
>  - ???

Nothing to control IMO.

> After we finish this I will attempt to begin implementing the following
> days. We can still change stuff afterwards.

I do expect quite some change, so keep the actual code backing limited
until we have finalized this please.

HS