Well, when this is done, working, we can begin to talk business: -add an option to ffmpeg to drop unused input data like srt-file-transmit (before first client connects) -add an option/document if it's already working to ffmpeg to have multiple srt clients like gstreamer
Regards, On Wed, Aug 29, 2018 at 10:48 AM Marton Balint <c...@passwd.hu> wrote: > > > 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 > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
