Luca Barbato wrote:
In Gentoo the suggested setting is
#net.core.rmem_max = 4194304
#net.core.wmem_max = 1048576
And checking around seems that there are people suggesting something even
larger.
On MacOSX it seems working fine.
If I recall correctly setting something larger that the
So what's the best course of action?
- Bump the size to be twice as big instead of 5 times
- Set the option twice
- Something else completely different
I'd recommend a setsockopt/getsockopt feedback loop that tries to set it to what
the user requested, and if that fails, sets it as high as
Le vendredi 15 mai 2015, 22:06:02 Luca Barbato a écrit :
On 15/05/15 20:39, Rémi Denis-Courmont wrote:
Le 2015-05-15 17:18, Luca Barbato a écrit :
Make it as large as 5 times the expected maximum udp packet.
Increasing the buffer size may be a good idea on Windows. But setting a
buffer
On 18/05/15 15:46, Tom Butterworth wrote:
Just to be clear, as one respondent seemed to misunderstand, these
compressed texture formats are passed to the graphics layer (OpenGL or
DirectX) as a final buffer for display. Unlike hardware decoding of eg
H.264 they don't return as buffers in a
This is patch 1 out of 3 that addresses the issue with detecting carrier loss.
This first one adds the raise-by-omission mechanism required for the NO_CARRIER
event to function properly on formats like MPEG-TS, the second adds the
NO_CARRIER event, and the third provides an implementation for
On 18/05/15 13:55, John Högberg wrote:
Luca Barbato wrote:
In Gentoo the suggested setting is
#net.core.rmem_max = 4194304 #net.core.wmem_max = 1048576
And checking around seems that there are people suggesting
something even larger.
On MacOSX it seems working fine.
If I recall correctly
Sorry, I haven't really managed to make my mail client work properly with this
mailing list. Here's the patch, I hope it ends up in the correct thread. :(
Regards,
John Högberg
From 97447c2e66296b37df89a44ba5d30b4204d23418 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?=
Hi,
I've fixed some issues with the no carrier patches I sent last week, and since
they had no comments and I've split them into three patches I figured that it's
simpler to mark the old ones as superseded and resend the patch set.
libavformat currently doesn't provide any mechanism for
This is patch 2 out of 3 that addresses the issue with detecting carrier loss.
The first one added the raise-by-omission mechanism required for the NO_CARRIER
event to function properly on formats like MPEG-TS, this second one adds the
NO_CARRIER event itself, and the third provides an
This is patch 3 out of 3 that addresses the issue with detecting carrier loss.
The first one added the raise-by-omission mechanism required for the NO_CARRIER
event to function properly on formats like MPEG-TS, the second one added the
NO_CARRIER event itself, and this third one provides an
Hi all
I have coincidentally been working on Hap support for libavcodec as well.
There are a couple of formats that are based on texture compression,
usually called DXTn or BCn, and described here:
http://en.wikipedia.org/wiki/S3_Texture_Compression. Currently in
libavcodec only txd uses this
Luca Barbato wrote:
You need that if you are receiving a full hd video over udp+mpegts and that's
getting the standard use case.
I second this. MPEG-TS over UDP is mainly used for IPTV, for which full HD has
been bog-standard for years. 12mbps streams are not uncommon, and many
distributors
Rémi Denis-Courmont wrote:
Of course, the kernel buffers need to be large enough to cope with packet
bursts, but that is not directly related to the bit rate.
While I fully agree that using the kernel receive buffer *instead of* a user one
is a hack at best, I think you either misunderstood
On 18/05/15 18:51, Rémi Denis-Courmont wrote:
Le lundi 18 mai 2015, 16:48:26 John Högberg a écrit :
I think you either misunderstood what the patch is
intended to fix (as I understand it) or underestimate how small the forced
default 64K is. In case you missed it, libav forces the receive
Le lundi 18 mai 2015, 16:48:26 John Högberg a écrit :
I think you either misunderstood what the patch is
intended to fix (as I understand it) or underestimate how small the forced
default 64K is. In case you missed it, libav forces the receive buffer size
to 64K (or buffer_size) overriding
Quoting Luca Barbato (2015-05-14 19:30:56)
Two patches, 1 is for general safety, while the second is possibly
stable-worthy.
If the problem this is supposed to solve is a caller sending a packet
with uninitialized fields, then I'd say the problem is on the caller
side. One should never send
Quoting Luca Barbato (2015-05-14 19:30:57)
Just setting data to NULL and size to 0 is not safe because of side
data.
Reported-By: Bernd Pfrommer
---
libavcodec/avcodec.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/avcodec.h
On 18/05/15 22:06, Anton Khirnov wrote:
Quoting Luca Barbato (2015-05-14 19:30:56)
Two patches, 1 is for general safety, while the second is possibly
stable-worthy.
If the problem this is supposed to solve is a caller sending a packet
with uninitialized fields, then I'd say the problem is on
Hi,
Quoting John Högberg (2015-05-18 14:23:43)
This is patch 1 out of 3 that addresses the issue with detecting carrier loss.
This first one adds the raise-by-omission mechanism required for the
NO_CARRIER
event to function properly on formats like MPEG-TS, the second adds the
NO_CARRIER
On 18/05/15 22:07, Anton Khirnov wrote:
Quoting Luca Barbato (2015-05-14 19:30:57)
Just setting data to NULL and size to 0 is not safe because of side
data.
Reported-By: Bernd Pfrommer
---
libavcodec/avcodec.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git
Hi,
Anton Khirnov wrote:
maybe I'm not seeing something obvious, but why don't you flip the meaning of
the flag, thus avoiding the need for the new function?
That's a good question. I implemented it that way at first, but I decided to try
this route since I wanted to avoid forcing the user to
This fixes running with -arch ppc.
There's a similar check further below (which checks the arch value
after autodetecting it, if it wasn't set), but if this particular
check is removed, the -arch parameter won't be validated at all
when doing e.g. gas-preprocessor.pl -arch foo -- gcc -v.
---
On 18/05/15 09:22, Martin Storsjo wrote:
This fixes running with -arch ppc.
There's a similar check further below (which checks the arch value
after autodetecting it, if it wasn't set), but if this particular
check is removed, the -arch parameter won't be validated at all
when doing e.g.
On 14/05/15 19:30, Luca Barbato wrote:
A flush packet is documented as an AVPacket with data and size set
to 0.
Reported-By: Bernd Pfrommer
---
libavcodec/utils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index c9ae19b..aee7ea2 100644
---
On 18/05/15 09:34, John Högberg wrote:
Luca Barbato wrote:
You need that if you are receiving a full hd video over udp+mpegts
and that's getting the standard use case.
I second this. MPEG-TS over UDP is mainly used for IPTV, for which
full HD has been bog-standard for years. 12mbps streams
25 matches
Mail list logo
