On Mon, Mar 16, 2015 at 04:04:16PM +0100, Nicolas George wrote:
Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit :
[...]
\r\n, five exclamation marks or an ASCII-art tortoise.
put some joke about how a computer can recognize ASCII-art tortoises
here
For the GUI application
Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit :
If the user passes just one header line then either he adds
CRLF at the end or he doesnt. These 2 cases can be easily distnguished
and teh code can add CRLF if its missing
this is basically carls patch and i think its good and
Le decadi 20 ventôse, an CCXXIII, wm4 a écrit :
Why not fix the shortcomings in FFmpeg? (The option API.)
https://lists.libav.org/pipermail/libav-devel/2015-March/067929.html
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
Le decadi 20 ventôse, an CCXXIII, Nicolas George a écrit :
I will try to propose another patch for pure validation.
See the attached patches.
Regards,
--
Nicolas George
From cef95aaec223b6644db6e52f9c6452d7aa01648b Mon Sep 17 00:00:00 2001
From: Nicolas George geo...@nsup.org
Date: Tue, 10
On Tue, Mar 10, 2015 at 02:09:10PM +0100, Nicolas George wrote:
Le decadi 20 ventôse, an CCXXIII, Carl Eugen Hoyos a écrit :
Please add a reference to ticket #3268
to the commit message.
I was about to reply locally added, but no, because it does not fix that
ticket.
what is the problem
Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit :
what is the problem ?
can you elaborate?
The problem raised in this trac ticket is that windows users seem unable to
put control characters in their command lines. I thought it was a
shortcoming of the windows command line
On Wed, Mar 11, 2015 at 01:24:28PM +0100, Nicolas George wrote:
Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit :
what is the problem ?
can you elaborate?
The problem raised in this trac ticket is that windows users seem unable to
put control characters in their command
Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit :
the question or well rather my question is why do they need to put
control characters in there in the first place.
There should be no need for that
Control characters are the only characters that are not valid in a HTTP
header
On Wed, Mar 11, 2015 at 02:59:04PM +0100, Nicolas George wrote:
Le primidi 21 ventôse, an CCXXIII, Michael Niedermayer a écrit :
the question or well rather my question is why do they need to put
control characters in there in the first place.
There should be no need for that
Control
On Tue, Mar 10, 2015 at 09:39:50AM +0100, Nicolas George wrote:
Le nonidi 19 ventôse, an CCXXIII, Michael Niedermayer a écrit :
there should be a loop that replaces each sequence of any \n\r by a single
crlf sequency
also ensure that one such sequence is at the end
I believe this would
Le decadi 20 ventôse, an CCXXIII, Carl Eugen Hoyos a écrit :
Please add a reference to ticket #3268
to the commit message.
I was about to reply locally added, but no, because it does not fix that
ticket.
Re-thinking on the whole discussion, I withdraw this patch, it is wrong. This
part of the
Nicolas George george at nsup.org writes:
What about the attached patch?
Please add a reference to ticket #3268
to the commit message.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Le decadi 20 ventôse, an CCXXIII, Michael Niedermayer a écrit :
iam fine with either, i was just trying to be completely correct
which may be overkill and indeed make the code less readable for no
gain
What about the attached patch?
Regards,
--
Nicolas George
From
On Tue, 10 Mar 2015 14:09:10 +0100
Nicolas George geo...@nsup.org wrote:
Le decadi 20 ventôse, an CCXXIII, Carl Eugen Hoyos a écrit :
Please add a reference to ticket #3268
to the commit message.
I was about to reply locally added, but no, because it does not fix that
ticket.
Michael Niedermayer michaelni at gmx.at writes:
if you only want t fix the end, then existing \r
and \n should be stripped and crlf be added
litterally without use of \r\n but literal byte
values
On which system can I test this (so that it
actually makes a difference)?
Thank you, Carl
Le nonidi 19 ventôse, an CCXXIII, Michael Niedermayer a écrit :
there should be a loop that replaces each sequence of any \n\r by a single
crlf sequency
also ensure that one such sequence is at the end
I believe this would be correct.
using no \r \n codes but only litteral bytes and
This
On Thu, Feb 26, 2015 at 04:28:54PM +0100, Carl Eugen Hoyos wrote:
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
Carl Eugen Hoyos cehoyos at ag.or.at writes:
I believe attached patch fixes ticket #3268 in some cases.
Ping, should one of the patches get applied?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
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
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 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
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 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
24 matches
Mail list logo
