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