mozilla :: #media

18 May 2017
00:04rilliankamidphish: ok. Thanks for the reminder. Will have to be tomorrow though.
01:52kamidphishrillian:
01:52kamidphishkinetik: ping
02:15kinetikkamidphish: hi
02:17kamidphishkinetik: Looking at the cubeb interface, I have to make an API breaking change to cubeb_device_collection_destroy to move the logic into the backends. Is that OK? Also, does cubeb_device_info_destroy need to be a public API?
02:19kinetikkamidphish: yeah, that's fine
02:19kinetikkamidphish: it doesn't look like cubeb_device_info_destroy needs to be public, i thought there was an API to get the current cubeb_device_info*, but it's actually cubeb_device*
02:20kamidphishkinetik: Ok. I'll remove the cubeb_device_info_destroy API and make it private to the back ends.
02:22kinetikkamidphish: sounds good
04:04jesupHoly... running mochitest with --debugger=rr --debugger-args=&quot;record -M&quot;, with MOZ_LOG=signaling:5,jsep:5,GMP:5,webrtc_trace:5,DataChannel:5,SCTP:5,rtplogger:5 - I saw it&#39;s losing SCTP/DataChannel packets. I trace down from the SCTP output routine (which does mSTS->Dispatch(WrapRunnable(RefPtr<...>(this), &SendPacket, ...) basically). When PutEvent() queues the runnable, I did a Count(...)...
04:04jesup...on the queue. 719 events waiting to be processed on STS... (and note this is e10s, so that will end up going over IPC for added fun!)
04:04jesuproc: ^ you might be amused
04:06jesupit is a debug, no-opt build, running an e10s mochitest. Not ideal perf case, but that&#39;s really impressive
04:07rocrunning it under rr hurts too
04:07jesupI&#39;m still surprised they&#39;re lost... I see audio packets sent and received, but maybe that&#39;s with high delay
04:07jesupoh yeah, for sure :-)
04:08jesupit doesn&#39;t fail if I don&#39;t use rr, or even with rr if I don&#39;t log all the packets with rtplogger:5
04:10jesupon like the 10th retransmit a packet does get through (perhaps the 1st one) and is received/processed, but it looks like the INIT-ACK never gets back to the INIT sender.
04:13drnojesup: are you trying to figure out where in the whole chain things get dropped?
04:15jesupwell, I think no packets shoudl be dropped, unless we&#39;re overrunning OS socket buffers or some such, which I hope we are not. If we&#39;re dropping it (as opposed to delaying), I want to know where and why.
04:15drnojesup: have you seen that the macos 10.12.5 update has fixes an issue where audio may stutter when played through USB headhpones? :)
04:16jesup?!
04:16drnoIm just looking at the latest macos OS update
04:16jesupI&#39;m continuing in rr, up to 6 INIT retransmits without a single call to SendPacket
04:17jesupAh, finally!
04:18jesupso, submitted around event 672898, SendPacket gets called for the first time at ~783954
04:18drnoso if from tomorrow on my webrtc calls break I know (kind of) why ;)
04:26rocjesup: so you need replay-only logging, so you can log all the packets without the performance hit :-)
05:08kamidphishkinetik: Do you want me to assign the review of the device_collection_destroy to you?
05:08kamidphishOr just let it be?
05:10kinetikkamidphish: try achronop for that one first, i can do it if doesn&#39;t have time
05:10kinetik+he
05:11kamidphishkinetik:
05:11kamidphishkinetik:
05:11achronopkinetik: kamidphish: I can take it
05:14kamidphishachronop: Thanks
05:31achronopkamidphish: the first comment says that it is not ready to land, is that accurate?
05:42kamidphishachronop: I removed that. Did the update not show?
05:43kamidphishachronop: On kinetik advice, I created the pull request to get the CI to kick in and put that message in.
05:45kamidphishachronop: This is what I see
05:45achronopkamidphish: just checked it on web and the update is there, the initial comment was on my mail
05:46kamidphishachronop: Ok. Cool.
08:24kentuckyfriedtakahecpearce: https://addons.mozilla.org/en-GB/firefox/addon/devtools-media-panel/?src=search
09:34cpearcekentuckyfriedtakahe: \0/
14:21jesupFound a nasty race condition with the MediaConduitInterface WebrtcCallWrapper - in video-only calls (like test_peerConnection_simulcastAnswer), if there&#39;s a packet-loss/reception/etc event it tries to log just as PeerConnectionMedia is destroying the wrapper, it can destroy the mEventLog instance before it destroys the mCall instance, and then event log calls from lower down will hit a...
14:21jesup...pure-virtual crash
14:21jesupPhew..... rr for the win!
14:22jesupLuckily I hit it when testing in rr
14:22jib
14:23jesupIt&#39;s been there since the 49 update I&#39;m sure (but by chance if audio is in use it clears mCall in ~WebrtcCallWrapper())
14:23jesupso the impact isn&#39;t that huge (and it&#39;s a race condition on top of that)
14:23achronopjesup: when is a good time to discuss about stereo gUM?
14:23jesupin 5 min?
14:24achronopsure even more just ping me when you can
14:25achronopI will attend the profiler talk in about 1 hour and 30 min but I think you are also busy then
14:26jesupyes
14:51jesupdminor: https://treeherder.mozilla.org/#/jobs?repo=try&revision=87d919bd4647189e40e3142864bcfe1c5404b212&selectedJob=100126389 with your latest patch
14:53jesupachronop: available now?
14:53achronopjesup: sure
14:53jesupone sec
14:54achronopjesup: let me give you the intro info in the mean time
14:54achronopeverything start from MediaEngineWebRTCMicrophoneSource::NotifyInputData which is driven by the AudioCallback driver
14:55achronopdriver has been enhanced to get stereo input when the device allows it
14:56achronopPassThrough == true when EC&&NS&&AGC are off
14:57achronopInsertInGraph has been enhanced to accept stereo input and everything is fine there
14:57jesupok
14:57dminorjesup: good ol&#39; static analysis, I&#39;ll fix those up
14:57achronopthe problem is when PassThrough == false
14:57jesupok
14:58achronopand we go through PacketizeAndProcess which goes through the webrtc code
14:58jesupExternalRecordingInsertData
14:58achronopand there limitation (at least that my finding)
14:59achronopI believe I cannot send a stereo stream there and that is something I would like to confirm with you
15:00jesupit does derive the number of channels before calling PrepareDemux
15:00achronopit does here TransmitMixer::GenerateAudioFrame
15:01achronopwhich is inside the PrepareDemux
15:01jesupright, and that seems to support stereo
15:02achronopthis one return always channel = 1 in my case: GetSendCodecInfo
15:04jesupi.e. num_codec_channels
15:04achronopright
15:04achronopand codec_rate = 32000
15:06jesupachronop: have you walked down into GetSendCodec() to see where it comes from?
15:07achronopyeah, channel->Sending is true
15:08achronopit comes from line 314
15:09achronopCodecInst is more complicated, I am not sure where it is set
15:10jesupI meant down where it calls channel->SendCodec(), which retrieves from the ACM database, which is populated (I think) from acm_codec_database.cc
15:10jesupfirst question is &quot;what codec does it think it&#39;s using&quot; since we&#39;re doing input here
15:11jesupso it isn&#39;t connected to a PeerConnection
15:11jesupperhaps L16 @ 32K?
15:11jesupbut there are L16 Stereo codecs too
15:11achronopno it is not, I get the stream and set it to an audio element
15:12jesup // Set &quot;codec&quot; to PCM, 32kHz on 1 channel
15:12jesupin MediaEngineWebrtcAudio.cpp
15:12jesupthere you have it :-)
15:12jesup#define CHANNELS 1
15:14achronopjesup: fantastic! :)
15:15achronopjesup: can I change just the channel there?
15:17jesupsure. You may want this to depend on PassThrough
15:18jesupAlso, it&#39;s unclear if you can go over 32K there, but probably you can
15:18jesupbut only if AEC is off I suspect - may be worth trying though!
15:19achronopPassThrough is one option but the real test would be to query the device via driver
15:21achronopI do not think driver is available there
15:24achronopthe good thing is that PassThrough is set when AllocChannel is called
15:39achronopjesup: setting the codec channel to 2 works just fine, anyway don&#39;t bother any more, that was enough for me start digging in this direction
15:46bwcUgh. The next door neighbor&#39;s dog got into the back yard and chewed through some network cabling...
15:46bwcI just burned almost an hour trying to figure out what had gone wrong.
15:47mjfOhhhh!!
15:47mjfYellow-bellied Backhoe, but different...
15:48bwcAlso damaged the broadband line pretty badly, I&#39;m going to have to wrap it to protect it from the elements.
15:49mjfAnd repair the dog-sized hole in the fence.
15:49mjfHave you thought about an electric fencer ;-)
15:49bwcI&#39;m starting to consider it.
15:49mjfThe dog clearly has a thing for chewing on wires...
15:51bwcBut, now I need to go get some network cable and other odds/ends.
15:51bwcSo much for getting actual work done today.
16:35mjfjesup: ping
16:36jesupmjf: pong
16:45ngbwc: you should wrap your lines in something a dog won&#39;t eat, e.g. the food you bought for it.
17:37mjfjib: ping
17:37jibmjf: pong
17:38mjfJust wondering if you were going to have time to look at the review for Bug 1365291 before too long? I dont want to go too long or Ill need to rebase (again :-))
17:38firebothttps://bugzil.la/1365291 NEW, mfroman@nostrum.com Make sure &#39;this&#39; is captured on dispatch to STS thread in AddRIDExtension_m and AddRIDFilter_m in Me
17:38jibthanks for the reminder, will look right now
17:40jibmjf: done, sorry for the delay!
17:40mjfNo worries! I know youre busy.
17:42jibmjf: thanks for fixing it. and sorry about the RefPtr<> Move() thing. Never realized that too was only used in testing :P
17:43mjfheh - no problem!
17:43mjfThanks for catching the this capture problem.
17:51rillianjya: how is the rust training?
17:51jyarillian: finished yesterday
17:54drnorillian: everyone keeps talking about rust trainings. do you have any pointers for more information about that?
17:54drnosorry wrong order. I guess my question is/was more for jya :)
17:55jyadrno: you can check this one
17:55jyahttps://skade.github.io/rust-three-days-course/presentation/#/
17:55* ng is also interested
17:55jyathis is the 3 days course I&#39;ve just completed
17:56drnooh even in German :D
17:56drnojya: awesome. thank you
17:56jyathe two people running the course were German
17:57drnoI think I need to twist my brain too much to read about programming in German ;)
17:58ngdrno: trying to keep your German from getting Rusty?
17:59drnong: Im more worried about getting physically rusty then my German language
17:59ngdrno: heh!
18:00drnoit just if you talk about any IT related things in German you keep using the English words. Except if you are Siemens, which published hand books completly in German only for some time.
19:52kentuckyfriedtakahejib: Apparently my network is blocking connections
19:52jibhmm
19:53jibyeah it doesn&#39;t seem to matter what I do on this end
20:01jesupdminor: ping
20:02jesupkentuckyfriedtakahe: if you&#39;re in taiwan, their network was renowned for blocking UDP connections. Might need to move to Guest
20:06jesupdminor: can you fix the types issue? It&#39;s blocking Try runs
20:07jesupdminor: also: https://treeherder.mozilla.org/logviewer.html#?job_id=100126359&repo=try&lineNumber=2382 (gtest changes broke all windows builds)
20:15dminorjesup: I&#39;m working on them atm, perhaps just drop my patch for now if it is causing problems
20:15jesupyup
20:16dminorthe asan stuff should be ready soon, the windows stuff is more involved. I got past the first build problem, but there are other, compiler related things that I&#39;m stuck debugging on try
20:17dminorsorry about the trouble, I forgot to do a try run before pushing to the queue, which I really should have done given the number of problems I had the first time around with the gtests.
20:18kentuckyfriedtakahejesup: I&#39;m at home. Power cycling my dsl modem seemed to fix it
20:19kentuckyfriedtakaheperhaps it leaks socket numbers and eventually runs out
20:32dminorjesup: I have try pushes for both the static analysis and the windows build on the go, I&#39;ll check back on them later on tonight.
21:49dminor|ptojesup: latest tries look green, I&#39;ll be afk for a bit but I&#39;ll push the fix later on tonight
22:05jesupdminor|pto: thanks
22:43Caspy7so, someone points out an interesting phenomenon on imgur...
22:43Caspy7on gifvs such as https://i.imgur.com/iOjTGck.gifv
22:43Caspy7if you right click and say &quot;save video as&quot; you get fed a &quot;gifv&quot; file
22:45Caspy7while in Chrome you get the MP4
22:48Caspy7the user reports that if they spoof their UA to &quot;asdf&quot; then it offers to save as MP4
22:50dminor|ptojesup: np, I&#39;m waiting on this to finish and then I&#39;ll push, I *think* the remaining problems are not gtest related: https://treeherder.mozilla.org/#/jobs?repo=try&author=dminor@mozilla.com&selectedJob=100243351
22:52TrelI as directed here to ask about this, if you try to save this video (right click save video) in Firefox, you get a gifv file which contains the html of the page. If you do it in chrome, you get the mp4 file with the actual video. And I&#39;ve gotten it to work the same in Firefox by UA spoofing
22:52Trelhttps://i.imgur.com/iOjTGck.gifv
22:58Caspy7Trel: this is what I already wrote: http://logs.glob.uno/?c=mozilla%23media#c335226
23:00Caspy7additionally if you right click it and say &quot;view video&quot; it used to show you the MP4 iirc, but now just shows you the gifv again
23:12cpearcepadenot: is there work in progress to make WebAudio usable from Web Workers? Is that AudioWorkers?
19 May 2017
No messages
   
Last message: 10 days and 14 hours ago