[FFmpeg-devel] make work (live) libsrt

[Marton Balint]

On Wed, 29 Aug 2018, Tudor Suciu wrote:

> Hello Marton,
>
> And should simply set SRTO_PACKETSIZE to our pkt_size parameter if we
>> don't want the libsrt default 1356.
>>
> At least for the specific case of mpegts I believe it's much better to have
> fixed size packets(188x*).
> It helps error recovery if we don't have to re-synchronize ts so
> (7*188=1316) seems a better default.
> The 1356 value could be treated as a maximum special case value, all sorts
> of network configurations can eat from the MTU (vpn comes to mind).
> If I understand correctly the working of libsrt, it "creates" a packet each
> time we send it some data. So without touching on the "maximum" value,
> h->max_packet_size insures that the "medium" value is effectively the
> expected one.
> The 1356 value, assuming no vpn/tunnel will spoil the party, will make ts
> advance with 40 bytes each packet, so almost any packet loss will produce
> ts that does not start with ts header. This doesn't seem good for packet
> loss recovery.
> Rtp encapsulated mpeg ts with pkt_size of 1316 will add an rtp header of ~
> 12 bytes so the needed srt payloadsize will be 1328. As wireshark does not
> recognize the protocol yet, I couldn't check in detail. I'm absolutely
> certain that ffmpeg will do bad things if rtp header is misplaced (not
> synchronized with a lost packet), it will end up happily reading random ts
> data as rtp header at some point given enough packet loss.

I am sorry for the consfusion, I meant 1316 and not 1356, and libsrt 
provides 1316 as default max payload size exactly for the reasons you 
described, and therefore that becomes the default max packet size. So all 
is fine in the code as far as I see, only my descriptive text was 
misleading, sorry.

Thanks,
Marton