Struct rml_rtmp::chunk_io::ChunkSerializer

pub struct ChunkSerializer { /* fields omitted */ }

Allows serializing RTMP messages into RTMP chunks.

Due to the nature of the RTMP chunking protocol, the same serializer should be used for all messages that need to be sent to the same peer.

Methods

impl ChunkSerializer

pub fn new() -> ChunkSerializer

Creates a new ChunkSerializer.

By default (per the RTMP specification) the serializer will break any message into RTMP chunks with a max size of 128. To change this amount a call to set_max_chunk_size() is required.

pub fn set_max_chunk_size(     &mut self,     new_size: u32,     time: RtmpTimestamp ) -> Result<Packet, ChunkSerializationError>

Changes the maximum amount of bytes from RTMP messages that can be in a single RTMP chunk.

Changing the maximum chunk size requires notifying the receiver of the change, as it will affect every chunk you send out from here on out. Therefore, when this method is called we automatically serialize a SetChunkSize RTMP message to be sent to the peer. This packet must be sent and cannot be ignored.

pub fn serialize(     &mut self,     message: &MessagePayload,     force_uncompressed: bool,     can_be_dropped: bool ) -> Result<Packet, ChunkSerializationError>

Turns an RTMP message payload into binary data (representing RTMP chunks) that can be sent over the network.

The RTMP chunk format has a basic form of header compression it utilizes. If a chunk is sent with some header information, and the next chunk to be generated has a lot of similar header information, than the subsequent chunk can ommit some information and flag itself as requiring information from the previous chunk.

This compression can be bypassed by setting force_uncompressed to true. This is required in certain circumstances, as some encoders or video players require the initial RTMP messages (after the handshake) to always be type 0 chunks (uncompressed). The reason for this is unclear, but in these circumstances the clients or servers will not work properly without it.

If the message to be serialized is a video or audio data message, and it's not a a/v header, then it can be safe to set can_be_dropped to true. This will mark the packet so that the network transport mechanisms can make a decision if the packet should be dropped (if there's not enough bandwidth to keep the stream in real time) or if it should be enqueued even if backlogged. Setting this to true makes sure that if the packet is dropped that the receiver will not have deserialization problems on any subsequent RTMP chunks.