Closed Bug 1144172 Opened 10 years ago Closed 10 years ago

[Youtube][HTML5] Specific video stops at 4 seconds on some hardware

Categories

(Core :: Audio/Video, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1139271
Tracking Status
firefox37 + verified
firefox38 + verified
firefox39 + verified

People

(Reporter: FlorinMezei, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

Reproducible with: - Firefox 37 Beta 6 - BuildID: 20150316202753 - latest Firefox 38 Aurora - BuildID: 20150316202753 - latest Firefox 39 Nightly - BuildID: 20150317030206 Reproducible on: Windows 7 x64 (only on some machines) Steps to reproduce: 1. Open Firefox and open the following youtube video: https://www.youtube.com/watch?v=AYYDshv8C4g. 2. Let the video play without doing anything. Expected results: Video should play without issues. Actual results: Video stops at 4 seconds and displays a spinner. No data seems to be buffered. See attached screenshot taken 3-4 minutes after the video stopped. This is a regression that appeared in Firefox 37 Beta 4. The main suspects seem to be bug 1133634 and bug 1133572. Both fixes landed in Central on February 18, and indeed the issue does not reproduce in Nightly from February 17, but shows in Nightly from February 19. Notes: - Video information: Mime Type: video/mp4; codecs="avc1.4d401e" DASH: yes (134/140) - I can reproduce this 100%, on two specific machines running Windows 7 x64, whenever I open the video after having opened Firefox - sometimes after reload the video works fine - about:media showed the following info (several minutes after video stopped): https://www.youtube.com/watch?v=AYYDshv8C4g mediasource:https://www.youtube.com/20d9534a-186f-42e8-bcfc-5371c55cc5fc currentTime: 4.85297 SourceBuffer 0 start=0 end=4.875895 SourceBuffer 1 start=0 end=5.004988 start=10.01 end=330.329988 Internal Data: Dumping data for reader 15d94da0: Dumping Audio Track Decoders: - mLastAudioTime: 4.852969 Reader 0: 18bc9c00 ranges=[(0.000000, 4.875895)] active=true size=85432 Dumping Video Track Decoders - mLastVideoTime: 3.837166 Reader 0: 1d05ec00 ranges=[(0.000000, 5.004988), (10.010000, 330.329988)] active=true size=5499439
[Tracking Requested - why for this release]: Nominating for tracking since we'll have Youtube HTML5 videos stopping by themselves in some cases
Tracking for 37, 38, and 39. Could this be related to bug 1142901? Edwin and Anthony, bugs you worked on are mentioned here by Florin as possibly affecting this issue, can you take a look? Thanks!
Flags: needinfo?(edwin)
Flags: needinfo?(ajones)
So far this reproduced on 3 separate machines, all running Windows: - Windows 7 x64 - GPU: nVIDIA GeForce GT 610 - Windows 7 x64 - GPU: AMD Radeon HD 5450 - did not reproduce on Ubuntu on the same machine - Windows 8.1 x64 - GPU: AMD Radeon HD 6450 Based on this I would say this is very likely affecting only Windows, and only some Windows machines. It doesn't seem specific to one Windows version, and doesn't seem to be specific to a certain video card model (since it reproduces on both AMD and NVIDIA). I'm really not sure what the 3 environments (that this reproduces on) have in common, and is at the same time different from the other environments where we do not see the issue. I'm not sure whether this is related to bug 1142901, since I cannot reproduce the issues mentioned there on either Windows or Mac so far.
Regression range: http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=52600b8172cf&tochange=68707623b5a3 If the video plays fine, and has progressed so far that reloading plays from the last playback time, then I can reproduce frequently by seeking to near the end and waiting for the video to finish, and then reloading.
Specifically, this is a regression from https://hg.mozilla.org/mozilla-central/rev/5cc5ea4bf072 Any reason we need to keep that change?
Flags: needinfo?(cpearce)
This looks like bug 1139271 to me. SourceBuffer 1 start=0 end=5.004988 start=10.01 end=330.329988
Flags: needinfo?(ajones)
Florin - can you retest with bug 1139271 fixed? If that doesn't fix it then we need to back out bug 1133572.
Flags: needinfo?(florin.mezei)
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #8) > Florin - can you retest with bug 1139271 fixed? If that doesn't fix it then > we need to back out bug 1133572. Re-tested this on my Windows 7 x64 machine where I reproduced this, and indeed now I can no longer reproduce the issue in: - latest 39 Nightly - BuildID=20150318055750 - latest 38 Aurora tinderbox - pushlog shows the patches for bug 1139271 - latest 37 Beta tinderbox - pushlog shows the patches for bug 1139271 Latest 38 Aurora, does not have the fix for bug 1139271 yet so the issue is still easily reproducible there (as well as in 37 Beta 6). Given all this, I'm pretty confident that the fix for bug 1139271 should have fixed this. I'll have another quick look tomorrow on the latest Aurora and Beta 7 just to confirm and close this.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(edwin)
Flags: needinfo?(cpearce)
Resolution: --- → DUPLICATE
A quick check today on Windows 7 x64 confirms the issue no longer shows in: - latest 38 Aurora - BuildID=20150319004016 - Firefox 37 Beta 7 - BuildID=20150319212106 Marking as verified as this appears to have been fixed by bug 1139271.
Just happened to me on firefox 37.0.1 in the html5 player. Also, this is not a duplicate. "Sound stops playing temporarily" is not the same as "entire video stops and will not continue".
(In reply to neopeeves from comment #13) > Just happened to me on firefox 37.0.1 in the html5 player. Also, this is not > a duplicate. "Sound stops playing temporarily" is not the same as "entire > video stops and will not continue". Can you please file a separate bug with detailed steps for the issue that you're seeing?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: