Media.PipelineStatus.Unsupported shows too high of a rate for PIPELINE_OKAY |
|||
Issue descriptionThis 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.
,
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
,
Mar 18 2016
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.
,
Mar 18 2016
+mse folk ass an FYI.
,
Mar 18 2016
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?
,
Mar 18 2016
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 |
|||
Comment 1 by dalecur...@chromium.org
, Mar 16 2016274 bytes
274 bytes View Download