[webkit-gtk] webRTC discussion.
philn at igalia.com
Tue Jun 19 11:21:04 PDT 2012
We discussed about this on IRC, here's the log:
19:56:05 < philn> danilocesar: it's a bit sad to see a new player
duplicating chunks of the current one
19:57:16 < philn> i think i prefer the supportsType(url, type,
codec) approach. Updating the other player implementations should
19:57:41 < daniloces> philn: but merging both (to keep only one player)
will create a huge/ugly monter... they share basically API,
most of the internal code is different
19:58:11 < mrobinson> danilocesar: Certainly there's a way to share
code between them without duplicating it?
19:58:12 < danilocesar> is a low price to keep the code elegant
20:01:08 < philn> one option would be a base class sharing the
common code and 2 sub-classes
20:05:02 < philn> i don't think the adding url in ::supportsType()
will face a lot of opposition. the ENCRYPTED_MEDIA case is
definitely a more controversial approach :)
20:08:30 < daniloces> philn: sure. I can work on something... I will
work on a decent supportsType commit and push it for review...
for the two players code base, I can do it when
I'm ready to push the StreamMediaPlayer
On 2012-06-19 18:33, Danilo Cesar wrote:
> Hi guys,
> In our work to push the WebRTC implementation using Farstream we
> decided that we should use another MediaPlayer (which consist on
> adding a new MediaPlayerPrivateInterface class and register as
> But we're having issues on how to identify if we should use this
> player or the gstreamer one, since the
> MediaPlayerPrivateInterface::supportsType(type,codec) doesn't have
> access to the media's url (which is a blob, in the case of the
> As a work around, we've implemented a new method on the
> MediaPlayerPrivateInterface supportsProtocol(url) (you can see on the
> diff ), which responds MediaPlayer::IsSupported if the URL is a
> blob (blob://BLOBHASH) generated by the MediaStream, then a new
> to select it
> I would like to discuss that with you, if it's the best way of doing
> I've also played with an alternative, like adding a new parameter
> (url) to the MPPI::supportsType(url, type, codec) method, than the
> could be used and we stay with the bestMediaEngineForTypeAndProtocol
> However it's a change that affects all ports media players.
> As an option I could add this method on a "#if ENABLE(MEDIA_STREAM)"
> block, so it could be used only by the players using it and keep
> others untouched. It could be a good solution, however
> "ENABLE(ENCRYPTED_MEDIA)" is doing the same trick, so we would end up
> with a MEDIA_STRAM OR ENCRYPTED_MEDIA build, both wouldn't work
> together (not without adding #if ENABLE(MEDIA_STREAM) &&
> ENABLE(ENCRYPTED_MEDIA), which is not elegant ).
> What do you guys think about it?
> Should I try to keep the first or the second option? Or is there even
> a better way to recognize the blob on a MediaPlayerPrivateInterface?
> Danilo Cesar
>  http://pastebin.com/GSkQpQyy
More information about the webkit-gtk