On 12/5/2016 11:45 AM, Carl Eugen Hoyos wrote: > 2016-12-05 15:23 GMT+01:00 James Almer <jamr...@gmail.com>: >> On 12/5/2016 7:20 AM, Carl Eugen Hoyos wrote: >>> 2016-11-29 21:53 GMT+01:00 James Almer <jamr...@gmail.com>: >>>> On 11/29/2016 5:41 PM, Carl Eugen Hoyos wrote: >>>>> 2016-11-29 21:11 GMT+01:00 James Almer <jamr...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel