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