New issue
Advanced search Search tips

Issue 595102 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Media.PipelineStatus.Unsupported shows too high of a rate for PIPELINE_OKAY

Project Member Reported by dalecur...@chromium.org, Mar 15 2016

Issue description

This status should only be logged if there are no audio and no video streams... but we're seeing this regularly logged with PIPELINE_OKAY.

https://uma.googleplex.com/histograms/?endDate=03-13-2016&dayCount=7&histograms=Media.PipelineStatus.Unsupported&fixupData=true&showMax=true&filters=simple_version%2Ceq%2C50.0.2661.26%2Cplatform%2Ceq%2CA%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

We should dig in and find out why this is happening.
 
Actually unsupported may be a misnomer here. I think this is due to MSE, where pipeline may be stuck in kInitDemuxer for some time (until init segments are appended).  Our default pipeline status is PIPELINE_OK, so we report that here. The attached page demonstrates this.
empty_mse.html
274 bytes View Download
Project Member

Comment 2 by bugdroid1@chromium.org, Mar 18 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/69da898ef90feb49e414476934abf708ed04c093

commit 69da898ef90feb49e414476934abf708ed04c093
Author: dalecurtis <dalecurtis@chromium.org>
Date: Fri Mar 18 21:26:37 2016

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.

Review URL: https://codereview.chromium.org/1800353002

Cr-Commit-Position: refs/heads/master@{#382093}

[modify] https://crrev.com/69da898ef90feb49e414476934abf708ed04c093/content/browser/media/media_internals.cc
[modify] https://crrev.com/69da898ef90feb49e414476934abf708ed04c093/media/base/media_log.cc
[modify] https://crrev.com/69da898ef90feb49e414476934abf708ed04c093/media/base/media_log.h
[modify] https://crrev.com/69da898ef90feb49e414476934abf708ed04c093/media/filters/ffmpeg_demuxer.cc

Status: WontFix (was: Assigned)
After digging some, this isn't too unexpected: It occurs when a MediaSource element is created but never used. So aside from some minor cleanup I'm going to call this as WontFix.
Cc: chcunningham@chromium.org wolenetz@chromium.org
+mse folk ass an FYI.
Would a distinct PipelineStatus that also means "OK" be useful to see how many of a PIPELINE_OK_BUT_NO_METADATA_YET actually occur? Since this still means "OK", we might need to patch in a helper like "isStatusOk(PipelineStatus status)?

Can this scenario also happen for a very slow src= data source or a very quick element close while FFmpegDemuxer hasn't yet handled OnFindStreamInfoDone()? In which case, perhaps differentiate CHUNK_DEMUXER vs ffmpeg with yet another PipelineStatus?
Yeah that's true it can happen with src= too if the connection stalls forever. I don't think it's worth diving much into.

Sign in to add a comment