James Almer (12023-04-28): > The longtime goal of this work is to have completely standalone modules > within the CLI and each of them threaded. So while ffmpeg may not be a > library, clearly defining what fields should be accessed from "the outside" > and which shouldn't would have the same effect and benefits as if it was > one, particularly ensuring no future accidental usage of fields that should > not be touched. The decoder side for example has no need to touch a frame > the filtering side is using internally, and more so if it could result in > races. > > There's also the fact Anton is maintaining this code and this helps him keep > track of the nature of each field, plus the fact this same change has been > done before elsewhere, so if you're going to argue you don't like it because > in your opinion it's unnecessary, then that's not enough grounds to block > it.
(As Anton repeatedly said he does not accept the usefulness of the role of maintainer, invoking that last argument feels a little like trying to have it both ways. But since I do acknowledge the usefulness of maintainers, I do accept it.) Thanks. This is slightly more convincing than what was explained until now. But there are ways of clearly stating which fields are internal and which fields are ok for outside access without littering the code with casts, because fgp_from_fg() and co. are exactly that. And during the work of turning all into threads, opportunities to split the structure in more logical ways with less code noise will almost certainly present themselves. Anyway, I find it sad that in the recent years FFmpeg has more and more followed “good practices” not because, being good, they bring actual benefit to the code but just because they're “good practices”. We are not underskilled Java developers following the rules from the textbook without understanding their purpose; we are FFmpeg, we try new and original ways of writing code to make it more efficient and more elegant. FilterGraphPriv is neither efficient nor elegant. But if I failed to convince you or others with this mail, I will not fight this anymore. Regards, -- 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".
