[Webkit-unassigned] [Bug 39053] [GStreamer] cache media duration in READY instead of PLAYING

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=39053





--- Comment #11 from Eric Carlson <eric.carlson at apple.com>  2010-09-07 08:22:45 PST ---
(In reply to comment #10)
> (In reply to comment #9)
> 
> > I don't understand why you would *ever* want to suppress the event. If you don't send the event when the duration changes, you won't ever send it unless the duration changes again. 
> > 
> > Why not always send it when m_mediaDuration != previousDuration?
> 
> It is already sent once by the HTMLMediaElement when it reaches HAVE_METADATA. Without using 
> that flag in durationChanged() I can see double emission of the event in 5 media tests at least.

Those darned tests :-). 

The point I was trying to make is that the existing logic makes it possible to miss sending a durationchange event if the reported duration ever changes unexpectedly. For example, the duration of a variable rate mp3 file is only known after looking at every packet so some media engines estimate the duration after looking at a portion of the file and refine the estimate as more data is examined. Even if GStreamer doesn't do this now, relying on the current behavior seems risky

At the very least your comment, "... because it most likely was first sent by the media element ...", is misleading if you mean it always happens.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.