Skip to content

Typefind fails to recognize application/dash+xml, falls back to application/xml

Describe your issue

Regression when trying to play back a particular mpeg-dash stream (does not happen with 1.20).

Expected Behavior

Stream plays.

Observed Behavior

Fails with error:

../subprojects/gst-plugins-base/gst/playback/gstdecodebin2.c(4704): gst_decode_bin_expose (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0:
no suitable plugins found:
Missing decoder: application/xml (application/xml)

Setup

Steps to reproduce the bug

  1. run gst-play-1.0 "https://livesim.dashif.org/livesim/testpic_2s/audio.mpd"

How reproducible is the bug?

Always

Screenshots if relevant

Solutions you have tried

Related non-duplicate issues

#1536 (closed)

Additional Information

This seems to happen because of a recent change: 11520403

The manifest in this particular case has a long list of attributes for the <MPD> element, and because of that the > character is after the first 512 bytes (looks like 523 on a quick check in an editor):

<?xml version="1.0" encoding="utf-8"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" availabilityStartTime="1970-01-01T00:00:00Z" id="Config part of url maybe?" maxSegmentDuration="PT2S" minBufferTime="PT2S" minimumUpdatePeriod="P100Y" profiles="urn:mpeg:dash:profile:isoff-live:2011,http://dashif.org/guidelines/dash-if-simple" publishTime="2023-03-16T22:42:44Z" timeShiftBufferDepth="PT5M" type="dynamic" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd">

But typefind's xml_check_first_element() default is to check the first 512 bytes for the closing character. Maybe this default should be increased? I can submit a MR with a larger limit (768? 1024?), if that's acceptable.

Edited by Ilie Halip