1414463 - Intermittent /tests/dom/media/test/test_eme_sample_groups_playback.html logged result after SimpleTest.finish(): Expected a license-request

Status: RESOLVED INCOMPLETE

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

Description

[Treeherder Bug Filer]

Filed by: philringnalda [at] gmail.com

https://treeherder.mozilla.org/logviewer.html#?job_id=141945176&repo=autoland

https://queue.taskcluster.net/v1/task/GDWFvfVoRCGw9Lxg4u-oBA/runs/0/artifacts/public/logs/live_backing.log

Comment 1

[Intermittent Failures Robot]

24 failures in 857 pushes (0.028 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* autoland: 12
* mozilla-central: 7
* mozilla-inbound: 4
* try: 1

Platform breakdown:
* linux64-qr: 8
* linux32: 7
* linux32-stylo-disabled: 5
* linux64-stylo-disabled: 2
* linux64: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1414463&startday=2017-10-30&endday=2017-11-05&tree=all

Comment 2

[Kilik Kuo [:kikuo] (inactive)]

In this test, the 'encrypted' event will be fired after the fragments have been appended.
And samples' keyids are extracted from sgpd (sbgp in traf sgpd in stbl), so each time when MFR is requesting a demuxed sample, the keyid will be filled to sample before the sample is returned to MFR.

There are several odd(for me) points in this test.

1) A second (unnecessary) |LoadEME()| is called after all fragments are appended. [1]
Before Bug 1395922, the 2nd |v.setMediaKey()| [2] will be rejected directly because HTMLMediaElement didn't support switching MediaKeys after load. So the new created mediakeys & sessions are not bound to HTMLMediaElement. Nevertheless, playback could still start correctly because "sbgp" & "sgpd" are still parsed correctly in MoofParser.

2) 'waitingforkey' [3] may be fired not only because of this " Video is waitingforkey, indicating that the samples are not being assigned the correct id from the sgpd box!", but also " Decoding is blocked and waiting for key because the license-response is not updated to CDM yet !"
For me, we SHOULD JUST TEST whether the file can be played correctly or not. It doesn't matter that if there's a 'waitingforkey' event or not.

[1] http://searchfox.org/mozilla-central/rev/5a60492a53667fc61a62af1847d005a210b7a4f6/dom/media/test/test_eme_sample_groups_playback.html#116
[2] http://searchfox.org/mozilla-central/rev/5a60492a53667fc61a62af1847d005a210b7a4f6/dom/media/test/test_eme_sample_groups_playback.html#71
[3] http://searchfox.org/mozilla-central/rev/5a60492a53667fc61a62af1847d005a210b7a4f6/dom/media/test/test_eme_sample_groups_playback.html#53-57

I'd like to refine this test.
JW, does it make sense to you ?

Comment 3

[Kilik Kuo [:kikuo] (inactive)]

Attachment: [Log][NG] The response of GenerateRequest from CDM is so late, and playback has already finished.

CDM child send the message back to parent sooooo late.

find "D/EME ChromiumCDMProxy::OnSetSessionId"

Comment 4

[Kilik Kuo [:kikuo] (inactive)]

Attachment: [Log][OK] The response of GenerateRequest from CDM comes faster than the end of playback.

Comment 5

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Kilik Kuo [:kikuo] from comment #2)
> 1) A second (unnecessary) |LoadEME()| is called after all fragments are
> appended. [1]
This seems suspicious to me too.

> 2) 'waitingforkey' [3] may be fired not only because of this " Video is
> waitingforkey, indicating that the samples are not being assigned the
> correct id from the sgpd box!", but also " Decoding is blocked and waiting
> for key because the license-response is not updated to CDM yet !"
Isn't it that we always ensure the keys are updated before starting playback in this test case so condition 2 should not happen?

Comment 6

[Kilik Kuo [:kikuo] (inactive)]

This issue should disappear after Bug 1415028 is landed.
Let's see if there's still problem after Bug 1395922 is landed too.

Comment 7

[Intermittent Failures Robot]

8 failures in 849 pushes (0.009 failures/push) were associated with this bug in the last 7 days.    

Repository breakdown:
* autoland: 4
* mozilla-inbound: 2
* try: 1
* mozilla-central: 1

Platform breakdown:
* linux64-qr: 3
* linux64: 3
* linux32-stylo-disabled: 1
* linux32: 1

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1414463&startday=2017-11-06&endday=2017-11-12&tree=all

Comment 8

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup