Implement support for multiple audio/video tracks in WebM stream parser |
||||||
Issue descriptionOur current WebM parser supports only up to 1 audio and up to 1 video track, which used to be a general limitation of the rest of the media pipeline. But now ChunkDemuxer/MediaSourceState and the rest of MSE code path supports multiple media tracks, so we'll need to fix WebM parser to support multiple tracks as well. When that's done we should also add additional unit tests, for example a ChunkDemuxer unit test for multiple audio or video tracks using exact same codec and codec id in a single SourceBuffer/MediaSourceState.
,
Sep 15 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 15 2017
,
Sep 17
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 19
Dale/Husain: do we want to fix this for Chrome? It is something where Chrome doesn't comply fully with MSE spec currently, but current data for all of MSE multi-track-in-same-sourcebuffer audio or multi-track-in-same-sourcebuffer video shows nonzero, but < 0.00% of Chrome MSE transitions to HAVE_METADATA detected more than one audio or more than one video track in the same SourceBuffer: https://goto.google.com/ycgxg Our MSE WebM tracks parser still supports no more than 1 track each for audio and video (it logs to media-internals, counts the occurrence, but otherwise ignores the extra tracks if they are found). It's a relatively low-priority issue, since modern MSE apps typically use single-track streams (in separate SourceBuffers if they have audio and video), or at most, 1 track each for audio/video in the same SourceBuffer). Note, our MSE MP4 stream parser already appears (from code reading) to support multiple audio/video tracks in a SourceBuffer (and its numbers are part of those included in the stats linked, above) I'm going to default this to P3 Available for now.
,
Sep 19
Don't think it's worth fixing unless someone actually wants this support.
,
Sep 19
Ok. I'll mark this WontFix for now. We can always reactivate/fix this later if someone requests. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by wolenetz@chromium.org
, Sep 14 2016