476035 - Odd sequence of duplicate progress events immediately after a seek

Status: RESOLVED INVALID

(Core :: Audio/Video, defect, P2)

Description

[Justin Dolske [:Dolske]]

I see unexpected |progress| events after a seek is triggered...

EG, loading http://tinyvid.tv/show/t5v1inpguy9t, I initially get:

...
videoctl: Got progress media event
videoctl: +++ load, 28163892 of 28826786
videoctl: Got progress media event
videoctl: +++ load, 28475212 of 28826786
videoctl: Got progress media event
videoctl: +++ load, 28721372 of 28826786
videoctl: Got progress media event
videoctl: +++ load, 28826786 of 28826786

If I then click to invoke a seek, the video starts downloading again (in part due to bug 473107 et al).

I first get a few dozen repeated 100% events. This is not expected:

videoctl: Got progress media event
videoctl: +++ load, 28826786 of 28826786
videoctl: Got progress media event
videoctl: +++ load, 28826786 of 28826786
videoctl: Got progress media event
videoctl: +++ load, 28826786 of 28826786
videoctl: Got progress media event
videoctl: +++ load, 28826786 of 28826786
...

Eventually it jumps back down to a sensible value, a |timeupdate| event is fired, and then a normal sequence of |progress| events as the download finishes:

...
videoctl: Got progress media event
videoctl: +++ load, 28826786 of 28826786
videoctl: Got progress media event
videoctl: +++ load, 3245916 of 28826786
videoctl: Got timeupdate media event
videoctl: time update @ 31370ms of 312875ms
videoctl: Got progress media event
videoctl: +++ load, 3315420 of 28826786
videoctl: Got progress media event
videoctl: +++ load, 3843940 of 28826786
videoctl: Got progress media event
videoctl: +++ load, 4715636 of 28826786
...

Comment 1

[cajbir (:cajbir)]

The 100% events are the result of seeking to find the duration, which seeks to the end of the file. The events are supposed to be suppressed during this time but it appears to not be happening.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Bug 455654 changes that, so let's see if it fixes it.

Comment 3

[Justin Dolske [:Dolske]]

Nope, same thing happens.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fixed now?

Comment 5

[Justin Dolske [:Dolske]]

Well... I don't see 100% progress events now. But seeking forward into a section of a video that hasn't been buffered yet does result in duplicate progress events being fired, in a similar fashion:

videoctl: Got media event ----> progress
videoctl: +++ load, 8450048 of 35154877
videoctl: +++ seeking to 278.36
videoctl: Got media event ----> seeking
videoctl: Delaying status fade-in...
videoctl: Got media event ----> progress
videoctl: +++ load, 10678272 of 35154877
videoctl: Got media event ----> progress
videoctl: +++ load, 10743808 of 35154877
videoctl: Delated start timer fired.
videoctl: Fading status in
videoctl: Got media event ----> progress
videoctl: +++ load, 10743808 of 35154877
videoctl: Got media event ----> progress
videoctl: +++ load, 10743808 of 35154877
videoctl: Got media event ----> progress
videoctl: +++ load, 10743808 of 35154877
videoctl: Got media event ----> progress
videoctl: +++ load, 10743808 of 35154877
videoctl: Got media event ----> progress
videoctl: +++ load, 10743808 of 35154877

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK. I think this isn't really a bug. With the media cache, we can have arbitrary regions of data cached, and the "progress amount" is just a synthetic number we calculate --- it's just the amount of data we have cached starting at the current stream reader position. So it's perfectly possible to read data into the cache and have that number not change. So I'll take the liberty of resolving this as INVALID.

Comment 7

[Justin Dolske [:Dolske]]

As far as out controls go, I guess that's fine. The duplicates don't hurt anything.

But I think it is technically a spec violation, which says progress events should be fired "every 350ms (±200ms) or for every byte received, whichever is least frequent".

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We're receiving bytes, they're just not adding to the progress total. I agree this is somewhat bogus, but trying to expose a "N out of N" progress count when we're doing all kinds of random access is inherently bogus.