[webkit-gtk] webRTC discussion.

[Philippe Normand]

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
                       be easy
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

Philippe

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
> MediaEngine).
>
> 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
> webrtc).
>
> As a work around, we've implemented a new method on the
> MediaPlayerPrivateInterface supportsProtocol(url) (you can see on the
> diff [1]), which responds MediaPlayer::IsSupported if the URL is a
> blob (blob://BLOBHASH) generated by the MediaStream, then a new 
> method
> to select it
> (bestMediaEngineForProtocolTypeAndCodec).
> I would like to discuss that with you, if it's the best way of doing 
> that.
>
> I've also played with an alternative, like adding a new parameter
> (url) to the MPPI::supportsType(url, type, codec) method, than the 
> URL
> could be used and we stay with the bestMediaEngineForTypeAndProtocol
> untouched.
> 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?
>
> Thanks,
> Danilo Cesar
>
> [1] http://pastebin.com/GSkQpQyy