mozilla :: #media

15 Mar 2017
00:13rilliankamidphish: did you get your rust code integrated?
00:17kamidphishrillian: yes I did
00:20rillianexcellent
00:29jesupjya: done
01:00kamidphishrillian: now I'm debugging why opus 7.1 test fails.
03:07jesupkinetik: ping
03:08kinetikjesup: pong
03:09jesupkinetik: see #developers... failed on Try because std::this_thread::sleep_for isn't allowed (not on all systems we support)
03:10jesupI imagine we need to recode using nanosleep (posix) or Sleep() (windows)
03:12kinetikjesup: oh, fun
03:12kinetiki wonder if we can easily replicate that symbol check on the cubeb CI to avoid this in the future
03:24jesupkinetik: perhaps something like this: https://pastebin.mozilla.org/8982074
03:24jesupwith the Windows side still to do....
03:26kinetiki'm surprised the std::thread ctor doesn't trigger the same test
03:27Caspy7FYI, ALSA post on HN https://news.ycombinator.com/item?id=13873026
03:30Caspy7looks pretty fresh, probably prime for some responses
03:32jesupkinetik: it's because of how time functions get implemented it seems
03:40jesupkinetik: compiled (linux): https://pastebin.mozilla.org/8982075 (with a change to a simple 10 for the define it uses)
03:53kinetikjesup: thanks, i'll do the windows side
04:03jesupkinetik: patch on the bug r? to you for the posix side
04:08kinetikjesup: thanks
05:19kinetikjesup: windows bit is up for review
06:12jesupkinetik: try push appears green with my part on non-windows platforms, no S reds now. Note: I haven't tested it!
06:12jesuppadenot: make sure you test linux and Mac before we land the patch
06:13kinetikjesup: i pushed your patch plus the windows bit upstream and it's green on the CI there (so it builds everywhere, at least)
07:06shacharzjesup: ping
07:22cpearcekentuckyfriedtakahe: a quote from #firefox. Cos I know you care... https://irccloud.mozilla.com/pastebin/eDmDyBBo/
07:29jyacpearce: i tend to agree with that view... I've always removed pulseaudio from my linux system until now
07:37jw_wangI don't quite get it. PA depends on ALSA, so you should have the same control no matter PA is installed or not.
09:57jyajhlin: you could have just made a single uplift request and say it applies to all patches
09:58jyajhlin: what about aurora?
09:59jhlinjya: will uplift 1344649 after landed in central
10:00jyaok
10:17bwujhlin: bug 1345545 has nothing to do with youtube live stream issue, right?
10:17firebothttps://bugzil.la/1345545 FIXED, jyavenard@mozilla.com SPS/PPS NAL not prepend to first frame.
10:17bwujya: ^^
10:19bwuRM, Gerry, is not sure if that patch should be lifted or not to aurora, so he asked me this afternoon.
10:19jyabwu: i've already applied for an aurora uplift with that one
10:20jyaand it should be uplifted
10:20jyajust received the dell xps 15... damn, dell can make as nice packaging as apple...
10:20jyanice unit
10:21bwujya: ah. I got dell xps 15 yesterday...
10:21bwudoes your xps have a touch panel?
10:21jyait does
10:22jyai think :)
10:22damo22does it run coreboot?
10:22jhlinbwu: the patch there fixes macroblocking
10:22jyait's the 4K version, don't they all?
10:22bwujya: dell xps 15 has different models, at least in Taiwan. Mine has a 4k touch panel.
10:22jhlinbwu: it should be uplifted to aurora(54), beta(53) is not affected, though.
10:23jyayes it is touch screen
10:23jyai just tap the screen to select my language.
10:23* jya puzzled on how anyone can stand having fingerprints all over their screen
10:23jyai'd be cleaning the screen every two minutes. I already do so every hour wihtout touch screen as I can't stand the dust
10:25bwuha. then you may not use the touch panel often.
10:25bwujhlin: sweet. I will tell Gerry.
12:31padenotjesup, thanks for the patch last night
12:31padenotjesup, are we clear to land now ?
12:35achronoppadenot: 8/13 Test #8: overload_callback ................ Passed 100.57 sec
12:35achronopis that normal
12:36padenotachronop, kinda, but we could make it faster
12:37padenotor maybe I wrote one too many zero in the Sleep in the data_callback for the test ?
12:51jyarillian: are you there?
12:53achronopdid time change in US?
12:53padenotachronop, it did
12:53achronopso we are having standup in 30ish
12:54padenotachronop, yep
12:54padenotachronop, google calendar handles this correctly last I checked
12:55padenotbut yeah, it's definitely one of the two weeks where people miss meetings
12:55achronop yeah calendar does a good work ... all my notifications started ringing and I was wondering why so early ...
12:57jyarillian: are you up yet?
13:07jcristaupadenot: care to request aurora/beta uplift on bug 1340718? i'm not sure which of the two patches they should get
13:07firebothttps://bugzil.la/1340718 FIXED, padenot@mozilla.com If a audio device (Citrix) disappears and fails on re-open attempts, output can be hung until restar
13:07padenotjcristau, I'm not sure either, I'll have a look
13:08jcristauta
13:18mreavyachronop: ping
13:18achronopmreavy: pong
13:21robswain-Mdoes anything in webrtc support what i believe is best expressed as TCP allocations when using TURN, such that the transport used between the TURN server and the peer is TCP (note: not the A -> TURN/TCP -> turn server -> UDP -> same turn server -> TURN TCP -> B case, but A -> TURN/TCP -> turn server -> TCP -> B)?
13:21robswain-Mthat is, a relay candidate with the transport set to tcp, not udp
13:22robswain-Mthe plethora of RFCs for SDP, ICE and TURN and then whether they are actually supported in the scope of webrtc is a bit of a rabbit hole filled with spaghetti
13:22* robswain-M looks at jesup, fippo
13:27fipporobswain-M: rfc 6062 is not supported by chrome. let me see if i can find something that says so...
13:27pehrsonsau, is it standup already?
13:28fippoi think the rationale is that you only want 6062 for reliability but webrtc uses sctp to provide that. since i said "sctp" jesup might jump on this now :-)
13:29mreavydminor: ping
13:29fipporobswain-M: https://groups.google.com/d/msg/discuss-webrtc/bq2tUi_guE4/cqjYdUPzo6MJ -- i doubt that guy changed his mind
13:29dminormreavy: pong
13:30mreavydminor, jib, pehrsons, padenot , achronop : be sure to read jesup's email from several hours ago and follow his instructions to enable logging on the chance we can repro the drift problem today.
13:30padenotyep
13:30pehrsonsah, then I'll be a min or two late
13:31robswain-Mfippo: jesup: i found this discussion as well: https://www.ietf.org/mail-archive/web/rtcweb/current/msg11837.html
13:31mreavydminor: hey Dan would it be ok if I took a 15 min break between the standup and our 1:1? There's something I need to do.
13:31jibmreavy: I get zero-size log files no matter what I do with m-c
13:31dminormreavy: sure, no problem
13:31jibno e10s, no sandbox
13:32mreavyjib, padenot, pehrsons ,jesup - I need to finish the standup "on time" today -- or even a little early
13:32padenotok
13:33mreavyjib, padenot, pehrsons - so I'll be starting it basically now
13:34padenotmreavy, we can't hear you it seems
13:34padenotyeah
13:44pehrsonsjib: I was talking about bug 1320994
13:44firebothttps://bugzil.la/1320994 ASSIGNED, pehrson@telenordigital.com Non deterministic recording-device-events notification count when stopping a screen share stream at
13:44jibthx
13:49pehrsonsjib: I also mentioned this thing and your name in the same sentence: https://github.com/w3c/mediacapture-record/issues/4#issuecomment-286702238
13:49achronopwe could check at the end if anyone was drifting
13:50pehrsonson how to get google to stop ignoring me
13:54padenotpehrsons, this is a bit hard, I've had success pinging folks on twitter to get their attention sometimes, but I don't like doing it
13:54padenota bit too aggressive
14:00pehrsonsright
14:02padenotit really depends on the people, it's really a pleasure to work with DOM folks and web audio folks from google
14:02padenot:-(
14:18mreavypadenot: ping -- I'm ready when you are
14:18mreavypadenot: same room as standup
14:19padenotmreavy, ok, I'll find a room and join
14:19mreavythanks
14:34blasseyjesup: in my room when you're ready
14:34jesupjib: ping
14:34jesupblassey: ping
14:34jibjesup: pong
14:36jesupjib: in a minute; but I heard you had logging issues
14:36jibyes
14:43jibjesup: actually, it may be more a problem of me understanding what to expect from "AudioLatency:5". Logging of e.g. "MediaManager:5" works fine, at least from non-e10s
14:44jibbut when I use AudioLatency:5 only I get nothing
14:46* jib pulls m-c and rebuilds
14:47mjfjib: you may not see log entries appear instantly. I have to wait a little over 30 seconds before the first entries are written to the log. At first, I thought the only way to get logs was turn off e10s. Also, with e10s, it seems like maybe remaining log entries are not written to the file when quitting.
14:47jesupYou should get one log per second from gum (and one per second from a peerconnection). And the buffer - the volume is low, so it takes a while before a 4k buffer is full
14:47jesupstdio buffering
14:48jibok I'll try again after rebuild and be a little less impatient
14:48mjfOn gum_test.html I dont see the peerconnection logging.
14:48jesupI got caught by the buffering the first time I tried to check it to a file :-)
14:48jesupmjf: no peerconnections there :-)
14:48mjfJust checking!
14:48mjf:-)
14:48jesuppc_test will show them
14:49mjfjesup: it does seem like the final buffer is not written to the log file on quit.
14:50mjfSo if you run and quit before the first 4k is filled, youll never see logs.
14:50jibstellar
14:51jesuperahm: ^
14:52padenotjesup, jib, mjf, logging.config.sync -> true
14:52padenota pref
14:52padenotsett LogModulePrefWatcher.cpp, that has all those magic prefs
14:52mjfjesup: when e10s is diabled, you _do_ get the final buffer on quit.
14:52jesupTrue, though that sync-writes all messages. I was referring the the final bufer
14:53jesupor MOZ_LOG=...,sync
15:04blasseymreavy: in my room when you're ready
15:08jibok a rebuild seems to have fixed it
15:09jibfrom latest m-c
15:42rillianjya: what's up?
15:42jyarillian: i was having issues with cargo and rust.
15:42jyait kept telling me it was missing a component but not telling me which one
15:43rilliangot it working?
15:43jyaso in the end I deleted everything in my home directory, and re-run mach bootstrap
15:43jyawell, not yet.. but it looks better :)
15:43rillianoh my :)
15:43jyastill not having much luck compiling on that win8 loaner
15:44rillianI don't know if the path update in instantaneous on windows
15:47jibmjf: were your logging successes on OSX?
15:49jibIt wfm me now on OSX, but on windows I'm seeing nothing but 0-byte log files
15:50jyagrrrrr.. and now cinnabar gives me a out of memory trying to check things out
15:50mjfjib: yes
15:50padenotjib, sandbox disabled ?
15:50mjfMOZ_LOG=AudioLatency:5,sync MOZ_LOG_FILE=/Users/mfroman/FxNightly.log ./firefox
15:50mjfsandbox was default, and e10s was on.
15:51padenotwindows and osx are different when it comes to sandbox
15:52jibpadenot: yes
15:54mreavyjib: ping
15:55jibmreavy: pong
15:55jibpadenot: wait, looks like it works now without sandboxing. pilot error, sorry
15:55padenotjib, it took me ages to double-check every bit of setup last time
15:56padenotI had kind of the same issue, empty log files
15:56jibI was looking at the wrong one. nspr.log.child-3 FTW apparently!
15:57jibstupid windows ls command had an odd default sort order
15:57achronoppadenot: can you review the uplift?
15:57padenotachronop, sure
15:58padenotachronop, with patches from chunmin and kinetik, and also jesup on top of yesterday's, right ?
15:58achronoppadenot: no
15:58achronoppadenot: it's only 1345049
15:59padenotah yeah ok
15:59padenotI'll be doing the other uplift
16:01achronoppadenot: I think they are not in m-c yet
16:01padenotnot yet, no
16:01padenotthere was a issue, but we have all the patches and reviews now
16:01achronopok
16:18padenotachronop, you did something weird with the patch file in your patch
16:18achronoppadenot: what is it?
16:19padenotupdate-cubeb-to-f07ee6d.patch looks like update.sh
16:22achronoppadenot: you are right, let me fix it
16:39achronoppadenot: I think it's good now
16:42padenotachronop, r+, but fix the strip number
16:43achronoppadenot: thanks, I will fix it
16:44padenotnow for the normal uplift
16:45padenotjesup, I'll handle merging kinetik's patch you r+ed today upstream, re-generate the patch, and push
16:47padenotoh it's already on
16:54jibLogging on windows is totally random for me. Not working again
16:56mjfjib: are you using the ,sync addition to the end of the MOZ_LOG var?
16:57jibno
16:57jibI got logs earlier without it
16:57mjfjib: and youre definitely giving it enough time to accrue 4K of logging?
16:58jibok I get logs again now. I think windows 10 is messing with me.
16:58mjf(without the sync added, gum_test.html took about 30-40 seconds before it would write logs)
16:59mjf(and then every 30-40 seconds as another 4K would fill)
16:59jibIf I launch it from an icon instead of from command line shell in Windows 10 then it picks up different settings
16:59mjfjib: ah, sure. That makes sense.
16:59jibI can't get the command line ones to take, even though they should work imho. Looks like I have to edit the global ones each time. sigh
16:59mjf*sigh*
17:00padenotjib, and with prefs ?
17:00padenotjesup, https://treeherder.mozilla.org/#/jobs?repo=try&revision=abe6e2dfe220113c3b9a68b07355b337e9672e7a, that includes kinetik's and your fix from last night
17:01jibpadenot: with e10s and sandbox.content.level=0
17:02jibseems to work much better if I don't launch firefox from command line
17:03padenotwe really should have a solution that requires no commandline and no environment variable
17:03padenotonly prefs and maybe restart
17:04padenotand we should probably have buttons in about:webrtc to do all this magically so we can reliably get logs from users
17:13* jib agrees
17:14* jib is having this problem right now in bug 1336073
17:14firebothttps://bugzil.la/1336073 NEW, jib@mozilla.com [e10s] No webcam shared on meet.jit.si
17:48mreavyng: ping
17:48ngmreavy: pong
18:03mjfbwc: ping
18:05bwc1mjf: pong
18:41dminorjesup: ping, I noticed a couple of new files that were missed being added in the branch update. Do you want me to add them as a separate patch or is it fine if they are part of my desktop capture patch?
18:53fippodrno: can you add 'rtcp.rtpfb.fmt == 1' (for NACKs) and 'rtcp.psfb.fmt == 1' (for PLIs) as example filters to the blog post? Then I will never have to figure out those again
18:59jesupdminor: separate patch.. but that shouldn't have happened; the hg addremove should deal with them - except some files we (believed) we didn't want; I had to bring some back already, so it's quite possible. For example. we don't include all the libjingle (cricket::) stuff
19:01dminorjesup: will do. the files are modules/audio_processing/include/config.h and modules/video_coding/fec_rate_table.h. I couldn't build without them.
19:05jesuphuh
19:05jesuppadenot: ping
19:05jesupjya: ping
19:05jgauntchuck told me there are knowledgeable people here re: playing video on the web
19:06jesuppadenot: bug 1340278 affects 52... what are our options?
19:06firebothttps://bugzil.la/1340278 NEW, nobody@mozilla.org Crash in abort | `anonymous namespace''::wasapi_stream_start
19:06jgauntI'm doing an experiment on brand name perception, showing videos of pages loaded to participants on any possible browser
19:06jgauntso far stimuli are in mp4, should that work for all browsers or should I include other formats to ensure compatibility?
19:06jesuppadenot: about 100 crashes/day from 52/52esr
19:07jesupNote that XP users are being punted to 52ESR from 51, instead of to 52
19:08jesupjya: when you're around.... we have a profile on that 100% usage thing; I took a bit of a look - points to media thread pools
19:08jesupjya: also we have some regressions that are NI'd to you from a while ago we went over in the eng boss triage meeting today.
19:09jesuppadenot: also bug 1340279
19:09firebothttps://bugzil.la/1340279 UNCONFIRMED, nobody@mozilla.org connection is not secure bogus message on Jango.com
19:09jesupafk for a few minutes
19:14jyajesup: I have looked a this one several times. Not sure why it keeps coming back to me. But I see nothing suspicious in those profile. The majority of times is spent in non media stuff (over 90%). But having said that, I just don't trust a profiler that only sample every 100ms
19:14jyaIt's pure luck if it show ms which thread is using the CPU.
19:43jesupjya: unfortunately this profiler shows waits as "it's in here taking time" even if it isn't executing as best I can tell. (I find this profiler confusing; more confusing than it used to be. ) The threads I saw getting hits outside of Wait functions were all MediaPlayback pool threads, clearly dispatching stuff
19:45* jesup would love to see it in jprof on linux... default is interrupt the current thread every N ms of execution (not Nms of realtime). And the default time I use for that is 2ms, not 100ms
20:08mjfdrno: ping
20:09drnomjf: pong
20:19* sheppy tries to find out when Chrome gets RTCPeerConnection.addTrack().
20:20sheppyNice not being the ones lagging rather pathetically on this.
20:26fipposheppy: https://bugs.chromium.org/p/chromium/issues/detail?id=700916 is the thing blocking addTrack
20:27fipposheppy: i'd bet on getSenders and replaceTrack coming before addTrack though
20:27sheppyfippo: probably
20:28sheppyThose will be relevant too, of course, but not as big a deal as addTrack(), without which you basically have to have two implementations of your stream setup code. :)
20:33abrmreavy: running a little late as I update dev edition
20:41drnomjf: today my CPU usage is way lower then in previous standup calls. how is yours looking?
20:42mjfdrno: hovering betweem 200-250%
20:43drnomjf: I see today only ~70% + ~100% which a lot lower then my usual close to 200% for each
20:43mjfwow
20:44mjfThats a big drop.
20:46abrjesup: Im running as MOZ_LOG=AudioLatency:5 MOZ_LOG_FILE=/tmp/latency.log MOZ_DISABLE_CONTENT_SANDBOX=1 ./firefox -P testing2 https://appear.in/moz-webrtc
20:47abrAnd the /tmp/latency.log file is there, but still empty
20:48jesupabr: e10s?
20:49jesupin e10s, the log will be in /tmp/latency.log.child-1 or some such
20:49abrAha! There it is.
20:49abrjesup thanks
20:51jesupmain .log will be Master process; children as child-N
20:52abrhttps://tools.ietf.org/html/draft-roach-perc-webrtc-00
20:52kamidphishJust checking that the media-playback standup is still in 8 minutes? gerald kentuckyfriedtakahe
20:53geraldkamidphish: Yep, should be
20:53geraldkamidphish: 6 minutes actually
20:53geraldkamidphish: Oh, right, you're in a different tz :-P
20:53kamidphishgerald: my laptop reports 7.
20:53kamidphishgerald: I'm in a special TZ.
21:03abrjesup: I assume this latency log has no value. :)
21:11drnojesup, mreavy: the GUM issue on my laptop in DE is actually an audio problem
21:11drnocamera works fine on gum_test.html, but mic does not
21:13drnojesup: is there any log file which I turn on on the fly in about:networking which could give us a clue what is going with my audio here?
21:27jesupabr: correct, unless there's drift from you
21:28abrjesup: Aside from those features that are probably due to bad wifi, I think that call had basically no flaws.
21:29jesupdrno: well, logging.MediaManager -> 5 logging.GetUserMedia ->5 may help. also logging.webrtc_trace -> 5 might help, might not (would create a separate log file in the execution directory I think
21:30jesupabr: right. Maybe aggregate devices is the golden bullet - but we can't uplift that to 53, so we're going to keep looking
21:56drnojesup: no luck. sandbox prevents me from creating log files on the flt :(
22:20jyacpearce, mattwoodrow : currently investigating some errors occurring on windows 8 try run...
22:20jyafrom time to time, MF_E_TRANSFORM_STREAM_CHANGE isn't called before a frame comes out
22:21jyaas the DXVA manage expect to have received it (which sets the size of the surface to use), that causes some failures
22:21jyaany ideas?
22:23mattwoodrowjya: So, currently we dont configure an output size initially, we just start feeding data
22:23mattwoodrowand we expect a STREAM_CHANGE to appear before the first output, and we configure a size then
22:23jyathat's right
22:23mattwoodrowBut these days we dont allow stream size changes for a decoder, right?
22:24mattwoodrowSo we could just configure it upfront
22:24mattwoodrowsince we know the size
22:24mattwoodrowand then make STREAM_CHANGE an error
22:24jyayes, but we still rely on MF_E_TRANSFORM_STREAM_CHANGE being called
22:24mattwoodrowCan we not?
22:24jyawell, i remember considering the issue a while back, thinking that we don't need it.
22:25jyabut i left it on the chance that windows calculate the size differently than we do
22:26jyafor H264 i'm highly confident it won't happen, as we calculate directly from the SPS NAL, likely exactly how windows is calculating it
22:26jyabut I'm concerned with VP9
22:27mattwoodrowjya: How about doing the size upfront, and recording telemetry if MF comes back with a different size?
22:27jyasounds like a lot of work :)
22:27mattwoodrowOr just make STREAM_CHANGE a MOZ_CRASH and watch crash stats while it rides the trains :)
22:28mattwoodrowIf its wrong, then youll find out pretty quickly
22:29jyaSTREAM_CHANGE does come out, it's when it doesn't come out that's a problem
22:29jyawhat about, check that stream change was called, if not use our own calculated size
22:30mattwoodrowIf we set the size ourselves before we provide any input, then it shouldnt be called ever
22:30mattwoodrowunless the size we set was wrong
22:30jyaoh I see what you mean
22:31mattwoodrowSo making that crash, and fixing the bug so we set it right seems like a good solution
22:36mattwoodrowjya: It should make the code simpler too, all the init will be done at one time, instead of in multiple stages
22:37jyaok... will do this tomorrow while traveling ... thanks for the brainstorm :)
16 Mar 2017
No messages
   
Last message: 158 days and 15 hours ago