To understand is to perceive <Patterns>

Most people in the streaming industry probably watch live streams a bit different from “normal” people. Personally, I am always curious about the formats and settings the streaming providers use and if there is anything special to be found. When I was watching the UEFA Champions League game between Bayern Munich and Salzburg I took the chance to look into the Amazon Prime DASH manifest and found something interesting.

For Chrome Desktop browsers, Amazon uses the DASH format with a video segment duration of exactly two seconds:

<SegmentTemplate timescale="25000">

<SegmentTimeline>
    <S d="50000" r="853" t="110492081250"/>
</SegmentTimeline>

So far so good, nothing special here. The only interesting thing here is that they use a  <SegmentTimeline> signaling with an @r attribute. In Why and how to align media segments for ABR streaming we discussed ways to align the duration of audio and video segments. One of the main advantages we gain from this alignment is the reduced DASH manifest size. We can easily use a <SegmentTemplate> mechanism or use the @r parameter together with <SegmentTimeline> for both audio and video at the same time. However, there are only certain combinations of video framerate, audio sampling rate and segment duration for which audio and video segments are aligned. Two seconds is not one of them. Consequently, the audio segments in the Amazon stream must have some kind of oscillating duration pattern. And this is where we come to the interesting part. 

To avoid large manifest files with a repeating <SegmentTimeline> duration pattern Amazon simply introduced a new <Pattern> element:

<SegmentTemplate timescale="48000">
    <SegmentTimeline>
        <S d="96256" r="2" t="212144796192"/>
        <Pattern r="211" t="212145084960">
            <S d="95232"/>
            <S d="96256" r="2"/>
        </Pattern>
        <S d="95232" t="212226492960"/>
        <S d="96256" r="1" t="212226588192"/>
    </SegmentTimeline>

The <Pattern> element has an @r counter similar to what we know from the <S> element. In addition, the @t attribute serves as a timing anchor. Inside the <Pattern> element we find the <S> element structure we know from “standard compliant” DASH streaming.

I remember that we had a similar discussion about <Pattern> elements in DASH-IF some years ago based on a presentation by AWS Elemental. To my best knowledge, this never made it into the MPEG specification or the DASH-IF IOP guidelines, as it would break backwards compatibility. It is interesting to see that the industry saw a need for it and implemented it accordingly. Obviously, Amazon has most certainly full control over the encoder, the packager and most of the platforms they are available on. Maybe the discussion will come up in MPEG or DASH-IF again, and we will see a similar <Pattern> approach also in one of the next specifications. For minor differences between the segment durations a <SegmentTemplate> approach instead of <SegmentTimeline> with <Pattern> works as well. The DASH ISO specification allows up to 50% deviation between MPD start time and the segment’s presentation time.

If you have any question regarding DASH streaming or dash.js in particular, feel free to check out our website and contact us.