phonon5 and the media sources

[Casian Andrei]

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

>
> I am wondering. Technically that is a SPU that might not be provided
> by the source (e.g. subtitle-from-file), so right now I am actually
> more inclined to say that is an effect applied to the player/output.
> Though that may be confusing from an outside POV, not sure.
>
What is a SPU?  Synergistic Processor Unit? :)

>
> For example an AbstractMediaStream source would not have a url, so
> using the url source as base makes no sense IMO.
>
Forgot about the AbstractMediaStreams...

>
> you then need to manually figure out what source that is by casting like
> mad.
> for example if you need to check that ::source == what you expect it
> to be you need
> if cast<UrlSource>(::source())
>   if (cast<UrlSource>(::source()).url == m_url)
>     doStuff()
>
Yep, I was figuring those could by bypassed by some convenience functions.

>
> so, I am not convinced we'd want to go for that. off the top of my
> head here are some other approaches:
>
> all assume one single Source class with a bunch of ctors for all
> things you can use as a source.
>
> a) Source has QList<ControlUnit *> ::controlUnits();
> a control unit basically is what the MediaController was, but acting
> on a Source rather than a Player.
> ControlUnits again use subclassing such that you get
> VideoSourceControl, DeviceSourceControl etc.
> using this you still need to cast if you want to use control units,
> BUT you do not if you do not want to which is quite the improvement.
>
> b) you can decorate/attach a Source with a control unit, this is
> mostly the inverse of a
> this is even closer to the MC thing we had before instead of getting
> units supplied by
> the Source instance the developer creates their own e.g.
>   VideoSourceControl control(source);
>   if (control.isActive()) // false if the source does not support a VSC
>     control.setChapter(0);
> this completely eliminates casting and assuming an application created
> a source with /dev/dvd or whatever it supposedly knows what control
> unit *should* be supported.
>
> b is actually what I prefer right now because it is what we intend to
> do with effects.
>
b looks better for me too

>
> > * The backends can set source validity to false if they don't like it
>
> Actually I think with both source subclasses or units we'd want two
> different properties here.
>
> isValid() // whether the source was constructed from lead to a valid
> source.... e.g. construction from invalid URL leads to an invalid
> source in libphonon already
>
> canBePlayed() // whether the source can be played by the backend, e.g.
> if a MedisStream source is valid but the backend has no streamreader
> it cannot be played but is still valid
>
> ^ the last property actually needs some larger considerations as
> mimetype crap is going away and should be replaced with some reliable
> low-resource runtime check for supportedness. so canBePlayed for
> example would create a tiny pipeline and push the source in without
> outputs and fast processing; if it doesn't go into error state the
> file can be played.
>
Ok, looks good.

>
> > * The backends might be able to provide info about what kind of source is
> > for a URL
>
> Not sure what you mean.
>
You  give the backend an URL, and it sais - dude this is a DVD, or dude
this is a hardware device, or dude this is a ordinary file. I think this is
no longer valid with the new approach, since we assume the application
always knows what's playing and won't try to control a microphone with a
VideoSourceControl.

With this approach, is an application able to show menus specific for DVD's
only when playing a DVD? Or buttons configuring subtitles only when playing
videos? Or other things like this? It must know what kind of media it
plays, but what if the developer is too lasy to implement such a thing? "I
want my player to play everything and always know what's playing! Quickly,
1h development time!"

Do we need to cover that use case?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20131020/b1e7b7b1/attachment.htm>
-------------- next part --------------
_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia