17:34	dcoloma	jesup: ping
17:38	jesup	dcoloma: pong
17:38	dcoloma	jesup: hey! we have been trying to find out what can be do to improve loop performance in FxOS
17:39	dcoloma	jesup: so far we have not found any concrete thing we could do, but we have found a huge number of frames dropped in FxOS
17:40	dcoloma	jesup: it seems FxOS Loop can manage quite well decoding, as in Desktop-FxOS calls, the Desktop stream is properly decoded with a good frame rate
17:40	dcoloma	jesup: but the stream that is being sent from FxOS seems to be missing a lot of frames
17:41	jesup	dcoloma: can you try disabling load adaptation: user_pref("media.navigator.load_adapt", false);
17:41	dcoloma	jesup: yep, we can try that
17:42	dcoloma	jesup: anything else we can do to check why the device is dropping those frames?
17:43	jesup	Also, I have a suspicion that the H.264 frame-counting stuff (that messed up the "dropped frames" report, and is now fixed on 2.1 IIRC) might also impact the FPS measurement code, which might make it think it's getting many more frames from the camera than it is and cause it to drop input frames. THis is just a guess. I'll go look deeper
17:48	dcoloma	jesup: Ok, I'll try to test your suggestion first and see what happens
17:48	jesup	thanks
18:02	dcoloma	jesup: changing load_adapt from true to false made the number of dropped frames increase
18:03	dcoloma	jesup: one thing I forgot to mention is that we cannot reproduce this when establishing WebRTC sessions in the browser
18:03	jesup	dcoloma: you mean desktop to desktop?
18:04	dcoloma	no, FxOS to FxOS
18:04	jesup	Or browser in the fxos phone?
18:04	jesup	ah. Can you try disabling H.264?
18:04	jesup	what base are you using? v184?
18:04	dcoloma	yep
18:04	dcoloma	DSP 1530.1
18:05	jesup	does your tree have the removal/disabling of the iframe-to-change-bnadwidth code?
18:05	* jesup looks up the bug
18:07	jesup	each iframe was causing 1-4 frames to be dropped, and we had to send a lot of iframes (for bandwidth changes)
18:07	* jesup tries to remember if the DSP fix for that is in 1530.1 or the rev after that
18:08	jesup	bug 1033335 - landed ~ oct 7th on b2g32 it looks like
18:09	jesup	sorry, the 10th
18:10	jesup	no, that was 2.0m. 2.0 was the 8th
18:10	* jesup should read more before commenting
18:10	jesup	and 1530.1 should work with that
18:10	jesup	dcoloma: ^
18:11	jesup	dcoloma: for the in-fxos-browser case, was that h.264 or vp8?
18:11	dcoloma	h.264
18:12	dcoloma	the number of frames dropped with vp8 is smaller than with h.264 in the test I've just made
18:13	jesup	dcoloma: how are you measuring dropped frames?
18:15	dcoloma	we added some logs to TB library
18:15	dcoloma	https://github.com/mozilla-b2g/fir...tokbox/v2.2.9.1/js/TB.js#L15929
18:15	jesup	does it have the "key frames and delta frame reports are wrong" patch that landed in nightly & 2.1?
18:16	jesup	Note: that's not on 2.0
18:16	dcoloma	jesup: I don't think so
18:16	dcoloma	we are using 2.0
18:18	dcoloma	jesup: ok, we are going to compare multiple scenarios on Monday
18:18	dcoloma	FxOS - FxOS via browser
18:18	dcoloma	FxOS - FxOS via Loop
18:18	jesup	I don't see where dropped frames comes from there
18:20	dcoloma	FxOS - FxOS via a vanilla WebRTC client
18:20	dcoloma	I think we basically did the same with the PeerConnection object that the webrtc stats page in Fx did
18:21	jesup	In CodecStatistics.cpp, we calculate "dropped frames" as input frames - (key frames + delta frames). But per bug 1069047, key and delta frames are way off for h.264
18:21	jesup	The patch makes it count each frame outgoing only once
18:22	dcoloma	ok, we will give it a spin in 2.1
18:22	dcoloma	so for the 3 scenarios I've mentioned above, apart from the "default" configuration with H.264, anything else interest to configure/measure?
18:23	jesup	A better measure overall (not of dropped frames, but of quality) is to talk to desktop and look at about:webrtc and look at the receive fps
18:24	jesup	Well, that's all I can think of at the moment. The difference between browser and app has to come from somewhere
18:28	dcoloma	jesup: OK, yep, let's try involving desktop too
18:28	dcoloma	jesup: thanks!
18:29	jesup	dcoloma: so what's different between browser and app? Different process. Perhaps different visual layers. On the "attention" screen IIRC. Perhaps status bar differences? (I found a lot of time in the profile was going to status-bar stuff; that won't be fixed for 2.0 but maybe it can be worked around some)
18:29	jesup	though status bar should update for browser too
18:29	dcoloma	jesup: yep, browser is part of the system process
18:29	jesup	browser is a sub-process of b2g
18:30	jesup	like the app I believe
18:31	dcoloma	jesup: humm, I thought it was part of the main process
18:31	jesup	but a lot of b2g time was being eaten in status bar updates, and the differences between your app and QC's were mostly in compositor and b2g IIRC (see analysis in email/bugs)
18:31	dcoloma	jesup: at least it was that way a while ago
18:31	jesup	dcoloma: long, long ago in a galaxy far away. Way too risk security-wise
18:31	jesup	risky
18:32	jesup	Perhaps there's a difference in how the status bar is hidden, for example, or how video elements are laid out/overlaid/etc
18:33	dcoloma	jesup: status bar is also in browser, the key difference is attention screen but we can easily test a loop app without attention screen
18:33	jesup	maybe (just maybe) there's a difference between full-screen app, and "status bar has slid off the screen"
18:35	dcoloma	jesup: anyhow, I am not sure if the CPU consumption could explain any issue with encoding
18:36	jesup	dcoloma: if the CPU is pegged or close, it will miss deadlines and effectively drop the frame rate
18:37	jesup	load adaptation (if on) will notice very high CPU and drop the framerate (and resolution in >1530.1) as well.