1083354 - [Media Recording API] Both recording are muted when the user muted only one while recording simultaneously

Status: RESOLVED INCOMPLETE

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

Description

[Yeojin Chung [:YeojinC]]

Attachment: logcat_20141015_BothStreamsMuted.txt

Description:
The user executes two media recordings using the same stream in the same content process. While recording simultaneously, the user mutes only one stream, but both stream get muted.
   
Repro Steps:
1) Update a Flame device to BuildID: 20141015001201.
2) Go to http://mozilla.github.io/qa-testcase-data/webapi/mediarecorder/index.html
3) Select "Microphone", type "2" for number of recorders, and select "Setup".
4) Grant the permissions.
5) Select "Start Recording" for both "index 0" and "index 1".
6) After 4 seconds of generating sound, select "Mute Media Stream" under "index 0".
7) After 5 seconds of generating sound, select "Unmute Media Stream" under "index 0".
8) Select "Stop Recording" for both "index 0" and "index 1".
9) Play both blob URLs generated.
  
Actual:
Both recordings are muted after the first 4 seconds.
  
Expected: 
Only 1st recording is muted after the first 4 seconds. The 2nd recording is NOT muted at all.
  
Environmental Variables:
Device: Flame 2.1
BuildID: 20141015001201
Gaia: 379ea4c9dd6d3f8ca2f79ce59c15f6afe6e557c3
Gecko: 4853208cb48a
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/10182/
See attached: logcat

Comment 1

[Yeojin Chung [:YeojinC]]

This issue also reproduces on Flame 2.2 and 2.0:

Flame 2.2 

Device: Flame 2.2 Master KK (319mb) (Full Flash)
Build ID: 20141015040201
Gaia: 5f1f0960ae9d22acf2a324ad37a48174d6df87f6
Gecko: 62f0b771583c
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 36.0a1 (Master)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Flame 2.0

Environmental Variables:
Device: Flame 2.0 KK (319mb) (Full Flash)
Build ID: 20141015000206
Gaia: c6c6116ca225c2c934220ae6867e5a3256d65e00
Gecko: 24a2aa6bf1c4
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware Version: v180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Both recordings are muted when the user muted only 1 of 2.

Comment 2

[Yeojin Chung [:YeojinC]]

Added video: http://youtu.be/VP9Nf3cQTcM

Comment 3

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Not nominating this as a blocker, as this is just a test site

Comment 4

[No-Jun Park [:njpark]]

can we check whether this still reproduces, and if so, ni? Jim Porter, I believe with the recent works in audiostream, this might not reproduce anymore.  Thanks!

Comment 5

[Shally Li（leave from Mozilla）]

Hi No-Jun,

    According to the STR of Comment 0, I still can repro this bug on latest Flame v2.0&2.1&2.2&3.0. Could you help with this bug again?

Thank you very much.

----------------------------------------------------------------
Actual results: Both the recordings are muted.
See attachments: verify_v2.2.MP4 and logcat.txt
Reproduce rate: 4/4

----------------------------------------------------------------
Device: Flame 2.0 build(Affected)
Build ID               20150503160204
Gaia Revision          84898cadf28b1a1fcd03b726cff658de470282f0
Gaia Date              2015-04-03 21:42:36
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/7280924bba4c
Gecko Version          32.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150503.193837
Firmware Date          Sun May  3 19:38:48 EDT 2015
Bootloader             L1TC000118D0

Device: Flame 2.1 build(Affected)
Build ID               20150503001202
Gaia Revision          b4a03b7ee61de5a479b3cf0916f47e91a43b0f50
Gaia Date              2015-04-30 21:31:55
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/bcbfb2d04b15
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150503.040110
Firmware Date          Sun May  3 04:01:22 EDT 2015
Bootloader             L1TC000118D0

Device: Flame 2.2 build(Affected)
Build ID               20150503002500
Gaia Revision          8d14361337e608c8cdf165ea5034db5eda23b618
Gaia Date              2015-05-01 18:23:46
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/cb7cb6597c91
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150503.040203
Firmware Date          Sun May  3 04:02:15 EDT 2015
Bootloader             L1TC000118D0

Device: Flame 3.0 build(Affected)
Build ID               20150503160200
Gaia Revision          e18cce173840d6ff07fb6f1f0e0ffb58b99aab3e
Gaia Date              2015-05-02 04:27:01
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/dc5f85980a82
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150503.193941
Firmware Date          Sun May  3 19:39:52 EDT 2015
Bootloader             L1TC000118D0

Comment 6

[Shally Li（leave from Mozilla）]

Attachment: logcat.txt

Comment 7

[Shally Li（leave from Mozilla）]

Attachment: verify_v2.2.mp4

Comment 8

[No-Jun Park [:njpark]]

Actually, Sotaro, would this bug be related to the omx driver?  Or is it something fixable on the gaia side?

Comment 9

[Sotaro Ikeda [:sotaro]]

njpark, how can I test it? The following URL in comment 0 is invalid now.

> 2) Go to http://mozilla.github.io/qa-testcase-data/webapi/mediarecorder/index.html

Comment 10

[No-Jun Park [:njpark]]

According to https://bugzilla.mozilla.org/show_bug.cgi?id=1083413#c14, the new url is http://mozilla-b2g.github.io/qa-testcase-data/webapi/mediarecorder/MediaRecorder.html but the links may not work there. Naoki, do you know who we should ask for the fix?

Comment 11

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Jsmith was the one that wrote these test cases.  They broke when the testcases git repo moved from mozilla to mozilla-b2g.

I think it's just a matter of trying to fix it regardless of who the owner is for these web apps.  I'm trying to fix it slowly by figuring out what's broken and fixing them.

Comment 12

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Taking myself off needinfo.  We're going to track the media test webapp breakage in a different bug.

Comment 13

[No-Jun Park [:njpark]]

[Tracking Requested - why for this release]:

We can test this once Bug 1164721 is fixed.

Comment 14

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Test case needs to be updated to this page:
http://mozilla-b2g.github.io/qa-testcase-data/webapi/mediarecorder-legacy/index.html

QAWanted to see if this still occurs.

Comment 15

[Shally Li（leave from Mozilla）]

Hi Naoki,

    This bug still can be repro on latest Flame KK v2.5 and Aries KK v2.5 by the STR in comment 0 in "http://mozilla-b2g.github.io/qa-testcase-data/webapi/mediarecorder-legacy/index.html". 
    Could you help to look the bug agian? Thank you very much.


Actual results: The Both recording are muted when the user muted only one while recording simultaneously.
See attachment: FlameKK_v2.5.3gp and logcat_1846.txt
Reproduce rate: 5/5


Device: Flame KK 2.5 (Affected)
Build ID               20150823150207
Gaia Revision          cddb9f610cbe03d0ca39d81bbdce46a0fca841ab
Gaia Date              2015-08-23 03:34:38
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/4ccdd06e51d7209ba429196df7cab97bf66962db
Gecko Version          43.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150823.184539
Firmware Date          Sun Aug 23 18:45:51 EDT 2015
Firmware Version       v18D v4
Bootloader             L1TC000118D0

Device: Aries KK 2.5(Affected)
Build ID               20150823221817
Gaia Revision          cddb9f610cbe03d0ca39d81bbdce46a0fca841ab
Gaia Date              2015-08-23 03:34:38
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/4ccdd06e51d7209ba429196df7cab97bf66962db
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150823.214038
Firmware Date          Sun Aug 23 21:40:46 UTC 2015
Bootloader             s1

Comment 16

[Shally Li（leave from Mozilla）]

Attachment: logcat_1846.txt

Comment 17

[Shally Li（leave from Mozilla）]

Attachment: FlameKK_v2.5.3gp

Comment 18

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Sotaro-san, please use the following URL ( "http://mozilla-b2g.github.io/qa-testcase-data/webapi/mediarecorder-legacy/index.html" ) instead of the url in step 2.

Comment 19

[Sotaro Ikeda [:sotaro]]

I seem to understand the cause of the problem. The test uses mediaRecorder.stream to mute/unmute the stream. MediaRecorder returns same stream that is given at "new MediaRecorder(stream)". Therefore, mediaRecorder.stream returns same MediaStream among multiple MediaRecoders, because all of them uses same MediaStream to create MediaRecorder.

Comment 20

[Sotaro Ikeda [:sotaro]]

It seems necessary to do similar thing to Bug 1073406. If mediaRecorder.stream returns MediaRecorder's media stream, the problem could be addressed.

Comment 21

[Sotaro Ikeda [:sotaro]]

FYI: diagram of MediaRecorder

https://github.com/sotaroikeda/firefox-diagrams/blob/master/media/dom_media_MediaRecorder_FirefoxOS_2_5.pdf

Comment 22

[Sotaro Ikeda [:sotaro]]

(In reply to Sotaro Ikeda [:sotaro] from comment #20)
> It seems necessary to do similar thing to Bug 1073406. If
> mediaRecorder.stream returns MediaRecorder's media stream, the problem could
> be addressed.

MediaRecorder's spec say the following. It seems to prohibit to create new DOMMediaStream to wrap source MediaStream.

> MediaRecorder
>    MediaStream stream
>        The MediaStream to be recorded. This will be the value of the stream attribute. See >[GETUSERMEDIA] for the definition of MediaStream. 

http://w3c.github.io/mediacapture-record/MediaRecorder.html#widl-MediaRecorder-stream

Comment 23

[Sotaro Ikeda [:sotaro]]

The test pass same MediaStream to 2 MediaRecorders. From comment 22, MediaStream.stream of the both 2 MediaRecorders becomes same. Then, applying "audioTracks[0].enabled = false" to one MediaRecoder mute also another MediaRecorder.

Comment 24

[Sotaro Ikeda [:sotaro]]

:pehrsons, is there a way to address the problem? Could MediaStream.clone() fix the problem? Though MdiaStream.clone() is not implemented yet?

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This seems like an issue in the test. Gecko and the spec are behaving correctly.

But making the test do what it's trying to do does require the ability to clone MediaStreams, either via clone() or the MediaStream constructor.

Comment 26

[Andreas Pehrson [:pehrsons]]

So muting is done by disabling the tracks. Yeah then gecko is behaving correctly.

With clone() or MediaStream() constructors not implemented yet (working on it!), can you fix this by getting separate gUM() streams for each recorder?

Comment 27

[Sotaro Ikeda [:sotaro]]

nhirata, What do you prefer to fix the problem? It becomes clear that the mute works correctly.

Comment 28

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Um, it seems to me that we should branch the test and disable it until  clone() gets implemented while with the clone of the test, fixing the test w/ getting separate gUM() streams for each recorder.

Is that correct?  

This would mean that we would have a test for cloning and a test with separate gUM() streams for each recorder.  Johan, what do you think?

Comment 29

[Johan Lorenzo [:jlorenzo]]

I'm not an expert in Media APIs, but these 2 scenarios look valid API integration tests to me.

Comment 30

[Randell Jesup [:jesup] (needinfo me)]

Andreas - this is closely related to the muting stuff we talked about, and track cloning.  Using muting-on-leaf-nodes should allow us to fix this.  As you mention, right now it's operating as intended.

Can you link it to the other muting bug, so the test can be fixed once track cloning and/or leafnode muting is available?  Thanks

Comment 31

[Andreas Pehrson [:pehrsons]]

(In reply to Randell Jesup [:jesup] from comment #30)
> Andreas - this is closely related to the muting stuff we talked about, and
> track cloning.  Using muting-on-leaf-nodes should allow us to fix this.
Well, cloning would allow us to fix this, and the muting-on-leaf-nodes is really a blocker of cloning.

> As
> you mention, right now it's operating as intended.
> 
> Can you link it to the other muting bug, so the test can be fixed once track
> cloning and/or leafnode muting is available?  Thanks
Both made blockers of this bug.

Comment 32

[Sotaro Ikeda [:sotaro]]

This bug is specific to b2g.