[FFmpeg-devel] make work (live) libsrt

[Marton Balint]

On Wed, 29 Aug 2018, Tudor Suciu wrote:

> 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

I pushed the patch which adds the pkt_size option and also fixes the 
error you were seeing. I cannot comment on the other things.

Regards,
Marton


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