RTMP-to-HLS conversion takes a live RTMP feed and delivers it as an HLS playlist with media segments that a compatible player can request over HTTP or HTTPS. It does not automatically require re-encoding: if the input codecs and stream characteristics suit the target player and HLS packaging, you may be able to remux the stream instead.
The practical choice is between a self-hosted converter such as FFmpeg, an RTMP server with HLS support, and a managed cloud workflow. The right route depends on the feed, the viewers’ playback requirements, your latency tolerance, and how much monitoring and recovery you are prepared to operate.
What changes when RTMP becomes HLS
RTMP and HLS describe different ways to deliver media. An RTMP publisher sends a continuous stream to an ingest endpoint. With HLS, the output is a playlist file that refers to media segments; the player repeatedly reads the playlist and fetches the segments it needs over HTTP(S). The FFmpeg HLS muxer documentation describes options for producing this playlist-and-segment output.
That packaging change is often called transmuxing or remuxing when the audio and video are copied into the new delivery format without changing their encoded content. Transcoding is different: a video or audio encoder decodes and re-encodes the stream, which can change codec, resolution, bitrate, or other characteristics. A conversion pipeline may remux, transcode, or do both for different streams.
HLS can make HTTP-based distribution and CDN delivery practical, but it does not make every player compatible with every source. A player must support the codecs, profiles, audio formats, and playlist form you produce. Nor does HLS guarantee a particular delay: segment duration, playlist window, buffering, network conditions, and player behaviour all contribute to what viewers experience.
For a 24/7 YouTube channel, first check whether RTMP-to-HLS is actually part of the distribution requirement. YouTube’s live ingest uses a contribution stream, and an HLS output created for another player is not automatically a replacement for the RTMP feed sent to YouTube. If your aim is simply to keep a pre-recorded programme running on YouTube, the guide to moving an always-on stream from a home PC to the cloud covers a different operational problem. Convert only when a receiving platform, website, or player needs the HLS output.
Check the input and the playback requirements
Before selecting options, identify the RTMP source and the destination. Record where the feed comes from, whether it is reachable from the conversion host, and which video and audio streams it contains. Then confirm what the destination player accepts, whether it expects a live playlist URL, and how viewers will reach the playlist and segments.
Do not infer codec compatibility just from the fact that the source plays in one application. Inspect the input with a media probe or the converter’s logs, and note the codecs, dimensions, frame rate, audio tracks, and any stream changes. A feed may contain H.264 video and AAC audio, but that does not establish that every target player will accept its exact profile, parameters, or packaging. Use the player or platform’s current documentation as the specification.
Also decide whether viewers need one rendition or several. A single HLS rendition may be enough for a controlled player and network. If you need adaptive bitrate playback across different connections or screen sizes, the pipeline must create multiple appropriately encoded renditions and a master playlist. Merely copying one source into HLS does not create adaptive bitrate output.
Think through delivery as well as encoding. The output directory must be writable by the process creating the files, and a web server or other delivery path must make the playlist and its referenced segments available to the intended viewers. Configure suitable MIME types, access controls, and HTTPS where appropriate. If the stream should be private or restricted, check that the protection method works for both the playlist and every segment request.
If your end goal is YouTube, keep the ingest settings and HLS delivery requirements distinct. For a YouTube contribution stream, the RTMP bitrate settings guide for a 24/7 stream in India helps you reason about the feed sent to YouTube; it does not determine what a separate HLS player can decode. Test each destination on its own terms.
Choose remuxing or transcoding
Choose remuxing when the incoming encoded streams are suitable for the target HLS packaging and player, and you do not need to alter resolution, bitrate, or codec. In FFmpeg, -c:v copy -c:a copy requests stream copy for video and audio. It avoids the compute and quality trade-offs of re-encoding, but it cannot fix incompatible codecs, repair a poor source, or create lower-bitrate renditions.
Choose transcoding when the target requires different codecs or stream parameters, when you need resized or bitrate-adjusted versions, or when the source is otherwise unsuitable for the required output. Encoding consumes processing capacity and introduces another quality decision: lower bitrates may reduce bandwidth use but can reduce detail, while higher bitrates need more network capacity. Select codecs, encoder settings, and stream maps explicitly according to the source and the receiving player. Do not copy a command from another source and assume its codec choices will suit yours.
A mixed approach is also possible. For example, you might copy compatible audio while encoding video into a required format, or encode one source into several output renditions. The key is to make a deliberate decision for each stream rather than treating “convert to HLS” as shorthand for “re-encode everything”.
| Route | What it changes | Useful when | Main trade-off |
|---|---|---|---|
| Remux / stream copy | Packages existing encoded streams into HLS without re-encoding | Source streams already meet the target requirements | Cannot change codecs, resolution, or bitrate to solve compatibility or rendition needs |
| Transcode | Decodes and re-encodes selected streams before HLS packaging | A player needs different encoding, or you need resized or multiple renditions | Uses processing capacity and requires quality, bitrate, and encoder choices |
| Managed pipeline | Combines ingest, encoding, packaging, and delivery services | You need managed operations or a larger distribution workflow | More service configuration, cost planning, and architecture decisions |
A useful operational comparison is not simply “free software versus paid service”. Compare who watches the process, how you discover a stale playlist, what happens when the input disappears, whether the setup supports your redundancy needs, and how viewers receive the segments. If you are still weighing a PC against hosted operation, the hosted streaming service guide explains the broader always-on trade-off without assuming that every channel needs a conversion pipeline.
Prepare FFmpeg for a live RTMP input
FFmpeg is one self-hosted route. Its HLS muxer can take a live RTMP input and write an HLS playlist plus segment files. Before running it, install a build that includes the needed input and HLS support, confirm that the host can reach the RTMP URL, and create an output directory with permissions for both writing and HTTP delivery. Check the documentation for the version you have installed because available options can differ by build.
The following is an illustrative starting pattern, not a tested universal preset. Replace the host, application, stream name, and output paths with values for your setup, and verify the options against your installed FFmpeg documentation:
ffmpeg -i "rtmp://HOST/APP/STREAM" \\
-c:v copy -c:a copy \\
-f hls \\
-hls_time 4 \\
-hls_list_size 6 \\
-hls_flags delete_segments+temp_file \\
-hls_segment_filename "/var/www/hls/stream_%06d.ts" \\
"/var/www/hls/stream.m3u8"
The values shown for -hls_time and -hls_list_size are examples to make the pattern concrete, not recommended settings for every feed. The first sets a target segment duration and the second bounds the number of entries in the live playlist. The output segment name and playlist path must agree with the directory you expose over HTTP(S); a generated playlist that points at missing or unreachable files is not a working stream.
This example uses stream copy, so it is only appropriate when the actual input streams are accepted by the HLS muxer and target players. If you need transcoding, select encoders and maps explicitly and test the resulting output. If you need multiple renditions, configure separate encodes and a master playlist; a single output from the example is not adaptive bitrate streaming.
The delete_segments flag illustrates that a live output needs a retention policy as well as a playlist size. Removing old segments saves disk space, but a viewer may still be requesting a segment that has just fallen out of the playlist. Choose playlist length and deletion behaviour together, allowing clients enough time to fetch the files they were offered. Review FFmpeg’s documented deletion threshold and other HLS options before using this in production.
FFmpeg is not the only self-hosted pattern. SRS documents built-in HLS output from an RTMP publication, so the RTMP server can handle ingest and HLS generation in one configured service. Its HLS documentation describes the route and shows that playback may fail if requested before the first segment exists. Check the version and configuration you intend to run; the cited documentation identifies version 7.0 as unstable and shows HLS disabled by default in its example configuration.
Managed services are another route when you want cloud encoding and packaging rather than operating the conversion process yourself. AWS documents RTMP push and pull inputs for MediaLive and an architecture that sends HLS output through MediaPackage; check the current MediaLive input documentation and the MediaLive-to-MediaPackage workflow before building around it. AWS’s published workflow example has a contribution-input redundancy limitation, so review the current architecture and recovery requirements rather than assuming a managed pipeline removes all failure modes.
Create a playlist and segments
A working HLS output is a set of related files, not just a .m3u8 URL. The playlist lists media segments, and the player uses that list to request the files. For a live stream, the playlist is updated as new segments are made. The path in the playlist must resolve from the viewer’s point of access, not merely from the converter’s local filesystem.
Segment timing is controlled partly by keyframes. FFmpeg documents hls_time as a target: the muxer cuts at a keyframe after the target has passed. If keyframes are spaced farther apart than your target, segments can be longer than the nominal value. The HLS options in FFmpeg’s formats documentation also discuss GOP considerations. For transcoded output, choose a keyframe cadence that works with the segment plan; for copied video, the source’s keyframe pattern constrains where cuts can occur.
This is why a four-second target in an example is not a promise that every segment lasts exactly four seconds. Inspect the actual files and playlist after the stream starts. If the output is intended for low-delay viewing, test end-to-end delay with the exact player and configuration, and compare that result with the channel’s needs. HLS may be a good fit for broad HTTP delivery while being a poor fit when a very short delay is essential.
For a live window, a bounded playlist avoids retaining every segment reference indefinitely, while segment cleanup controls disk use. Those are related but separate decisions. Keep old files long enough for viewers already downloading them, and decide how to clean up files after a process stops. For long-running channels, monitor available storage and ensure temporary or orphaned files do not accumulate.
Validate playback and playlist updates
Test from outside the converter host. First check that the RTMP input connects and that logs show the expected video and audio streams. Then confirm that the .m3u8 file appears and changes as new segments arrive. Open the playlist over the same HTTP(S) route viewers will use, and check that every referenced segment returns successfully.
Try the output in the actual target player, not only in a local preview tool. Check video, sound, aspect ratio, playback start, and whether the player continues to follow playlist updates. Repeat on the intended device types and network conditions. This validates a particular source, configuration, and player combination; it is not a guarantee of compatibility for other devices.
For a YouTube channel with an independent HLS destination, monitor both paths separately. A healthy YouTube broadcast does not prove the HLS playlist is updating, and a working HLS player does not prove the YouTube ingest is healthy. The guide to checking whether a devotional YouTube stream is actually running 24/7 offers a useful way to think about checking the destination rather than trusting that a process is merely running.
For production, decide who receives an alert if the RTMP source drops, if the playlist stops changing, or if segment requests begin failing. Keep logs long enough to diagnose an overnight interruption, secure access to the ingest and output, and test restart and cleanup procedures. If a CDN is involved, verify that its caching behaviour does not leave viewers with an out-of-date playlist while still allowing segment delivery. A process that starts successfully is only the beginning of a reliable operational check.
Common live conversion problems
The playlist exists, but playback fails. Check whether its segment paths are correct, whether the web server can read the files, and whether the requests return successfully from the viewer’s network. Then review codec and audio compatibility for the player. A playlist file by itself does not establish that its referenced media is reachable or decodable.
Segments are longer than expected. Inspect the source keyframe cadence and the FFmpeg logs. The target duration does not force a cut in the middle of a GOP; a cut waits for a suitable keyframe after the target. If you control the encoder, align GOP settings with the intended segmentation, then test the actual output rather than relying on the command line alone.
Playback starts late. The converter must produce initial media before a player has something to request, and the player may buffer before playback. SRS specifically notes that its HLS playback can fail if started before the first segment is generated. Test start behaviour with the intended player and do not promise viewers a latency based only on a segment setting.
The stream works locally but not remotely. Check firewall and routing rules, HTTP(S) access, permissions, TLS, and any access-control policy. Confirm that the playlist and segments are served consistently, including through the CDN if one sits in front. A local file path is not a public playback URL.
The copied stream will not play. Recheck the source’s codecs and stream characteristics against the target player’s current requirements. If they do not fit, stream copy cannot make them fit; choose a deliberate transcode or a different target. Keep the audio and video decisions separate if only one of them needs conversion.
A managed input does not connect. Verify the protocol the service accepts and the actual address and credentials. AWS’s current MediaLive input documentation should be checked for RTMP versus RTMPS support before you configure a sender. In any managed workflow, follow the documented service start sequence and verify current console behaviour, since service settings can change.
Choose an operating model that fits the channel
A self-hosted FFmpeg process gives you control over the exact pipeline, but you own process supervision, disk cleanup, output serving, monitoring, and recovery. An RTMP server with built-in HLS can reduce the number of separate processes to join, but you still own its configuration and operational checks. A managed cloud workflow can shift some packaging and scaling work to a provider, while adding service configuration, cost management, and architecture decisions.
| Operating route | You take responsibility for | Consider it when |
|---|---|---|
| FFmpeg on a host you manage | Input access, process supervision, file permissions, HTTP delivery, monitoring, and cleanup | You need a straightforward, controlled pipeline and can maintain the host |
| RTMP server with HLS support | Server configuration, version checks, ingest, HLS output, delivery, and monitoring | You prefer a server that combines RTMP ingest and HLS generation |
| Managed cloud services | Service setup, stream design, access, monitoring, resilience, and cost review | You need managed encoding or distribution capabilities and can support a cloud workflow |
No route is automatically the safest or simplest for every channel. Consider the value of adaptive renditions, the likely audience geography, CDN integration, latency, redundancy, and the time available to investigate a failure. For a small devotional station with one known player, a single remuxed rendition might be enough; for a public player with varied devices and networks, you may need transcoding and more thorough compatibility testing.
If your underlying concern is keeping a YouTube loop online while your own computer is off, conversion itself is not the answer to that problem. StreamNeo turns an uploaded video into a YouTube live stream, so it removes the need to keep a local playback computer running for that use case; it is YouTube-only and does not create an HLS output. Keep that distinction clear when choosing tools for separate destinations.
When the requirements are written down, make a small test stream before committing to a long-running setup. Confirm the source, output paths, target player, and recovery steps in that test. The guide to restarting a YouTube live stream automatically after a disconnect is relevant to recovery thinking, though an HLS converter needs its own monitoring and restart plan.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does converting RTMP to HLS always require re-encoding?
No. If the incoming audio and video are compatible with the HLS packaging and target player, you can often remux or copy the encoded streams. Transcode when the target needs different codecs or stream characteristics, or when you need resized or multiple renditions.
Can FFmpeg turn one RTMP feed into adaptive bitrate HLS?
Not through the single copied output shown in this guide. Adaptive bitrate delivery requires you to produce multiple renditions and a master playlist, usually with explicit stream maps and encoding settings. Choose those settings based on the source and player requirements, then test the result.
Why does an HLS segment not match the configured target duration?
The target is not an exact timer. FFmpeg cuts at an available keyframe after the target has passed, so the source’s keyframe cadence or your encoder’s GOP settings affect actual segment duration. Inspect the generated segments and adjust the pipeline if necessary.
Will HLS work on every phone, browser, or smart TV?
No conversion method can guarantee compatibility across every device and player. Check the target player’s current requirements, test the actual output on devices your viewers use, and adjust codecs or renditions when testing shows they are needed.