A new approach to making IPTV behave more like traditional tuners

[EODCrafter 181]

21 minutes ago, thejacer87 said:

@PowerCCwhere can I find the install instructions? I couldn't find anything in google or github.

Kernel — Your Media, Your Way https://share.google/mJyjayR4H3qqgYaNk

[thejacer87 9]

45 minutes ago, EODCrafter said:

Kernel — Your Media, Your Way https://share.google/mJyjayR4H3qqgYaNk

Sorry, I clearly don't fully understand everything here. But I need to install KMS and XCStream?...

PowerCC said: "Another media server can integrate with XCstream directly and use it as the continuity engine."

So how do I get this setup with my Emby? KMS downloads have no readme, and despite the site mentioning docker installation, I don't see any docker instructions.

Thanks

[ExploitPanda 1]

I am also curious to test this project out with Emby

[PowerCC 33]

A little more news, because I know several of you have been following this from the beginning.

XCstream has reached the point where I’m comfortable saying that there will be a standalone public beta.

What started as an Emby-focused watchdog has evolved into something much narrower and, I think, much more useful: a dedicated MPEG-TS live-stream continuity engine.

The biggest change along the way has been pass-through. Earlier in development I expected hardware transcoding to be the safest default. Real-world testing changed my mind. XCstream can now remux, buffer, validate, monitor and recover a live stream while preserving the original video and audio whenever possible. A dedicated GPU is no longer required for normal operation. That is a pretty significant shift from where this project started.

I also want to give a big thank-you to Nick (Fyb3roptik) and the Kernel Media Server project. Nick has been incredibly open to testing XCstream, challenging the integration, and helping turn the direct handoff model from an idea into something running against a real media server. He’s also been very supportive of XCstream continuing as an independent project, which I genuinely appreciate.

That work helped prove something important: XCstream does not need to own the media server.

A media server can simply select the source and hand it to XCstream at tune time. From there, the responsibilities become very clean:

Media server: users, lineup, EPG, scheduling, DVR and playback
XCstream: source connection, buffering, validation, outage containment, recovery and MPEG-TS continuity

That model is now working, and I think it creates a very interesting opportunity for Emby as well.

Rather than requiring an Emby-specific plugin or asking Emby to take responsibility for unreliable upstream IPTV behavior, Emby could choose the source at tune time and hand it directly to XCstream. XCstream would return one stable MPEG-TS session while Emby continues doing what it already does best.

So I’d like to extend an open invitation to @Luke, @ebrand the Emby team: if that architecture is interesting to you, I’d genuinely like to work together on a native direct integration.

To be clear, XCstream will also remain usable independently. Nobody will need to wait for a media-server integration in order to use it.

The original goal of this thread hasn’t changed:

A bad IPTV source should not automatically mean a failed playback session or a ruined recording.

What has changed is how much simpler the answer has become.

Keep the original media when it’s good.
Intervene only when it isn’t.
Keep the session alive.
Let the media server be the media server.

That’s where XCstream is heading.

And yes—I’m looking forward to finally getting this into some of your hands.

[ExploitPanda 1]

Excited to test out the first version of XCstream

[PowerCC 33]

A lot has happened with XCstream since my last update.

0.9.9-beta is still in development and qualification, so there isn’t a public download for this build yet.

Before I get into the changes, I should probably explain one of XCstream’s core concepts because I use the word Slate a lot.

What is Slate?

When an IPTV provider completely stops delivering usable media, XCstream eventually reaches a point where there is nothing left to preserve.

Instead of simply allowing the downstream stream to die, XCstream can temporarily replace the failed upstream media with a synthetic MPEG-TS stream that I call Slate.

Think of it as a controlled outage bridge.

The provider may be dead behind XCstream, but the media server downstream can continue receiving valid MPEG-TS while XCstream works on getting the real source back.

Conceptually:

Healthy Provider
↓
Provider fails
↓
XCstream can no longer safely preserve the source
↓
Slate keeps protected MPEG-TS flowing downstream
↓
XCstream works on recovering the real provider

Provider video itself is still pass-through. XCstream does not transcode the provider feed. Only the synthetic Slate is encoded.

That distinction becomes pretty important in 0.9.9.

One thing I’ve learned pretty clearly over the last few days is that the behavior I originally built for recording is not always the behavior you want when somebody is just sitting there watching Live TV.

XCstream was built from day one around one basic idea:

Protect the upstream source and salvage as much usable video as possible.

That works really well for DVR.

If a provider stops sending usable video for 10 or 15 seconds but there’s a decent chance it will recover, I would rather XCstream wait and save that material than instantly give up and throw Slate into the recording.

That was always the priority.

But for Live TV?

Nobody wants to stare at a frozen football game for 15 seconds while XCstream patiently waits to see if the provider is going to wake back up.

So v0.9.9-beta is getting a new Streaming Priority setting.

Current XCstream Setup UI on macOS ARM64 (v0.9.8-beta). 0.9.9-beta expands this with Streaming Priority and additional recovery controls.

DVR Priority — Default

This keeps the current XCstream behavior.

It is intentionally more patient with bad providers.

XCstream gives the source more opportunity to recover naturally before deciding the stream is really gone and moving into recovery/Slate.

The goal is simple:

Save as much of the original program as possible.

Live TV Priority

Same exact recovery engine.

No second Live TV engine.

It just changes how aggressive XCstream is.

It checks stream progression more frequently, declares a real stall much sooner, waits less for spontaneous recovery, retries the provider sooner, and uses a smaller initial buffer so playback can get moving faster.

A quick hiccup can still recover naturally.

A genuinely dead source should move toward recovery/Slate much faster instead of sitting there frozen forever.

That gives me both behaviors without ruining the recording-first logic XCstream was originally built around.

The other big thing coming in 0.9.9 is Session-Matched Slate.

Right now XCstream has validated generic H.264 and HEVC Slate available when the real source is gone.

That works, but it is still a different media stream.

With 0.9.9, once XCstream has identified the source profile, it can prepare Slate that matches the stream much more closely:

• video codec
• resolution
• frame rate
• pixel format / bit depth
• audio codec
• sample rate
• channel layout

So if I’m watching a 1080p H.264 / AC3 channel and the provider dies, XCstream can use Slate that is much closer to what the decoder was already seeing.

The idea is to avoid unnecessary codec changes, resolution changes, audio changes, decoder resets, etc. just because the provider fell over.

The Slate is generated in the background while the source is healthy.

And I’m not generating one for every channel.

If several channels use the same effective media profile, XCstream generates it once, validates it, caches it for the life of the running process and reuses it.

Different channel. Different provider. Different tuner.

Doesn’t matter.

If the media contract matches, reuse it.

And just to be clear:

Provider video is still NOT being transcoded.

Provider video stays pass-through MPEG-TS.

Only the synthetic Slate gets encoded.

I’m also adding an experimental option called Protected Slate Handoff.

Getting into Slate cleanly is one problem.

Getting back out of Slate cleanly is another.

A provider can start sending again, look good for two seconds, and immediately die again.

I don’t want this:

Slate → Live → dead → Slate → Live → dead

That’s ugly.

So with Protected Handoff enabled, XCstream can keep Slate publicly playing while the real provider recovers privately in the background.

The recovered source has to prove that it is actually healthy before XCstream puts it back on the public stream.

Basically:

Healthy Live
↓
Provider dies
↓
Matched Slate
↓
Provider recovers privately
↓
XCstream proves MPEG-TS delivery and the media clock are healthy
↓
Controlled return to Live

If the recovered source still looks questionable, XCstream leaves Slate up and keeps working on the real source behind it.

That feature is going to stay Disabled by default initially.

The return-to-live path is one of the touchiest parts of the engine and I want to beat the hell out of it before I make it normal behavior.

One thing I also want to make really clear because XCstream has changed quite a bit since I started this thread:

XCstream is not an HLS/DASH segmenter.

It does not create the HLS segments your media server uses.

That belongs downstream.

XCstream’s job is:

Provider
↓
XCstream protects / buffers / validates / recovers
↓
continuous protected MPEG-TS
↓
Kernel Media Server / Emby / Jellyfin / Channels DVR Server / Plex whatever consumes it

The media server still owns playback, HLS/DASH packaging, DVR scheduling, users, libraries, clients, etc.

XCstream owns the ugly part upstream.

If the provider freezes, starves, stops advancing video while the connection still looks alive, wakes back up, dies again, or needs the producer completely restarted, XCstream is supposed to fight through that before the media server ever has to care.

That is still the whole point of the project.

0.9.9 just makes XCstream smarter about the fact that:

protecting a recording and protecting somebody watching Live TV sometimes need different timing.

Still testing.

Still breaking things.

Still abusing some absolutely horrific IPTV streams because they make great test subjects. 

[EODCrafter 181]

I think people just want to know where they can get a copy of the binary.....