Closed
Bug 1202296
Opened 9 years ago
Closed 9 years ago
HTML5 Video on YouTube are not playing with FF 41 beta 7
Categories
(Core :: Audio/Video: Playback, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla43
Tracking | Status | |
---|---|---|
firefox41 | --- | unaffected |
firefox42 | --- | unaffected |
firefox43 | --- | fixed |
People
(Reporter: giopeppe, Assigned: mattwoodrow)
References
Details
(Keywords: regression)
Attachments
(3 files)
1.30 KB,
text/plain
|
Details | |
16.73 KB,
patch
|
cpearce
:
review+
|
Details | Diff | Splinter Review |
5.07 KB,
patch
|
cpearce
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150831172306
Steps to reproduce:
Update from Firefox 41 beta 6 to Firefox beta 7 and go to Youtube to playsome videos.
Actual results:
I can't play video with HTML5 player anymore, i get the message "An error is occurred". Using Adobe Flash works.
Rolling back to beta 6 they work again.
While doing some backtracking (at first i tought it was due to an extension) i found that it's probably related to hardware video decoding.
Noticing that all seems to works with a new profile i found that the culprit is
media.hardware-video-decoding.failed : false
In Beta 7, If i set it to "true", all seem to work (but hw video decoding should be gone, right?).
Expected results:
Videos should just play normally.
WFM, could you test with a fresh profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Flags: needinfo?(giopeppe)
(In reply to Loic from comment #1)
> WFM, could you test with a fresh profile, please.
> https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles
Sure, i already do, here the results:
With 41 beta 6:
When i create a fresh profile "media.hardware-video-decoding.failed" is automatically set to "false" and html5 video playback is working.
With 41 beta 7, using the fresh profile created with beta 6:
Video playback is not working and "media.hardware-video-decoding.failed : false", if i reset the value in about:config, it's not recreated, if i add it manually and set to "true", videoplaback works again.
With 41 beta 7, creating a freshly profile:
Video playback works and "media.hardware-video-decoding.failed : true" is automatically set to "true".
I have the about:support data of all three conditions, could they help?
Flags: needinfo?(giopeppe)
(In reply to giopeppe from comment #2)
> I have the about:support data of all three conditions, could they help?
The graphics section of about:support would help to identify which GPU we're dealing with so we can try to repro it. You could use http://mozilla.github.io/mozregression/ to figure out which change broke it.
Matt/Mason - are you aware of anything that changed in b7?
Flags: needinfo?(mchang)
Flags: needinfo?(matt.woodrow)
This is the about support of Beta 7 with a freshly created profile, it have h264 HW support: False and videoplayback of html5 videos works.
With beta 6, H264 HW support is: True and videoplayback works, updating to beta 7 form an older profile, HW support is setted to "True" but video playback don't work at all.
Comment 5•9 years ago
|
||
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #3)
> (In reply to giopeppe from comment #2)
> > I have the about:support data of all three conditions, could they help?
>
> The graphics section of about:support would help to identify which GPU we're
> dealing with so we can try to repro it. You could use
> http://mozilla.github.io/mozregression/ to figure out which change broke it.
>
> Matt/Mason - are you aware of anything that changed in b7?
I'm not aware of anything that changed in b7.
Flags: needinfo?(mchang)
Assignee | ||
Comment 6•9 years ago
|
||
Bug 1193547 landed for b7 I believe, that's my guess.
We should probably back that out for now.
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 7•9 years ago
|
||
I can reproduce this on a machine in the TO office.
Looks like reconfiguring the MFTransform when we decide we can't use DXVA doesn't work sometime, it may be specific to the windows 7 version of the library (since it definitely works on other machines).
Comment 8•9 years ago
|
||
[Tracking Requested - why for this release]: we cannot tolerate any regressions on youtube.
Updated•9 years ago
|
Blocks: 1193547
Summary: HTML5 Video on Youtube are not playing with FF 41 beta 7 → HTML5 Video on YouTube are not playing with FF 41 beta 7
Tracked.
Assignee | ||
Comment 10•9 years ago
|
||
Assignee: nobody → matt.woodrow
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attachment #8658943 -
Flags: review?(cpearce)
Assignee | ||
Comment 11•9 years ago
|
||
This works much better for windows 7, and seems simpler too.
Attachment #8658945 -
Flags: review?(cpearce)
Updated•9 years ago
|
Attachment #8658943 -
Flags: review?(cpearce) → review+
Comment 12•9 years ago
|
||
Comment on attachment 8658945 [details] [diff] [review]
Recreate MFT rather than re-configuring it
Review of attachment 8658945 [details] [diff] [review]:
-----------------------------------------------------------------
r+ with explanations or fixes for my comments.
::: dom/media/platforms/wmf/WMFVideoMFTManager.cpp
@@ +330,2 @@
> // SupportsConfig only checks for valid h264 decoders currently.
> + if (mStreamType != H264) {
Why are you returning true that non-H264 supports DXVA? We haven't really tested non-H264 DXVA have we? Shouldn't this remain at "return false"?
@@ +358,1 @@
>
You deleted the line:
HRESULT hr = mDecoder->GetOutputMediaType(mediaType);
Do we need to keep that line? Can the output type change after we re-init? Wouldn't the YUV format need to change from NV12 to YV12 when we switch from DXVA to non-DXVA? Or are you getting a MF_E_TRANSFORM_STREAM_CHANGE on first output that is causing us to re-get the output types next cycle?
Attachment #8658945 -
Flags: review?(cpearce) → review+
Assignee | ||
Comment 13•9 years ago
|
||
(In reply to Chris Pearce (:cpearce) from comment #12)
> Comment on attachment 8658945 [details] [diff] [review]
> Recreate MFT rather than re-configuring it
>
> Review of attachment 8658945 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> r+ with explanations or fixes for my comments.
>
> ::: dom/media/platforms/wmf/WMFVideoMFTManager.cpp
> @@ +330,2 @@
> > // SupportsConfig only checks for valid h264 decoders currently.
> > + if (mStreamType != H264) {
>
> Why are you returning true that non-H264 supports DXVA? We haven't really
> tested non-H264 DXVA have we? Shouldn't this remain at "return false"?
We're returning true to mean that we have no idea if it's supported (since the test below doesn't take it into account), and we shouldn't take any action.
>
> @@ +358,1 @@
> >
>
> You deleted the line:
> HRESULT hr = mDecoder->GetOutputMediaType(mediaType);
>
> Do we need to keep that line? Can the output type change after we re-init?
> Wouldn't the YUV format need to change from NV12 to YV12 when we switch from
> DXVA to non-DXVA? Or are you getting a MF_E_TRANSFORM_STREAM_CHANGE on first
> output that is causing us to re-get the output types next cycle?
Yep, we're re-inputting on the brand new MFT and returning immediately, which should once again trigger the STREAM_CHANGE and we'll go through this function again.
Comment 14•9 years ago
|
||
OK, cool.
Comment 15•9 years ago
|
||
Would you be able to nominate a patch for this soon? We will gtb 41 RC on Monday morning PST.
Flags: needinfo?(kinetik)
Comment 17•9 years ago
|
||
I assume you meant to ask the other Matt. :-)
Flags: needinfo?(kinetik) → needinfo?(matt.woodrow)
Assignee | ||
Comment 18•9 years ago
|
||
Bug 1193547 got backed out of beta/aurora, so would shouldn't need to uplift anything here.
status-firefox42:
--- → unaffected
status-firefox43:
--- → affected
tracking-firefox41:
+ → ---
Flags: needinfo?(matt.woodrow)
Updated•9 years ago
|
Priority: -- → P1
Comment 19•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/8a7d924a0f34
https://hg.mozilla.org/mozilla-central/rev/e7e0427710e1
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in
before you can comment on or make changes to this bug.
Description
•