Kiloview’s decoders including D300, DC220 and DC230 now support RTMP service! With it the encoders can directly stream videos to decoder with RTMP protocol for decoding and outputting – without RTMP transferring platform.
In addition, it supports RTMP stream distribution, for example, D300 supports up to 50 RTMP streaming.
What is RTMP protocol and how does it benefit streaming?
RTMP (Real-Time Messaging Protocol) is a protocol for streaming audio, video and data over the Internet with high performance, with a constant connection between a Flash player and a server. The majority of encoders today can transmit RTMP, and most media servers can receive it including big social media players like Facebook, YouTube, Twitch, and Periscope, which makes it popular in AV area.
RTMP is a TCP-based protocol features persistent connections as well as low-latency communication. To deliver streams smoothly and transmit as much information as possible, it splits streams into fragments, and their size is negotiated dynamically between the client and server whereas sometimes kept unchanged; the default fragment sizes are 64 bytes for audio data, and 128 bytes for video data and most other data types. Fragments from different streams may then be interleaved, and multiplexed over a single connection. Thanks to its longer data chunks, the protocol carries only a one-byte header per fragment – this makes very little overhead. However, in application, individual fragments are not typically interleaved. Instead, the interleaving and multiplexing is done at the packet level, with RTMP packets across several different active channels being interleaved in such a way as to ensure that each channel meets its bandwidth, latency, and other quality-of-service requirements. Packets interleaved in this fashion are treated as indivisible, and are not interleaved on the fragment level.
The RTMP defines several virtual channels on which packets may be sent and received, and which operate independently of each other. For example, there is a channel for handling RPC requests and responses, a channel for video stream data, a channel for audio stream data, a channel for out-of-band control messages (fragment size negotiation, etc.), and so on. During a typical RTMP session, several channels may be active simultaneously at any given time. When RTMP data is encoded, a packet header is generated. The packet header specifies, amongst other matters, the ID of the channel on which it is to be sent, a timestamp of when it was generated (if necessary), and the size of the packet’s payload. This header is then followed by the actual payload content of the packet, which is fragmented according to the currently agreed-upon fragment size before it is sent over the connection. The packet header itself is never fragmented, and its size does not count towards the data in the packet’s first fragment. In other words, only the actual packet payload (the media data) is subject to fragmentation.
For decoding, Kiloview’s engineers now have it employed in D300, DC220 and DC230. Now you guys could download them with
