A practical guide to converting a MasterPlay RTMP stream into ASI for Charter headend ingest using Thor Broadcast workflow.
This educational Thor-style case study explains a practical RTMP to ASI workflow for a cable TV deployment. It shows why a direct RTMP to ASI converter is usually not the best answer in a professional DVB environment, and why a broadcast IP decoder plus HDMI encoder modulator can be the most reliable path to Charter headend ingest.
Table of Contents
MasterPlay outputs an RTMP IP stream, while the destination expects a stable ASI feed for cable headend ingest.
RTMP is not commonly used as a direct professional DVB ingest format, so direct RTMP-to-ASI hardware options are limited.
Decode the IP stream with a Thor Broadcast IP set-top box, then encode the HDMI output into ASI using the H-1HDMI-QAM-IPLL family.
In this case, the customer needed to deliver a live video channel from MasterPlay TV Station in a Box software to a Charter cable TV location where the signal would be handed off as DVB-ASI.
The conversation revealed an important integration issue: one side wanted an IP stream directly from the software, while the cable and broadcast side required a format that would be compatible with professional ASI ingest equipment.
That is where system design matters. Many modern video workflows start in IP, but the final delivery stage for cable TV, headend distribution, and professional modulation can still depend on ASI, MPEG transport stream workflows, and broadcast-grade handoff methods.
For a real-world MasterPlay to Charter headend workflow, the most dependable approach is often:
RTMP output → IP decoder STB → HDMI → Thor HDMI encoder/modulator → ASI output → Charter ingest
This keeps HDMI local to the Charter-side equipment chain. HDMI is not being used as a long-haul delivery format; it is simply the practical handoff between a decoder and the encoder that creates the required ASI output.
The diagram below illustrates the recommended IP to HDMI to ASI workflow. This is the educational reference version for SEO, sales, and technical review.
The workflow begins at the content origin. MasterPlay produces the live channel as an RTMP stream or another software-based IP output. This is common in streaming and software playout environments.
At the Charter-side location, a Thor Broadcast compact IP decoder set-top box receives the incoming stream and converts the IP video into a local HDMI output. This is the bridge between a software-driven IP workflow and a broadcast hardware workflow.
The HDMI feed is connected to a Thor Broadcast H-1HDMI-QAM-IPLL family encoder/modulator. In this workflow, the critical benefit is the unit’s ability to produce an ASI output suitable for cable TV, digital video distribution, or professional ingest workflows.
Once encoded, the ASI signal can be handed to the receiving equipment for Charter headend ingest. This final stage is aligned with the expectations of many professional broadcast and cable distribution systems.
These official Thor Broadcast product pages are relevant to the RTMP-to-ASI application example below.
Best fit for the decode stage. This IP set-top box is designed to receive supported IP network streams and decode them to HDMI, making it a natural solution for IPTV decoding, local display feeds, and bridge workflows between software playout and professional video hardware.
View the Compact IP Decoder Set Top BoxBest fit for the HDMI to professional output stage. This product family covers the H-1HDMI-QAM-IPLL and related models used in HDMI encoding, QAM modulation, IPTV streaming, and ASI-output workflows. It is the core family for turning a local HDMI source into a cable-ready or distribution-ready feed.
View the H-1HDMI-QAM-IPLL FamilyBest fit as an alternative path when the source can provide a more broadcast-native IP transport stream. This gateway is useful for ASI to IP and IP to ASI conversion, but it is not the preferred answer for raw RTMP in this case.
View the H-IP-ASI-B-V3 GatewayRTMP is popular in streaming, social video, cloud workflows, and software encoders, but it is not the dominant handoff format for professional DVB-ASI systems. Broadcast and cable infrastructure more commonly expects MPEG transport streams, UDP/RTP-based IP delivery, or direct ASI.
That is why many successful deployments use a two-stage process: first decode the stream into a local video signal, then re-encode or gateway it into the format expected by the downstream headend equipment.
Saying “HDMI will not work” can be misleading unless the location and role of HDMI are clearly defined. In this design, HDMI is not the remote transport between sites. It is an internal local connection at the Charter-side location, after the IP stream has already arrived and been decoded.
| Option | Workflow | Best use case | Pros | Considerations |
|---|---|---|---|---|
| Recommended | RTMP → IP decoder STB → HDMI → H-1HDMI-QAM-IPLL → ASI | When the source is RTMP and the destination requires ASI | Proven hardware path Works with existing broadcast gear Clear local handoff to Charter |
Requires decode and re-encode Adds one more device to the chain |
| Alternative | Broadcast-native IP stream (UDP/RTP or MPEG-TS) → H-IP-ASI-B-V3 → ASI | When the software can output a format better suited for professional ASI/IP gateways | No HDMI step More native broadcast transport path Cleaner gateway-style workflow |
Depends on MasterPlay output options Not every software license or profile supports this |
| Not preferred | RTMP → direct RTMP-to-ASI conversion | Only when a very specific custom workflow is available | Fewer devices on paper | Harder to source in pro-DVB workflows Lower interoperability with standard cable and headend equipment |
When planning an IP video to cable TV workflow, the most important question is not simply “What does the source output?” It is also “What does the destination reliably accept?”
In practice, the destination often determines the workflow. If the handoff point is an ASI ingest port, then the safest path is the one that delivers a stable, standards-friendly ASI signal with predictable behavior.
This is why broadcast integration often uses bridges between streaming formats, local baseband-style video outputs, and professional transport layers. A well-designed system does not force every device to speak the same language; it uses the right conversion at the right stage of the chain.
It can be the right product when the IP input is a broadcast-friendly transport stream. For a raw RTMP workflow, the safer recommendation is usually to decode the stream first with an IP decoder set-top box and then feed the resulting HDMI into the encoder workflow.
Why not avoid HDMI completely?If MasterPlay can provide a supported broadcast-native IP output such as UDP, RTP, or MPEG-TS, then HDMI may be avoidable. If the practical source output is RTMP, HDMI can still be an effective local bridge after decoding.
Does this workflow support educational, local channel, and cable TV distribution projects?Yes. The same design logic is useful for educational channels, community media, private cable systems, hospitality TV, enterprise video distribution, and many other professional AV-over-IP to cable headend workflows.
For this MasterPlay to Charter application example, the most practical and educational answer is not a simplistic “yes or no” on HDMI. The correct answer depends on where HDMI is used in the chain.
In this workflow, a Thor Broadcast Compact IP Decoder Set Top Box receives the source stream, the H-1HDMI-QAM-IPLL family converts that decoded HDMI into an ASI-ready professional output, and the resulting ASI feed is handed to the cable ingest point.
That makes this design a strong fit for customers searching for RTMP to ASI conversion, IP to ASI for cable TV, Charter headend ingest solutions, broadcast video transport over IP, and Thor Broadcast decoder and encoder workflows.
EN
