ogv video stopped working after one of the updates

VERIFIED FIXED in Firefox 47

Status

()

defect
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: creativetalking, Assigned: jya, NeedInfo)

Tracking

({regression, testcase})

44 Branch
mozilla49
Points:
---

Firefox Tracking Flags

(firefox46 wontfix, firefox47+ verified, firefox48 verified, firefox49 verified)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160421124000

Steps to reproduce:

Please, open this link http://www.chinesehideout.com/tools/strokeorder.php?c=5ZCX - there you're supposed to see chinese animation.


Actual results:

The animation (ogv videos) are loaded but not displayed. It was fine a long time ago, but after one of the updates it stopped displaying. It is working fine in google Chrome.


Expected results:

The animation should be visible.

Comment 1

3 years ago
Posted file 1270154.html

Comment 2

3 years ago
Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8f72e3889e802851d568f7a3cefa0a2979f9ba3d&tochange=32f7dd06ba4c1ecdbb281a0a25df3a08c6401e73

Surely faulty:
Jean-Yves Avenard — Bug 1217304
Blocks: 1217304
Status: UNCONFIRMED → NEW
Component: Untriaged → Audio/Video: Playback
Ever confirmed: true
Flags: needinfo?(jyavenard)
Keywords: regression, testcase
Product: Firefox → Core
Version: 46 Branch → 44 Branch
(Assignee)

Comment 3

3 years ago
[Tracking Requested - why for this release]: it's a regression that appears worth fixing.
Flags: needinfo?(jyavenard)

Comment 4

3 years ago
For the record, the MP4 video in the testcase is broken if loaded in a tab, but it has been always the case, it's probably poorly encoded (and that's not the main issue of this bug).
(Assignee)

Comment 5

3 years ago
the mp4 isn't broken, it's just mpeg4 part 2 (divx) which we don't support.

The issue here is that following 1217304, loadedmetadata succeeded and it appears that we have an opaque blank frame container located right above the ogv window playing underneath, so you can't see it.
(Assignee)

Updated

3 years ago
Assignee: nobody → jyavenard
Comment on attachment 8751299 [details]
MozReview Request: Bug 1270154: P1. Forget the media element's media-resource-specific tracks when error occurs. r?jwwang

https://reviewboard.mozilla.org/r/51945/#review49001

Can you explain how this change fixes the bug?
Attachment #8751299 - Flags: review?(jwwang) → review+
(Assignee)

Comment 8

3 years ago
(In reply to JW Wang [:jwwang] from comment #7)
> Can you explain how this change fixes the bug?

TBH, I can't. the elements are created in exactly the same fashion. But if the videoTrack is enabled on the previously tried video then it hides the video that's actually playing.
Blocks: 1207198
No longer blocks: 1217304
(Assignee)

Updated

3 years ago
See Also: → 1272182
nsVideoFrame::BuildLayer calls |element->GetVideoSize(&videoSizeInPx)| which returns NS_ERROR_FAILURE for |mDisableVideo| is true which is set by |mDisableVideo = !track->Selected()| in HTMLMediaElement::NotifyMediaTrackEnabled().

It makes sense to clear all audio/video tracks when loading a new resource as HTMLMediaElement::AbortExistingLoads() also does that.

However, NotifyMediaTrackEnabled() doesn't handle multiple tracks for now. (https://hg.mozilla.org/mozilla-central/file/3461f3cae78495f100a0f7d3d2e0b89292d3ec02/dom/html/HTMLMediaElement.cpp#l1008)

Loading a 2nd resource without clearing tracks will hit this case.

Comment 11

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/7043159e6b74
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
(In reply to Jean-Yves Avenard [:jya] from comment #3)
> [Tracking Requested - why for this release]: it's a regression that appears
> worth fixing.

Jean-Yves  -- Can you ask for uplift if you still think this fix is a good candidate for uplift to  Fx48 and Fx47?  Thanks.
Flags: needinfo?(jyavenard)
Hello, could you please verify whether this issue is fixed as expected on a latest Nightly build? Thanks!
Flags: needinfo?(creativetalking)
(Assignee)

Comment 14

3 years ago
Comment on attachment 8751299 [details]
MozReview Request: Bug 1270154: P1. Forget the media element's media-resource-specific tracks when error occurs. r?jwwang

Approval Request Comment
[Feature/regressing bug #]: 1270154
[User impact if declined]: regression, content with multiple media source will not play. 
[Describe test coverage new/current, TreeHerder]: in central for a while, manually tested. 
[Risks and why]: low. We're allowing fallback when things didn't work. 
[String/UUID change made/needed]:none
Flags: needinfo?(jyavenard)
Attachment #8751299 - Flags: approval-mozilla-beta?
Attachment #8751299 - Flags: approval-mozilla-aurora?
Comment on attachment 8751299 [details]
MozReview Request: Bug 1270154: P1. Forget the media element's media-resource-specific tracks when error occurs. r?jwwang

The fix seems simple enough, seems like a recent regression since Fx46, Aurora48+, Beta47+
Attachment #8751299 - Flags: approval-mozilla-beta?
Attachment #8751299 - Flags: approval-mozilla-beta+
Attachment #8751299 - Flags: approval-mozilla-aurora?
Attachment #8751299 - Flags: approval-mozilla-aurora+
Wontfix for 46, as we don't have another driver for 46.0.2 and are only a couple of weeks away from 47 release.
QA Whiteboard: [good first verify]
I have reproduced this bug with Firefox Nightly 49.0a1 (Build ID: 20160504043118) on 
Windows 8.1, 64-bit.

Verified as fixed with Firefox release 47.0 (Build ID:20160604131506)
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

Verified as fixed with Firefox beta 48.0b1 (Build ID:20160606200529)
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0

Verified as fixed with Firefox Developer edition 49.0a2 (Build ID:20160613004107)
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
QA Whiteboard: [good first verify] → [good first verify][bugday-20160608]
I have reproduced this bug with Firefox Nightly 49.0a1 (2016-05-04)on Ubuntu 16.04, 64 bit.

The bug's fix is now verified on latest Aurora 49.0a2, Nightly 50.0a1.

Aurora 49.0a2:
Build ID 	20160722004032
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0

Nightly 50.0a1:
Build ID 	20160722030235
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0


[testday-20160722]
As it is verified on both windows(Comment 19) and linux(Comment 20) Marking it as verified!
You need to log in before you can comment on or make changes to this bug.