Live TV: MPEG-TS timestamp discontinuities cause HLS segment corruption with -copyts (Pluto TV ad breaks)

[Renato Meneses 0]

Hello Emby team,

I've been investigating Live TV playback failures during Pluto TV advertising transitions. After several controlled tests, I found a reproducible timestamp-handling issue involving -copyts in Emby's bundled FFmpeg.

I'm opening this as a technical investigation rather than another general report of Pluto TV freezing.

First, I would like to acknowledge the work shared by n0se in this thread:

https://emby.media/community/topic/150042-live-tv-m3u-streams-breaking-at-ad-breaks-%E2%80%94-working-threadfin-ffmpeg-solution/

The author documented a working Threadfin + FFmpeg buffering workaround. My findings support the usefulness of an intermediate normalization layer, but I would like to investigate whether the underlying issue could be addressed directly within Emby.

Environment

• Emby Server: 4.11.0.13

• Platform: Docker/Linux, TerraMaster NAS

• Bundled FFmpeg: 5.1-emby_2023_06_25_p6

• Live TV source: Pluto TV through SynthIPTV

• Input: MPEG-TS, H.264 video and AAC audio

• Playback clients: Edge on Windows and Android

Original issue

The channel plays normally until Pluto transitions into or out of an advertising break.

When this happens, Emby may freeze, repeat previously displayed frames, or fail to resume automatically.

The same source is generally more tolerant of these transitions in VLC. I also observed VLC's playback timer resetting around advertising transitions.

Emby's FFmpeg logs showed extensive Non-monotonous DTS errors, sometimes accompanied by segments with extremely short durations.

Controlled test using Emby's FFmpeg

I tested the same MPEG-TS source using the FFmpeg executable bundled with Emby and the MPEG-TS segment muxer.

Two FFmpeg processes ran concurrently, using equivalent parameters except for timestamp handling:

A — With timestamp preservation

-copyts -start_at_zero

B — Without timestamp preservation

-fflags +genpts

Both were configured with H.264 stream copy, AAC-to-MP3 audio transcoding, and 3-second target segment duration.

The test ran for approximately 10 minutes of wall-clock time, including an observed Pluto advertising transition.

Results

Metric	With -copyts	Without -copyts
Output DTS errors	8,969	0
Segments produced	276	200
Segments with abnormal durations	64	1
Gaps in segment CSV timeline	1	0
Sum of segment durations	476.113 s	599.015 s
Final segment CSV timestamp	95,276.931 s	599.400 s

The most significant discontinuity occurred between segments 48 and 49:

• Segment 48 end: 147.113344

• Segment 49 start: 94950.064367

• Timestamp jump: +94,802.951 seconds

Following this jump, multiple output segments had reported durations of approximately 0.034 seconds.

The output with -copyts also contained thousands of messages similar to:

Non-monotonous DTS in output stream 0:1; previous: ..., current: ...; changing to ...

The equivalent test without -copyts did not report output DTS errors and generated a much more consistent timeline.

Both processes were stopped by the test's wall-clock timeout. Neither was terminated manually because of a playback error.

Additional playback test

Separately, I tested a temporary HLS output generated by FFmpeg 8.1.2 without -copyts, with a single FFmpeg process producing the playlist.

Emby successfully reproduced the channel across advertising transitions on both Windows and Android.

This is encouraging, but I recognize that the working HLS experiment also changed the upstream delivery format and FFmpeg version. Therefore, it does not independently prove that removing -copyts from Emby's production command will resolve all playback issues.

Questions for the developers

• Is there a supported setting to disable -copyts specifically for M3U Live TV inputs?

• Could Emby detect large MPEG-TS timestamp discontinuities and apply the appropriate correction while generating HLS segments?

• Is there a reason -copyts must always be used in this Live TV pipeline, even for sources with discontinuous timestamps?

My preference would be to resolve this inside Emby rather than maintain a separate FFmpeg normalization pipeline for each affected Live TV channel.

Thank you for taking a look. I hope these measurements help narrow down the issue.

[mwongjay 103]

IMO if you want the best outcome you will want to manage the streams separately from Emby. There are a large quantity of iptv providers and each can have their own quirks and quality issues that need to be handled. I've been using Dispatcharr to manage HDHR tuners and iptv playlists. It allows you to create stream profiles which contain the command parameters for ffmpeg, vlc, etc and assign them to specific groups or be the default for all streams. There you can handle normalization such as adding presentation timestamps in your example (+genpts) or handle 4k resolution differently from 1080/720 streams. I've also observed that Emby and Dispatcharr's native exception handling for streams don't handle network issues well, but ffmpeg has parameters that can greatly improve the quality if they're tuned well and you can do this with stream profiles.