Bug 165394 - [GStreamer][MSE] Support multiple streams per SourceBuffer and dynamic audio/video/text type changes
Summary: [GStreamer][MSE] Support multiple streams per SourceBuffer and dynamic audio/...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Enhancement
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 167107
  Show dependency treegraph
 
Reported: 2016-12-05 11:46 PST by Enrique Ocaña
Modified: 2017-10-10 15:12 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enrique Ocaña 2016-12-05 11:46:32 PST
The current GStreamer MSE platform implementation doesn't support more than one stream per SourceBuffer.

Caps changes are managed as stream quality changes in order to support adaptive streaming, but that's all. An audio/video/text stream can't be reconverted to other type. This feature is required for LayoutTests/media/media-source/media-source-seek-detach-crash.html to work properly.
Comment 1 Alicia Boya García 2017-10-10 15:12:25 PDT
> An audio/video/text stream can't be reconverted to other type. This feature
> is required for
> LayoutTests/media/media-source/media-source-seek-detach-crash.html to work
> properly.

Note that MSE not only does not require support for converting streams to other
formats, but even forbids it per spec:

https://www.w3.org/TR/media-source/#sourcebuffer-init-segment-received

3. If the first initialization segment received flag is true, then run the
following steps:

  1. Verify the following properties. If any of the checks fail then run the
append error algorithm and abort these steps.

     * The number of audio, video, and text tracks match what was in the first
       initialization segment.

     * The codecs for each track, match what was specified in the first
       initialization segment.

     * If more than one track for a single type are present (e.g., 2 audio
       tracks), then the Track IDs match the ones in the first initialization
       segment.


What the test is checking is that if that any of these conditions is met the
error is handled gracefully, which is not currently the case.

The test expectation should be changed from [ Skip ] to [ Crash ] and the bug
eventually fixed.