Reduce MediaLog spam and add a note about unsupported statuses.

Reduce MediaLog spam and add a note about unsupported statuses.

Prevents FFmpegDemuxer's metadata report from hitting the 1/sec
throttling in RendererMediaLog; should reduce chances of missing
log messages.

Also adds a note about the Media.Pipeline.Unsupported metric: it
will record PIPELINE_OK if a MSE instance is created but never
used -- which is a bit surprising for this metric.

BUG=595102
TEST=metadata reports as normal.

Committed: https://crrev.com/69da898ef90feb49e414476934abf708ed04c093
Cr-Commit-Position: refs/heads/master@{#382093}

[DaleCurtis, 2016-03-16 00:26:52]

dalecurtis@chromium.org changed reviewers:
+ xhwang@chromium.org

[DaleCurtis, 2016-03-16 00:26:52]

And the perf-crastination continues :p

[DaleCurtis, 2016-03-16 00:32:43]

Description was changed from

==========
Reduce MediaLog spam and prevent UMA for pipeline's w/o a status.

Resolves two minor issues. One where we were creating too many
events back to back and hitting the 1 second throttling which might
cause stats to fall into the unsupported bucket by reporting has
audio or has video w/o a status.

Also prevents UMA logging for pipelines which never received a
pipeline status during their lifetime. Previously we'd log a
default status of OK to the unsupported UMA.

BUG=595102
TEST=pipeline events show up as normal, but UMA stat is not logged
unless an MSE player reaches its final state.
==========

to

==========
Reduce MediaLog spam and prevent UMA for pipeline's w/o a status.

Resolves two minor issues. One where we were creating too many
events back to back and hitting the 1 second throttling which might
cause stats to fall into the unsupported bucket by reporting has
audio or has video w/o a status.

Also prevents UMA logging for pipelines which never received a
pipeline status during their lifetime. Previously we'd log a
default status of OK to the unsupported UMA.

This also makes a minor change to the presentation of "start_time"
and "duration" from showing "unknown" to "inf" when duration or
start time is not known.

BUG=595102
TEST=pipeline events show up as normal, but UMA stat is not logged
unless an MSE player reaches its final state.
==========

[DaleCurtis, 2016-03-16 22:10:27]

Friendly ping Xiaohan :)

[xhwang, 2016-03-16 23:17:24]

On 2016/03/16 22:10:27, DaleCurtis wrote:
> Friendly ping Xiaohan :)

As chatted offline, Dale will take another look at this CL :)

[DaleCurtis, 2016-03-17 21:25:42]

Description was changed from

==========
Reduce MediaLog spam and prevent UMA for pipeline's w/o a status.

Resolves two minor issues. One where we were creating too many
events back to back and hitting the 1 second throttling which might
cause stats to fall into the unsupported bucket by reporting has
audio or has video w/o a status.

Also prevents UMA logging for pipelines which never received a
pipeline status during their lifetime. Previously we'd log a
default status of OK to the unsupported UMA.

This also makes a minor change to the presentation of "start_time"
and "duration" from showing "unknown" to "inf" when duration or
start time is not known.

BUG=595102
TEST=pipeline events show up as normal, but UMA stat is not logged
unless an MSE player reaches its final state.
==========

to

==========
Reduce MediaLog spam and add a note about unsupported statuses.

Prevents FFmpegDemuxer's metadata report from hitting the 1/sec
throttling in RendererMediaLog; should reduce chances of missing
log messages.

Also adds a note about the Media.Pipeline.Unsupported metric: it
will record PIPELINE_OK if a MSE instance is created but never
used -- which is a bit surprising for this metric.

This also makes a minor change to the presentation of "start_time"
and "duration" from showing "unknown" to "inf" when duration or
start time is not known.

BUG=595102
TEST=metadata reports as normal.
==========

[DaleCurtis, 2016-03-17 21:26:11]

PTAL; I've reverted the internals change in favor of a note about why we see
high PIPELINE_OK rates here. I don't think there's an easy way around this, so
I'll leave it alone for now.

[xhwang, 2016-03-17 21:40:26]

Looking good. I just have one dumb question.

Where the "inf" coming from? Is it some trick in JS? Personally I found it less
readable than "unknown"...

[DaleCurtis, 2016-03-17 23:52:56]

Description was changed from

==========
Reduce MediaLog spam and add a note about unsupported statuses.

Prevents FFmpegDemuxer's metadata report from hitting the 1/sec
throttling in RendererMediaLog; should reduce chances of missing
log messages.

Also adds a note about the Media.Pipeline.Unsupported metric: it
will record PIPELINE_OK if a MSE instance is created but never
used -- which is a bit surprising for this metric.

This also makes a minor change to the presentation of "start_time"
and "duration" from showing "unknown" to "inf" when duration or
start time is not known.

BUG=595102
TEST=metadata reports as normal.
==========

to

==========
Reduce MediaLog spam and add a note about unsupported statuses.

Prevents FFmpegDemuxer's metadata report from hitting the 1/sec
throttling in RendererMediaLog; should reduce chances of missing
log messages.

Also adds a note about the Media.Pipeline.Unsupported metric: it
will record PIPELINE_OK if a MSE instance is created but never
used -- which is a bit surprising for this metric.

BUG=595102
TEST=metadata reports as normal.
==========

[DaleCurtis, 2016-03-17 23:53:27]

inf can occur on live streams. It's also not supported by base::Values so
switched back to "unknown" but killed dead setters on the media log.

[xhwang, 2016-03-18 17:31:35]

https://codereview.chromium.org/1800353002/diff/40001/media/filters/ffmpeg_de...
File media/filters/ffmpeg_demuxer.cc (right):

https://codereview.chromium.org/1800353002/diff/40001/media/filters/ffmpeg_de...
media/filters/ffmpeg_demuxer.cc:185: }
OOC, when will we set the max TimeDelta?

We do use kNoTimeStamp() in our code base. Is it possible that we report that?
What will it look like in media-internals page?

[DaleCurtis, 2016-03-18 17:36:49]

https://codereview.chromium.org/1800353002/diff/40001/media/filters/ffmpeg_de...
File media/filters/ffmpeg_demuxer.cc (right):

https://codereview.chromium.org/1800353002/diff/40001/media/filters/ffmpeg_de...
media/filters/ffmpeg_demuxer.cc:185: }
On 2016/03/18 at 17:31:35, xhwang wrote:
> OOC, when will we set the max TimeDelta?
> 
> We do use kNoTimeStamp() in our code base. Is it possible that we report that?
What will it look like in media-internals page?

kInfiniteDuration() return TimeDelta::Max(). We could say kInifiniteDuration
here?

[xhwang, 2016-03-18 17:40:10]

https://codereview.chromium.org/1800353002/diff/40001/media/filters/ffmpeg_de...
File media/filters/ffmpeg_demuxer.cc (right):

https://codereview.chromium.org/1800353002/diff/40001/media/filters/ffmpeg_de...
media/filters/ffmpeg_demuxer.cc:185: }
On 2016/03/18 17:36:49, DaleCurtis wrote:
> On 2016/03/18 at 17:31:35, xhwang wrote:
> > OOC, when will we set the max TimeDelta?
> > 
> > We do use kNoTimeStamp() in our code base. Is it possible that we report
that?
> What will it look like in media-internals page?
> 
> kInfiniteDuration() return TimeDelta::Max(). We could say kInifiniteDuration
> here?

Yeah, that makes sense for the duration, but for timestamp (e.g. start_time),
will we ever see kNoTimeStamp()?

[DaleCurtis, 2016-03-18 18:01:30]

https://codereview.chromium.org/1800353002/diff/40001/media/filters/ffmpeg_de...
File media/filters/ffmpeg_demuxer.cc (right):

https://codereview.chromium.org/1800353002/diff/40001/media/filters/ffmpeg_de...
media/filters/ffmpeg_demuxer.cc:185: }
On 2016/03/18 at 17:40:09, xhwang wrote:
> On 2016/03/18 17:36:49, DaleCurtis wrote:
> > On 2016/03/18 at 17:31:35, xhwang wrote:
> > > OOC, when will we set the max TimeDelta?
> > > 
> > > We do use kNoTimeStamp() in our code base. Is it possible that we report
that?
> > What will it look like in media-internals page?
> > 
> > kInfiniteDuration() return TimeDelta::Max(). We could say kInifiniteDuration
> > here?
> 
> Yeah, that makes sense for the duration, but for timestamp (e.g. start_time),
will we ever see kNoTimeStamp()?

We DCHECK() that it doesn't happen in a lot of cases, but I suppose that doesn't
prevent in field reports of that value. I've added both cases to the time
conversion.

[xhwang, 2016-03-18 18:27:49]

lgtm

Thanks!

[DaleCurtis, 2016-03-18 19:28:18]

The CQ bit was checked by dalecurtis@chromium.org

[commit-bot: I haz the power, 2016-03-18 19:28:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1800353002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1800353002/60001

[commit-bot: I haz the power, 2016-03-18 21:26:49]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-03-18 21:28:35]

Description was changed from

==========
Reduce MediaLog spam and add a note about unsupported statuses.

Prevents FFmpegDemuxer's metadata report from hitting the 1/sec
throttling in RendererMediaLog; should reduce chances of missing
log messages.

Also adds a note about the Media.Pipeline.Unsupported metric: it
will record PIPELINE_OK if a MSE instance is created but never
used -- which is a bit surprising for this metric.

BUG=595102
TEST=metadata reports as normal.
==========

to

==========
Reduce MediaLog spam and add a note about unsupported statuses.

Prevents FFmpegDemuxer's metadata report from hitting the 1/sec
throttling in RendererMediaLog; should reduce chances of missing
log messages.

Also adds a note about the Media.Pipeline.Unsupported metric: it
will record PIPELINE_OK if a MSE instance is created but never
used -- which is a bit surprising for this metric.

BUG=595102
TEST=metadata reports as normal.

Committed: https://crrev.com/69da898ef90feb49e414476934abf708ed04c093
Cr-Commit-Position: refs/heads/master@{#382093}
==========

[commit-bot: I haz the power, 2016-03-18 21:28:36]

Patchset 4 (id:??) landed as
https://crrev.com/69da898ef90feb49e414476934abf708ed04c093
Cr-Commit-Position: refs/heads/master@{#382093}