mozilla :: #media

20 Apr 2017
00:19rilliankamidphish: woot!
00:19kamidphishrillian: Can I get you to review it?
00:20rilliansure
00:35rilliankamidphish: r+, but you need to add me as a collaborator if you want me to merge it.
00:35rillian:)
00:36kamidphishrillian: will do
02:40geraldSingingTree: Bug 1356506 is one of those int64_t -> media::TimeUnit conversion bugs I hinted at this morning. There have been quite a few already, TimeUnit is spreading like <insert cliche> at the moment!
02:40firebothttps://bugzil.la/1356506 NEW, jwwang@mozilla.com Change the type of MediaData::mTimecode to TimeUnit
02:41SingingTreegerald: Cheers. Let me take a look
03:00SingingTreeAnyone familiar with ErrorResult? I&#39;ve run into one that is throwing but is then seemingly unhandled and could use a brain to pick about it
03:04SingingTreeIn particular this code: https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaRecorder.cpp#390 makes a call with a ErrorResult which may have Throw called on it, but then never handles that. Which looks odd to me
03:17SingingTreeAfter diving the code: looks like if it does throw it will result in an assert since it&#39;s not handling the internal exception. It will also not end up passing the exception to JS, which may be desirable
09:01padenotSingingTree, still here ?
09:02padenotSingingTree, you probably want `IgnoredErrorResult`
09:03padenotwhich kind of conveys the intent you&#39;re going to ignore it, in a way, it&#39;s when you know what you&#39;re doing
09:24SingingTreepadenot: Cheers
09:40achronoppadenot:
09:41padenotachronop, yes ?
09:41achronoppadenot: early enter ... so should a restrict the channels to 2 ?
09:42padenotachronop, I don&#39;t know, what do you think ?
09:42achronoppadenot: I would say no
09:42padenotis it easy to just have something generic that handles anything ?
09:42padenotit must be
09:43achronopWe could let it work with any channel and claim that we support up to 2 for now
09:43padenotwell if it works with any channel, we can just do tht
09:44achronopand yes it&#39;s easy to let it work for any number of channel, it&#39;s not easy to test
09:45padenotachronop, are you familiar with sound flower ?
09:45achronopnot really but I can be
09:47padenotit might be able to simulate a multi-channel input device
09:47padenotI&#39;m installing it, we&#39;ll see
09:48achronopdo you mind push that first and continue with sound flower?
09:51padenotyeah
09:51padenotI think soundflower makes firefox crash
09:51padenotI&#39;ll debug now
09:55* achronop installed Soundflower
09:57padenotyeah it crashing when activating the 64 channel output device and playing anything
09:57achronop64 channels, isn&#39;t it too much?
09:58padenotit certainly should not crash
10:01padenotok I&#39;ll get a fix soon, it&#39;s easy
12:17padenotachronop, so, I managed to setup things so that I can record the output of firefox using sound flower
12:17padenotchunmin, ^
12:17padenotit works with a 5.1 file, now, with my patches
12:21achronoppadenot: fantastic!
12:21achronopcan you send me the patch?
12:21padenotI&#39;m putting it up for review now
12:21padenotand I&#39;ll write some instructions
12:21padenotit&#39;s not too hard it seems
12:21achronopsuper!
12:23padenotnow, with your patches, we&#39;ll be able to do some testing with 5.1 input or whatnot
12:33jesupdminor|bbiab: 57 compiles!
12:34jesuprepo updates. Note: compiles ... doesn&#39;t link yet
12:36jesupLooks like part of it is new directories aren&#39;t getting built (like api/video)
12:51dminorjesup: nice :)
13:32jesupdminor: looks like stuff in api/BUILD.gn that&#39;s not in api/api.gyp
13:32jesupthe video_frame_api target
13:47padenotachronop, https://github.com/kinetiknz/cubeb/pull/288
13:48achronoppadenot: do you want me to review?
13:49padenotachronop, yeah I assigned you, but if you can&#39;t I&#39;ll find someone else
13:49achronoppadenot: I can
13:49padenotit&#39;s not hard, it was just crashing badly
13:49padenotthe rest works fine
13:50achronopI did not see the assignment
13:51padenotachronop, right hand side, &quot;Reviewers&quot;
13:51padenotnot sure if it sends an email or what
13:51achronopyeah I see it now, I meant I didn&#39;t notice
13:57dminorjesup: have you chatted with the build team about gn support? I&#39;m not super familiar with the build system, but I had a look at the gyp implementation and at first glance it seems like gn support will be more challenging, e.g. if we have to first build gn in tree and then run it against the gn files before continuing with the build...
13:58padenothttps://trac.webkit.org/changeset/214721/webkit
13:58dminorbut for all I know, it could be easy :)
13:58padenotcrazy
13:58jesupdminor: yes. We need it for this, skia, etc. However, no action on scheduling doing it
13:58jesupwe can get by for this import. It gets progressively harder after it
14:11jesupdminor: updated api.gyp/etc to build video/*
14:11dminorjesup: cool, I&#39;ll reimport
14:12jesupCool, that got rid of the errors for video_frame_buffer()/etc
14:13jesupwhole bunch of audio/aec/audio_processing link errors
14:13achronopmreavy: ping
14:13jesupbunch of receive_statistics_proxy errors
14:13mreavyachronop: pong
14:14achronopmreavy: hi, I have Bug 1355520 reported on release (53), can I provide a fix there?
14:14firebothttps://bugzil.la/1355520 NEW, achronop@gmail.com Headset plugging/unplugging blocks the media from playback
14:16mreavyachronop: are you now able to repro or is this a speculative fix?
14:17achronopmreavy: I cannot repro, it&#39;s more like a speculative fix
14:17achronopI could ask QA to verify
14:17achronopthe fix
14:19mreavyachronop: yes, asking QA to verify is definitely the way to go. Put up a patch for Fx 55. have them verify it on 55 and then we can decide if it&#39;s worth uplift to 54. 53 has already shipped and it&#39;s very unlikely it would be a &quot;ride along&quot; if we do a point release for 53.
14:19mreavySo it&#39;s best to focus on 55 for now and then see if it&#39;s upliftable to 54 once it&#39;s verified.
14:20achronopmreavy: the problem is not reported on 55, exists only on 53
14:20achronopmreavy: 54 and 55 are unaffected
14:21mreavyachronop: ah, sorry, I was looking at liz&#39;s comment
14:21mreavyachronop: we can consider a patch for 52-esr
14:22mreavyachronop: so that&#39;s the release to focus on (52-esr) and see if qa can verify the fix there
14:22jesupdminor: and a lot more :-( Please feel free to start poking at why we&#39;re getting link fails and provide specific fixes
14:22dminorok will, do
14:23achronopmreavy: cool, I will focus on 52esr and we decide later if we want it on 53
14:24jesupdminor: to avoid stepping on feet, let&#39;s poke each other about directories we&#39;re trying to resolve
14:25dminorjesup: sure thing
14:25fippomreavy: speaking of microphones heads re https://twitter.com/Mrbysco/status/855001224151740416 -- if that is true multiple apps can no longer share a mic on windows 10 creators update which would be... bad.
14:26jesupdminor: I&#39;m going to look at the /call.cc failures next
14:27dminorjesup: ok, I&#39;ll let you know once I pull down your video/* fix
14:27dminorMy build might be failing elsewhere, there were so many warnings I couldn&#39;t find the actual error :/
14:29jesupfippo: sounds like they have some bugs... and maybe changed defaults in a kinda-painful way --- though the same issue existed for video already
14:30padenotfippo, do we know if this is a bug or a feature ?
14:35* padenot should get a windows 10 anniversary edition
14:35padenotor creator update, even
14:35padenotor both, maybe
14:44mjfjesup: ping
14:46jesupmjf: pong
14:46jesupthe twitter comments seem to imply they have Sound bugs as well
14:47jesupdminor: if you see any pattern to why things aren&#39;t linking, let me know
14:47mjfjesup: would it surprise you to hear that I dont see any rtp packets with extension.hasRID set to true when I run test_peerConnection_simulcastAnswer.html?
14:48jesupmjf: I presume it&#39;s setting the rids at the send side?
14:48jesupmjf: use nils&#39;s rtp dump and wireshark to see what extensions are there
14:48jesupdrno|irccloud: ^
14:49mjfI put printfs in rtp_utility.cc and were never setting it.
14:50mjfI have printfs in the 3 files that hasRID appears, and we never set it or receive it.
14:50mjfI will try to find where we build the rtp packet.
14:51mjfAlthough I would have expected that to turn up in my dxr search.
14:52jesupdminor: call.cc issues appears to be BUILD.gn changes that weren&#39;t mirrored in webrtc_call.gypi
14:53jesupdminor: when you imported the .gyp* files, did you update them to match 56->57 BUILD.gn changes?
14:57dminorjesup: only partially, I updated for removed files, not added files. I thought it would be easier to add the new files to resolve linker errors at the end.
14:57fippopadenot: one of the MSFT QA guys is on it so might be their bug. but wont stop users from blaming so if there are odd reports that involve creators update...
14:57dminorrather than adding files we don&#39;t end up using
14:58jesupah.... that&#39;s probably the source of most of the failures
14:58mjfjesup: I dont see where wed ever add that extension to a packet. I just got called at the car dealership, so Ill be offline for the next 40 minutes or so.
14:58jesupmjf: drno: nils, when you get in can you look
14:59jesupdrno|irccloud: ^
15:01achronoppadenot: did you test it?
15:07padenotfippo, yeah
15:07padenotfippo, keep me posted if you have more info ?
15:07padenotachronop, what have I tested ?
15:08achronoppadenot: sorry I was not very specific, I mean the cubeb PR did you try it?
15:08padenotachronop, yeah it works fine, I can record Firefox
15:08jesupdminor: could you generate a diff between 56 and 57 for all the BUILD.gn files in upstream? That would help going through this I think
15:09padenot&#39;s output into ableton or audacity
15:09padenotachronop, and also have gUM be the output of another program
15:09padenotI can have firefox play a 5.1 file and record each channel in a different channel in ableton
15:09padenotI&#39;m writing instructions at the moment
15:09dminorjesup: sure, will do
15:12achronoppadenot: I have a concern about it
15:12padenotI&#39;m all ears
15:13achronoplet me explain in review comments in order to specify the lines
15:14padenotsure
15:14padenotalso you can just r- and I&#39;ll fix it
15:17achronoppadenot: check
15:18padenotyou must be right, one sec
15:18jesupdminor: pushed fixes for call.cc (gyp was missing the flexfec* stuff)
15:19dminorjesup: https://people-mozilla.org/~dminor/56-57.diff
15:21jesupthanks
15:21dminorjesup: I&#39;m getting ASAN related build errors, do you want me to figure those out, or switch to a vanilla build and get things linking?
15:22dminor(help get things linking that is)
15:22jesupdminor: we almost certainly need to go through those changes and integrate them for any parts we care about
15:23jesupASAN issues building with 57, or generally?
15:23jesupi.e. clang getting upset I imagine if it&#39;s ASAN with 57
15:23dminorjesup: building with 57
15:23jesuplet&#39;s get things linking first I think
15:23dminorwill do
15:26dminorjesup: while I&#39;m waiting for my new build, can you assign me an area to look at?
15:26jesupmaybe start at the bottom of the .gn changes and work up, looking for added files (that map to gyp files we compile; don&#39;t care about the ones we don&#39;t)
15:27jesupI&#39;m starting at the top
15:28dminormakes sense
15:29jesupand we don&#39;t care about some stuff eg libjingle*
15:31jesupfor keeping the upstream unit tests working, we&#39;ll need some of those changes
15:51Caspy7dvander: FYI, https://www.reddit.com/r/firefox/comments/66gvzg/how_does_one_check_the_new_compositor_is_actually/
15:56jesupdminor: pushed some more fixes (audio/etc)
15:56padenotCaspy7, btw, I relayed your message about pulse audio being missing from the requirements and it&#39;s fixed
15:56padenotCaspy7, so, thanks
15:57Caspy7awesome
16:03dminorjesup: ok, I&#39;m up to congestion_controller from the bottom, modulo a unified build error to sort out.
16:05achronoppadenot: I have a build if you have the instructions
16:05jesupdminor: lot of changes to make in base.gypi
16:05jesupdminor: lot of changes to make in base.gyp
16:05padenotachronop, have you installed soundflower ?
16:08achronoppadenot: yes
16:08achronoppadenot: I have 2 devices 2ch and 64ch
16:09padenotachronop, so, alt click on the volume icon, and select the 64 channels thing for both input and output
16:09padenotalso, install audacity
16:09jesupupdated the repo with base.gyp changes
16:09mjfng: ping
16:09achronoppadenot: I have it
16:09ngng: pong
16:10padenotand then, play something in this new build of firefox (like https://people.xiph.org/~xiphmont/demo/surround/6.ogg, which nis 5.1), and launch audacity, and record from soundflower 64, at least 6 channels
16:10padenotrecord in audacity, that is
16:10padenotand you&#39;ll see 6 tracks, one per channels, with the right channel on the right track
16:15padenotachronop, does it work for you ?
16:16achronophmmm I see six channels but no input
16:16padenotthey are all silent ?
16:17padenotthe file is very short, you might want to right click-> loop
16:17achronopyeah, like I recorde without FF playing anything
16:17padenotahh
16:17padenotwait I think I don&#39;t understand
16:18padenotyou need to play something in the firefox you built to see somehting in the audacity, not sure if I&#39;m clear
16:20achronoppadenot: yeah, I have it, it works
16:21padenotcool
16:21padenotanyway, legitimate concern about the mask thing, I&#39;m not sure what to do
16:22padenotachronop, the same crash exist on windows, but I don&#39;t have my windows machine
16:22padenotachronop, so, what I&#39;m thinking is that this soundflower code is open-source
16:22padenotwe can cook up something to do integration testing
16:23achronoppadenot: can I play it on audacity and record in FF with gUM?
16:23padenotyeah
16:24padenotbut I don&#39;t have a build with your patches yet so it&#39;s mono only for now
16:24padenotbut when we land your patches it&#39;s going to be fun
16:24padenotalso we&#39;ll need to enable more than stereo for AudioContext and we&#39;ll be mostly done on this front I thinkl
16:25padenotmore than stereo output, I mean
16:25drnomjf: interesting. Im 100% positive that I fixed the missing RID header extension for simulcast some time ago
16:25drnobut quite plausible that it has regressed since then, as we dont have any tests verifying it working
16:26padenotachronop, heh, audacity crashes for me when I record 64 channels
16:26padenotableton works fine, though
16:27mjfdrno: I was just talking with Nico to see if he can see where wed be creating it.
16:27achronoppadenot: I record 6 and it&#39;s fine
16:27padenotI was being greedy
16:27drnomjf: Ill have a look
16:27mjfdrno: do you happen to have a bug number that I can look at?
16:27drnomjf: let me saerch that first
16:28padenotmaybe one day we&#39;ll be able to do wave field synthesis using Firefox
16:29padenotmaybe next week
16:30achronoppadenot: which cubeb layout is the ogg file that you sent?
16:30padenotachronop, 5.1 I suppose
16:31achronoppadenot: I&#39;ll set CUBEB_LAYOUT_3F2_LFE
16:31padenotyep sounds about right
16:34drnomjf: bug 1337468
16:34firebothttps://bugzil.la/1337468 FIXED, drno@ohlmeier.org RID RTP header extensions never gets send
16:36dminorjesup: I&#39;m hitting a yasm error (missing include file) building libvpx. Did you see that problem as well?
16:37achronoppadenot: that&#39;s a fun log line: (0x1205a5100) Opening input side: rate 44100, channels 6, format 2, latency in frames 512.
16:39drnomjf: just sanity checking: have you tried the simulcastOffer test or just the simulcastAnswer test so far?
16:40drnobecause for the simulcastOffer test I do see foo and bar in the packets on the wire
16:40mjfdrno: In the rtp packets or in sdp?
16:41mjf(and no, I havent checked simulcastOffer.
16:41mjf)
16:42drnomjf: in the RTP packets on the wire
16:42drnomjf: but I also see them in the RTP packets for the simulcastAnswer test :)
16:43mjfdrno: Ok - can you show me where that gets set on the packet in the code?
16:45drnowell there is this http://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/video/vie_channel.cc#658
16:45dminorjesup: did you possibly bring in libvpx/libvpx/third_party as part of libvpx_update_from_inbound but forget to hg add third_party?
16:45drnowhich enables the rtp header extension
16:46drnomjf: and then there is this here http://searchfox.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/rtp_rtcp/source/rtp_sender.cc#1468
16:46drnowhich is suppose to add the extension to each RTP packet
16:47mjfThank you - those are the places I was missing.
16:51padenotachronop, what does &quot;format 2&quot; means ?
16:51padenotand why input ?
16:51padenotdoes it work for you ?
16:51achronoppadenot: because I read from audacity the 6 channels in a gUM
16:51padenotah
16:51achronopignore format
16:51padenotdoes it work ?
16:52achronopI am not able to hear anything, but no crash or warnings
16:52achronopwe need to update your js code
16:53padenotyeah
16:53padenotalso the MSG is always stereo
16:53padenotit&#39;s mixed down
16:53mjfdrno: I can see it setting the RID, but we dont seem to receive it. Let me poke at it a bit more.
16:53drnomjf: :) what do you mean by receiving?
16:54drnoIm pretty sure it is still in the packet when we receive the packet
16:54mjfIt is not set on when we look at the packet header
16:54achronoppadenot: I hacked the gUM and get 6 channels out
16:54achronophttps://irccloud.mozilla.com/pastebin/Q8abdBkM/
16:54mjfSo maybe were not parsing it correctly. I dont know.
16:54padenotcool
16:55achronopbut it&#39;s hardcoded
16:55padenotwe can fix it tomorrow
16:55achronopsure
16:55drnomjf: the RTP parser which gets invoked to learn about the new SSRCs has no clue which extension ID would be the one for RID
16:55drno(if thats where you are expecting it to find it)
16:55mjfI put printfs in every place that mentioned hasRID.
16:56drnobut thats what Im saying: none of these will kick in
16:57drnowell depending on which invocation of the parser I guess
16:57drnomjf: I would manually check if the parsed RTP header shows RTP header extension number 3
16:58mjfIll try that.
17:26mjfdrno: we are never hitting: https://dxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/rtp_rtcp/source/rtp_utility.cc#440
17:31drnomjf: the problem is probably that this lookup fails https://dxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/webrtc/modules/rtp_rtcp/source/rtp_utility.cc#342
17:31mjfdrno: GetType is returning (for this test) either 1 or 3, and kRtpExtensionRtpStreamId is 6
17:31mjf(and I do see lots of Failed to find)
17:33drnomjf: so the lookup for kRtpExtensionTransmissionTimeOffset and kRtpExtensionAbsoluteSendTime work?
17:34drnomy guess would be that we never register kRtpExtensionRtpStreamId for receiving
17:36mjfIm not looking at kRtpExtensionTransmissionTimeOffset and kRtpExtensionAbsoluteSendTime.
17:36drnoah darn it. we add the rtp-stream-id extension into the offer in the test
17:37drnoso the offerer C++ code is not aware of it being used
17:38mjfAh, so we never set up the RtpHeaderExtensionMap properly...
17:39drnowell the whole test is faking out a lot of things, as we officially dont support receiving simulcast and RID for that matter
17:42mjfIm not seeing that section hit in the offer test either.
17:42drnono it wont
17:42drnosame thing: we are only sending RID. For that purpose it gets enabled.
17:43drnoBut we never add it to the receiving extension lookup table
17:43mjfOk - so I think the short answer is, those tests probably should be disabled.
17:43drnomjf: well the answerer test probably needs to disabled for now
17:43mjfThe offer test suffers from the same receive problem occasionally too
17:44drnoit does?
17:44mjfjust not as often. Ive actually seen it happen here once (and Ive only run the test a couple times).
17:44mjfThere is a bug for it too.
17:44Caspy7I&#39;m able to reliably reproduce a bug similar to bug 1348326 on a different site
17:44firebothttps://bugzil.la/1348326 REOPENED, alwu@mozilla.com BBC video/audio fails to load after focusing the videos tab
17:44mjfThat is back to the ssrc switching issue.
17:44mjfdrno: ^
17:44drnohmmm I know that there are intermittent for the offerer case, but I think nobody ever looked closely enough
17:45Caspy7set media.block-autoplay-until-in-foreground to true on Beta on a fresh profile, load a twitter page with video in a background tab, wait 60s, media fails
17:45mjfdrno: Bug 1351590
17:45firebothttps://bugzil.la/1351590 NEW, nobody@mozilla.org Intermittent dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html | Error in test execu
17:45drnoI guess disabling is only short time option here
17:45mjfSame issue.
17:46mjfYep.
17:46drnoalthough I would really prefer if we not let simulcast slip into some rotten state again, because of disabled tests
17:46drnobwc: ^
17:46drnoany thoughts on how we could teach these tests to parse the RID extension?
17:47drnoI currently see the following options:
17:47drno#1 add header extension to our lookup tables from answers (even if we did not offered them)
17:48Caspy7...or should I just file a bug? Was mentioning in here hoping it was known
17:48drno#2 modify the SDP offer before SLD(), and then add the header extension to our lookup table
17:48mjfSLD?
17:48ngWith #1 both sides have to agree on the extension
17:48bwcWe could add a function to interrogate the offerer.
17:48drno#3 add a special function call, similar to select_ssrc(), to enable only the RID specifically for receiving
17:49bwc&quot;What SSRC are you going to use for rid 1?&quot;
17:49drnomjf: SLD = SetLocalDescription
17:49bwcAnd then turn around and hand that off to selectSsrc().
17:50bwcA big fat hack, sure, but I think it would work.
17:51drnoactually we need to interrogate the answerer in this case, but yeah
17:51bwcIf I recall correctly, _eventually_ we&#39;re going to implement spec API that lets you get the ssrc for a rid we&#39;re sending.
17:52bwcYeah: https://w3c.github.io/webrtc-pc/#dom-rtcrtpencodingparameters
17:52bwcSo maybe not such an evil hack.
17:52drnoIm not big fan of options #1 and #2, because it basically allows people out there to munge SDP to achieve things
17:53bwcdrno: How dare they! :D
17:53bwcdrno: All you web people, trying to &quot;do stuff&quot;.
17:53bwc(I kid)
17:53drnobwc: Im fine with the web people trying to do stuff if they use APIs for it
17:54drnoSDP is not an API
17:54bwcNot with that attitude. :)
17:54jesupdrno: #3 seems reasonable (if a hack) unless we want to enable simulcast-reception -- it might help with debugging some simulcast code without a server working... but not a prime concern (if any concern)
17:58drnobwc: couldnt we do the which SSRC are you using for RID X today already by inspecting the SDP?
17:58bwcdrno: Yes.
17:58bwcdrno: Unless that is broken.
17:58bwc(who knows!)
18:00mjfAlright, so I dont really follow what you want me to tackle.
18:01Caspy7I have filed bug 1358211
18:01firebothttps://bugzil.la/1358211 NEW, nobody@mozilla.org Blocking autoplay for background tabs (bug 1308154) is breaking twitter videos
18:02drnobwc: actually we cant find out just by SDP inspection
18:02drnothe SDP lists both SSRCs, but they are not linked in any way which of the two is bound to which of the RID&#39;s
18:03ngthat is kind of the point of rid, is so that you don&#39;t have to advertise your SSRCs
18:03drnong: right. you are suppose to learn the SSRCs from looking at the RID in the initial packets
18:04ngdrno: right
18:05drnothe other concern I have with interrogating the PC about the SSRC to be used is, that we would need to do it before the SLD() call, because otherwise it racy again as we dont know when the PC is going to start sending its first RTP packet
18:05drnomjf: I think for now please diabled both tests
18:06drnowe should probably create a follow up ticket to fix and re-enable them
18:06drnoin that follow up ticket I can write a summary of the options at hand
18:07mjfdrno: How do you disable them?
18:07drnomjf: by commenting them out in mochitest.ini
18:08mjfdrno: so simple ;-)
18:13mreavyng: ping
18:13ngmreavy: pong
18:13mjfdrno: Ill disable them, and create the new bug.
18:14drnomjf: thanks
18:17jesupdminor: pushed some more fixes (common_audio)
18:17jesupnumber of link failures is going down some
18:21dminorjesup: it is not horrible. I&#39;m at modules/audio_coding. I think the diff we needed was https://people-mozilla.org/~dminor/55-57.diff, I found a few things missing in 56 - 57.
18:22jesupworking on common_video now
18:29jesupdminor: media/media.gyp now
18:34drnobwc: what do you think about this: https://bugzilla.mozilla.org/show_bug.cgi?id=1285009#c6 ?
18:34firebotBug 1285009 REOPENED, drno@ohlmeier.org offerToReceiveAudio and offerToReceiveVideo are ignored when renegotiating
18:36bwcYep.
18:36drnoShould we remove the support for initial false altogether? :D
18:36drnoOr should we complain about the spec?
18:37ngWhy not both?
18:37drnoRemoving support for false would mean nobody can do sendonly offers any more (until we have transceivers I guess)
18:37bwcWell, we&#39;re going to be supporting integer values for a while, probably.
18:38bwcReally, the question comes down to whether you can use offerToReceive to switch off pre-existing m-sections.
18:38bwcWhich we have never allowed.
18:39drnoHow else can someone then create a sendonly m-section?
18:41drnoAnd maybe the answer is they cant. Although Im pretty sure that is going to anoy the hell out of some people like fippo ;)
18:45drnoI guess this is the answer https://www.w3.org/TR/webrtc/#dom-rtcrtptransceiver-setdirection
18:46jesuppeople will want to do sendonly.... for example a screenshare stream
18:47mjfdrno: Bug 1358224
18:47firebothttps://bugzil.la/1358224 NEW, nobody@mozilla.org simulcast mochitests (offer and answer) need work to filter by rid to avoid issues with switching ss
18:47drnojesup: right. although right now according to spec they can only via Transceivers
18:53drnomjf: thx
18:54mjfdrno: Of course! Now Ill start looking at the fix! :-)
19:01jesupdminor: done with audio_device and audio_mixer
19:01jesupnow on audio_processing
19:06jesupdminor: there&#39;s stuff missing in the gyp files that isn&#39;t in the diff.... perhaps they&#39;d stopped maintaining them before 56. For example, utility/ooura_fft* in audio_processing
19:11dminorthat&#39;s too bad. if I remember correctly, they deprecated gyp before removal, so maybe some stuff got lost on the way.
19:12dminorjesup: you&#39;ve caught up to me, don&#39;t go any further :)
19:12dminorI&#39;m fixing up some desktop capture stuff
19:12jesupok
19:13dminoronce done, I&#39;ll push my fixes and we can see where we are
19:17jesupdminor: about to push audio_processing fixes
19:18jesupdminor: pushed. lot less undefined
19:18jesupinteresting to see the intersection of your an my fixes
19:26dminorjesup: I&#39;ve just pushed mine (just the patch files, I didn&#39;t add them to the series). I&#39;ll pull your changes in and see what happens!
19:29jesupdminor: resolving conflicts
19:32jesupdminor: resolved, building
19:32jesupwill push update in a sec
19:32jesupthe libvpx third_party one had some conflicts for me, ignoring for now
19:33jesupsome unified build issues...
19:35dminorcompiling here, waiting for linking
19:36jesupdminor pushed update
19:36jesupstill a bunch of undefined
19:37jesupbut this helped
19:37jesupI&#39;ll start at the top of the list from the linker
19:38dminorsure, sounds good, I&#39;ll start at the bottom then
19:39jesupfix for the Agc issues at the top building
19:40jesupworked
19:47jesupchipping away at audio_processing.gypi issues
19:55dminorfixed the VideoConduit one, trying to figure out why we&#39;re trying to build alsa
19:56dminorheh, we define LINUX_ALSA when building for pulse
20:02jesupdminor: congestion_control stuff dealt with (&quot;field_trial&quot; stuff)
20:03dminorjesup: cool, I&#39;m on webrtc/video
20:04guigsCan I ask a qq, how long should it take to download the Primetime Content Decryption Module when toggling the Play DRM Contnet? Context: https://support.mozilla.org/en-US/questions/1157003#answer-961049
20:04jesupgerald: ^guigs
20:04dminorjesup: what&#39;s the way to deal with field_trial?
20:05jesupI&#39;m leaving it in (at one point we removed them). I want to be able to add a pref for field_trial
20:05padenotguigs, should be quite fast
20:05jesupdminor: on voice_engine
20:07dminorjesup: there&#39;s one on video_send_stream
20:11guigspadenot: ty!
20:28jesupdminor: resolving the BuiltInAEC issue
20:30dminorjesup: I&#39;ve fixed up to just below there. Wondering what to do about &quot;cricket::kH264FmtpSpropParameterSets&quot;
20:30jesupI have the fix for that
20:30jesupbase.gyp - base64 needs to be in the approved_base set
20:31dminorjesup: ok, I&#39;m going to push what I have so far. Assuming we&#39;re seeing linking errors in the same order, we should be done
20:31jesupsure
20:31* dminor crosses fingers
20:32jesuplove this in base64.cc: &quot;Evil due to base/stringutils.h wanting non-standard &char for the second arg&quot;
20:32jesupfor strchr()
20:34dminorheh
20:34dminorjesup: pushed my stuff
20:34jesupick, they change a std string.h function to be char or wchar and change the type.
20:34jesupI&#39;m going to try ignoring that part
20:35jesupbuilds base64 now!
20:39dminorjesup: almost dinner time for me, I&#39;ll check in with you tomorrow morning.
20:41jesupdminor: did you push it to a new head?
20:41dminorjesup: yes
20:41jesupAh
20:41jesuptypically when sharing we don&#39;t
20:41jesupI&#39;ll deal with it
20:42dminorjesup: wait, no, at least not as far as I can tell. I see two heads, one made by you back in Feb, the other tip.
20:42dminorI made a new commit rather than updating the one in the series, thought that was what you meant.
20:43jesupnew commit is good. did you hg pull -u --mq first?
20:43jesupor before pushing, and resolve any conflicts?
20:44dminorI did a &#39;hg incoming&#39;, saw nothing new, and pushed
20:45dminorI&#39;ve never worked with a shared mq before, quite possibly I messed something up this time, although as far as I recall I didn&#39;t do anything different than the other times I pushed
20:46jesupdminor -- did you change series?
20:46jesuphg incoming pulls from inbound, not the patch queue
20:47jesupyou need to add --mq to all pull/push/log/merge/etc things
20:47dminorjesup: I&#39;ve been keeping the patch queue in a separate repo, so it should be fine
20:47jesupeg hg incoming --mq; hg push --mq; hg pull -u --mq
20:47dminorI didn&#39;t touch the series file
20:47jesupah
20:49jesuptypical flow is hg pull -u --mq; modify things and use hg qnew/qref as you work, then before pushing hg pull -u --mq (and resolve any conflicts using hg merge --mq and hg commit --mq), then hg push --mq to publish
20:51jesupdminor: ta! I&#39;ll update the repo when I&#39;m done
20:51dminorjesup: cool. I&#39;ll try the &quot;proper&quot; mq workflow. How do you tell it which repo --mq should point to?
20:52jesupdown to around a page
20:52dminorjesup: or can you just checkout the shared mq repo under .hg/patches?
20:52jesupediting .hg/patches-queuename/.hg/hgrc (after hg init --mq)
20:52dminorok, I&#39;ll give it a try.
20:53jesupor .hg/patches/.hg/hgrc if you don&#39;t use hg qqueue
20:53jesupafk for a bit
21:20jesupdminor|afk: down to around a dozen!
21:56dvanderCaspy7: heh. i guess in retrospect it should have been some note in about:support.
21:57Caspy7dvander: figure we can get it in 54?
21:57dvanderCaspy7: if you file a bug and CC/assign me ill put a patch up
21:57dvandershould be easy
21:58Caspy7cool cool
21:59Caspy7_awaydvander: did you say it was also not included in Beta?
22:29dvanderCaspy7_away: its nightly/aurora only, the about:support info
22:52Caspy7dvander: I filed bug 1358304
22:52firebothttps://bugzil.la/1358304 NEW, dvander@alliedmods.net Include GPUProcessPid in about:support for all release branches
22:57dvanderCaspy7: cool, thanks
22:57Caspy7np
22:59Caspy7oops, missed that flag
23:44SingingTreejesup: ping
23:44kamidphishrillian: So we good to land Bug 1346665?
23:44firebothttps://bugzil.la/1346665 NEW, dglastonbury@mozilla.com Implement PulseAudio backend for Cubeb in Rust
21 Apr 2017
No messages
   
Last message: 154 days and 23 hours ago