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
_______________________________________________
webkit-gtk mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
