How to Ingest SRT HEVC (H.265) and Transcode to RTMP

Treat SRT, MPEG-TS, HEVC, and RTMP as four separate contracts

SRT is a transport. The SRT project describes it as content agnostic: it can carry continuous media such as MPEG-TS, but it does not turn one codec into another. H.265, also called HEVC, is the video bitstream format standardized by ITU-T. MPEG-TS packages the video, audio, timing, and programme information for transport. RTMP is the next delivery interface in this particular workflow.

Keeping those layers separate prevents the most common false conclusion in this setup: “SRT connected, therefore the video is valid.” An SRT handshake proves that two transport endpoints agreed well enough to establish a session. It does not prove that the incoming programme contains HEVC, that the audio is present, that Callaba can decode the exact profile on the available host, or that the RTMP service will accept the output profile.

Collect the receiver contract before touching the transcoder

Start with the RTMP destination, not with a generic preset. Record its current accepted video codec, audio codec, resolution, frame rate, bitrate range, keyframe interval, rate-control expectations, URL format, stream key, and whether an event must be opened before the encoder connects. These values belong to the destination and can change; do not copy a profile from an unrelated platform.

Build and prove the workflow in Callaba

1. Create one controlled SRT ingest point

   Open SRT Servers, add a server with a clear operational name, and use an unused UDP listener port. Set latency and maximum-bandwidth headroom from the measured path rather than from a copied “low latency” number. Add a passphrase when encryption is required. Keep the firewall limited to the required source addresses when the network design allows it.

   Create explicit publisher access in Streams instead of opening the whole server to unknown clients. Choose SRT, select the server, assign the Publisher role, and set the intended Stream ID or allowed host. Start the server before the encoder begins calling. This gives the contribution feed its own identity and keeps receiver permission separate.

2. Make the encoder the SRT caller

   Configure the encoder to send MPEG-TS over SRT to the publisher connection details issued for this server. Match the UDP port, complementary caller/listener roles, passphrase, and Stream ID exactly. Coordinate latency settings and verify the effective negotiated latency. Enable HEVC/H.265 video and save the complete encoder profile in the event runbook.

   Start with one source and one programme. Do not add a backup, second destination, overlay, or resize while basic ingest is unknown. If the encoder offers several HEVC profiles or 8-bit/10-bit choices, select the one that has been tested with the next processing stage; the codec name alone is not a compatibility result.

3. Prove SRT health before creating an output

   In the SRT Server operator view, confirm that the expected publisher is connected and live bitrate is non-zero. Compare incoming bitrate with the encoder’s configured output. Watch Network RTT, packet-loss counters, connection duration, and current volatile connection events through a representative rehearsal period. Save timestamps and observations externally when the production needs durable evidence.

   If RTT or loss changes under load, fix the network or adjust the recovery budget from measurements. SRT can retransmit missing packets inside the configured latency window, but it cannot create bandwidth that the path does not have. A bitrate higher than the available upload will remain an encoder/network problem.

4. Identify the payload independently

   Create receiver access for the verified server when an external confidence receiver is part of the test. Open the generated receiver URL in a current SRT-capable probe or player. For a command-line acceptance check, an FFprobe build with SRT and the required decoder can report the streams without changing them:

   Install steps Copy

   ffprobe -v error \
     -show_entries stream=index,codec_type,codec_name,width,height,pix_fmt,r_frame_rate \
     -of json "PASTE_THE_CALLABA_RECEIVER_URL_HERE"

   The expected result is a video stream reported as HEVC plus the intended audio stream or streams. Also watch moving pictures and listen to programme audio in a compatible confidence receiver. FFprobe identifies the stream; it does not replace a visual and audible check for corruption, freeze, drift, or wrong track selection.

5. Create one SRT-to-RTMP Restream job

   Open Re-streaming and create a job named for both source and destination. Select the already verified SRT Server/Stream as the input, or use the reviewed SRT URL input when that is the chosen architecture. Select Other RTMP destination, then enter the destination URL and stream key supplied by the receiver.

   Enable video transcoding only because this destination contract requires a different output. Select a destination-approved H.264 profile in the product UI and set the destination-approved resolution, frame rate, bitrate, GOP, pixel format, and rate-control values. Configure the accepted audio codec, bitrate, sample rate, channels, and track. Leave overlays and unrelated modification disabled for the first acceptance test.

   The same workflow can be created through the Restreams API, but the API does not remove the need for the source and destination checks. It automates a known working contract; it should not be used to guess one.

6. Verify the output at both ends

   Start the Restream job and read its runtime statistics. Confirm non-zero output bitrate and the expected frame cadence. Then open the destination’s own preview or confidence return and check motion, audio, aspect ratio, colour, captions or ancillary requirements relevant to the programme.

   Compare the input and output as two distinct signals. The SRT Server should continue to show the original contribution health while the Restream job reports the processed output. This separation lets an operator see whether a failure belongs to the source, the decoder/transcoder, credentials, or the RTMP receiver.

7. Rehearse one failure at a time

   Stop the encoder, confirm that the live Callaba operator view reflects the disconnect, and verify that the Restream output reflects source loss. Save the timestamp and recovery observation externally, then reconnect with the same authorized identity. In a separate test, use a deliberately invalid RTMP key and confirm that the source stays healthy while the destination fails. Restore the correct key, then run the planned profile under realistic motion long enough to expose thermal or capacity problems.

Read health signals as evidence, not decoration

Troubleshoot the first boundary that fails

Questions operators usually ask

Technical references

• Haivision SRT project: protocol purpose, content-agnostic payload, recovery, and encryption
• Haivision SRT live-transmit guide: caller/listener modes, MPEG-TS testing, RTT, latency, and firewall considerations
• Haivision SRT socket options: negotiated receiver latency and peer latency
• ITU-T Recommendation H.222.0: MPEG transport-stream systems
• ITU-T Recommendation H.265: High efficiency video coding
• FFprobe documentation: inspect container and media-stream information
• FFmpeg protocol documentation: SRT URL syntax and socket options
• Callaba user guide: SRT Servers, Streams and connection access, and Re-streaming and transcoding