Bug 159458

Summary: [GStreamer] duration query improvements
Product: WebKit Reporter: Philippe Normand <pnormand>
Component: PlatformAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: calvaris, cgarcia, pnormand, zan
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
patch none

Philippe Normand
Reported 2016-07-06 02:15:47 PDT
Currently the player caches the result of the duration query but this is overkill because it's cached by playbin already. The only time where the player needs to cache the duration is when EOS was reached because in that situation the query would fail.
Attachments
patch (11.03 KB, patch)
2016-07-06 02:28 PDT, Philippe Normand 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Philippe Normand
Comment 1 2016-07-06 02:28:48 PDT
Created attachment 282866 [details] patch
Xabier Rodríguez Calvar
Comment 2 2016-07-06 04:24:06 PDT
Comment on attachment 282866 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=282866&action=review > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:521 > + m_durationAtEOS = 0; Why do you need this?
Philippe Normand
Comment 3 2016-07-06 06:28:32 PDT
Committed r202857: <http://trac.webkit.org/changeset/202857>
Philippe Normand
Comment 4 2016-07-06 07:37:34 PDT
Comment on attachment 282866 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=282866&action=review >> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:521 >> + m_durationAtEOS = 0; > > Why do you need this? For no good reason it seems :)
Xabier Rodríguez Calvar
Comment 5 2016-07-06 07:57:21 PDT
Comment on attachment 282866 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=282866&action=review >>> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:521 >>> + m_durationAtEOS = 0; >> >> Why do you need this? > > For no good reason it seems :) Well, I guess it is correct to assume that if you are seeking and the end is not reached as it is set in like 520, considering the new paradigm of not caching the duration until the playback ends, we should not have a valid value here.
Note You need to log in before you can comment on or make changes to this bug.