Closed Bug 1000108 Opened 6 years ago Closed 5 years ago
Switching videos from sd to hd in quicktime is not working properly in Firefox
Environment: FF 24.5.0 ESR Build Id:20140414143035 FF 29 RC Build Id: 20140421221237 OS: Win 7 x64 STR: 1. Go to http://trailers.apple.com 2. Play a video. 3. Switch the quality of the video from sd to hd. Expected: The video plays without any issues at hd quality. Actual: The video is not correctly playing. The issue vary from playing only the sound with a black window instead of image, to playing for a few seconds and hanging or stuttering, to crashing the Quicktime plugin.
I tried this on a Surface Pro 2 with Fx29b2, Fx29b9, Fx29RC, and the latest nightly, and I'm having problems playing any videos in any definition from within the site in step 1. In my machine the video loads for a few seconds and then crashes. https://crash-stats.mozilla.com/report/index/683ec0c1-8856-4233-bdc6-326ad2140423 However, if I load the videos using the direct link, it plays properly. Try: http://movietrailers.apple.com/movies/ifc_films/luckythem/luckythem-tlr1_720p.mov http://movietrailers.apple.com/movies/ifc_films/luckythem/luckythem-tlr1_1080p.mov In Firefox 28, playing the trailers work fine, in any definition, from within the site, and also using the direct links.
Since we have this bug for a while (ESR), we won't fix it for 29 but tracking for the other releases.
QT not working is a moderately-big deal for some users and this is a regression from 28->29; video not playing well is a competitive problem for Firefox. I think we should reconsider tracking this for 29. dmajor is investigating in bug 1000364.
OK. I was confused by ESR being impacted. Therefor, we are definitely going to track it and take a low risk backout/fix in a potential build2.
I'm still trying to find a regression range for this, but I wanted to mention that if I try reloading the page with the same video after crashing the plugin once, then playback seems to work. If I then try to play a different video, the plugin crashes.
I think I have narrowed down the plugin crash issue to something between 12/13/2013 and 12/14/2013. Nothing obvious jumped out, but here's the range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8b5875dc7e31&tochange=9d593727eb94
I don't see anything obvious in that range either :-(
More details in bug 1000364, but as far as I can tell this began in FF27.
(In reply to David Major [:dmajor] (UTC+12) from comment #8) > More details in bug 1000364, but as far as I can tell this began in FF27. (Referring to the crash, not the SD/HD switching issues. Though, they may be related: in order to switch the quality you have to mouse over the video, which for me is what triggers the crash)
Now that bug 1000364 is fixed, does this still reproduce?
Updating ESR flags as I understand from comment 3 that this is a regression introduced in 29.
(In reply to Lukas Blakk [:lsblakk] from comment #10) > Now that bug 1000364 is fixed, does this still reproduce? The bug is still reproducible using the latest nightly: FF32 Build Id: 20140605030202 Os: Win 7 x64
There were two separate issues here, the crash and the definition switch problem. The crashed was fixed, but the issue originally described here remains.
Won't be fixed for 30. Tracking for 32 too (I guess this release is affected too).
Too late for 31. We still have time for 32.
I reviewed this issue with Benjamin and it doesn't seem critical enough to require a fix in 32. As such, I'm dropping tracking. I'll note that we have already shipped a few releases with this issue.
This is still around in 34 Beta -- I'm wondering if it's affecting Firefox 35 and 36 as well.
This issue still reproduces on Windows 7 32bit and Windows 8.1 64bit using Firefox 35 Beta 4 (buildID: 20141216120925).
Reproduced on Windows 7 32bit and Windows 8 64bit using Firefox 36 Beta 4 (BuildID: 20150126151838).
[Tracking Requested - why for this release]: Issue is still seen in Firefox 37 Beta 7. I'm wondering whether we shouldn't reconsider this for tracking at least in Firefox 38.
I'm not sure how high a priority quicktime playback is currently. We're not going to fix this in 37 but I'll leave it nommed for review for 38.
Florin, did anything change about this issue? Or is it something that is routinely encountered in exploratory testing? Anthony do you feel this should be a priority? If not, I think we should untrack it.
This is routinely found during exploratory testing for quicktime playback, which is why we wanted to bring it back in focus.
This is not a video problem. It is either a plug-in problem or an evangelism problem.
Flags: needinfo?(ajones) → needinfo?(benjamin)
After you switch to HD quality, if you refresh the window does it stay set in HD and does that then work? Or is this really "all quicktime HD playback has issues" and the switching is just related to getting into HD mode?
Flags: needinfo?(benjamin) → needinfo?(florin.mezei)
I've had a look today using Firefox 38 Beta 1 on Windows 7 x64, and I found out the following: - the issue shows each time when starting in SD and then switching to HD (720p or 1080p) -> black image with sound shows - image comes back when reverting to SD - if I refresh and thus video starts directly in HD, then there is no playback issue, and switching to/from SD will work without problem (switching to the other HD resolution will still show the issue though) - Opera and Chrome also show this issue - Safari does not show the issue - I get some weird video artifacts during the switch from SD to HD, but then the video continues with both image and sound - sometimes after several switches and starting videos in various resolutions I can get the video to successfully switch from SD to HD, however, if I use Ctrl+Shift+R to reload the page (with SD video setting) then the problem reproduces again Hope the info above helps.
ok, since Opera/Chrome show this also, I think we are going to account this as a plugin or website bug. It's not important enough to fix, so I'm going to mark this INCOMPLETE.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
OK, let's stop tracking it then. Thanks for all the work!
You need to log in before you can comment on or make changes to this bug.