mozilla :: #media

21 Apr 2017
00:56jesupSingingTree: pong (not available long)
00:57jesupdminor|afk: 1 reference left...
00:58SingingTreejesup: Do you know why DestroyRunnable may dispatch another DestoryRunnable? https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaRecorder.cpp?q=MediaRecorder.cpp&redirect_type=direct#391
00:58SingingTreeMy reading of that is that it could be flattened and the extra dispatch removed, but I fear I'm missing something
01:00jesupSingingTree: I think because Stop is async, so we need the Destroy to be behind it (I suspect)
01:01jesupafk
03:44jesupdminor|afk: It links. Pushed to queue
05:04jesupdminor|afk: pushed a small update. Audio calls "work" (though I think I didn't hear any audio output, so still more work to do)
07:09ngnick|ngafk
09:53bwumchiang: bug 1353313 should require uplift.
09:53firebotBug https://bugzil.la/1353313 is not accessible
09:54bencsudo install -m644 <font-name>.ttf installs a font?
09:54benchttps://github.com/hotice/webupd8/blob/master/install-google-fonts#L23
10:14mchiangbwu: yes, after the patch is landed in central and no accident over one day, I will request to uplift.
10:14bwusweet.
11:56dminorjesup: built locally, please let me know what to look at next
12:24jesupwith the latest stuff, I can make audio calls (but get no output). Looking at what&#39;s going on there might be good. I&#39;m investigating why video capture isn&#39;t starting. Note: gum audio capture works, which uses only the AEC/NS code (audio_processing) from webrtc.org.
12:24jesupdminor: ^
12:26dminorjesup: ok, I&#39;ll have a look at the audio stuff.
12:31dminorjesup: are you using https://mozilla.github.io/webrtc-landing/ for testing or something else?
12:32jesupYes, with one-way, and audio-only
12:32jesupdata_test.html works (no surprise). gum_test with audio works (no big surprise, but means hook into audio processing is working, and that we have an input stream.
12:33jesupIt may be easier to modify the page to just use fake:true to get a sine-wave source, which means you&#39;ll have obvious signal all the time
12:34jesupyou can just Save Page As, modify it, and load it from disk
12:56dminorjesup: fwiw, I can receive both video and audio on appear.in
12:56* dminor was curious
13:19jesupdminor: awesome!!!
13:33dminorjesup: I&#39;m not seeing a difference in behaviour on https://mozilla.github.io/webrtc-landing/pc_test.html between nightly and our build. Time advances and I get audio on bottom left and top right. Time doesn&#39;t advance and no audio on top left and bottom right. Am I looking at the right things?
13:35jesupfor a one-way call, that&#39;s right. small <video> elements are send-side (local image/audio), large ones are received data.
13:36jesupdminor: I forgot to un-mute the large lower-left receive element. Audio calls work!
13:37dminorjesup: ok good, just making sure I&#39;m not crazy :)
13:38padenotyay
13:38dminorjesup: I noticed some strange behaviour with the muting on my side on the appear.in call I tried. Do you want me to investigate that, or is there something else I should look at first?
13:40jesupOk, that&#39;s awesome. I&#39;m debugging video capture.
13:40jesupsure, look at htat
13:41jesupalso, when I change pc_test to be fake always (no video gum capture), I get an assertion WebrtcVideoConduit::CreateSendStream() (MOZ_ASSERT(mSendStreamConfig.rtp.ssrcs.size() == mEncoderConfig.StreamCount(),
13:42jesupStreamCount() is 0, ssrcs.size() is 1
13:43dminorafk for a little bit, I can look at those when I&#39;m back
14:06achronoppadenot: would you like to push stereo input and continue from there?
14:11jesupng: we have audio-only calls working in 57, basically first-try after getting it to compile \o/
14:12jesupvideo and screencapture will be the problem children, as always, plus cleanup
14:34padenotachronop, yeah I think so
14:34achronoppadenot: I&#39;ll push the last comments
14:35achronoppadenot: I&#39;ll restrict it to stereo for now
14:38achronoppadenot: up
15:10ngjesup: that is awesome!
15:22padenotachronop, I think we should not arbitrarily retrict to stereo, there is no real reason to limit to two channels
15:23achronoppadenot: I will change it right after we finish with sound flower test
15:23padenotachronop, sure
15:23padenotachronop, which reminds me, I need to push my new patch
15:24achronopprobably will be landed together with your fix and anything else we find
15:25padenotnext I&#39;ll be trying to use virtual audio cable on windows to have the same thing as soundflower
15:25padenotit&#39;s really handy
15:27achronoppadenot: about chunmin comment I&#39;m not convinced we want that
15:28achronopunmapped is not invalid and right now we handle both the same, returning undefined
15:29achronopfor a valid layout that contains unmapped channels we return undefined
15:29achronopis this what we want?
15:29jesupdminor: ng: one-line fix and I have video gum working
15:30jesup&quot;error = 0;&quot; :-)
15:31jesupvideo calls, not yet, debugging crash
15:31jesupdminor: you might want to also check desktop capture. will push the one-liner
15:32jesupah, same assertion as with fake video (makes sense)
15:49jesupdminor: disabled a couple of assertions - don&#39;t crash, also doesn&#39;t do remote video. Working through why (has to do with number of streams and the video encoder factory stuff they added instead of structure-based config)
16:06ngjesup: heh, nice
16:35dminorjesup: we&#39;re attempting to send audio using NullTransport rather than AudioConduit on appear.in, I&#39;m investigating further
17:04jesupodd, since audio works in pc_test calls
17:05jesupdminor: ^
17:10dminordefinitely strange
17:10dminorperhaps a symptom of a different problem somewhere else
17:22jesupIt may pass the data through NullTransport as well, perhaps
17:32dminorjesup: the NullTransport is set in MediaEngineWebRTCMicrophoneSource::AllocChannel(), but I&#39;m not seeing calls to WebrtcAudioConduit::SendRtp. So I guess it&#39;s not a mistaken use of NullTransport after all but there seems to be something wrong here.
17:33jesupdminor: audio-only call?
17:33dminorjesup: no, I&#39;m trying appear.in, so it does try to get video as well.
17:33dminorI can hear and see video, but I don&#39;t send anything
17:34jesupyeah, that&#39;s not likely to work well yet. Let&#39;s hold off on appear.in
17:34dminorok sure
17:34dminordesktopcapture then?
17:34jesupfocus on building blocks. Working to get video encoders configured; yeah, look at desktop capture. Likely dragons there; lots of rewrite
17:47mreavyng: ping
17:47ngmreavy: pong
17:49k_jhi
17:49k_jhas firefox changed the permissions on media devices recently?
17:50k_jit seems that i can use the webrtc audio from the mic only when https, while video is ok with http
17:50k_jplease confirm
17:51fippodrno: bwc: so i&#39;ve pondered on this a=ice-options:trickle in a media sections which is valid in the sdp draft referenced by ice-bis.
17:51fippohow does RTCPeerConnection.canTrickleIceCandidates behave if one mediasection has those ice options and the other does not?
17:52fippoabr: ^^
17:52drnofippo, bwc: to make matters worse if I read it correctly it allows you to be an ice-lite implementation level, plus then supporting trickle one m-section, but not the other
17:52jesupk_j: doesn&#39;t sound right
17:52k_jjesup, what does not sound right?
17:53drnofippo: majority wins? :D
17:53k_jjesup, that video is still possible with http, or that audio should also be allowed with http?
17:53jesupthere should be no lock to https for mic access. Can you confirm with http://mozilla.github.io/webrtc-landing/gum_test.html (and https: to the same site)
17:53k_jlet me check
17:55drnofippo: http://searchfox.org/mozilla-central/source/dom/media/PeerConnection.js#1022
17:55drnoso our current implementation only pays attention to the session level ice-options
17:56jesupdminor: found another no-longer-relevant check on # of streams
17:56k_jjesup, it works, I think there is something wrong with my code, but this is really strange, it&#39;s code that had been working for years and really this problem only happens when switching to http
17:56drnofippo: hold on. I overlooked the OR in line 1025
17:57drnoso that looks to me that if session or any of the m-section contains trickle we turn on canTrickel
17:57jesupdminor: progress, now crashing in the encoder
17:57jesupstill # of streams config stuff
18:04fippodrno: lets make canTrickleIceCandidates an array of mediasections for which can be trickled. wait... that doesn&#39;t make sense either...
18:05fippoyou would have to send the full sdp if a single section does not contain trickle.
18:06drnofippo: well I gues you could wait for EOC for the sections w/o trickel support, then send your SDP and trickle the rest
18:06drnobut who on earth would want to implement such a logic?
18:06drnoplus: what is the lickeliness of one m-section getting its EOC way before others?
18:10k_jjesup, do you see any problem ? this always worked so far: var constraints = {}; constraints[&#39;audio&#39;] = { optional: [{ echoCancellation: false }] };
18:14lgrahlHey guys, is there a general purpose buffer I can use to buffer binary data or is nsAutoCString the way to go?
18:21fippodrno: https://github.com/ice-wg/trickle/issues/11
18:23rilliankamidphish: yes, should be good to land.
18:41abrfippo: I see the issue, and it looks like things are going in the right direction; however, Ill also note that the ICE SDP document does have handling that kind of disambiguates this for implementations:
18:41abr In [RFC5245] ICE options could only be defined at the session level.
18:41abr ICE options can now also be defined at the media level. This can be
18:41abr used when aggregating between different ICE agents in the same
18:41abr endpoint, but future options may require to be defined at the media-
18:41abr level. To ensure compatibility with legacy implementation, the
18:41abr media-level ICE options MUST be aggregated into a session-level ICE
18:41abr option.
18:41abrSo Firefoxs current implementation of only using the session-level options should continue to work for the foreseeable future.
18:42fippoabr: i&#39;ll check if chrome does that, thanks!
18:44abrfippo: On a quick test, Chrome doesnt appear to include a=ice-options at all.
18:46abrfippo: Which isnt surprising. I think Chrome had effectively stopped updating their impleentation before the requirement to use ice-options was added to JSEP.
18:46fippoabr: that was fixed earlier today. but i suspect it only puts ice-options into media sections
18:46fippothey used to put gice there... but that went away thankfully :-)
18:47abrThat would be odd. JSEP 5.2.1 says to put it in session-level
18:49fippoabr: the comment in the code refers to draft-petithuguenin-mmusic-ice-attributes-level-03 -- i did not want to check how ancient that is. but will complain
18:50abrIf it were a human child, it would be in Kindergarten by now.
18:51abrIn many cases, it would be able to read simple sentances.
18:51abrLike, it *EXPIRED* in 2012.
19:11ngabr: woof that is dark, oh you mean the spec.
19:11* mjf chuckles
19:11abrng: Your mind goes to scary places
19:15jesupdminor: ng; fixed the configuration issue, now I&#39;m feeding frames in, but not getting frames (or packets?) out. walking through it
19:17jesupk_j: seems reasonable, but check with jib on monday (jib is on PTO) or email him
19:20jesupk_j: and/or file a bug with an example -- you could modify gum_test pretty easily to show this
19:20k_jjesup, thanks
19:30dminorjesup: cool, I&#39;m digging into the desktop capture stuff, fixed a trivial problem, now dealing with some of the refactors to the render callback code
20:17kamidphishrillian: done
20:19rillian\o/
20:27* drno consinders launching an ICE implementers certification to fight only Chrome interporable implementations
20:34* mjf cheers for drno
21:09rillian&quot;Compiling cubeb-pulse v0.0.1&quot;
21:34ngdrno: it should involve a written test on filing chrome bugs
21:35drnong: a chrome bug which got fixed, or is filled good enough? :)
21:37drnong: maybe filled vs fixed is bronze vs. silver level degree at the end?
21:38ngdrno: silver is for getting stars, gold is for getting it fixed.
21:38ngdrno: the test also needs a section on proper brow furrowing
21:39drnong: and a fixed spec issue in platinum
21:39drnos/in/is
21:41ngdrno: you get a platinum copy of the PR
21:55jesupdminor|afk: ng: working video calls with fake video. Working video gum. Have a crash (unaligned access) with video calls with real video... but really good progress!
21:57ngwoot!
22:10drnojesup: awesome. sounds like its compiling now? ;)
22:13jesupcompiing, running. audio calls work. video calls now work with fake video. video gum works. datachannels works. screencapture still needs some work (dminor is on thart
22:13* jesup goes to push his fixes
22:26* jesup pushed
22 Apr 2017
No messages
   
Last message: 94 days and 22 hours ago