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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
