Thank you all for taking the time to reply!
While I may have seemed inactive, I have read each and every reply
multiple times to make sure I understood the points made correctly.
It has really been food for thought and exactly what I hoped for, so
thanks again!
I think it would be best to be inde
On 4/26/2018 12:29 PM, wm4 wrote:
> You never follow that though. You participate in endless flames, until
> the other side is tired and gives up.
This. The one who has endless energy to argue their point wins on ffmpeg-devel,
not the one with the correct or even most-supported point. Observed num
On Thu, 26 Apr 2018 14:19:51 +0200
Nicolas George wrote:
> Josh de Kock (2018-04-26):
> > >>Generally, adding more things to public API is a bad move
>
> > What I mean by this is making private fields public is generally a bad move.
> > They were initially made private for a reason, and if you
Josh de Kock (2018-04-26):
> >>Generally, adding more things to public API is a bad move
> What I mean by this is making private fields public is generally a bad move.
> They were initially made private for a reason, and if you suddenly need to
> modify them outside then you must ask: What does th
On Thu, 26 Apr 2018 12:47:58 +0200
Nicolas George wrote:
> Josh de Kock (2018-04-26):
> >It's also not impossible, nor irrational to be removing code which
> > doesn't fit or could be written better if an alternative is provided, the
> > need was never there or removal can otherwise be ju
On 2018/04/26 11:56, Nicolas George wrote:
Josh de Kock (2018-04-26):
Generally, adding more things to public API is a bad move
I do not accept this statement as is. Please justify it.
What I mean by this is making private fields public is generally a bad
move. They were initially made pri
Josh de Kock (2018-04-26):
> Generally, adding more things to public API is a bad move
I do not accept this statement as is. Please justify it.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
f
On 2018/04/24 22:33, Stephan Holljes wrote:
Hi all,
I've discussed this on IRC a bit, but I don't want to exclude those
views that are not present there.
The consensus seems to be that there are more disadvantages in using
the http server of libavformat than there are advantages.
I honestly t
Josh de Kock (2018-04-26):
> It's also not impossible, nor irrational to be removing code which
> doesn't fit or could be written better if an alternative is provided, the
> need was never there or removal can otherwise be justified.
Then justify. But you will need to address all the argu
On 2018/04/25 23:18, Nicolas George wrote:
Josh de Kock (2018-04-25):
If anything, this should have never been added and a suitable
external library should have been picked.
This opinion should have been expressed three years ago. It was decided
then that lavf deserved a HTTP ser
Kieran Kunhya (2018-04-25):
> It was objected heavily to at the time
And eventually a decision was made. This is one of the problems of this
project: developers pulling in every direction without consistency nor
leadership. One step forward, two steps on the side, one step backward;
iterate.
>
On Tue, Apr 24, 2018 at 11:33:53PM +0200, Stephan Holljes wrote:
> Hi all,
>
> I've discussed this on IRC a bit, but I don't want to exclude those
> views that are not present there.
>
> The consensus seems to be that there are more disadvantages in using
> the http server of libavformat than the
On Wed, 25 Apr 2018 at 23:18 Nicolas George wrote:
> Josh de Kock (2018-04-25):
> > If anything, this should have never been added and a suitable
> > external library should have been picked.
>
> This opinion should have been expressed three years ago. It was decided
> then that lavf
Josh de Kock (2018-04-25):
> If anything, this should have never been added and a suitable
> external library should have been picked.
This opinion should have been expressed three years ago. It was decided
then that lavf deserved a HTTP server. It is done.
Regards,
--
Nicolas Geo
On 2018/04/24 22:46, Nicolas George wrote:
Stephan Holljes (2018-04-24):
The consensus seems to be that there are more disadvantages in using
the http server of libavformat than there are advantages.
I completely disagree. There is no point in having the HTTP server in
libavformat if it cannot
On Tue, 24 Apr 2018 23:46:09 +0200
Nicolas George wrote:
> Stephan Holljes (2018-04-24):
> > The consensus seems to be that there are more disadvantages in using
> > the http server of libavformat than there are advantages.
>
> I completely disagree. There is no point in having the HTTP server
Thank you for your replies so far.
On Tue, Apr 24, 2018 at 11:46 PM, Nicolas George wrote:
> Stephan Holljes (2018-04-24):
>> The consensus seems to be that there are more disadvantages in using
>> the http server of libavformat than there are advantages.
>
> I completely disagree. There is no po
On 24 April 2018 at 22:33, Stephan Holljes wrote:
> Hi all,
>
> I've discussed this on IRC a bit, but I don't want to exclude those
> views that are not present there.
>
> The consensus seems to be that there are more disadvantages in using
> the http server of libavformat than there are advantag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I'm not an ffmpeg developer, but I do have experience in software
engineering and ddesign.
On 2018-04-24 17:33, Stephan Holljes wrote:
> This arose partly out of the discussion that there is no way to get
> a connected peer's address through the pub
Stephan Holljes (2018-04-24):
> The consensus seems to be that there are more disadvantages in using
> the http server of libavformat than there are advantages.
I completely disagree. There is no point in having the HTTP server in
libavformat if it cannot be used to implement exactly that kind of
20 matches
Mail list logo
