On date Tuesday 2016-11-01 02:45:00 -0300, James Almer encoded: > On 10/31/2016 3:30 PM, Nicolas George wrote: > > Le decadi 10 brumaire, an CCXXV, James Almer a écrit : [...] > > * What benefits do you see for the separate tool approach? > > > > * Can you negate any of these drawbacks? > > I'll repeat what i said. This is not a technical discussion. This is a > design issue. For your very specific debugging needs and scenario, you > devised a way to dump media streams into a text file and declared said > dumps a multimedia "format" so they may qualify for a demuxer. > Libavformat is not a dumping ground for code molded by a single person's > specific needs, and it is not a library meant to hold your or anyone's > debug tools. > > At least three developers have stated being against the implementation > of such an arbitrary custom format, and as much as you want to cover your > ears, declare it's all "duplicate arguments" in order to downplay and > discard their opinions, and decree that no matter how many people are > against something from a design PoV the only thing that matters are > technical arguments limited to the realm of how to implement the solution > for the very specific scenario you're presenting, if more people are > against it than in favor then it should not go in, or a vote should be > called. >
> And why not just keep it in a separate repo for that matter? Why does it > need to be committed to the main repo? It depends. If implemented as a libavformat component, it's impossible to publish it in a separate repository. If implemented as a standalone tool that would be possible, but still would require to duplicate the FFmpeg infrastructure (mostly the configure/build system). For my first use case (injecting data streams) it would be much easier to write a custom tool. I was asked to integrate this into FFmpeg to avoid the conversion step (custom format => standard format), and while doing this I was suggested to use the more general ffprobe format, which although not a real format was something which was already used internally by the project. Talking about conversion tools (say it ffprobe-dump and ffprobe-undump), I wonder how they would work. I expect something as: ffprobe-dump IN > OUT.ffprobe (this could also be a modified version of ffprobe, probably with some custom options). Now you need to import the file (possibly after you edit it). The problem here is that you need to convert it to another internally supported format, using libavformat. That's when it becomes inconvenient, because you basically need to use the library to convert the format (see the arguments by Nicolas and Michael). > You talk about maintenance, yet keeping it in a separate repository would > mean as much maintenance for you as it would in the main repository. I see the validity of the arguments for not integrating this into FFmpeg, yet (sorry for repeating), there are also valid arguments in favor of the integration, that's why I proposed a vote since I think that technical arguments cannot resolve the decision alone, since it also involves design and policy (which depend on how each every developer conceives the project, which is somehow subjective). -- FFmpeg = Foolish & Faithless Mortal Proud Ermetic Gigant _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
