On Mon, Dec 06, 2021 at 02:42:58PM +0100, Nicolas George wrote: > Hendrik Leppkes (12021-12-06): > > You just keep re-iterating that avfilter internals need it. And I'll > > just keep saying that avfilter internals shall not define public API > > design. I have not heard anything that justifies yet another field > > that has no benefit to the external public API - to the contrary even, > > a user would assume pts is pts, and he would be wrong. > > Thank you. > > I need to add that libavfilter internals need it only because it was > designed in a very naive way, by duplicating the frame instead of using > dummy frames without content. > > This is not the only part of these patch series that are improperly > designed.
> Having two different filters to overlay subs depending on > whether they are text or bitmap is unacceptable. i do agree that is inconvenient i would not call it unacceptable > Not having any utility > filters (to shift or scale the times, to discard a segment, tu > concatenate subtitles along with audio and video, to print diagnostic > information, etc.) is also a big issue i agree too [...] > Now, if I knew I had the support of the core developers here, I could > serenely get on with implementing FATE tests for the negotiation system > and refactor it, which is the necessary first step before extending it > for a third media type. Anyone who does that without triggering hostilities and (either works together with other developers OR finds any other solution all involved are happy with) has my support. But i am a bit scared of more fights, hostilities between 2 cooks trying to cook one soup. And myself having more headaches from reading more escalating threads. Basically i dont want to end up hiding depressed in a corner after some quite hard headed developers fail to treat each other respectfully and cooperate. Also judging from your question here i guess that you have time and want to work on FFmpeg ? If you rather want to work on something else within FFmpeg. I have both easy and hard things that need to be done Easy one, fix ssl support on fate.ffmpeg.org (that is setup letsencrypt) Hard one, can low latency support to libavfilter be improved? consider a use case like realtime streaming, cloud gaming or some cloud based metaverse any filtering done for these would benefit from really low latency. Because the end user interacts with the remote and so any filtering done adds top the latency of this loop Is libavfilter optimal for this usecase ? would some different threading be better, or maybe some information exchange between filters about which lines from the previous filter are already available to the next to process thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
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".
