Skip to content

RTMP Protocol

RTMP (Real Time Messaging Protocol) is a proprietary and closed protocol for transmitting video over TCP. Its main advantage was its implementation in Adobe Flash Player, which for a brief period became the primary way to stream video in browsers and on mobile phones.

Its widespread adoption in a short amount of time was a precondition for the protocol not to disappear but to remain in use today as a means of contribution. Nowadays, no one watches videos via RTMP, but it is used to publish videos to social networks.

Applicability and Limitations

RTMP copes moderately well with sending a single video track of average quality and a single audio track of average quality over a good, preferably wired, internet connection. Today, this protocol can be found, for example, in OBS - a free software for broadcasting from a laptop to social networks.

When is RTMP not suitable?

  • Sending multiple languages through this protocol cannot be done with standard methods. Special modifications to the client and server are required.
  • Multibitrate streaming is practically impossible with it, this is the prerogative of HLS.
  • A poor connection becomes an insurmountable obstacle due to the head-of-line blocking issue, i.e., a single lost packet can render the connection unusable, leading to the loss of many seconds of video.
  • High-quality modern codecs (AV1, Opus) are only available through extensions that have not yet become widely adopted.
  • There is no standard way to transmit subtitles, as well as other metadata.

RTMP Technical Details

RTMP incorporates numerous ideas for RPC (remote procedure call). Its creators intended to create something akin to Corba (but without schemas, i.e., with the corresponding prospect of support): method calls, object references, separate channels for object method calls.

Designed but not widely adopted were Shared Objects - a method for synchronizing data between connected clients. RTMP evolved from an application server that was supposed to provide server logic for connected Flash clients. Video and audio were not the primary focus.

This is evident from the list of limitations:

  • No more than one video track
  • No more than one audio track
  • A fixed selection of codecs, out of which only three remain relevant today (H.264, AAC, PCMA)

The iterative design of RTMP has led to a situation where there are many ways to do the same thing and even more situational undocumented solutions that work in a specific client-server setup. In addition, it incorporates hidden mechanisms for competitive struggle.

Adobe Lawsuits

In 2012, Adobe published the RTMP specification, which started with the words "the reader of this specification is obliged to follow it byte by byte and not to invent anything on their own," after which they immediately started to litigate against alternative implementations on the basis that they violated this specification.

It's not surprising, because if a flash player connected to a server written according to this specification, it could not play H264 (by cunningly checking the garbage part of the first packet). They rushed it to the extent that nothing could be done according to this specification, but lawsuits ensued.

A similar fate befell the tool rtmpdump, whose authors reverse-engineered the RTMPE protocol, which was claimed as advanced protection against data copying (instead of DRM). Significant marketing budgets were allocated for RTMPE, and it turned out that all the security was based on an obfuscated key, which was plainly visible in the text in every copy of the flash player. That is, basic TLS (and RTMPS working over it) is incomparably more secure against copying because RTMPE does not just fail to protect against copying by the client, it also does not protect against traffic eavesdropping.

RTMP Delayed Handshake

At the start of the protocol, it's necessary to exchange packets twice, which contain no data, only "garbage" that is specially interpreted in different clients and servers. This adds a minimum of 2 unnecessary RTTs (Round-Trip Times) at the start, which could be avoided.

Video Chunking

One of the artifacts of the idea about an application server with a protocol for RPC is the chunking of video. This was planned so that a call to a method could be inserted in the middle of a long keyframe, but in practice, this is unnecessary today since no one except the connected flash player requires this.

Especially fortunate in design was the decision to make the default chunk size slightly larger than the MTU, ensuring packet fragmentation and increasing the packet rate for video transmission.

FLV at the Core

At the core of RTMP lies the FLV format, which is comparably fortunate in its design. This means a fixed set of supported codecs, millisecond accuracy of timestamps, and the inability to specify more than one video and audio track.

The millisecond accuracy of timestamp specification is insufficient for repackaging into mpegts or fmp4. For example, to remove stuttering on iPhones, it was necessary to recalculate the DTS of audio frames based on their actual duration.

More details on combating codec limitations below.

Ambiguity with URLs in RTMP

When designing this protocol, it turned out that it lacks classic URLs.

The issue is that when a URL like rtmp://server/live/tvchannels/cnn is specified, it will be split into several parts in the player:

  • the server name server
  • the application name, for example, live
  • the stream name tvchannels/cnn

This introduces ambiguity, as could the correct division be live/tvchannels and cnn?

The client can't guess, as different CDNs have developed different defaults. There are several solutions:

  • Reduce the number of segments to 2, then it's possible to guess where each part goes.
  • Specify a delimiter in the path: for example, a triple slash rtmp://server/live/tvchannels///cnn.

This technical solution has its reasons, as RTMP was made for an application server, and that's how these applications were named.

Today, such a solution has no practical sense but continues to introduce confusion.

Added to this is the fact that sometimes you can encounter application names like live?key1=value1. If the stream name also includes a query string, it's unclear how to assemble them into a URL, resulting in such monstrosities: rtmp://server/live?key1=value1///cnn?key2=value2

RTMFP, RTMPT

RTMFP flashed by momentarily (Adobe acquired a company with its technologies and wanted to incorporate UDP into Flash Player, but the market wasn't ready, with a decade of HLS ahead) and RTMPT - low latency broadcasting over HTTP. The latter was a decent idea, if not for being such a behemoth that required regular polling to download chunks from the server several times a second.

Enhanced RTMP

The practice, established among broadcasters, of publishing video to servers via RTMP (why didn't HTTP MPEG-TS fit their needs? After all, it is absolutely better in every aspect) led to an unpleasant situation: the protocol does not allow for the purchase of new hardware and the implementation of new codecs like H265 and AV1. Similarly, with audio, it's quite odd to build a service without Opus.

The first iteration of adding H265 simply used an unused codec number, and this was enough for the client and server to communicate.

However, YouTube decided to implement a more extensive specification, Enhanced RTMP, which allows for the addition of new codecs. This protocol will stay with us for a while.

RTMP Implementation in Flussonic

Setting up the reception and transmission of streams via RTMP in Flussonic is performed in standard ways. Make sure to take into account the RTMP URL peculiarities described above.

Also, to use RTMP/Enhanced RTMP and RTMPS, it's necessary to specify ports in Flussonic.

Flussonic supports:

Setting Ports for RTMP/Enhanced RTMP and RTMPS

Ports for RTMP/Enhanced RTMP and RTMPS can be specified in the Listeners section under the Config -> Settings tab.

Note

To use RTMPS, it's necessary to obtain an SSL certificate.

Listeners