mozilla :: #media

19 May 2017
01:21dminor|ptojesup: pushed my fixes. hopefully no more fallout. I'm on pto tomorrow and monday is a holiday in Canada, so if there's any more problems please just remove my stuff from the series and I'll deal with it on Tuesday
03:13bwujhlin: bug 1365582 looks serious. Is there anyone checking it?
03:13firebot NEW, Audio&Video playback does not pause when Firefox is closed
03:58jesupbwu: perhaps Bug 1322650?
03:58firebot FIXED, [geckoview] [e10s] Make WebGL work
03:58jesupthere are patches in there related to decoders on android I think
05:37bwujesup: Good to know. Thanks!
05:37jesupjust a guess from the regression-range
06:36jyacpearce: what's the setting for the proxy again?
07:10padenotcpearce, no and no
07:28jesupdminor|pto: v57 pushed again. Try is looking better; fixed a bug I introduced, and simulcastOffer (and others) with another fix. First results for linux opt are green across the board. Still some windows things to deal with
07:28jesupasan is green too
08:08jyabwu: ping
08:08bwujya: ah. I am trying to ping you now!
08:08bwuavailable for talk?
08:29cpearcejya: `ssh -D 1234`
08:33jyabwu : bug 1366195
08:33firebot NEW, Make sure our mochitests properly detects decoding error regressions
12:23jesupdminor|pto: ng: pehrsons: v57 is totally green on linux now
12:23jesupcouple of failure on windows
12:26pehrsonsjesup: yay
12:26pehrsonsjesup: the MediaRecorder refactor is looking good too:
12:27jesuproc: rr was quite helpful in resolving fallout of the merge (though I found large amounts of log output caused a major pileup of events in STS thread and effective packet loss, at least with e10s, causing some tests to fail). Might be something to check in the logging stuff you were telling me about (perhaps that would sidestep the problem, maybe - or might make it worse)
12:28jesup is the latest v57
12:29rocit should sidestep the problem
12:29roclogging is off during recording
12:29jesupmac must have a pileup... mda try run submitted 6 hours ago, hasn't started
12:30rocthen you replay with logging on, and that's slower but you still get the exact replay (plus logs)
12:30jesuproc: that was what I was hoping. Trying to figure out why it was failing with rr I found when I was submitting an event to STS there were 700+ events queued there (mostly it seems because everything was Very Slow)
15:07koda<jya> we&#39;ve just integrated av1 decoder in firefox fwiw (but only in webm of course)
15:08kodathat&#39;s great but please don&#39;t forget mp4
15:08kodait&#39;s something i mentioned during an av1 presentation too
15:08kodaone of the things that hindered vp9 adoption was implementing webm
15:08kodaplease let&#39;s not repeat the same mistake
15:14jyakoda: there&#39;s nothing done to define how av1 should be integrated in mp4 yet, and there&#39;s no tool to create such content at this stage... but it won&#39;t be forgotten
15:14kodai&#39;m glad to hear that
15:15kodaone could even argue that the codec itself isn&#39;t finished yet though ;)
15:16decoderkoda: are you in contact with the fuzzing team to make sure AV1 gets fuzzing before being enabled by default? just checking
15:17jesupdecoder: jya: koda: given the attack surface of codecs, have we considered putting new/experimental codecs into GMP shells? (also avoids killing content processes if they crash, but that&#39;s probably secondary)
15:17kodadecoder: i&#39;m not sorry
15:18jyajesup: moving the software decoder to say the GPU process wouldn&#39;t be hard
15:18decoderkoda: there is now an official process in place for that, that involves you just sending an email. i just have to check if it should go directly to us, or to somewhere else :)
15:18decoderill let you know in a few
15:18jya(and I&#39;ve argued for such thing in the past)
15:20kodajya: i suppose that only the 8bit profile has been implemented so far, isn&#39;t it?
15:20jyakoda: that&#39;s the only thing our compositor supports anyway
15:21jesupjya: what&#39;s the security level of the GPU process vs GMP? I doubt it&#39;s as locked-down
15:21jyaso at best we would have 10->8 conversion first
15:21jyajesup: no idea...
15:22kodajya: i&#39;m aware, even so being able to stream 10 bit only without having a fallback to 8bit for firefox would be nice
15:23jesupcpearce: ^ what&#39;s the security level of the GPU process vs GMP? I doubt it&#39;s as locked-down
15:24kodajya: I guess my main arguement is to not release anything until feature parity is reached re bitdepth and encapsulation, otherwise users will start adopting one thing and not the other, bringing fragmentation and confusion to the market
15:27jyakoda: performing a conversion on the fly from 10 to 8 bits on YUV software buffer isn&#39;t that particularly difficult
15:27jesupI presume GPU has in some ways a looser sandbox than Content (has to talk to video drivers/HW), though compromising it doesn&#39;t give immediate access to sensitive data in Content
15:27jesupjya: I suspect libyuv has something for that
15:27kodajya: agreed, that&#39;s why i believe it should be implemented in firefox :p
15:29kodait would allow me to stream h264 and vp9 at 10 bit too..
15:35jyakoda: the solution I had in mind requires each and every single decoder to be patched
15:35jyaor more likely, worked around
15:35jyait&#39;s not a universal solution for native 10 bits support
15:35jyathough it could be
15:37kodai&#39;d just be happy with any solution that lets me stream 10 bit honestly :p
19:40RyanVMwho should I CC to a new media capture API bug?
19:40RyanVMjib: ^?
19:41RyanVMok, I&#39;ll start with you and pehrsons and you can loop in whoever :)
19:41jibcan I get a vovel?
19:42jibRyanVM: sure thanks!
20:55* drno wonders how reliable Talos results are
20 May 2017
No messages
Last message: 9 days and 17 hours ago