FFmpeg CDN Integration: 4 Practical Live Streaming Workflows with CDNsun

FFmpeg has been around for a long time because it keeps solving real media delivery problems without much ceremony. It can ingest, transcode, repackage, inspect, and even play streams from the command line, which is exactly why it still shows up in modern live workflows. On many Linux systems, the package set also includes ffmpeg, ffplay, and ffprobe, giving you an encoder, a quick player, and a stream inspection tool in one practical toolkit.

For CDNsun CDN HTTP Live, the clean mental model is this: FFmpeg -> Publishing Point -> CDN HTTP Live service -> playback URL. The Publishing Point is the ingest side. The CDN HTTP Live service is the delivery side. Keeping those two roles separate makes the setup much easier to reason about, especially when you switch between RTMP-based and HLS-based workflows.

Set up the CDNsun side first

Before running any FFmpeg command, prepare the delivery path in CDNsun:

1. Create a Publishing Point and choose the input method that matches your workflow. For direct FFmpeg publishing, that is usually RTMP Push. For a local HLS workflow, use HLS Pull.
2. Create a CDN HTTP Live service and select that Publishing Point as the Origin Publishing Point.

From the generated service instructions, note these values:

• Server URL: the ingest address used for publishing, for example rtmp://push-1.cdnsun.com/p12345
• Service Domain: the playback domain used by viewers, for example your-service-domain
• Stream name: the stream identifier you append during publishing, for example mystream

That distinction matters. An ingest URL and a playback URL are not the same thing:

• Ingest URL: rtmp://push-1.cdnsun.com/p12345/mystream
• Playback URL: https://your-service-domain/mystream/playlist.m3u8

If you use RTMP Push or RTMP Pull, the stream must use H.264 video and AAC or MP3 audio, and the RTMP output is published in FLV format. If you use HLS Pull or HLS Push, the expected source is an HLS workflow with .m3u8 playlists and .ts segments.

1. RTMP Push from an MP4 file with -re

This is the quickest lab setup when you want to test end to end without introducing a live camera or a separate encoder. If your MP4 already contains H.264 video and AAC or MP3 audio, FFmpeg can publish it directly while -re makes the file run at real-time speed instead of flooding the ingest server.

ffmpeg -re -i ./demo.mp4 -acodec copy -vcodec copy -f flv "rtmp://push-1.cdnsun.com/p12345/mystream"

Here the ingest URL is rtmp://push-1.cdnsun.com/p12345/mystream. Your viewers do not use that address. They use the playback URL:

https://your-service-domain/mystream/playlist.m3u8

If the MP4 is not already compatible, re-encode it on the way in:

ffmpeg -re -i ./demo.mov -c:v libx264 -preset veryfast -pix_fmt yuv420p -c:a aac -b:a 128k -ar 44100 -f flv "rtmp://push-1.cdnsun.com/p12345/mystream"

This is also the RTMP-based workflow where CDNsun can transcode a single-bitrate RTMP origin stream into a multi-bitrate HLS CDN stream. That multi-bitrate note applies here, not to the HLS Pull examples below.

2. Local HLS generation with FFmpeg plus an HLS Pull Publishing Point

Sometimes you do not want FFmpeg to publish RTMP directly to CDNsun. You may prefer to generate HLS files locally or on your own origin server and let CDNsun pull them. In that case, the Publishing Point input method is HLS Pull, not RTMP Push.

FFmpeg can generate a simple rolling HLS output like this:

ffmpeg -re -i ./demo.mp4 -c:v libx264 -preset veryfast -pix_fmt yuv420p -c:a aac -b:a 128k -ar 44100 -f hls -hls_time 6 -hls_list_size 6 -hls_flags delete_segments /var/www/html/live/mystream.m3u8

In this workflow, the ingest source for CDNsun is the HLS playlist on your side, for example:

https://origin.example.com/live/mystream.m3u8

Your HLS Pull Publishing Point should reference that playlist, and the related .ts segments must also be reachable from the same origin path. The viewer still uses the CDNsun playback URL, not your origin URL:

https://your-service-domain/mystream/playlist.m3u8

This is a good fit when you already have an HLS-producing workflow and simply want CDNsun to distribute it through CDN HTTP Live.

3. Live event restreaming and normalization into RTMP Push

A very practical FFmpeg job is taking an incoming live source that is not in the shape you want and normalizing it before handing it to CDNsun. That can mean cleaning up codec choices, forcing a known output format, or converting a third-party live input into a stable RTMP contribution feed.

A simple example looks like this:

ffmpeg -i "https://origin.example.com/event/master.m3u8" -c:v libx264 -preset veryfast -pix_fmt yuv420p -c:a aac -b:a 128k -ar 44100 -f flv "rtmp://push-1.cdnsun.com/p12345/eventlive"

Again, keep the paths separate:

• Ingest URL: rtmp://push-1.cdnsun.com/p12345/eventlive
• Playback URL: https://your-service-domain/eventlive/playlist.m3u8

This workflow is useful when the upstream event source is not something you want to expose directly to viewers, or when you want FFmpeg to normalize the source into the H.264 plus AAC RTMP shape expected by RTMP Push. If you plan to use CDNsun multi-bitrate transcoding for a single-bitrate live origin, this RTMP Push path is the relevant one.

4. Simple internet TV or loop playout workflow

Not every live stream is a one-time event. Sometimes you just want a small always-on channel that loops a file or a prebuilt program block. FFmpeg can do that with a single command, which makes it surprisingly convenient for internet TV prototypes, promo loops, or a low-maintenance web channel.

ffmpeg -stream_loop -1 -re -i ./channel.mp4 -acodec copy -vcodec copy -f flv "rtmp://push-1.cdnsun.com/p12345/tvloop"

If the file is not already H.264 with AAC or MP3, use the re-encode pattern from the first workflow. The addressing remains the same:

• Ingest URL: rtmp://push-1.cdnsun.com/p12345/tvloop
• Playback URL: https://your-service-domain/tvloop/playlist.m3u8

One practical detail from the CDN HTTP Live side is that a single service can deliver multiple streams distinguished by different stream names. That makes small channel experiments easy to organize, because mystream, eventlive, and tvloop can each map to their own playback path under the same service domain.

Verify playback quickly

Once FFmpeg is publishing and the service is configured, the fastest confidence check is to test the HLS playback URL directly. For example:

ffplay https://your-service-domain/mystream/playlist.m3u8

If you are testing another stream name, replace mystream accordingly. This verifies the delivery side, not the ingest side, which is exactly what viewers will consume.

Final takeaway

FFmpeg works well with CDNsun because the responsibilities stay clear. Pick the right Publishing Point for ingest, attach it to a CDN HTTP Live service for delivery, publish with the correct Server URL, and always verify using the Service Domain playback URL. Once that model is clear, RTMP Push tests, HLS Pull workflows, event restreaming, and loop playout all become variations on the same reliable pattern.