[FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[James Almer]

On 12/5/2016 11:45 AM, Carl Eugen Hoyos wrote:
> 2016-12-05 15:23 GMT+01:00 James Almer <jamrial at gmail.com>:
>> On 12/5/2016 7:20 AM, Carl Eugen Hoyos wrote:
>>> 2016-11-29 21:53 GMT+01:00 James Almer <jamrial at gmail.com>:
>>>> On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote:
>>>>> 2016-11-29 21:11 GMT+01:00 James Almer <jamrial at gmail.com>:
>>>
>>>>>> He's trying to override an announced project decision of removing a feature.
>>>>>
>>>>> We - obviously - announced it to find somebody who would fix the issues
>>>>> raised. If they are fixed, the "decision" is of course void, and we don't
>>>>> have to vote about it.
>>>>
>>>> That's not what was announced, at all. Please, read the news entry in question
>>>> and inform yourself in the subject before trying to participate in a discussion.
>>>
>>> That is exactly what I would like you to do.
>>> What else would have been the reason for the announcement?
>>
>> How about you actually *try* reading the news entry, instead of passing the
>> ball? You might just find out if you do it carefully and pay attention to
>> each sentence. Especially the part where it invites people to write a
>> replacement, and says nothing about voiding the decision if "issues are
>> fixed".
> 
> You misunderstand:
> I did not claim that the news entry says that the issues should be fixed,
> I wrote that the only reasonable base on which the entry was written is
> imo the search for somebody to fix the issues.

That's an odd interpretation of a news entry consisting on very few, very
clear paragraphs, and ending with a sentence that goes completely against
said interpretation.

> 
> Or are you arguing that ffserver should be removed because some
> developers don't like it?
> 
>>> I believe that it is absolutely unacceptable to remove a used feature of
>>> FFmpeg without a technical reason and I therefore believe that this
>>> vote does not make much sense.
>>
>> The technical reasons are there, described in the news entry you seem to
>> not want to read, or at least properly parse.
>> These past week however saw one developer working against the clock doing
>> what the actual people interested in ffserver should have done for the past
>> few months and even years. That is, he addressed most, but not all, of those
>> and other reasons.
> 
> Which reasons were not adressed?

<@wbs> I don't think it's still "fixed" in the sense that ffserver and ffmpeg can be built from differing major versions
<@wbs> since it sends literal enum values over the wire, and those enum values are free to be changed at any major bump 
<@wbs> and also, it doesn't even specify which major version it is talking about in the protocol
<@wbs> so api-wise it might be "fixed"; design wise, not yet
<+wm4> so my question would be does ffserver always use ffm for input/output, require it only for one of them, or is it completely optional?
<@wbs> wm4: afaik both ffmpeg and ffserver uses ffm, so if ffmpeg were to be able to communicate with ffserver, it needs an ffm demuxer/muxer as well
<@wbs> wm4: and it's all pretty backwards compare to most other protocols; if ffmpeg is to send data to ffserver, ffserver first tells it what codecs and encoder parameters to use, and then switches(?) communication direction to ffmpeg sending, ffserver receiving
<+wm4> huh
<@wbs> all of this is custom code in ffmpeg.c ofc
<+wm4> lol really?
<+wm4> so ffmpeg.c has explicit ffserver handling, outside of the ffm libavformat parts?
<@wbs> yes
<@wbs> see ffmpeg_opt.c, read_ffserver_streams etc
<@wbs> was the first I found with a quick grep
<+wm4> ah
<@wbs> so yes, it no longer uses deprecated api (avstream->avcodeccontext), but it still uses a bunch of networking internals from lavf, and the design is buried deep in ffmpeg
<+wm4> just looked at ffserver.c
<+wm4> #include "libavformat/avio_internal.h"
<+wm4> ...yeah
<+wm4> even #include "libavformat/internal.h"
<@wbs> and it uses a bunch of internal rtp/udp functions that don't fit in in the normal avio/urlprotocol api
<@wbs> so it's not "fixed" yet. one of the deprecated details in codecpar might be worked around

Also, the part about "confusing configuration file syntax", but i guess that
can be considered subjective.

> 
>> You and Nicolas sure love your historical revisionism.
> 
> I am sure you know that I was strongly against adding mailing list rules.
> But if you continue calling people names in this thread, I suggest you go
> elsewhere.

Saying you and Nicolas are ignoring events (or rewriting history) to support you
position on this subject is not name calling.

And i suggest you go hunt instead the people that actually called others names.
I pointed them to you in a previous email.