Bug 173045 - Add WebRTC stats logging
Summary: Add WebRTC stats logging
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: youenn fablet
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-06-06 21:57 PDT by youenn fablet
Modified: 2017-06-08 09:39 PDT (History)
5 users (show)

See Also:


Attachments
Patch (7.84 KB, patch)
2017-06-06 22:25 PDT, youenn fablet
no flags Details | Formatted Diff | Diff
Patch (7.84 KB, patch)
2017-06-07 08:32 PDT, youenn fablet
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description youenn fablet 2017-06-06 21:57:03 PDT
To help debugging
Comment 1 youenn fablet 2017-06-06 22:25:55 PDT
Created attachment 312162 [details]
Patch
Comment 2 Build Bot 2017-06-06 22:28:16 PDT
Attachment 312162 [details] did not pass style-queue:


ERROR: Source/ThirdParty/libwebrtc/Source/webrtc/api/stats/rtcstats.h:78:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 1 in 5 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 3 youenn fablet 2017-06-07 08:32:39 PDT
Created attachment 312185 [details]
Patch
Comment 4 Build Bot 2017-06-07 08:34:38 PDT
Attachment 312185 [details] did not pass style-queue:


ERROR: Source/ThirdParty/libwebrtc/Source/webrtc/api/stats/rtcstats.h:78:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 1 in 5 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 5 Eric Carlson 2017-06-07 08:36:16 PDT
Comment on attachment 312185 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=312185&action=review

> Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.cpp:1005
> +    if (!m_statsTimestamp)
> +        m_statsTimestamp = report->timestamp_us();
> +    else if (m_statsLogTimer.repeatInterval() == 1_s && (report->timestamp_us() - m_statsTimestamp) > 30000000) {
> +        callOnMainThread([protectedThis = makeRef(*this)] {
> +            protectedThis->m_statsLogTimer.augmentRepeatInterval(4_s);
> +        });
> +    }

Is there any reason to do this when RELEASE_LOG_DISABLED is defined?
Comment 6 youenn fablet 2017-06-07 08:52:00 PDT
(In reply to Eric Carlson from comment #5)
> Comment on attachment 312185 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=312185&action=review
> 
> > Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.cpp:1005
> > +    if (!m_statsTimestamp)
> > +        m_statsTimestamp = report->timestamp_us();
> > +    else if (m_statsLogTimer.repeatInterval() == 1_s && (report->timestamp_us() - m_statsTimestamp) > 30000000) {
> > +        callOnMainThread([protectedThis = makeRef(*this)] {
> > +            protectedThis->m_statsLogTimer.augmentRepeatInterval(4_s);
> > +        });
> > +    }
> 
> Is there any reason to do this when RELEASE_LOG_DISABLED is defined?

m_statsTimestamp is never used otherwise and the build system does not like that.
This code will never be executed if RELEASE_LOG_DISABLED is defined anyway.
Comment 7 WebKit Commit Bot 2017-06-07 09:55:13 PDT
Comment on attachment 312185 [details]
Patch

Clearing flags on attachment: 312185

Committed r217888: <http://trac.webkit.org/changeset/217888>
Comment 8 WebKit Commit Bot 2017-06-07 09:55:14 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 Jon Lee 2017-06-07 11:13:36 PDT
rdar://problem/32276496
Comment 10 Eric Carlson 2017-06-08 09:39:58 PDT
Comment on attachment 312185 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=312185&action=review

>>> Source/WebCore/Modules/mediastream/libwebrtc/LibWebRTCMediaEndpoint.cpp:1005
>>> +    }
>> 
>> Is there any reason to do this when RELEASE_LOG_DISABLED is defined?
> 
> m_statsTimestamp is never used otherwise and the build system does not like that.
> This code will never be executed if RELEASE_LOG_DISABLED is defined anyway.

The m_statsTimestamp declaration could be guarded with RELEASE_LOG_DISABLED as well.