phonon5 and the media sources

[Casian Andrei]

2013/10/25 Harald Sitter <sitter at kde.org>

> 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).
>
Ok. Looks both nice and flexible enough for me.


>
> > 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.
>
Ok.

>
> >  - property (R): bool active
> >  - property (R): source maybe?
>
> What would that be?
>
Source *source() ... but it's kind of irelevant.

>
> >  - 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.
>
Yes, irelevant.

>
> > 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?
>
yes. got confused by the orderings in mediacontroller.h
     - property (R ):  int titleCount
     - property (RW): int currentTitle

> Why is there previous/next? There is no such facility to iter through
> angles or channels...
>
That's what I found in mediacontroller.h, don't know why it is that way.


> >  - 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.
>
Ah, yes, I forgot. So these go away from our VideoSourceControl.


>
> >  - 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.
>
Sure.

>
> > 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?).
>
I still think we need to keep them split up. Imagining a multimedia
application developer, the developer would like to use a streamline low
resolution video feed for his webchat application, or a slowish but high
resolution video feed for his backyard surveillance system. Also, things
that one could possibly change for video differ from audio. Keeping them
separate would allow for greater flexibility for us and a nicer api imo.
But we will see when we get to them, right now it doesn't matter that much.

>
> > class AbstractMediaStreamSourceControl OR MediaStreamSourceControl OR
> > StreamSourceControl (does this make sense?)
> >  - ???
>
> Nothing to control IMO.
>
Great, nothing to implement here :D

>
> > 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.
>
Sure.

I will place review requests before committing anything related to this.

>
> HS
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia at kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20131028/2023cd48/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia