The newest version (1.15.5) of United Streaming software has rolled out, storing new fixes and features for customers so that they can stream content more efficiently.

Here are just a handful.

TTML

Unified Streaming now writes TTML subtitles more efficiently, writing only referenced styles and regions in TTML fragments. So you're sending only the TTML that may be consumed by the client. This change reduces the volume of data sent onward to the client.

In video streaming, every kilobyte of information matters. If you reduce the size of those packages (in this case, TTML subtitle data), the data transmission will be faster than sending all the data. How's that for efficiency?

What is TTML, by the way? It’s short for Timed Text Markup Language, a standard used mostly for subtitling and captioning. Many industry groups use TTML, including Society of Motion Picture and Television Engineers (SMPTE); European Broadcasting Union (EBU); Advanced Television Systems Committee (ATSC); Digital Video Broadcasting (DVB); Hybrid Broadcast Broadband TV (HbbTV); and Motion Pictures Experts Group (MPEG).

DVB-DASH adds

DVB-DASH is a streaming specification that defines the delivery of live and on-demand TV content via HTTP adaptive streaming. DVB-DASH is a profile of MPEG DASH, which is an internationally standardized, adaptive bitrate, HTTP-based streaming solution.

Several enrichments for DVB-DASH have been put into the newest release.

For Unified Virtual Channel, you can now toggle DVB-DASH output using the mpd_profile query parameter. This allows you to serve both regular DASH and DVB-DASH clients from a single virtual channel. We’ve also made some fixes to ensure the output is properly compliant with the DVB-DASH profile.

Most significantly, the update no longer sets MPD@timeShiftBufferDepth dynamically when serving a growing manifest with a fixed start time. If MPD@timeShiftBufferDepth is no longer set, then video players should assume it's infinite (unlimited), which, in theory, makes video playback more stable and reliable.

What is MPD@timeShiftBufferDepth? Well, MPD stands for Media Presentation Description. It’s a file used in DASH streaming. Basically, it tells a video player how to stream a video. And "timeShiftBufferDepth" is a setting inside that MPD file.

What does timeShiftBufferDepth do? It tells the video player how much of the recent video stream it can go back and re-watch, like a DVR buffer. For example, if timeShiftBufferDepth = 300 seconds, the player can rewind up to 5 minutes. And if it's not set, the video player assumes it can rewind as far back as needed (infinite or unlimited).

Why does this matter?

Well, if the buffer is too short, viewers might not be able to rewind to what they want. If it's infinite, players have more flexibility and can offer a smoother, more reliable experience — especially for live or growing content.

HEV1 and DASH

For Unified Origin, we’ve added support for 'hev1' (HEVC with in-band VPS/SPS/PPS) with DVB-DASH (urn:dvb:dash:profile:dvb-dash:2014), further increasing the options available to DVB-DASH compliant players.

SCTE 35 things

In the category of SCTE 35 markers, or cue messages that can signal start times and durations of advertisement breaks, there is the following update. When a SCTE 35 segment's duration is provided, and the duration expires without a segment end being signaled, then the value of “segmentation_event_id” may be reused, if it’s appropriate. This helps with avoiding errors in playback when an end event has not been sent.

As this signaling is used for advertising, it's important to know when ad content ends, so content in the main stream can continue.

The benefits of this SCTE 35 signaling update, particularly regarding the reuse of the segmentation_event_id, are quite meaningful for both playback reliability and ad delivery accuracy.

Here’s a breakdown of the key advantages.

1. Improved playback continuity

If the end of an ad break isn’t explicitly signaled (time_signal() type 49 is delayed), some video players detect a gap in the output timeline. Reusing the segmentation_event_id when the specified duration has ended ensures that playback continues smoothly, even if the final cue is slightly late. This avoids stalls or freezes in playback.

 2. Better timeline accuracy

By acknowledging that the ad break ended when the duration expired (even without an explicit end signal), the output timeline remains consistent. This maintains sync between ad content and main programming without introducing misalignments.

3. Resilience against delays in signaling

Sometimes, the time_signal() that marks the end of an ad break arrives late (even just a few milliseconds). Instead of causing logic or playback issues due to this tiny delay, the system can gracefully handle it by assuming the break ended when expected and safely reusing the ID.

4. Efficient use of segmentation_event_id values

SCTE 35 messages often rely on unique IDs to track segments. Allowing reuse after a clean timeout helps avoid unnecessary exhaustion or confusion from accumulating unused or “stuck” IDs.

5. Compatibility across devices and players

Some players are strict about timeline continuity. Ensuring that there is no perceived gap helps maintain broad device compatibility and user experience, especially in dynamic ad insertion scenarios.

6. Aligns better with real-world ad durations

Ads often run to a predefined duration (e.g., 30s), regardless of whether signaling is perfectly timed. Using the duration as a trustworthy indicator of end time makes the system more aligned with operational realities in ad delivery.

Bone

And here’s a bone we can throw to that unsung hero, Unified Capture.

When unexpected cURL errors occur, Unified Streaming says, please retry twice before giving up, instead of giving up immediately. This should make capturing over unreliable transports “a bit more robust.”

To ask questions about our G.A. release, simply email us.