Bug: DASH manifest attributes are not unescaped

Support
1

DASH manifest / XML requires attributes be escaped (<, >, &, ', "). Unfortunately, bitmovin is not unescaping these attributes as expected. In the case where SegmentTemplate initialization/media attributes contain multiple query parameters, this can lead to a 404 when requesting segments.

A workaround for this would be to implement a network.preprocessHttpRequest to forcibly unescape the request url. However, while this allows the stream to work in the browser, chromecasting with the default receiver will fail with the same issue.

Proxying the manifest to forcibly unescape attributes does work with bitmovin/chromecast, but is non-compliant XML. Testing this manifest with shaka and other players will fail with xml errors.

https://www.w3.org/TR/xml11/#sec-predefined-ent

2

Hi @david.g.lark , welcome to Bitmovin community and thanks for reporting this. Let me share some insights about Casting playback first.

The playback on cast device is done by Google’s CAF receiver SDK which uses Shaka player under the hood for playback. Bitmovin web player SDK on sender device sends the DASH URL to Cast device and the download and parsing of DASH MPD is done exclusively on receiver by Cast SDK and underlying Shaka player, so Bitmovin web player has no role to play in parsing MPD for playback on cast device. If you are observing playback issues on default CAF receiver, then it is most likely that CAF receiver SDK provided by Google or the Shaka player used under the hood is not able to parse the MPD file. Can you please share more insights into failures reported during playback on cast device?

You can also verify the playback of the asset on cast device using CAC tool provided by Google

Regarding Bitmovin web player SDK not unescaping the escaped XML attributes, can you please share a sample DASH MPD URL with such escaped attributes? It will help us to look further into it to investigate the behaviour.

3

Very well. https://flask-production-11bc.up.railway.app/content/assets/art-of-motion-dash-hls-progressive/mpds/f08e80da-bf1d-4e3d-8899-f0f6155f6efa.mpd?a=1&b=2

It simply modifies your demo manifest to inject any query parameters supplied. Segment requests will 404 if any parameters start with amp;. Otherwise, it will redirect accordingly.

Again, initialization/media attributes are parsed properly and unescaped by shaka and the dash if reference player. Bitmovin does not unescape.

4

Hi @david.g.lark , thanks for sharing the sample asset.

  • I am able to replicate the behaviour with Bitmovin player. As you already pointed out, the current solution for Bitmovin player is to use network.preprocessHttpResponse config as demonstrated below. We will also put this into our backlog for a fix so that this configuration is not required in long term.
 network: {
      preprocessHttpResponse: function (type, response) {         
        if (type === 'manifest/dash') {
          response.body = response.body.replaceAll(/&amp;/g, '&');
        }
        return Promise.resolve(response);
      },
    },
  • I also tried this casting with this content but I could not replicate the behaviour. Casting playback works fine when done from Bitmovin web player. I also tried using CAC Tool with Bitmovin default CAF receiver and playback worked fine without the need of any specific configuration.

So as an immediate solution using network.preprocessHttpResponse should be sufficient for playback using Bitmovin web SDK and casting playback.

5

Aye, I was still using the non-CAF receiver due to performance issues with the CAF receiver and older Chromecasts. Will test CAF again to see if things have improved.