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 clien
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,
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
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
On Sat, 25 Aug 2018, Tudor Suciu wrote:
Hello Marton,
The new version takes into account your remarks, modifications.
I checked the srt API, and we are doing this all wrong.
The SRTO_PAYLOADSIZE socket parameter defines the maximum allowed packet
size. So we should query this parameter, a
Hello Marton,
The new version takes into account your remarks, modifications.
Regards,
From 11cd8cf4bedecc88700424f1a0782beafe70c9f1 Mon Sep 17 00:00:00 2001
From: Tudor Suciu
Date: Sat, 25 Aug 2018 14:06:57 +0200
Subject: [PATCH] add pkt_length to libsrt
---
doc/protocols.texi | 7 +++
On Sat, 25 Aug 2018, Marton Balint wrote:
On Sat, 25 Aug 2018, Tudor Suciu wrote:
Hello,
Is this patch in a better shape for inclusion?
The code seems OK, please resend the patch with a docs/protocols.texi
update for the new option.
On the second look, there are some strange things:
On Sat, 25 Aug 2018, Tudor Suciu wrote:
Hello,
Is this patch in a better shape for inclusion?
The code seems OK, please resend the patch with a docs/protocols.texi
update for the new option.
Thanks,
Marton
Regards,
On Fri, Aug 24, 2018 at 2:46 AM myp...@gmail.com wrote:
On Fri, A
Hello,
Is this patch in a better shape for inclusion?
Regards,
On Fri, Aug 24, 2018 at 2:46 AM myp...@gmail.com wrote:
> On Fri, Aug 24, 2018 at 2:55 AM Marton Balint wrote:
> >
> >
> >
> > On Thu, 23 Aug 2018, myp...@gmail.com wrote:
> >
> > > On Wed, Aug 22, 2018 at 4:30 AM Tudor Suciu
> w
On Fri, Aug 24, 2018 at 2:55 AM Marton Balint wrote:
>
>
>
> On Thu, 23 Aug 2018, myp...@gmail.com wrote:
>
> > On Wed, Aug 22, 2018 at 4:30 AM Tudor Suciu wrote:
> >>
> >> Hello,
> >>
> >> I get errors when I try to send a live srt stream that the first packet is
> >> too big:
> >> 21:30:39.8966
On Thu, 23 Aug 2018, myp...@gmail.com wrote:
On Wed, Aug 22, 2018 at 4:30 AM Tudor Suciu wrote:
Hello,
I get errors when I try to send a live srt stream that the first packet is
too big:
21:30:39.896626/ffmpeg*E: SRT.c: LiveSmoother: payload size: 1504 exceeds
maximum allowed 1316
Here ar
On Wed, Aug 22, 2018 at 4:30 AM Tudor Suciu wrote:
>
> Hello,
>
> I get errors when I try to send a live srt stream that the first packet is
> too big:
> 21:30:39.896626/ffmpeg*E: SRT.c: LiveSmoother: payload size: 1504 exceeds
> maximum allowed 1316
>
> Here are example commands for server and cl
Hello,
I get errors when I try to send a live srt stream that the first packet is
too big:
21:30:39.896626/ffmpeg*E: SRT.c: LiveSmoother: payload size: 1504 exceeds
maximum allowed 1316
Here are example commands for server and client:
ffmpeg -re -i ~/Downloads/ToS-4k-1920.mov -vcodec libx264 -g 5
13 matches
Mail list logo
