mozilla :: #media

16 May 2017
00:52bwukentuckyfriedtakahe: my train was delayed due to heavy rain, so i would be late by around 20 mins.
00:53kentuckyfriedtakaheCan we move the call to tomorrow?
00:55bwuSure. It works for me.
05:00drnojesup: if you are still around would be great if you could do a quick review of bug 1365090
05:00firebot NEW, Crash when renegotiating SDP and simulcast is enabled
05:06drnojesup: thx
06:34jesupdminor|afk: ng: pehrsons: pushed a bunch of simulcast fixes (rid really didn't work). not quite there yet, but now actually transfers data and selects on RID. Not getting the right size though; need to check if it's passing the right rid values all the way down
07:05bwuchunmin: Have you checked if our audio 5.1 work on this link ?
07:38chunminbwu: Yes. That's how I test the code.
07:38bwuchunmin: Cool! good to know. Thanks
11:03jyakentuckyfriedtakahe: nice.
11:32jesupdminor: ng|biab: etc: Simulcast appears to be working (sending RID was basically all broken by their changes and the merge). test is still failing due to the final resolution being wrong; need to check the scaling. Right now I'm ignoring scaleResolutionBy in the simulcast code, due to apparent restrictions in the upstream code that each layer must be >>1 of the bigger layer (1/4 the...
11:32jesup...pixels), instead of taking it from scaleResolutionBy
11:32jesupthough in our test we use '2.0', which should be the same
11:33jesupafk for a while (primary day in PA)
11:43decodercan someone tell me if/how media encoding is exposed to content at all?
11:44decoderthanks :)
11:44decoderand nice to see you around roc
11:44rocI lurk
12:02dminorjesup: good stuff
13:17fippojib: \o/
13:18jibAWRIGHT! :-D
13:21fipponext step: kill onaddstream.
14:02achronopjesup: I have a question about webrtc code
14:02jibfippo: cool, yeah adapter already has ontrack
14:03achronopjesup: the GetSendCodecInfo() here:
14:05achronopjesup: returns max codec channel = 1, is it limitation in codec? Max freq is also 32000
14:06achronopjesup: gUM usually has 44100 or 48000, I wonder how it works
14:39mjfjib: ping
14:49jibmjf: pong
14:52jesupachronop: IIRC the AEC only works up to 32K currently, so unless you disable the AEC (and noise suppression, and AGC) it gets downsampled to 32K mono. That may be separate from the GetSendCodecInfo issue
15:06dminorjesup: I'm down to one gtest failure that seems it might be significant: webrtc/modules/video_capture/test/, the rotation test on line 406. Do you think that is worth investigating right now, or should I just disable that test case?
15:07jesupWe don't handle rotation attached to frames yet
15:07dminorjesup: just saw your message from yesterday, I'll kick off an Android try job with your latest stuff and see where we are.
15:07dminorjesup: ok, that makes sense
15:07jesupI've pushed my latest. simulcast will fail, but shouldn't crash
15:07achronopjesup: actually my problem is only when AEC, NS and AGC are on. how does it work now? does it get upsampled somewhere else in the code after the AEC?
15:09jesupwhen any of them are on (and AGC is off by default for us), it has to downsample to 32K mono (I believe; and I don't think this has changed in 57)
15:10pehrsonsdminor: could you answer bug 1364900 real quick? I imagine it's a spec thing.
15:10firebot UNCONFIRMED, Received DTMF tones was not played for OPUS 48kHz
15:14dminorpehrsons: sure, I'll have a look
15:14dminorjesup: I've pushed my gtest stuff, please let me know if there's any fallout with what you're doing
15:15achronopjesup: the playback of the stream happens at 44100 in my case, does is get upsampled or what?
15:17jesupyes, it gets upsampled when inserted in the Graph
15:20achronopjesup: would be possible to point me out the file?
15:23jesupachronop: one spot (maybe the spot) is in GenerateAudioFrame(). Note that AECM is the mobile (fixed-point) AEC
15:24jesupI think as well
15:25jesupand APMAnalyzeReverseStream()
15:26jesupboth of which call RemixAndResample()
15:26jesupachronop: ^
15:27achronopjesup: hmm I thought that GenerateAudioFrame() (in in) does the downmix, let me check the others
15:27jesupthe APM ones are probably on the output stream, but check
15:43achronopjesup: yeah the APM looks like it, I'll keep digging there, thanks
16:06ng|biabjesup: awesome! that scaling x2 scaling restriction came from VP9 AFAIK, so I find it interesting that it is skippable
16:07jesupI'm not skipping it... and vp9 doesn't do simulcast I think
16:08jesupng: dminor|bbiab: actually, simulcast now works with no changes - somewhere along the way the RID list gets reversed; just need to check where
16:32Caspy7not to intrude, but to better understand availability, can someone tell me when the All Hands is?
16:32derfThe week of June 26th.
16:33Caspy7derf: cool, thanks
16:34Caspy7ah, ok, that's a bit further off than I was thinking
16:41ngjesup: I seem to remember that the vpx encoder would barf if each successive layer wasn't exactly 1/2 size on a side as the resolution of the previous (order dependent).
16:43fippong: oh yes... let me dig up the bug where i ran into that
16:44fippong: -- something like this?
16:49dminorjesup: android is looking green :)
16:50dminormodulo the lint jobs, I'll have a look at those
16:53dminorpresumably we shouldn't run checkstyle on upstream code anyway
16:53ngfippo: yes, something like that. The root cause was limitations on the using VPX's single pass encoding for layers. Not having much luck tracking it down in the vpx code, it is much easier to find at the end of a stack trace =p.
17:12jesupI know we have some out-of-order initializers to deal with
17:28jesupdminor: ng: mjf: Simulcast is green locally after I swapped an array order
17:29ngjesup: huzzah!
17:29jesuppushed to the queue
17:35mreavydrno: ping
17:35drnomreavy: pong
17:36mreavydrno: is now a good time?
17:36mreavy(I'm in my room if it is.)
17:36mreavy(If not, just let me know.)
17:42ngjib: ping
17:42jibng: pong
18:57alex_mayorgaHola! Is a dupe?
18:57firebotBug 1365315 NEW, fails to play
19:25Caspy7ok, just updated to today's nightly and mp4s still have bad artifacts...
19:26Caspy7at least the "gifv" version I'm currently looking at
19:26Caspy7which I checked is mp4
19:26Caspy7while looks fine in Chrome (which I also checked is mp4)
19:26Caspy7this one as an example
19:27Caspy7oh, this will do too, it guarantees h.264
19:29* Caspy7 sighs
19:29Caspy7dang, this build says from the 14th
19:30Caspy7ok, ignore me - though I don't know why it updated to a 2 day old build
20:19jesupCaspy7: I saw something about blocking updates due to a bug
20:20firebotBug 1365256 FIXED, disabled addons are not actually disabled, these addons are loaded.
20:20jesupdiscussion (a little) in #release-drivers
20:21jesupCaspy7: also see RyanVM
20:21Caspy7jesup: yeah, thanks, I spoke w/ someone in #nightly and was told about the block
20:21Caspy7I just wish they hadn't turned updates back on b/c I updated to a not fun time
21:32rilliankentuckyfriedtakahe: 1:1?
22:16drnobwc: does this make sense to you ?
22:16firebotBug 1365090 NEW, Crash when renegotiating SDP and simulcast is enabled
22:18drnobwc: I think you noticed 3) from their list already when you worked on simulcast, or?
22:20bwcSo that guy loses me right off the bat.
22:28drnobwc: the scenario what he describes is that the renegotiated with simulcast on
22:28drnothe line he refers to in his first paragraph in this here
22:29bwcRight, but why is that wrong?
22:29bwcAnd why should it be adding the target bitrates instead?
22:29drnoI understand that going through the multiple layers for simulcast each layer grabs the maximum it get
22:29drnoand then the last one is left with not enough bits
22:30bwcYes. I've understood that for some time.
22:30drnobut I dont get why using the target rates and therefore getting to a lower over all rate changes anything about each of the lower grabbing what ever they can
22:30bwcThe upshot is "don't get greedy with your max bitrate for simulcast".
22:30bwcNot "we need to change how overall max bitrate should be calculated"
22:31drnowhen a simulcast layer tries to take its portion it needs to consider how is left from the over all bitrate
22:31bwcThat would be nice.
22:33bwcWhere in is this guy talking about in #4?
22:37drnobwc: dont know either
22:38drnobwc: my guess would be somewhere in here
22:38drnoahh probably this here
22:40drnobwc: but thanks for confirming that Im not the only one with difficulties following his arguments :)
22:43bwcdrno: Hmm, ok, I think I see part of the puzzle here:
22:44bwc_That's_ why he is saying the overall max bitrate needs to be max of largest stream, plus the target for all other streams.
22:45bwcBecause the logic for allocating the bandwidth uses the target (if possible), unless it is on the largest stream, in which case it uses the max.
22:45bwcWhich is kinda goofy, because why have both target and max?
22:46bwcIn that particular case.
22:46bwcSome might say this code is confusing.
22:46bwcI would say it is _confused_.
22:50* drno is confused
22:56drnoso this if here
22:57drnois basically where the layer decides it is too greedy to take the maxBitrate, because it wont let enough room for the minBitrate of the layer above, and takes the targetBitrate instead?!
23:01* drno wonders how this worked for Google before if this is a bug in the code base
17 May 2017
No messages
Last message: 93 days and 6 hours ago