mozilla :: #media

11 Aug 2017
02:10bkellycpearce: hope you don't mind, I directed a user with a problem to you on twitter
02:11bkellycpearce: they just started getting a green line in youtube in FF55... goes away with hardware accel turned off
02:11bkellynot sure if that rings any bells or if there is anything we can do
02:12bkellythread starts here:
02:12bkellythey determined its hardware accel here:
02:15bkellyI filed a bug:
02:15firebotBug 1389359 NEW, user seeing green bar on youtube video with hardware acceleration enabled starting in FF55
06:52hsivonenIs there a 1-to-1 correspondece between JS RTCPeerConnection objects and C++ PeerConnectionImpl objects? Does PeerConnectionImpl live exclusively on a non-main thread?
06:56hsivonenhmm. apparently not exclusively on non-main thread
07:09robswain-Mdoes firefox support ssltcp candidates?
07:10* robswain-M looks at jesup and fippo
07:43hsivonenWhy does PeerConnectionImpl store a particular thread as mThread for doing main-threadish things on instead of using dispatching to any of the Quantum DOM main threads?
07:48fipporobswain-M: i doubt it. this is google proprietary
07:48fippoeven though microsoft has a standard for it :-)
07:48robswain-Mright, i had a look at what it did
07:48robswain-Mi was just checking though
12:11jesuphsivonen: not sure... mThread goes back to the very beginning of the PeerConnectionImpl code, or close. Had to do archaeology on the mothballed copy of alder that it was developed on, but the mThread var as added by anant in July of 2012, so that they could pass nullptr to Initialize() for some fakemediastream tests in signaling_unittests.cpp (and also since at that time, the gtest tests might have been running with a non-MainThread mThr
12:11jesupead). Nowadays, signaling_unittests.cpp calls GetMainThread() and passes that in, so I think all support for passing in null threads has been removed (and even asserted against), though in theory one could pass a non-MainThread thread in to use for all the MainThread dispatches. Likely that would break a zillion other things, though. So, I suspect all this pass-mainthread-in-and-store-it could be removed, though I suppose in theory sto
12:11jesupring it has very minor perf wins. Note that there's a CheckThread/CheckThreadInt() call that checks if we're running on mThread, that would have to become a "check we're running on a virtual MainThread"
12:11jesuphsivonen: you can file a bug on it and cc dminor and me if you want
17:40mjfI just found a video stream that wont play in Firefox, but does in Chrome and Safari. My niece is riding in the world finals.
17:48mjfkentuckyfriedtakahe: ^
18:28jesupanyone remember what the company was which was using WebRTC to stream back browser displays from cross-browser tests?
18:28jibno idea
18:29robswain-MI don't know but testrtc springs to mind as a possibility...?
18:30robswain-MIt sounds like you mean s company whose focus is cross-browser testing and they just happen to use webrtc
18:30robswain-MWhereas testrtc focus on webrtc service testing
18:36jesupbwc: I think so
18:40fipporobswain-M: browserstack
18:49fippoits basically remote desktop using webrtc. works quite nicely.
19:26mjfWell, power just died here.
19:27* mjf bracing for shutdowns
19:29erahmSo we're 'upstream' for mtransport right? how about webrtc?
19:43jesuperahm: webrtc we're definitely NOT upstream for. A current push (now that we're close to tip) is to push more of our mods upstream and stop carrying them
19:43erahmjesup: okay I want to remove some gonk refs from webrtc code, does that mean I need to submit a patch upstream?
19:44* jib doubts there's any gonk upstream
19:49jibright that's in our tree only I assume. jesup?
19:50jesuperahm: just replied in the bug
19:50erahmjesup: thanks!
19:50jesupif those bits are in upstream. If they aren't then we can jsut remove them
19:51* jesup checks
19:51jesupno 'gonk' in upstream; they can all be removed
19:54rilliandmajor: is 'VideoChild' the correct thread to watch for video decoders in the Gecko Profiler?
19:58dmajorrillian: I'm not sure. I'd ask #flow.
20:00dmajor(I normally use an external profiler to inspect media things)
20:02rillianok, thanks.
20:03rillianI'm trying to figure out what's causing the av1 playback stalls
20:03rillianthe gecko profiler says everything's in pthread_cond_wait, but I don't really know what I'm doing.
20:25rillianwell, I found my naive frame downsample in the profile. it says '37 ms' next to it. I don't know if that's real or not though
20:25rillianthe decode thread does get a lot busier at the point where it stops dropping frames
20:33dmajorrillian: what do you mean by "real or not"?
20:54* mjf enjoying restored electricial service!
21:22erahmjesup: oh, so all those are local? Do I need to do anything special?
21:22erahmWas gralloc b2g only or do we still use that on android?
21:32rilliandmajor: I don't know what that's measuring. if it's taking 37 ms out of 33 ms per frame, that would explain why we're late, but I don't think that number is time per frame
22:01rilliankinetik: sadly, not leaking every video frame didn't fix the performance issue :)
23:34jesuperahm: yeah, all the 'gonk' references are local-only right now, so can be removed with a simple r+
23:38jesuperahm: I think gralloc is b2g only. and it appears to be gone (ignoring grallic() in graphite, which is something else). You can check on #mobile but a chfind mostly just finds a few comments
23:39erahmjesup: ah good, something else to rip out :) We added some abstractions for "platform data" that are only used for gralloc stuff that we can probably ditch now
12 Aug 2017
No messages
Last message: 10 days and 6 hours ago