Michael Niedermayer (HE12025-07-28): > About STF, it depends on who does the work. > If a FFmpeg developer does the work, then i think STF is a good idea. > OTOH It would be an inappropriate task for a new contributor (like in GSoC).
Indeed, way too hard for somebody who does not already know libavfilter very well. If perchance they do but for some reason never contributed, we cannot trust that they do. > One thing thats important for this is that whoever wants to work on this > speaks with Nicolas to make sure theres agreement on the implementation. Thanks. I had started to make the negotiation modular and extensible a few years back, that is when I realized what I now say an repeat: Any work on the format negotiation of libavfilter must start wit adding test coverage. Otherwise, the work is very likely to break specific cases that were fixed along the years. We talked about it a few weeks ago, I procrastinated answering: Adding test coverage is a boring but not difficult task, it can be done by a stranger motivated by a bounty. But I personally have absolutely no idea how to make it happen with the STF. In particular, I have absolutely no idea how much to offer. > My original plan was based on arbitrary graphs and a solution that could be > proofen to be within a constant factor of the global optimum. This would > have required simplifying the graph iteratively with a random seed multiple > times IIRC. But because a single pass "just worked" i never implemented this. I do not understand what you are talking about. Right now, the negotiation process does a loop, and it often requires a few passes to converge. There are two things missing: 1. If we want to add a new orthogonal category, copy-paste it is. 2. We have no way to negotiate dependant categories. Is it audio? let us negotiate the sample format and channel layout; is it video? let us negotiate the pixel format. Making the negotiation categories modular, with callbacks instead of hard-coded function calls, would make both relatively easy, and more importantly not a maintenance nightmare. Regards, -- Nicolas George _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
