[FFmpeg-devel] make work (live) libsrt

[Tudor Suciu]

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 <cus at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>