Closed Bug 1270154 Opened 4 years ago Closed 4 years ago

ogv video stopped working after one of the updates

Categories

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

44 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla49
Tracking Status
firefox46 --- wontfix
firefox47 + verified
firefox48 --- verified
firefox49 --- verified

People

(Reporter: creativetalking, Assigned: jya, NeedInfo)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

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.
Attached file 1270154.html
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
[Tracking Requested - why for this release]: it's a regression that appears worth fixing.
Flags: needinfo?(jyavenard)
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).
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: 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+
(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
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.
https://hg.mozilla.org/mozilla-central/rev/7043159e6b74
Status: NEW → RESOLVED
Closed: 4 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)
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.