mozilla :: #media

8 Sep 2017
07:10dietrichhello! can someone point me to our defaults for the opus encoding and ogg containerizing that the MediaRecorder API does?
07:11dietrichi'm doing recording/encoding on the command line with opus/ogg tools but it's not matching what browser is generating
07:21jesupdietrich: see dom/media/encoder/OpusTrackEncoder*
07:21* jesup crashes
07:22dietrichthanks jesup!
07:30jyamattwoodrow|away: ping
08:40jyamreavy: ping
10:38mreavyjya: pong
11:41pehrsonsjesup: padenot: it can happen that we switch from one audio callback driver to another audio callback driver, yes?
12:08padenotpehrsons yes
12:08padenotsorry all, I'm in a train, I'm doing stuff offline
12:08pehrsonspadenot: cool, well, if you have time check my PM
12:10padenotreading now
12:43padenotpehrsons, specifically, it happens when the first driver errors out or we're going from output-only to duplex or duplex to output-only
12:43padenotmaybe I'm lying for the first case
12:44pehrsonsif it errors we'll go via a fallback systemclock right?
12:44padenotyes indeed
12:44padenotand then try to switch to an audio driver when the graph discovers that, in fact, it still has an audio track
12:46pehrsonsthat could end up in endless flipflopping in the worst case I guess?
17:57jesuppadenot: ping
18:02jesuppehrsons: awesome,thanks!
18:34pehrsonsI hope this will do it :p
19:40dminorjesup: ping, have a moment to discuss max-fs?
19:46dminorjesup: unping, will leave question on bug :)
19:46jesupor you can ask now
19:51dminorjesup: thanks, so I was testing my patch for max-fs and it works fine for VP8, but on H.264, the size gets reset here as soon as we send an image:
19:51drnodminor: I would not be surprised if max-fs never worked for H264 before
19:52dminordrno: you're not inspiring confidence here :)
19:52drnodminor: or in other words: I would rater land a working patch for VP8 now and deferrer remaining H264 problems into a new bug
19:53dminorjesup: If I comment out the call to RegetEncoderForResolutionChange it works as expected, but I'm guessing the video frame should be resized before it gets there?
19:53dminordrno: sure, I can do that.
19:58jesupdminor: hard to find the original, but it was bug 1059765
19:58firebot FIXED, H264 codecs in webrtc don't use content analysis and framerate/resolution adaptation
19:59jesuppeterv and bwc modified it later to be async
19:59jesupdminor: "Experimentation has shown the current OpenH264 codec doesn't change SPS/PPS when input resolution changes; it insets. Since we can't easily reconfigure a codec, shut down and re-init the codec on a resolution change, which is expensive. We should rev the API in the future (35) to a) let the codec tell us if it needs reiniting for resolution changes and/or b) provide an API to tell... to reconfigure dynamically (or at least tell it a new resolution)."
20:00jesupI wouldn't be at all surprised if that has been fixed; try simply deleting the block of code for resolution changes
20:00dminorjesup: sure, thank you for your help!
20:00jesupthen force an input resolution change and see what happens
20:01jesupyou can use one of jib's fiddles, or a canvas source that you resize
20:01jesupIf that's still needed, it *should* work, but will drop a frame or two at a switch I thihnk
20:02jibwhat flavor fiddle do you want?
20:02mjfjesup: Nico said Im sending crazy audio when my apple earbuds are plugged in.
20:02mjfWe tried and Both have the issue.
20:03drnojib: a strawberry fiddle for me please :)
20:03mjfI just updated Nightly. These are the earbuds I use each week for the standup.
20:03ngThe snozfiddles taste like snozfiddles.
20:03jesupThough it doesn't check that it's in the middle of re-initiing I think - I think that was a miss when updating to make it async (i.e. change to NxM-> RegetEncoder() (async), new frame NxM -> RegetEncoder again -- if it hasn't finished)
20:04ngI just plugged in my headphones and the tab crashed.
20:05dminorjib: something that will force a resolution change part way through a call, do you have anything handy?
20:06jesupbe nice if we had a resolution-change mochitest...
20:08mreavydminor, jesup, mjf, ng - this smells like a libcubeb issue (ref: apple earbuds)
20:09jibdo earbuds affect fast-path in any way?
20:10jibif so could be bug 1396879
20:10mjfSo Nico just tried the same thing and it didnt happen on his end.
20:10firebot NEW, Severe mic distortion/slowdown/delay using applyConstraints to turn off processing (+intermittent nu
20:10jesupjib: shouldn't
20:10jibbut that bug shows we have threading issues
20:10mjfOK. Ill bite. What is fast-path?
20:10ngPlugging in my ear buds didn't exhibit the same issues (for the record).
20:11jibturn off all audio processing here:
20:11jibmjf: ^
20:11jesupjib: only with switching between no processing and processing
20:11jesupthat normally never happens in apps. No-processing mode is almost entirely for music/etc apps
20:11jibbut in general the audio stack seems brittle when changing parameters live
20:11mreavydminor, jesup, mjf, ng - do we have a bug open yet for this problem (ref: apple ear buds)?
20:11mreavyjib also ^^
20:12mreavyif not, let's file a bug now
20:12jesupng: crash-stats link?
20:12mreavyonce a bug is filed, please put it in this channel
20:13mreavykentuckyfriedtakahe, jya, padenot, achronop ^^. (It's the weekend, but this bug needs to be a top priority first thing Monday); it smells like a libcubeb regression, but please prove me wrong -- as long as it gets fixed.
20:13jibng: can I have crashstat as well?
20:14jibnote bug 1396879 is also a crash, subject buries it a bit
20:16mreavyto be clear, it's actually 2 bugs -- one is the horrible audio (which is what I think is a libcubeb issue), the other bug is the crash. Can we file 2 bugs even one or both wind up being dups?
20:17jibmreavy: do you mean split bug 1396879 into two bugs, or did you mean something else?
20:17ngjib: sure give me a minute
20:18mreavyjib: No, that bug is separate from what I think ng and mjf experienced (with the distortion with apple earbuds on one side and the crash on the other).
20:19jibng: was it that crashed?
20:21jibgah no stack
20:21ngIt was or
20:21ngIt was
20:23fippong: thank you, now I can go to bed :-)
20:23jibok so we have another audio crash somewhere blocked on bug 1385531
20:23firebot NEW, Crash in EMPTY: no crashing thread identified; OK
20:23ngfippo: do it quickly
20:35jesupng: ugh: No signature could be created because we do not know which thread crashed
20:37mjfjib: turn off all audio processing
20:37jesupI crashed before even giving microphone access on
20:37mjfjib: and then what?
20:37jesupCrashed in mozilla::net::RequestContext::Notify()
20:37mjfjib: retry the call w/ Nico?
20:37jesup(this is bug 1385521)
20:38firebot FIXED, nsRange::GetCommonAncestor() is expensive for the obvious case
20:38* drno wishes that video elements playing back when shutting down would be included in session restore
20:38mjfdrno: ping
20:38drnomjf: pong
20:39jibmjf: oh sorry, that was bug 1396879, see STRs there
20:39firebot NEW, Severe mic distortion/slowdown/delay using applyConstraints to turn off processing (+intermittent nu
20:39jibprobably a different issue
20:42jibcomment 1
20:42mjfjib: for the record, I get no audio there at all.
20:42jibin nightly?
20:42jesupNo site that I know of uses applyConstraints to turn off/on audio processing (though it's good to fix the bug with this!) mjf and ng's bug is something else
20:42jesupor rather their bugs
20:43jibmjf: does the spectrum analyzer move at all?
20:43ngso far I can't get to crash
20:43jesupand the thing is a bug in the doorhanger code
20:43jesupyou need a debug build
20:43jesupMOZ_ASSERT in TimeStamp
20:43mjfjib: it does this time.
20:44jesupit's comparing timestamps with unset timestamps
20:44jibmjf: using the fiddle or the blog post
20:44mjfjib: noise mostly, no recognizable content.
20:44mjf(from the blog poast)
20:45mjfmjf: both now.
20:45mjfjib: ^
20:45mjfSomething changed between runs
20:46jibit could also be per tab
20:46jibnow that we have multiple content processes
20:46jibif dom.ipc.processCount > 1 (default 4)
20:47jibmjf: so that bug is two bugs, hammer on e.g. echoCancellation if it's the last checkmark for 30 seconds crashes
20:47jibbut different stack from yours
20:48jibit's just the stack ng posted gave me deja vu, there's another audio bug somewhere where this came up, but I can't locate it now
20:49jibng: but please file regardless
20:49jibpadenot or achronop may remember
20:50mjfjib: ok - Ill move along. This is the first time Ive experience that particular issue, or rather been the generator of that particular issue.
20:50mjfdrno: sorry - got sidetracked.
20:51mjfdrno: Im concerned that were not passing _any_ rtp header extensions on audio.
20:52jibHere's another one. Anyone seen this one?
20:58drno|irccloudmjf: are you saying that even the existing extensions when we negotiate them don't show up in RTP?
21:00* jib files bug 1398343 on his crash
21:00firebot NEW, Tab crashed while trying to revoke cam or mic permission from desktop
21:00* jib gotta run. Nice weekends to everyone!
21:00mjfdrno|irccloud: yep. Im going to get some more data on a real call in a minute
21:01mjfBut the code looks like were not adding anything to the extmaps that allows rtp header extensions to works.
21:07jibng: are you filing a bug on your crash?
21:08ngjib: yes
21:08jibcool thanks!
21:08* jib wasn't sure what "move along" meant :)
21:09* jib is really leaving now
21:11mjfreally, really leaving ;-)
21:13ngI got distracted by another crash that happened while filing the first.
21:18jesupng: 5 crashes, all since 8/29 builds (in fact, all 8/29-8/31 - you shoudl try a newer build!)
21:19jesupng: and it smells like a sec issue (random addresses for the crash)
21:20ngHmmm, I just updated nightly prior to that. I guess I didn't get the latest.
21:22ngUptime of 15 hours ... **begins to doubt sanity**
21:52drno|irccloudmjf: sounds like we really need the RTP parsing in JS
9 Sep 2017
No messages
Last message: 13 days and 7 hours ago