On Sun, 28 Feb 2021, Paul B Mahol wrote:
On Sun, Feb 28, 2021 at 11:14 PM Marton Balint wrote:
On Sun, 28 Feb 2021, Paul B Mahol wrote:
> This work is sponsored by Open Broadcast Systems.
>
> Signed-off-by: Paul B Mahol
> ---
> configure | 5 +
> doc/protocols.texi |
On Sun, Feb 28, 2021 at 11:14 PM Marton Balint wrote:
>
>
> On Sun, 28 Feb 2021, Paul B Mahol wrote:
>
> > This work is sponsored by Open Broadcast Systems.
> >
> > Signed-off-by: Paul B Mahol
> > ---
> > configure | 5 +
> > doc/protocols.texi | 29 +
> > libavformat/Mak
On Sun, 28 Feb 2021, Paul B Mahol wrote:
This work is sponsored by Open Broadcast Systems.
Signed-off-by: Paul B Mahol
---
configure | 5 +
doc/protocols.texi | 29 +
libavformat/Makefile| 1 +
libavformat/librist.c | 236 +++
On Sun, 28 Feb 2021, Paul B Mahol wrote:
On Fri, Feb 26, 2021 at 9:54 PM Marton Balint wrote:
On Fri, 26 Feb 2021, Paul B Mahol wrote:
> This work is sponsored by Open Broadcast Systems.
>
> Signed-off-by: Paul B Mahol
> ---
> configure | 5 +
> doc/protocols.texi |
On Fri, Feb 26, 2021 at 9:54 PM Marton Balint wrote:
>
>
> On Fri, 26 Feb 2021, Paul B Mahol wrote:
>
> > This work is sponsored by Open Broadcast Systems.
> >
> > Signed-off-by: Paul B Mahol
> > ---
> > configure | 5 +
> > doc/protocols.texi | 29 +
> > libavformat/Make
On Fri, 26 Feb 2021, Paul B Mahol wrote:
This work is sponsored by Open Broadcast Systems.
Signed-off-by: Paul B Mahol
---
configure | 5 +
doc/protocols.texi | 29 +
libavformat/Makefile| 1 +
libavformat/librist.c | 248 +++
On Mon, 2021-02-01 at 16:25 +0100, Nicolas George wrote:
> Sergio M. Ammirata, Ph.D. (12021-02-01):
> This is a packet protocol. In your example above,
> thereader will get three reads of 20, 30 and 40
> Thank you for the clarification. I looked a little in the
> code in themeantime.
> Considerin
Sergio M. Ammirata, Ph.D. (12021-02-01):
> This is a packet protocol. In your example above, the
> reader will get three reads of 20, 30 and 40
Thank you for the clarification. I looked a little in the code in the
meantime.
Considering what was said, h->max_packet_size should be set to the
maximu
> Can you clarify something? Is this supposed to be a
> packet protocol or astream protocol?
> I.e., if the reader is waiting for 100 octets, and the
> writer sent 20then 30 then 40, will the reader get three
> reads of 20, 30, 40 or asingle read of 20+30+40=90?
This is a packet protocol. In your
Rodney Baker (12021-02-02):
> Nagle can introduce unwanted latency which is not desirable for real-time
> streaming. Mind you, tcp is inappropriate for real-time streaming anyway -
> that's what rtsp was invented for. I don't think Nagle belongs at app level
> anyway - it's a network stack funct
On Tuesday, 2 February 2021 0:52:23 ACDT Nicolas George wrote:
> Sergio M. Ammirata, Ph.D. (12021-01-31):
> > For writing, the data you give librist, will go out "as is"
> > to the network with some added protocol overhead bytes (28
> > bytes without encryption enabled and 36 bytes with
> > encrypt
Sergio M. Ammirata, Ph.D. (12021-01-31):
> For writing, the data you give librist, will go out "as is"
> to the network with some added protocol overhead bytes (28
> bytes without encryption enabled and 36 bytes with
> encryption enabled).
Can you clarify something? Is this supposed to be a packet
On Monday, 1 February 2021 8:03:28 ACDT Sergio M. Ammirata, Ph.D. wrote:
> librist has an internal buffer limit of 1 bytes (the
> protocol has none).
>
> For writing, the data you give librist, will go out "as is"
> to the network with some added protocol overhead bytes (28
> bytes without enc
librist has an internal buffer limit of 1 bytes (the
protocol has none).
For writing, the data you give librist, will go out "as is"
to the network with some added protocol overhead bytes (28
bytes without encryption enabled and 36 bytes with
encryption enabled).
To avoid your data being fra
On Sun, 31 Jan 2021, Paul B Mahol wrote:
On Sun, Jan 31, 2021 at 12:29 PM Marton Balint wrote:
On Sun, 31 Jan 2021, Paul B Mahol wrote:
> On Sun, Jan 31, 2021 at 12:00 PM Marton Balint wrote:
>
>>
>>
>> On Tue, 26 Jan 2021, Paul B Mahol wrote:
>>
>> > This work is sponsored by Open Broa
On Sun, Jan 31, 2021 at 12:29 PM Marton Balint wrote:
>
>
> On Sun, 31 Jan 2021, Paul B Mahol wrote:
>
> > On Sun, Jan 31, 2021 at 12:00 PM Marton Balint wrote:
> >
> >>
> >>
> >> On Tue, 26 Jan 2021, Paul B Mahol wrote:
> >>
> >> > This work is sponsored by Open Broadcast Systems.
> >> >
> >> >
On Sun, 31 Jan 2021, Paul B Mahol wrote:
On Sun, Jan 31, 2021 at 12:00 PM Marton Balint wrote:
On Tue, 26 Jan 2021, Paul B Mahol wrote:
> This work is sponsored by Open Broadcast Systems.
>
> Signed-off-by: Paul B Mahol
> ---
> configure | 5 +
> doc/protocols.texi |
On Sun, Jan 31, 2021 at 12:00 PM Marton Balint wrote:
>
>
> On Tue, 26 Jan 2021, Paul B Mahol wrote:
>
> > This work is sponsored by Open Broadcast Systems.
> >
> > Signed-off-by: Paul B Mahol
> > ---
> > configure | 5 +
> > doc/protocols.texi | 32 +
> > libavformat/Mak
On Tue, 26 Jan 2021, Paul B Mahol wrote:
This work is sponsored by Open Broadcast Systems.
Signed-off-by: Paul B Mahol
---
configure | 5 +
doc/protocols.texi | 32 +
libavformat/Makefile| 1 +
libavformat/librist.c | 251 +++
On 1/30/2021 8:57 PM, Marton Balint wrote:
On Tue, 26 Jan 2021, Paul B Mahol wrote:
This work is sponsored by Open Broadcast Systems.
Signed-off-by: Paul B Mahol
---
configure | 5 +
doc/protocols.texi | 32 +
libavformat/Makefile | 1 +
libavformat/librist.c |
On Sun, 31 Jan 2021, Marton Balint wrote:
On Tue, 26 Jan 2021, Paul B Mahol wrote:
This work is sponsored by Open Broadcast Systems.
Signed-off-by: Paul B Mahol
---
configure | 5 +
doc/protocols.texi | 32 +
libavformat/Makefile| 1 +
libavformat/librist.c
On Tue, 26 Jan 2021, Paul B Mahol wrote:
This work is sponsored by Open Broadcast Systems.
Signed-off-by: Paul B Mahol
---
configure | 5 +
doc/protocols.texi | 32 +
libavformat/Makefile| 1 +
libavformat/librist.c | 251 +++
Will apply soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Hello Paul,
In the librist_read function, you must call the new API
called rist_receiver_data_block_free to free the buffer
when you are done using it.
I am not sure if ffmpeg supports a custom callback for
freeing a buffer. If it does, you could actually use the
rist buffer as a reference as lon
Marton Balint (12020-12-25):
> Actually it should be POLLING_TIME as defined in libavformat/network.h for
> blocking mode if you want behaviour to be consistent with other protocols.
> The function cannot block indefinitely even in blocking mode to be able
> allow generic code in libavformat/avio.c
On Thu, 24 Dec 2020, Nicolas George wrote:
+static int librist_read(URLContext *h, uint8_t *buf, int size)
+{
+RISTContext *s = h->priv_data;
+const struct rist_data_block *data_block;
+int ret;
+
+ret = rist_receiver_data_read(s->rist_ctx, &data_block, 5);
Already mention
Look guys I will apply this patch soon.
Your reviews are very bad!
Why your reviews are extremely bad?
You really have no skills or experience to say anything useful in this
patch.
Simple proof is that I posted one variant where you objected about
allocation and than
your are not happy how I re
On 12/24/2020 8:08 AM, Paul B Mahol wrote:
+typedef struct RISTContext {
+const AVClass *class;
+
+int profile;
+int buffer_size;
+int packet_size;
+int log_level;
+int encryption;
+char *secret;
+
+struct rist_logging_settings logging_settings;
+struct rist_pe
Paul B Mahol (12020-12-24):
> I have zero respect about your disrespectful and extremely rude reviews.
>
> Why such flag should be handled? It does not make sense.
> timeout is correct.
> payload is never silently discarded, it is make sure that it is never
> bigger than max packet size, its just
On Thu, Dec 24, 2020 at 12:32 PM Nicolas George wrote:
> Paul B Mahol (12020-12-24):
> > This work is sponsored by Open Broadcast Systems.
> >
> > Signed-off-by: Paul B Mahol
> > ---
> > configure | 5 +
> > doc/protocols.texi | 32 ++
> > libavformat/Makefile| 1
Paul B Mahol (12020-12-24):
> This work is sponsored by Open Broadcast Systems.
>
> Signed-off-by: Paul B Mahol
> ---
> configure | 5 +
> doc/protocols.texi | 32 ++
> libavformat/Makefile| 1 +
> libavformat/librist.c | 242
Paul B Mahol (12020-12-24):
> This work is sponsored by Open Broadcast Systems.
>
> Signed-off-by: Paul B Mahol
> ---
> configure | 5 +
> doc/protocols.texi | 32 ++
> libavformat/Makefile| 1 +
> libavformat/librist.c | 233
On 12/23/2020 8:53 PM, James Almer wrote:
On 12/23/2020 8:32 PM, Paul B Mahol wrote:
+static int librist_close(URLContext *h)
+{
+ RISTContext *s = h->priv_data;
+ int ret = 0;
+
+ s->peer = NULL;
+
+ if (s->rist_ctx)
+ ret = rist_destroy(s->rist_ctx);
+ if (ret < 0)
+
On 12/23/2020 8:32 PM, Paul B Mahol wrote:
+static int librist_close(URLContext *h)
+{
+RISTContext *s = h->priv_data;
+int ret = 0;
+
+s->peer = NULL;
+
+if (s->rist_ctx)
+ret = rist_destroy(s->rist_ctx);
+if (ret < 0)
+return risterr2ret(ret);
+s->rist_ct
On Wed, 23 Dec 2020, Paul B Mahol wrote:
On Wed, Dec 23, 2020 at 10:30 PM Marton Balint wrote:
INT_MAX for pkt_size is probably not a good default. pkt_size is used (at
least in other protocols) to determine the maximum allowed packet size for
output, and the maximum supported packet siz
Paul B Mahol (12020-12-23):
> I nowhere see proof that this cause any bugs.
get_file_handle() returns a file descriptor for use with select() or
poll(). If you give it a random number (fd is a random number), the
application will poll it as if it were a file descriptor. At best, it
causes EBADFD.
Paul B Mahol (12020-12-23):
> This work is sponsored by Open Broadcast Systems.
Thanks for the disclosure.
>
> Signed-off-by: Paul B Mahol
> ---
> configure | 5 +
> doc/protocols.texi | 29 +
> libavformat/Makefile| 1 +
> libavformat/librist.c | 227
On Wed, Dec 23, 2020 at 11:29 PM Nicolas George wrote:
> Marton Balint (12020-12-23):
> > > +static int librist_get_file_handle(URLContext *h)
> > > +{
> > > +RISTContext *s = h->priv_data;
> > > +
> > > +return s->fd;
> > > +}
> >
> > I don't think this is right, s->fd is a flow id, not
Marton Balint (12020-12-23):
> > +static int librist_get_file_handle(URLContext *h)
> > +{
> > +RISTContext *s = h->priv_data;
> > +
> > +return s->fd;
> > +}
>
> I don't think this is right, s->fd is a flow id, not an ordinary file
> descriptor. You probably don't need this callback anywa
On Wed, Dec 23, 2020 at 10:30 PM Marton Balint wrote:
>
>
> On Wed, 23 Dec 2020, Paul B Mahol wrote:
>
> > This work is sponsored by Open Broadcast Systems.
> >
> > Signed-off-by: Paul B Mahol
> > ---
> > configure | 5 +
> > doc/protocols.texi | 29 +
> > libavformat/Mak
On Wed, 23 Dec 2020, Paul B Mahol wrote:
This work is sponsored by Open Broadcast Systems.
Signed-off-by: Paul B Mahol
---
configure | 5 +
doc/protocols.texi | 29 +
libavformat/Makefile| 1 +
libavformat/librist.c | 227 +++
41 matches
Mail list logo
