The GStreamer MSE platform implementation needs to report duration changes and trigger monitorSourceBuffers() calls.
Created attachment 290618 [details] Patch
Comment on attachment 290618 [details] Patch For me this is a go unless Eric or Jer say otherwise.
(In reply to comment #2) > Comment on attachment 290618 [details] > Patch > > For me this is a go unless Eric or Jer say otherwise. This is fine with me. But I am curious why the MediaSourcePrivate would want to set the duration rather than its SourceBufferPrivate objects doing so.
Created attachment 291046 [details] Call sequence of MediaSource duration change from MediaSourceGStreamer::durationChanged() (In reply to comment #3) > This is fine with me. But I am curious why the MediaSourcePrivate would want > to set the duration rather than its SourceBufferPrivate objects doing so. MediaSourceGStreamer is our platform implementation of MediaSourcePrivate. MediaSourceGStreamer::durationChanged() is the one reporting the duration change to MediaPlayerPrivateGStreamerMSE (our player private) and the player reports it to MediaSource (seen as MediaSourcePrivateClient by it). See attached call hierarchy snapshot to get it graphically (levels go from callees to callers, two callers at the same level mean they're independent callers). How would the call sequence be for the duration report via SourceBufferPrivate which you suggest?
Aha. I had thought that MediaSource was the only MediaSourcePrivateClient, as the point of the client interface is to avoid having the platform/ have knowledge of dom-level objects. In the Mac port, the MediaSourcePrivate and MediaPlayerPrivate objects talk directly to one another. So when the duration changes, SourceBufferPrivate tells SourceBuffer, who tells MediaSource, who tells MediaSourcePrivate, who tells MediaPlayerPrivate. We did it this way because the duration calculations all happen up in the dom-level MediaSource object. There's no reason why our Private classes have to calculate the duration. So you're welcome to keep using the client interfaces the way you do in this patch, but I'd recommend trying to re-use the dom-level code as much as possible; that way when other ports update that behavior according to newer versions of the spec, your port will. Rendition from that.
Created attachment 291772 [details] Patch
Created attachment 292902 [details] Patch
Comment on attachment 292902 [details] Patch Clearing flags on attachment: 292902 Committed r207889: <http://trac.webkit.org/changeset/207889>
All reviewed patches have been landed. Closing bug.