mozilla :: #media

13 Sep 2017
06:35jyamattwoodrow|away: ping
06:47jyajw_wang: you're a magician at reading backtraces. i can't make sense of this one:
06:47jyait shows a null deref at a line that doesn't have a nsCOMPtr dereference.
06:47jyaand the add code calls a static function
06:50jw_wangjya, which static function?
06:50jyathe crash is line 400
06:54jw_wanghmmm... I can't find any nsCOMPtr either...
06:55jw_wangand I don't think the compiler will merge the code of the arrow operator of nsCOMPtr and RefPtr
06:56jyai wonder if it could inline the code of D3D11Checks.cpp D3D11Checks::DoesNV12Work(ID3D11Device* device)
06:56jyawhich does use a nsCOMPtr nsCOMPtr<nsIGfxInfo> gfxInfo = services::GetGfxInfo(); and then use it without checking if the pointer is null
06:57jyaI did so, because everywhere else using that same line, never check the return value
07:00jyayes, there it does, but in the code i modified and the init code it doesn&#39;t
07:00jyacan&#39;t reproduce the crash here either which doesn&#39;t help
07:15jyajw_wang: yes, that is it.. the code must be inlined.. weird for a debug build
07:19jw_wangso when will services::GetGfxInfo() return null? during shutdown?
07:21jyajw_wang: it seems that the call to the other code doing similar access to gfxInfo is only done if you&#39;re in the XRE_Process
07:21jyaI mean parent process (XRE_IsParentProcess)
07:22jyaif that&#39;s the case, it means my entire code is broken, as my aim is to pass to the GPU process if NV12 is usable or not
07:27jw_wangit is funny that you can&#39;t access gfxinfo in GPU process.
08:05jyajw_wang: yeah, it&#39;s a pain, I need to block certain driver version
08:05jyacan&#39;t just rely on the device id
08:06jyaI wonder the whole point of this D3D11DeviceStatus which is supposidly passed over IPC
08:06jyayet, it is being re-initialised in the GPU process and it doesn&#39;t seem the data is ever used
08:09jyasomething seems broken here
09:19padenotachronop, where are you with the osx issues ?
09:44achronoppadenot: I am try to apply jesup&#39;s comment (it&#39;s not just osx)
09:45achronoppadenot: r u talking about bug 1396879?
09:45firebotBug is not accessible
09:46padenotachronop, yes, but also the deadlock thing
09:46padenotachronop, I think for the deadlock we should treat the 3.5mm jack as a usb device, re-init everything manually
09:46padenotthe automatic switch thing is not reliable
09:47achronoppadenot: yeah probably, it&#39;s the platform that stop triggering the callback
10:33jyajhlin: ping
10:34jyaOr as my phone wants it
11:36pehrsonspadenot: do you remember when bug 1399423 should have worked?
11:36firebot NEW, Restarting pulseaudio kills audiocapture until Firefox restart
11:36pehrsons52 is broken too
11:36padenotaround 25 maybe
11:41padenotjesup, ping
12:16padenotachronop, pehrsons, I wouldn&#39;t focus on it too much, it&#39;s an easy fix but we have other things to do
12:16padenotre. bug 1399423
12:16firebot NEW, Restarting pulseaudio kills audiocapture until Firefox restart
12:16pehrsonsI agree with you
12:17padenotwe simply need to re-connect to the pulse daemon when we find out our connection does not work anymore
12:17pehrsonsbeing not a regression makes it lower prio even
12:19padenotdoes it happen with output only things ?
12:19padenotthis used to not work, then it got fixed, maybe we broke it again ?
12:19achronoppadenot: can you check my cubeb review?
12:20pehrsonspadenot: I only checked per my STR, didn&#39;t find anywhere where it works
12:20pehrsonsperhaps it worked some time ago for output
12:21padenotpehrsons, we regressed for output as well
12:21padenotmaybe not
12:21padenotno it works
12:21padenotit just takes maybe a second or two
12:21pehrsonsfor input as well
12:21padenotspotify is busted
12:21padenotpehrsons, no, for input it&#39;s broken it seems
12:22padenotachronop, yes
12:23padenotachronop, does it really always work when the device is the default?
12:24padenotachronop, I thought this was the issue
12:24achronoppadenot: I am not sure what you mean
12:25padenotachronop, ok you&#39;ll see the review comment, it&#39;ll be clearer with the context
12:45padenotjya, the AudioConverter only works with interleaved audio right ?
13:10jesuppadenot: pong
13:10padenotjesup, I picked up your patch from yesterday
13:10padenotjust so you know
13:11padenotnot calling into audio API is important for sandboxing
13:11jyapadenot: yes
13:12jesupyes. I have one more partial patch I&#39;ll upload that gets rid of a bunch more from MediaEngineWebRTCAudio. Thanks for picking it up
13:12jyapadenot: the original code could do anything, but right now, the output format must be interleaved
13:12padenotjya, that&#39;s not an issue, I was just making sure, but then I read some code and it was clear
13:13jyaIIRC, I have asserts about it.
13:13* jya trying to comprehend some of the gfx ipc architecture
13:14padenotjya, ok cool, I haven&#39;t run the code just yet, finishing stuff up
13:14padenotjesup, those interfaces are _really_ annoying
13:14padenotI don&#39;t know why we even bother
13:21jyapadenot, jesup : I&#39;m right in the middle on something I&#39;m struggling with, I wouldn&#39;t have much to add to webrtc meeting today. so I won&#39;t join
13:21padenotjya, ok
13:21jyahappy with the dates of 16th to 20th BTW?
13:22padenotI&#39;m free
13:28padenotmreavy, I&#39;ll be a minute late for the call
13:28padenot(just a minute)
13:38jesuppadenot: I&#39;ve uploaded the last patch for that bug with the final changes I made (compiles, doesn&#39;t work due to graphrate() issues I think). Removes VoEBase and channels entirely. :-)
13:38padenotjesup, cool
13:38padenotjesup, I&#39;ll have a look after the calls
13:39jesup(my bzexport failed the first time)
13:53padenotjib, want to re-try hangout ?
13:54pehrsonspadenot: achronop: so I have a ~9s latency on my output right now.. can I live debug this?
13:54padenotpehrsons, what os
13:55pehrsonspadenot: linux
13:58mreavypadenot: can you rejoin the room - moz-webrtc/
13:59padenotpactl list
13:59padenotpehrsons, ^
13:59padenotput that in a pastebin
14:00padenotit&#39;s going to spit a bunch of text
14:02pehrsonsstarting and stopping an oscillator node is ~9s delayed :-)
14:08dminorpehrsons: sorry, I missed the first part of what you said about screen sharing testing. not enough to put on headphones, I also have to turn up the volume :/
14:08pehrsonsdminor: hah. just wondered if you had thought about it. Since you fixed it I figured you might have had some thoughts on how to mochitest.
14:09pehrsonsI was thinking of writing something up
14:09pehrsonspadenot: anything else I can do? fwiw, audio context nodes (i.e., MSG) are delayed, playback is not.
14:10padenotpehrsons, yeah, underrun issue
14:12pehrsonspadenot: in the beginning especially I was hearing some audio artifacts -- am on wifi today. I&#39;m guessing that could play part in this?
14:12pehrsonspacket loss concealment etc
14:12padenotpehrsons, yes, pulse adjusts its output buffer if it underruns
14:14dminorpehrsons: I haven&#39;t thought about it too much. I guess different colours in different quadrants and make sure the resulting video is offscreen so that you don&#39;t end up with the picture in picture in picture... effect.
14:14dminorpehrsons: I can take over writing the test if you are otherwise occupied
14:14dminorjib: would you like me to do the pi-request for screen sharing?
14:14jibthat would be awesome!
14:15pehrsonspadenot: right, so we&#39;re looking at &quot;device.buffering.buffer_size = &quot;352800&quot;&quot;?
14:15dminorjib: will do :)
14:15pehrsonsor I guess &quot;Buffer Latency: 8407528 usec&quot;
14:18pehrsonsdminor: no, I think it&#39;s a reasonable amount of work for me to finish by friday.. my other bugs need more and I hate to leave them half-done
14:32padenotachronop, it&#39;s possible to squash via the gh interface, I&#39;m going to merge now once the appveyor test is done
14:32achronoppadenot: cool thanks
14:58jesupjib: interim now, right?
14:58jibyes, thanks for the reminder
14:59jesupwhere is the info on how to connect?
15:00jesupjib: ^
15:01jibone sec, restarting ff
15:02jibin pm
15:12jesupjib: I need to join the regression-triage meeting; can you ping me if they&#39;re on a topic I care abouit? especially the scaling issue, though that may simply been pushed over to the JSEP draft
15:30pehrsonsjib: dminor fyi the fullscreen canvas works fine in a mochitest. Now let&#39;s see how the capture fares...
16:00achronoppadenot: can you check that comment
16:00firebotBug 1375327 UNCONFIRMED, getUserMedia() cannot capture audio on Firefox, Windows 10
16:00achronoppadenot: both logs look correct
16:01achronoppadenot: cubeb wasapi reports input frames
16:03achronoppadenot: the reporter mentioned the error is relevant to his external device plug or unplug, are you aware of anything similar?
16:09padenotachronop, differing requested and actual rate for input, plus stereo headset but mono request for input
16:09padenotstereo headset input
16:11padenotnot that it should be an issue, it works fine locally, but it&#39;s a non common setup
16:13achronoppadenot: if I ask him to configure his headset with 48000 Hz for in/out would be a good debug step?
16:13padenotmaybe yeah
16:14padenotachronop, also ask the person to check which device is chosent
16:20gcpjesup: there&#39;s nothing enforcing a signle camerasparent afaik
16:20gcpjesup: in fact, it breaking with multiprocess isn&#39;t very surprising
16:21gcpgcp: there was some talk of unifying work done for B2G to have a broker camera broker that could share camereas, and then B2G got canned, etc
16:21gcpproper camera broker
16:25jesupgcp: ugh.... though they should be in same process, so you should be able to open it twice. But there may be bugs I suppose.
16:25gcpit depends on OS
16:26gcpon Android, it (of course) even depends on the camera driver
16:26jesupgcp: If this is real/common, this is a big problem for e10s.
16:26gcpcan&#39;t share camera to multiple tabs?
16:28jesupyes. It&#39;s not a huge usecase, but there can be real uses from multiple tabs. Including testing your code by calling from one tab to another. Or recording from one tab while in a call in another.
16:28jesupSo maybe not a *huge* issue, but an issue for sure
16:29gcpSure. But we&#39;ve had this issue for a while.
16:30gcpHmm, I guess without e10s multi mediamanager hid the problem?
16:30gcpOpening multiple MediaEngineRemoteVideoSource to the same thing would&#39;ve just failed as well in e10s vs e10s multi
16:30gcpCan&#39;t get around the fact that CamerasParent opens the actual hardware (read: let do that)
16:31gcpAnd doesn&#39;t have any smarts wrt sharing devices.
16:31gcpWe had code and a design for this from b2g.
16:32jesupgcp: yeah, if you access the same device from MediaManager (same process), you get the same stream
16:33gcpbug 1073017
16:33jesupBut since you&#39;re not going through MediaManager for CamerasParent, you don&#39;t get sharing in the Master process with multiple CamerasParents
16:33firebot NEW, [Camera][Gecko] Move camera manager into the b2g parent process
16:34gcpAndrew Osmond worked on this. He&#39;s still at Mozilla.
16:34gcpjesup: right in the parent mediamanager and cameraparent are not friendly
16:35firebotBug 1194699 NEW, [e10s][link-clicker side] Camera and microphone not shared in a new conversation window during a cal
16:35gcpassigned to me!
16:35jesupAnd you didn&#39;t land a fix?!!! ;-)
16:35gcpI&#39;m seeing the secondary CamerasParent object being constructed in the parent and it attempting to reopen the camera. Given that these are now in the same process, that shouldn&#39;t fail, but it does.
16:36gcpForgotten because we shelved Hello.
16:39achronoppadenot: cubeb is green, if you think is ready I could start the import
16:39padenothop, merged
16:39padenotand squashed
16:47achronoppadenot: import contains only this one, can I carry over the r+?
16:47padenotachronop, ues
16:48padenotachronop, can you look at my PR ?
16:48achronoppadenot: sure but I do not see it
16:59achronoppadenot: hmm I need to take a better look tomorrow, I will hold the import
17:01padenotachronop, we can do multiple imports
17:09jesuppadenot: so please go ahead and take that bug - bzexport (grr) probably re-assigned it to me. those patches remove all the VoE junk; it just uses AudioProcessingModule::Create() now
17:09jesupthere&#39;s one #if 0&#39;d section that needs updating,
17:09padenotjesup, I did substantial work on your patch today, but it&#39;s not ready, got side tracked by the meeting and a PI request
17:11jesupNote I added another patch that did the final removals of VoEBase/mChannel/etc
17:11jesupmuch simplified.
18:38ngmjf: ping
20:40nground to the nearest 1/4 pixel
20:42ngspicy fds
22:21firebotBug 1352016 FIXED, thick green line on the right and/or bottom of the HTML5 video
23:26kentuckyfriedtakahejya: looks like your patch got accepted for beta
23:30kentuckyfriedtakahekinetik: do we know how often audio over RDP is used? It seems common enough that we always get bugs filed about it pretty quickly
23:31kinetikkentuckyfriedtakahe: no idea
23:31kinetiki&#39;ve only ever seen 2-3 bugs related to it iirc
23:35jyakentuckyfriedtakahe: I was referring to the tracking flag
23:36kentuckyfriedtakahekinetik: I&#39;ve commented in bug 1385207; feel free to contradict me if you think I&#39;m wrong here
23:36firebot NEW, Audio over RDP connections not working in 57
23:37kinetikkentuckyfriedtakahe: sounds fine
23:37kinetikkentuckyfriedtakahe: btw sandboxing also broke PulseAudio on some configurations: in case you haven&#39;t seen it
23:37firebotBug 1396542 UNCONFIRMED, Firefox 57 audio fails on some Linux machines
23:38kinetikhopefully the scope of that one is fairly limited
14 Sep 2017
No messages
Last message: 8 days and 10 hours ago