Soft Works (12021-08-19): > No, I don’t think this would be ridiculous. I just wasn't sure how far > I should go with the initial patchset. I also had an scopy filter > that I had removed before submitting because it wasn't needed from > a proof-of-concept perspective.
Well, it is already ridiculous, and more importantly annoying for both users and developers to have all the utility filters duplicated for both media types, it would be even worse to have them triplicated. So I will state it plain an clearly: I consider that negotiating the media type is an absolute prerequisite for any project of adding support for more media types in libavfilter. This is not that hard to do. As I pointed, I already started working on it. It would have gone faster if there were other people interesting in, reviewing the code trustfully and offering useful suggestions. > I'm not sure what you mean exactly, probably I should take a look > at your code that you mentioned. That would be a good idea for the sake of the discussion. > We already have AVSubtitle which is understood by encoders and decoders, > so I see no reason to convert this back and forth to something different > just for carrying around by AVFrame. There have been extensibility issues raised against AVSubtitle, and in particular AVSubtitleRect. Reworking this API has been considered necessary for a long time. > I need a solution and the discussion last year ended up nowhere after > discussing some freaky details about which I (and probably most others) > don't care at all. > From that experience I wanted to avoid this to happen again. Not taking into consideration what was already said on a subject is really not a good way of making the discussion progress. Every once in a while, we have somebody arrive with a series of patch and make a tantrum "but my code works and I want MY feature NOW!" without consideration for users who may want to use the feature a little differently or the developers who will have to keep that feature alive continue developing FFmpeg around it. I hope you do not intend to be that guy. Extending FFmpeg, especially for a feature that central, requires looking at the big picture, and looking at the big picture requires having spent time maintaining code, developing different features and interacting with users. > I don't think that my patchset is going a totally wrong way, even though > some things might need adjustment, but it is clearly just a step and > not arrival at a finish line. Even if it not going in "a totally wrong way", since what you are doing is part of the public API, any mistake made now will bug us for a very long time. Therefore I insist we are extra careful not to make mistakes. > The primary motivation for submitting this right away as is, is to > avoid this do be discussed to death once again and make a step that > > - doesn't break anything > - allows things to work that haven't been possible before - is part of the public API - makes it harder to maintain libavfilter "But my code works and I want MY feature in NOW. (And I won't be around long enough to have to maintain it anyway.)" Please do not be that guy. I am very happy if somebody wants to seriously work on subtitles in libavfilter, but seriously is an important word here. If it was as easy as slapping a few pieces of code around like you did, I would already have done it years ago. The first step in libavfilter is to refactor the negotiation to make the media type negotiated. It is already started. -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
