Some WebRTC log messages don't make the log |
||||||||
Issue descriptionSome WebRTC log messages in the end of calls don't make the log. This is because all we register all logging handlers as listeners, and we filter forwarding of the messages by which render processes that have a MediaStream request. Afaik, the reason for filtering is to avoid unnecessary calls to those not interested in log messages. Since logging in the browser process was introduced, the way we call up to the logging handler (which lives in the embedder) has changed from going through the RenderProcessHost(Impl) to be a direct callback. With the new design, it allows to and makes more sense to register the callback when logging is started, and unregister when stopping, and then remove the MS request filtering. This will then ensure all messages reaches the logging handlers that are interested.
,
Apr 8 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/34f2e5e23e6a3a34742089fc49590075d4352685 commit 34f2e5e23e6a3a34742089fc49590075d4352685 Author: grunell <grunell@chromium.org> Date: Fri Apr 08 12:54:59 2016 Change WebRTC log callback registration in browser process. This ensures we forward all log messages, also when shutting down. * Register the callback when logging is started, and unregister when stopping. * Remove the MediaStream request filtering when running callbacks. BUG= 601389 Review URL: https://codereview.chromium.org/1871533002 Cr-Commit-Position: refs/heads/master@{#386058} [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/chrome/browser/chrome_content_browser_client.cc [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/chrome/browser/media/webrtc_log_uploader_unittest.cc [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/chrome/browser/media/webrtc_logging_handler_host.cc [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/chrome/browser/media/webrtc_logging_handler_host.h [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/content/browser/renderer_host/media/media_stream_manager.cc [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/content/browser/renderer_host/render_process_host_impl.cc [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/content/browser/renderer_host/render_process_host_impl.h [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/content/public/browser/render_process_host.h [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/content/public/test/mock_render_process_host.cc [modify] https://crrev.com/34f2e5e23e6a3a34742089fc49590075d4352685/content/public/test/mock_render_process_host.h
,
Apr 8 2016
,
Apr 8 2016
Thanks for the fix! grunell@, can you describe some logging scenarios that should now work with M51 that may not have worked consistently in M50?
,
Apr 11 2016
There is some info during shutdown that I saw would not make it, most notably "AISW: number of detected audio glitches: 0 out of x" Also other data around glitches I plan to add to the logging. However, I also noted that often the logging was stopped by the application before these "late messages" reached the logging handler, so it also depends on that.
,
Apr 29 2016
Verified in M51 Beta 51.0.2704.29 Established a 2 way hangout call and verified that in the logs (attached), I do not see the line "AISW: number of detected audio glitches: 0 out of x" (checked with M50, that the logs have the above line)
,
May 4 2016
I don't understand how the results in comment #6 verifies this. On the other hand, the result is that we saw a log in M50 and not in M51. In comment #5 I mean that the issue is that the log line often isn't seen. But as I wrote there too, it also depends on the application so it's not possible to verify reliably. The probability of certain log lines making it should be higher than before. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by grunell@chromium.org
, Apr 8 2016