1190377 - html5 video elapsed time ends with wrong value

Status: RESOLVED DUPLICATE of bug 1180214

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

Description

[u123541]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20150725030209

Steps to reproduce:

Play an HTML5 video.


Actual results:

The time scale appears when hovering over the video, and shows progress.  When the video ends, the time is some [random?] value larger than the actual time.  The video I watched this time is 3:17 long; yet the end times seen were 31:26 and 4:00.  Trying to save time analyzing what might be happening, discovered that starting the video and moving the slider to near the end, the ending value is correct.  So it appears the video must be played in its entirety to see the bug.
Will add a shorter video link when I find one:
 http://cl.exct.net/?qs=8bb6e650d97df930d86294647b064f816995a4cf07f4c7ad903b4f4481f4a39d

On videos that end then display a panel of other videos (generally from youtube), the time scale appears to show only partial progress; as though it's assuming the time scale includes subsequent videos.


Expected results:

Display correct elapsed time.

Comment 1

[Chris Peterson [:cpeterson]]

Pierre, so the problem only in the reported time? Were the audio and video still synchronized at the end of the video? Is this a new bug?

Are you using GStreamer to decode the video? I don't see the problem on OS X.

Comment 3

[u123541]

(In reply to Chris Peterson [:cpeterson] from comment #1)
> Pierre, so the problem only in the reported time? 
Just tried several times to access the above video (3:17). I'm getting different results each time; but after a few tries, it then starts acting correctly...  Confusing...

Sometimes, I see the times as play/length.  As play increases, so does length; but it keeps going beyond the real length.

[ARGH...  just right clicked on another video and FF hung.]
 
> Were the audio and video still synchronized at the end of the video?
Yes.

> Is this a new bug?
I've been seeing "something wrong" with the times for a while; but didn't find the time to report until now.

> Are you using GStreamer to decode the video? I don't see the problem on OS X.
How do I tell?
lsof reports /usr/lib64/libgstreamer-0.10.so.0.30.0

Comment 4

[Jean-Yves Avenard [:jya]]

(In reply to Pierre Fortin from comment #3)
> (In reply to Chris Peterson [:cpeterson] from comment #1)
> > Pierre, so the problem only in the reported time? 
> Just tried several times to access the above video (3:17). I'm getting
> different results each time; but after a few tries, it then starts acting
> correctly...  Confusing...

It would behave properly once everything is in the data cache.

You probably will find that if you cleared the cache, the wrong behaviour will occur again.
Would be interesting for you to report if that's the case: as it would confirm my theory

Comment 5

[u123541]

Why was this closed as Resolved/Invalid with no explanation?

Cleared the cache -- 350MB -> 3.3MB

Video https://www.youtube.com/watch?v=opdXxpP67-A starts correctly with 0:00/1:49. When it gets to 0:03, the right counter starts to increment until it reaches 13:39.  When the video ends at 1:49, it jumps to 13:39/13:39.

Comment 6

[Jean-Yves Avenard [:jya]]

(In reply to Pierre Fortin from comment #5)
> Why was this closed as Resolved/Invalid with no explanation?

you closed it in comment 3!!!

Comment 7

[u123541]

Forgot to mention: the time scale scales to match the 2nd value which causes the actual video scale to be shorter.  Moving mouse over scale shows thumbnails up to the real end value; anything to the right just shows the final frame -- in comment 5, that means 1:49 thru 13:39 show the frame from 1:49. So the problem affects the timescale usability.

Comment 8

[u123541]

(In reply to Jean-Yves Avenard [:jya] from comment #6)
> you closed it in comment 3!!!

Oh great! Do we have another bug?  That would require accessing 2 dropdowns...  no way I would have done that deliberately...  :(

Comment 9

[u123541]

Actually, comment 3 shows DUPLICATE → INVALID...  The only dropdown choices are UNCONFIRMED & RESOLVED... Ah.....  There's a Mark as Duplicate link immediately below (never used that since, to me, that is a developer/researcher function).  Without actually trying it, wouldn't that link ask for the duplicate's number?

Comment 10

[Jean-Yves Avenard [:jya]]

the email I got when you posted your comment showed:
"
Pierre Fortin <[e-mail]> changed:

          What    |Removed                     |Added
----------------------------------------------------------------------------
        Resolution|DUPLICATE                   |INVALID

--- Comment #3 from Pierre Fortin <[e-mail]> 2015-08-12 16:41:35 PDT ---
(In reply to Chris Peterson [:cpeterson] from comment #1)
"

Now, *I* had marked it as duplicated of bug 1180214 in comment 2.
You changed however that resolution and marked is as invalid in comment 3.

it is a duplicate. So resolving it as such

Comment 11

[u123541]

Sorry for orthogonal comments 5(line1), 6-9 & this one.  Suspect this might have been caused by another bug being tracked at https://bugzilla.gnome.org/show_bug.cgi?id=724200 -- need to logout and login to clear for another ~month of normality. :/

Comment 12

[u123541]

Sorry...  beginning to look like this Status issue is due to "mid-air collisions"...

Comment 13

[Jean-Yves Avenard [:jya]]

it is the same as 1180214