[FFmpeg-devel] [PATCH] libavformat: add librist protocol

Sergio M. Ammirata, Ph.D. sergio at ammirata.net
Sun Jan 31 23:33:28 EET 2021


librist has an internal buffer limit of 10000 bytes (the
protocol has none).

For writing, the data you give librist, will go out "as is"
to the network with some added protocol overhead bytes (28
bytes without encryption enabled and 36 bytes with
encryption enabled).

To avoid your data being fragmented because of network MTU,
you should really limit the write size to what you want
your IP packets to be. For mpegts, for example, 1316 is a
good number to keep the overall packet size below the
typical internet MTU size of 1500 (1400 to be safe).

I suggest this "max" write size be a configurable setting
in ffmpeg so that a higher number can be used if you are
running it where the network supports jumbo packets.

For reading, you can keep the 9964 number always.

Most implementations of RIST "simple and main profiles"
have been focused on mpegts payloads. However, librist has
a more generic approach and will replicate the payload
passed to it, byte by byte to the other side. Within the
protocol itself, librist pretends to be sending an mpegts
payload and will inter-operate well with other
implementations when mpegts is the payload sent. When you
send other payload types, the other side needs to have
librist and/or needs to know how to process such payloads. 
For example, ffmpeg to ffmpeg with librist on both sides
will be able to transfer any payload/protocol that can be
auto-detected on the receiver end. 

Regards,

Sergio


On Sun, 2021-01-31 at 12:46 +0100, Marton Balint wrote:
> 
> On Sun, 31 Jan 2021, Paul B Mahol wrote:
> 
> On Sun, Jan 31, 2021 at 12:29 PM Marton Balint <cus at passwd.hu> wrote:
> 
> 
> 
> On Sun, 31 Jan 2021, Paul B Mahol wrote:
> 
> On Sun, Jan 31, 2021 at 12:00 PM Marton Balint <cus at passwd.hu> wrote:
> 
> 
> 
> On Tue, 26 Jan 2021, Paul B Mahol wrote:
> 
> This work is sponsored by Open Broadcast Systems.
> 
> Signed-off-by: Paul B Mahol <onemda at gmail.com>
> ---
> configure               |   5 +
> doc/protocols.texi      |  32 +++++
> libavformat/Makefile    |   1 +
> libavformat/librist.c   | 251 ++++++++++++++++++++++++++++++++++++++++
> libavformat/protocols.c |   1 +
> 5 files changed, 290 insertions(+)
> create mode 100644 libavformat/librist.c
> 
> 
> [...]
> 
> 
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -690,6 +690,38 @@ Example usage:
> -f rtp_mpegts -fec prompeg=l=8:d=4 rtp://@var{hostname}:@var{port}
> @end example
> 
> + at section rist
> +
> +Reliable Internet Streaming Transport protocol
> +
> +The accepted options are:
> + at table @option
> + at item rist_profile
> +Supported values:
> + at table @samp
> + at item simple
> + at item main
> +This one is default.
> + at item advanced
> + at end table
> +
> + at item buffer_size
> +Set internal RIST buffer size for retransmission of data.
> +
> + at item pkt_size
> +Set internal RIST buffer size for receiving and sending data.
> 
> You should mention the default here. And by the way, why have you
> selected
> 9968 as default? I thought primaryly mpegts is targeted, so maybe 1316
> makes more sense no?
> 
> 
> NO
> 
> Please explain why, and give a reason for 9968 then.
> 
> 
> because that is max allowed value that works,
> 
> And is this some librist or protocol limitation?
> 
> I really wonder why it should  be lowered.
> 
> I suggested to lower it for write only. 9968 is not divisible by 188, so 
> libavformat will split packets inside mpegts packet, instead of at mpegts 
> packet boundaries, which will surely cause issues on the some receivers.
> 
> Regards,
> Marton
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list