It looks like #include netinet/tcp.h might work BUT
According to this page http://linux.die.net/man/7/tcp
it looks like this socket setting is not truly portable. :(
My intent was to offer some flexibility in what looks like a long standing
problem with rtmp streaming.
For my purposes, I can get
I don't understand why I need to do that. The free is already present in
the uninit, and before every update of the prev_frame update.
---
libavfilter/vf_palettegen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
index
On 25/02/15 11:55 AM, Paul B Mahol wrote:
+static inline void line_copy8(uint8_t *line, const uint8_t *srcp, int width,
int mergin)
Unless I'm missing something, mergin seems to always be 1.
The code below could be simplified.
+{
+memcpy(line, srcp, width);
+
+for (int i = mergin;
On Wed, Feb 25, 2015 at 04:14:11PM +0100, Clément Bœsch wrote:
On Wed, Feb 25, 2015 at 03:43:23PM +0100, Nicolas George wrote:
Le septidi 7 ventôse, an CCXXIII, Clement Boesch a écrit :
+float ratio = (float)nb_out / nb_in;
+snprintf(buf, sizeof(buf), %f, ratio);
I wonder if
Removing these removes the dependency of this code on mips32r2 which would
allow it to be used on processors which have FPU instructions, but not r2
instructions (like the mips64el debian port for instance).
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aacdec_mips.h |
Q_fract should have be declared as 'const float*'.
Also fix the constness of some local variables affected by this.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aacpsdsp_mips.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
There are no independant uses of mips32r2 instructions except for the
FPU parts. Due to the heavy use of mips32r2 specifc fpu extensions, I
am guessing the original author intended MIPSFPU to imply MIPS32R2 anyway.
Since these fpu instructions are available on mips64 (non-r2), enable them
there
Remove some assembly that the compiler can easily handle optimally on its own.
GCC produces almost identical assembly.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/fft_mips.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git
On 2/26/2015 4:04 PM, Nicolas George wrote:
If we are talking about end-user interface, the changes should happen in
cmdutils.c.
Fair enough.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Am 09.02.15 um 21:55 schrieb Carl Eugen Hoyos:
Thilo Borgmann thilo.borgmann at mail.de writes:
Am 09.02.15 um 12:33 schrieb Carl Eugen Hoyos:
On Monday 09 February 2015 11:26:57 am Thilo Borgmann wrote:
do you really mean to check for CoreGraphics.h
in case of lib ApplicationServices?
On 2/26/2015 4:10 PM, Clément Bœsch wrote:
Yes, it will return an error and abort the operation. Be it done on the
command line or via the API. So said differently it won't work anymore.
I do wonder what the point of the whole AVOption API is then, if we can't
break it any more than a struct.
L'octidi 8 ventôse, an CCXXIII, Derek Buitenhuis a écrit :
I read it as a 'text stream', which isn't necessarily file i/o only, but I
doubt it is worth bikeshedding over.
You are probably right, I meant file I/O in the Unix sense.
I think relying on the user to input a CR+LF cia command line
On Thu, Feb 26, 2015 at 05:15:56PM +0100, Clément Bœsch wrote:
On Thu, Feb 26, 2015 at 04:13:10PM +, Derek Buitenhuis wrote:
On 2/26/2015 4:10 PM, Clément Bœsch wrote:
Yes, it will return an error and abort the operation. Be it done on the
command line or via the API. So said
Carl Eugen Hoyos cehoyos at ag.or.at writes:
Attached patch sets bits_per_raw_sample when decoding hqx.
I will push this if nobody objects.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Hi!
A user reported that the Solaris libc detection has never worked on all
installations. Attached patch forces the definition of __EXTENSIONS__
which is needed for network compilation.
This fixes the following error:
libavformat/udp.c:174: error: storage size of 'mreq' isn't known
Please
On Thu, Feb 26, 2015 at 01:42:52PM +, James Cowgill wrote:
Change register constraint on the v variable from = to +. This was causing GCC
to think that the v variable was never read and therefore not initialize it.
This fixes about 20 fate failures on mips64el.
Signed-off-by: James
Am 11.02.15 um 11:33 schrieb Carl Eugen Hoyos:
Hi!
Attached patch silences many warnings that clang prints
when compiling libavdevice/qtkit.o. I don't think the
warnings are very helpful.
OK.
-Thilo
___
ffmpeg-devel mailing list
On Thu, Feb 26, 2015 at 04:13:10PM +, Derek Buitenhuis wrote:
On 2/26/2015 4:10 PM, Clément Bœsch wrote:
Yes, it will return an error and abort the operation. Be it done on the
command line or via the API. So said differently it won't work anymore.
I do wonder what the point of the
On Thu, Feb 26, 2015 at 01:42:45PM +, James Cowgill wrote:
Remove some assembly that the compiler can easily handle optimally on its own.
GCC produces almost identical assembly.
Signed-off-by: James Cowgill james...@cowgill.org.uk
applied
thanks
[...]
--
Michael GnuPG fingerprint:
On Thursday 26 February 2015 03:31:39 pm Derek Buitenhuis wrote:
On 2/26/2015 2:09 PM, Carl Eugen Hoyos wrote:
+snprintf(header, len + 3, %s\r\n, s-headers);
This does not necessarily work on windows. The C standard idctates that in
text mode, \n is translated to the system's
On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote:
On 2/26/2015 1:50 PM, Clément Bœsch wrote:
If the option is set by default, you don't want to warn for no reason.
It's not set by default. That patch never went in.
Ah, my bad.
I don't believe silently not writing it is a
On Thu, Feb 26, 2015 at 4:54 PM, Clément Bœsch u...@pkh.me wrote:
On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote:
On 2/26/2015 1:50 PM, Clément Bœsch wrote:
If the option is set by default, you don't want to warn for no reason.
It's not set by default. That patch never went
On Thu, Feb 26, 2015 at 01:42:46PM +, James Cowgill wrote:
The optimized C version of this code actually runs faster than this
version, so remove it.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/sbrdsp_mips.c | 34 --
1 file
On Thu, Feb 26, 2015 at 01:42:44PM +, James Cowgill wrote:
Q_fract should have be declared as 'const float*'.
Also fix the constness of some local variables affected by this.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aacpsdsp_mips.c | 6 +++---
1 file
L'octidi 8 ventôse, an CCXXIII, Derek Buitenhuis a écrit :
This does not necessarily work on windows. The C standard idctates that in
text mode, \n is translated to the system's native newline.
Use memcpy and 0x0D / 0X0A / 0x00.
I think you are confusing two subtly different issues and
On 2/26/2015 3:35 PM, Nicolas George wrote:
The second issue is that with the windows file API, when the file is opened
in the so-called text mode, there is an implicit conversion between '\n'
in memory (which is actually exactly 0x0A) and \r\n in the file; there is
also a conversion between
On Thu, Feb 26, 2015 at 01:42:42PM +, James Cowgill wrote:
GCC is perfectly happy generating optimized multiplication code on its own for
64-bit arches. GCC refuses to optimize the loongson code when in 32-bit mode,
so I've left that.
Signed-off-by: James Cowgill james...@cowgill.org.uk
On Thu, Feb 26, 2015 at 05:04:53PM +0100, Hendrik Leppkes wrote:
On Thu, Feb 26, 2015 at 4:54 PM, Clément Bœsch u...@pkh.me wrote:
On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote:
On 2/26/2015 1:50 PM, Clément Bœsch wrote:
If the option is set by default, you don't want to
On 26.02.2015 00:51, Michael Niedermayer wrote:
On Wed, Feb 25, 2015 at 05:35:33PM +0100, Tobias Rapp wrote:
avienc.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
09f8c8250ce5ec1bdad79a1bf280028c9d3af376
0001-libavformat-avienc-Fix-duration-for-audio-stream-Ope.patch
On Wed, Feb 25, 2015 at 06:55:48PM +0100, Michael Niedermayer wrote:
On Wed, Feb 25, 2015 at 04:10:44PM +0100, Clément Bœsch wrote:
From: Clément Bœsch clem...@stupeflix.com
This makes the sorting of the colors along an axis (r, g or b)
predictible, and thus testable under FATE. The
The optimized C version of this code actually runs faster than this
version, so remove it.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/sbrdsp_mips.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/libavcodec/mips/sbrdsp_mips.c
The assembly versions have a few problems
- They only work with mips32r2 enabled
- They don't work on 64-bits
- They're massive and complex
So replace them with C implementations which solve these problems and let GCC
magically optimize for different platforms. All the functions are manually
This also restricts it to MOV and MP4, since it is only
defined for those formats.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/movenc.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c
This is obviously needed for 64-bit support.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aacdec_mips.c | 2 +-
libavcodec/mips/aacpsdsp_mips.c | 12 ++--
libavcodec/mips/sbrdsp_mips.c | 10 +-
3 files changed, 12 insertions(+), 12 deletions(-)
On mips64, the registers t[4-7] do not exist. Instead of using a lot of #ifdef
or defines to handle differing register names, use variables and let GCC
allocate the registers automatically (like in the other mips assembly files).
In get_band_cost_ESC_mips, t4 and t5 were renamed to t6 and t7 to
On Sun, Feb 22, 2015 at 7:26 AM, Clément Bœsch u...@pkh.me wrote:
On Wed, Feb 18, 2015 at 06:20:54PM -0800, Chris Kennedy wrote:
More details attached, debug level and gdb backtrace. Hopefully this
helps, and I will work on getting a file I can share showing the issue.
Thanks
[...]
On 2/26/2015 1:42 PM, James Cowgill wrote:
The assembly versions have a few problems
- They only work with mips32r2 enabled
- They don't work on 64-bits
- They're massive and complex
So replace them with C implementations which solve these problems and let GCC
magically optimize for
On 2/26/2015 2:09 PM, Carl Eugen Hoyos wrote:
+snprintf(header, len + 3, %s\r\n, s-headers);
This does not necessarily work on windows. The C standard idctates that in
text mode, \n is translated to the system's native newline.
Use memcpy and 0x0D / 0X0A / 0x00.
This may also
On Thu, Feb 26, 2015 at 02:14:33PM +0100, Tobias Rapp wrote:
On 26.02.2015 00:51, Michael Niedermayer wrote:
On Wed, Feb 25, 2015 at 05:35:33PM +0100, Tobias Rapp wrote:
avienc.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
09f8c8250ce5ec1bdad79a1bf280028c9d3af376
Hi,
This patchset aims to cleanup the MIPS optimizations a bit and add support for
64-bit processors.
I haven't attempted specifically to optimize any of this for 64-bit systems,
except for the removal of some assembly blocks which GCC can optimize just as
well itself. Also I havn't gone through
GCC is perfectly happy generating optimized multiplication code on its own for
64-bit arches. GCC refuses to optimize the loongson code when in 32-bit mode,
so I've left that.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/mathops.h | 26 --
1
This mainly consists of replacing all the pointer arithmatic 'addiu'
instructions with PTR_ADDIU which will handle the differences in pointer
sizes when compiled on 64 bit mips systems.
The header asmdefs.h contains the PTR_ macros which expend to the correct mips
instructions to manipulate
On 2/26/2015 1:50 PM, Clément Bœsch wrote:
If the option is set by default, you don't want to warn for no reason.
It's not set by default. That patch never went in.
I don't believe silently not writing it is a valid approach. Then
again I think setting a default movflag like that instead of
On Thu, Feb 26, 2015 at 01:47:01PM +, Derek Buitenhuis wrote:
This also restricts it to MOV and MP4, since it is only
defined for those formats.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/movenc.c | 29 +++--
1 file changed, 23
On Mon, Feb 23, 2015 at 01:56:59PM +0100, Clément Bœsch wrote:
Here are two tests for the recently added filters. I'm hopping that qsort will
not cause any issue, otherwise we might need to switch to AV_QSORT (I'm
thinking of the sort where multiple different values have the same score in
The float_copy and fmul_and_reverse functions are refactored out from the
multiple copies in this file.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
libavcodec/mips/aacdec_mips.c | 612 --
1 file changed, 111 insertions(+), 501 deletions(-)
Change register constraint on the v variable from = to +. This was causing GCC
to think that the v variable was never read and therefore not initialize it.
This fixes about 20 fate failures on mips64el.
Signed-off-by: James Cowgill james...@cowgill.org.uk
---
On Thu, 2015-02-26 at 13:51 +, Derek Buitenhuis wrote:
On 2/26/2015 1:42 PM, James Cowgill wrote:
The assembly versions have a few problems
- They only work with mips32r2 enabled
- They don't work on 64-bits
- They're massive and complex
So replace them with C implementations
On Thu, Feb 26, 2015 at 04:13:10PM +, Derek Buitenhuis wrote:
On 2/26/2015 4:10 PM, Clément Bœsch wrote:
Yes, it will return an error and abort the operation. Be it done on the
command line or via the API. So said differently it won't work anymore.
I do wonder what the point of the
On Thu, Feb 26, 2015 at 01:47:01PM +, Derek Buitenhuis wrote:
This also restricts it to MOV and MP4, since it is only
defined for those formats.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/movenc.c | 29 +++--
1 file changed, 23
Hello everyone,
I'm trying to encode video and audio directly from a capture board, 1 video
stream and 8 single channel audio streams into a MXF file encoding it in
Mpeg-2.
Everything is working fine except when I call av_write_trailer() at the end
(and before freeing CodecContext as stated in
On 26.02.2015 15:09, Luca Barbato wrote:
On 26/02/15 12:19, Andreas Cadhalpun wrote:
On 26.02.2015 04:15, Luca Barbato wrote:
The decoder has this
/* channels */
avctx-channels = buf[7];
if (avctx-channels = 0 || avctx-channels 2)
return AVERROR_INVALIDDATA;
So by
On Thu, Feb 26, 2015 at 04:54:02PM +0100, Clément Bœsch wrote:
On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote:
On 2/26/2015 1:50 PM, Clément Bœsch wrote:
If the option is set by default, you don't want to warn for no reason.
It's not set by default. That patch never
On 2/26/2015 5:02 PM, Michael Niedermayer wrote:
just of the top of my head, i can think of:
AVOptions allows listing the available options, like for automatically
building a list of available options in a GUI
it allows changing the type int-int64, int-double
it stores default value, min and
Am 08.02.15 um 15:19 schrieb Carl Eugen Hoyos:
[...]
Also attached is a patch that I believe is necessary for
iOS audio capture, but it is mostly untested.
(It allows device listing though.)
Looks OK, please apply.
-Thilo
___
ffmpeg-devel mailing
The init_put_bits() function (in libavcodec/put_bits.h) takes a buffer and
a buffer size (in bytes). Several of the encoders are passing the buffer
size in bits, by multiplying the buffer size by 8. This is incorrect.
We saw this problem when encoding a ProRes (Anatoliy) file at size
4096x4096.
Hi
On Thu, Feb 26, 2015 at 10:42:06AM -0800, Dyami Caliri wrote:
The init_put_bits() function (in libavcodec/put_bits.h) takes a buffer and
a buffer size (in bytes). Several of the encoders are passing the buffer
size in bits, by multiplying the buffer size by 8. This is incorrect.
We saw
L'octidi 8 ventôse, an CCXXIII, Andreas Cadhalpun a écrit :
the bit format muxer currently segfaults, when it is passed a packet of size
0.
This can be triggered e.g. with:
ffmpeg -y -f lavfi -i sine=duration=0.1 -c:a flac -f bit /dev/null
Attached patch fixes this.
This looks wrong. The
Do you want sample code that generates the crash?
For the code shouldn't really crash even without the patch, are you
saying that the code, as it's written, doesn't look it would crash?
Or are you saying that we need to change the code to make sure it doesn't
crash, even without the patch?
Here
This adds another option to a change authored by Brian Brice
bbr...@gmail.com 2015-01-19
librtmp: Allow changing the socket send buffer size
(Brian is aware of this change).
Unlike a previous patch, this has no dependency on rtmpdump.
Options to the ffmpeg commandline in support of now
On Thu, Feb 26, 2015 at 06:15:30PM +0100, Michael Niedermayer wrote:
On Thu, Feb 26, 2015 at 04:54:02PM +0100, Clément Bœsch wrote:
On Thu, Feb 26, 2015 at 01:53:13PM +, Derek Buitenhuis wrote:
On 2/26/2015 1:50 PM, Clément Bœsch wrote:
If the option is set by default, you don't want
Le septidi 7 ventôse, an CCXXIII, Michael Niedermayer a écrit :
i think the case i tested had HAVE_W32THREADS set
also theres HAVE_OS2THREADS
I suspect my question was too vague.
If I understand correctly,
HAVE_THREADS = HAVE_PTHREADS || HAVE_W32THREADS || HAVE_OS2THREADS
Am I right?
My
L'octidi 8 ventôse, an CCXXIII, Nicolas George a écrit :
Last: how come ffmpeg/lavf tries to mux an empty packet?
It comes from that commit:
commit 0957b274e312e985d69cb490bee2a7ff820acaa6
Author: Anton Khirnov an...@khirnov.net
Date: 2014-04-29 15:06:45 +0200
lavc: add an option to
On Thu, Feb 26, 2015 at 12:10:49PM -0800, Dyami Caliri wrote:
Do you want sample code that generates the crash?
For the code shouldn't really crash even without the patch, are you
saying that the code, as it's written, doesn't look it would crash?
Or are you saying that we need to change the
On 26.02.2015 20:48, Nicolas George wrote:
L'octidi 8 ventôse, an CCXXIII, Andreas Cadhalpun a écrit :
the bit format muxer currently segfaults, when it is passed a packet of size 0.
This can be triggered e.g. with:
ffmpeg -y -f lavfi -i sine=duration=0.1 -c:a flac -f bit /dev/null
Attached
Use this instead. (sorry, corrected grammatical errors.)
On Thu, Feb 26, 2015 at 1:22 PM, Cary Tetrick ctetri...@gmail.com wrote:
This adds another option to a change authored by Brian Brice
bbr...@gmail.com 2015-01-19
librtmp: Allow changing the socket send buffer size
(Brian is aware
On Wed, Feb 25, 2015 at 02:55:58PM +, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol one...@gmail.com
---
doc/filters.texi | 34 ++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/vf_neighbor.c | 289
I have updated the patch.
Can you please explain me which user options to include?
From b44034b68233cc5734924f64185f3c830a2e227d Mon Sep 17 00:00:00 2001
From: Arwa Arif arwaarif1...@gmail.com
Date: Tue, 24 Feb 2015 12:17:30 +0530
Subject: [PATCH] Port FFT domain filter.
---
On 02/25/2015 10:04 PM, Deron wrote:
On 2/21/15 8:05 AM, Deron wrote:
On 2/15/15 5:44 AM, Anshul wrote:
attached another cleaned patch.
-Anshul
Not sure if I should be posting here, privately, or do the user list
since it is an unaccepted patch... This patch applies cleanly to
ffmpeg
On 26.02.2015 04:15, Luca Barbato wrote:
The decoder has this
/* channels */
avctx-channels = buf[7];
if (avctx-channels = 0 || avctx-channels 2)
return AVERROR_INVALIDDATA;
So by the time you get there the channels are already validated.
the extradata is validated on
On Thu, Feb 26, 2015 at 01:41:08PM +0530, arwa arif wrote:
I have updated the patch.
Can you please explain me which user options to include?
yes
it could be similar to the vf_geq.c flter
so something like
-vf fftfilt=dc=128:lum='(1 / (1 + exp(-Y/10.0+H/100.0)))'
could result in the
Am 24.02.15 um 11:32 schrieb Carl Eugen Hoyos:
Thilo Borgmann thilo.borgmann at mail.de writes:
You just misread me, I know what the first patch is for
- which is what you just wrote. However, my question
was about reason for the second #define patch.
My comment was only about the
On 26.02.2015, at 23:46, Hendrik Leppkes h.lepp...@gmail.com wrote:
On Thu, Feb 26, 2015 at 11:21 PM, Reimar Döffinger
reimar.doeffin...@gmx.de wrote:
When ff_thread_get_format is called from the main thread, e.g.
during codec init it will access the thread_ctx as a PerThreadContext
even
On Thu, Feb 26, 2015 at 05:26:36PM +, Eng. Tweellt wrote:
Hello everyone,
I'm trying to encode video and audio directly from a capture board, 1 video
stream and 8 single channel audio streams into a MXF file encoding it in
Mpeg-2.
Everything is working fine except when I call
On Thu, Feb 26, 2015 at 07:56:06PM +0100, Nicolas George wrote:
Le septidi 7 ventôse, an CCXXIII, Michael Niedermayer a écrit :
i think the case i tested had HAVE_W32THREADS set
also theres HAVE_OS2THREADS
I suspect my question was too vague.
If I understand correctly,
HAVE_THREADS =
When ff_thread_get_format is called from the main thread, e.g.
during codec init it will access the thread_ctx as a PerThreadContext
even though it is a FrameThreadContext.
Catch this case and add asserts to protect against similar issues
in other places.
In addition, when ff_thread_get_format is
On 26.02.2015 21:47, Nicolas George wrote:
L'octidi 8 ventôse, an CCXXIII, Nicolas George a écrit :
Last: how come ffmpeg/lavf tries to mux an empty packet?
It comes from that commit:
commit 0957b274e312e985d69cb490bee2a7ff820acaa6
Author: Anton Khirnov an...@khirnov.net
Date: 2014-04-29
On Thu, Feb 26, 2015 at 10:11:37PM +0100, Andreas Cadhalpun wrote:
On 26.02.2015 20:48, Nicolas George wrote:
L'octidi 8 ventôse, an CCXXIII, Andreas Cadhalpun a écrit :
the bit format muxer currently segfaults, when it is passed a packet of
size 0.
This can be triggered e.g. with:
ffmpeg
On Thu, Feb 26, 2015 at 11:21 PM, Reimar Döffinger
reimar.doeffin...@gmx.de wrote:
When ff_thread_get_format is called from the main thread, e.g.
during codec init it will access the thread_ctx as a PerThreadContext
even though it is a FrameThreadContext.
Where is this a problem exactly? I
No, i just extended what Brian already had. Just an option to to control
the no delay. I put the changes inside you #if for networking config.
On Feb 26, 2015 7:42 PM, Michael Niedermayer michae...@gmx.at wrote:
On Thu, Feb 26, 2015 at 03:23:40PM -0600, Cary Tetrick wrote:
Use this instead.
On Thu, Feb 26, 2015 at 03:23:40PM -0600, Cary Tetrick wrote:
Use this instead. (sorry, corrected grammatical errors.)
On Thu, Feb 26, 2015 at 1:22 PM, Cary Tetrick ctetri...@gmail.com wrote:
This adds another option to a change authored by Brian Brice
bbr...@gmail.com 2015-01-19
On Thu, Feb 26, 2015 at 08:00:49PM -0600, Cary Tetrick wrote:
No, i just extended what Brian already had. Just an option to to control
the no delay. I put the changes inside you #if for networking config.
you misunderstood my question
my question is what #includes it needs and if this is
82 matches
Mail list logo
