On 11/09/16 21:41, Hendrik Leppkes wrote:
We don't care because "caring" would severly limit the things we can
change in the code.
Your logic would be sound if the code hadn't been declared as deprecated. I do
agree that for live code the users have to accept changes when it means there is
a
On Sun, Sep 11, 2016 at 7:52 PM, Sven C. Dack wrote:
> On 11/09/16 18:27, Clément Bœsch wrote:
>>
>> Aside from the stdout output in ffprobe, no stdout/stderr output is
>> standardized in FFmpeg and thus can be changed at will (and does
>> regularly). You can try to parse it, but there is zero war
On 11/09/16 19:45, Nicolas George wrote:
Please stop about ffserver. This branch of the discussion is not about
ffserver, it is about you not understanding 40+ years of good software
design, namely the separation between normalized reliable output on stdout
and human-readable diagnosis output on
On 11/09/16 18:57, Clément Bœsch wrote:
I think we disagree, because no user of a working setup will ever read the
documentation just to check for deprecated tools. Having the warning at
runtime is the most efficient way to reach out a maximum of users as soon
as possible so they have time to mig
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
> Did you at least read the second part of my mail? Because I sure do get you
> don't care. It's all you, Nicolas and Hendrik have been saying here really.
Not really.
> ff
On Sun, Sep 11, 2016 at 06:52:50PM +0100, Sven C. Dack wrote:
> On 11/09/16 18:27, Clément Bœsch wrote:
> > Aside from the stdout output in ffprobe, no stdout/stderr output is
> > standardized in FFmpeg and thus can be changed at will (and does
> > regularly). You can try to parse it, but there is
On 11/09/16 18:27, Clément Bœsch wrote:
Aside from the stdout output in ffprobe, no stdout/stderr output is
standardized in FFmpeg and thus can be changed at will (and does
regularly). You can try to parse it, but there is zero warranty that it
will work the next day.
Regards,
Did you at least
On Sun, Sep 11, 2016 at 06:17:01PM +0100, Sven C. Dack wrote:
> On 11/09/16 16:31, Nicolas George wrote:
> > I see how it can do that, but you refuse to understand that this part of the
> > output is not meant to be parsed, unlike, for example, the output of
> > ffprobe.
>
> Nonsense. All messages
On 11/09/16 16:31, Nicolas George wrote:
I see how it can do that, but you refuse to understand that this part of the
output is not meant to be parsed, unlike, for example, the output of
ffprobe.
Nonsense. All messages, regardless if send to stdout or stderr, can be parsed.
There is no rule in
On Sun, Sep 11, 2016 at 5:04 PM, Sven C. Dack wrote:
> On 11/09/16 15:12, Nicolas George wrote:
>>
>> I do not care at all about ffserver, but the argument of parsing stderr to
>> revuse a warning is completely void, period.
>>
>> Regards,
>
>
> Please no foot stomping of opinions. When you cannot
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
> Please no foot stomping of opinions. When you cannot see how changing the
> output can confuse scripts of users then that's ok
I see how it can do that, but you refuse to understand that this part of the
output is not meant to be parsed,
On 11/09/16 15:12, Nicolas George wrote:
I do not care at all about ffserver, but the argument of parsing stderr to
revuse a warning is completely void, period.
Regards,
Please no foot stomping of opinions. When you cannot see how changing the output
can confuse scripts of users then that's o
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
> No, it's not bogus.
Yes, it is.
> It's what sometimes must be done. For example, just this
> morning did I again have to pipe the output of ffprobe through "|&" because
> it likes to print its findings to stderr and
On 11/09/16 10:45, Nicolas George wrote:
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
Error messages go to stderr and one sometimes parses these to respond to an
error.
This is bogus and should not be considered a reason for design decisions.
If there are cases where this is act
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
> Error messages go to stderr and one sometimes parses these to respond to an
> error.
This is bogus and should not be considered a reason for design decisions.
If there are cases where this is actually necessary, then report them and we
On 11/09/16 08:39, Nicolas George wrote:
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
This could interfere with users' current scripts for running ffserver and
turn into "adding insult to injury" for the time it is still around.
Deprecation messages go to stderr. If users' scripts
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
> This could interfere with users' current scripts for running ffserver and
> turn into "adding insult to injury" for the time it is still around.
Deprecation messages go to stderr. If users' scripts rely on the format of
stderr, breaking
On 11/09/16 02:07, Carl Eugen Hoyos wrote:
Or actually: Don't you agree that a deprecation message printed by
the program would make much more sense?
Carl Eugen
This could interfere with users' current scripts for running ffserver and turn
into "adding insult to injury" for the time it is st
2016-09-11 2:59 GMT+02:00 Carl Eugen Hoyos :
> 2016-09-11 1:48 GMT+02:00 Timo Rothenpieler :
>
>> It's not intended to deprecate ffserver (yet), just a signal to users
>> that they really want to switch to/use something else, or pick up
>> maintainership of it.
>
> A sufficient signal is already on
2016-09-11 1:48 GMT+02:00 Timo Rothenpieler :
> It's not intended to deprecate ffserver (yet), just a signal to users
> that they really want to switch to/use something else, or pick up
> maintainership of it.
A sufficient signal is already on the homepage.
Carl Eugen
___
On 9/11/2016 1:22 AM, Carl Eugen Hoyos wrote:
> 2016-09-10 23:25 GMT+02:00 Timo Rothenpieler :
>
>> - --disable-ffserver disable ffserver build
>> + --enable-ffserverenable ffserver build
ffserver is unmaintained for a very long time now.
It's been discussed about deprecating or e
2016-09-10 23:25 GMT+02:00 Timo Rothenpieler :
> - --disable-ffserver disable ffserver build
> + --enable-ffserverenable ffserver build
This is not ok and you are not explaining it.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@
On 10/09/2016 22:50, Timo Rothenpieler wrote:
On 9/10/2016 11:40 PM, Josh de Kock wrote:
On 10/09/2016 22:25, Timo Rothenpieler wrote:
[...]
+DEPRECATED_PROGRAM_LIST="
+ffserver
+"
[...]
I don't really see the point of this, the other programs are unlikely to
be deprecated soon, and this
On 9/10/2016 11:40 PM, Josh de Kock wrote:
> On 10/09/2016 22:25, Timo Rothenpieler wrote:
>> [...]
>> +DEPRECATED_PROGRAM_LIST="
>> +ffserver
>> +"
>> [...]
>
> I don't really see the point of this, the other programs are unlikely to
> be deprecated soon, and this list will be removed after f
On 10/09/2016 22:25, Timo Rothenpieler wrote:
[...]
+DEPRECATED_PROGRAM_LIST="
+ffserver
+"
> [...]
I don't really see the point of this, the other programs are unlikely to
be deprecated soon, and this list will be removed after ffserver is. I
think it'd just be best to leave it in PROGRA
---
configure | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index b11ca7f..d67d8a2 100755
--- a/configure
+++ b/configure
@@ -116,7 +116,7 @@ Program options:
--disable-ffmpeg disable ffmpeg build
--disable-ffplay disab
26 matches
Mail list logo
