On Thu, 13 Jun 2024 at 04:14, Paul B Mahol <one...@gmail.com> wrote: > > On Wed, Jun 12, 2024 at 9:52 PM Stefano Sabatini <stefa...@gmail.com> wrote: > > > On date Tuesday 2024-06-11 21:13:48 +0800, Shiqi Zhu wrote: > > > On Fri, 7 Jun 2024 at 19:55, Rémi Denis-Courmont <r...@remlab.net> > > wrote: > > > > Le 7 juin 2024 12:53:51 GMT+03:00, Michael Niedermayer < > > mich...@niedermayer.cc> a écrit : > > > > >We can require anything from an API that we are able to change and > > extend > > > > >Of course we can decide not to allow such requirment even if optional > > > > >but we surely _could_ add such a feature if we choose to do so > > > > > > > > Sure. You can also require infinite memory or an oracle be provided. > > That's just not going to happen though. And having libraries depend on the > > main thread is a well-documented malpractice. > > > > > > > > I don't think we should add maintenance burden with code that can't be > > used safely. > > > > > > Thank you all for your attention to this patch; I greatly appreciate it. > > > > > > I'd like to provide a brief recap of the issue we've been discussing, > > > with the following points: > > > > > > 1. Addition of sink type in the filter: > > > This enhancement is primarily based on the existing avfilter mechanism > > > and serves as a strengthening module. Using SDL as the sink doesn't > > > seem to be a good fit, as I'll attempt to rectify in the following > > > patch. > > > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240611130310.1131755-1-hiccup...@gmail.com/ > > > > > > 2. Utilizing SDL as an implementation for the sink: > > > Before submitting the patch, I hadn't considered many aspects. During > > > the intense discussions, I retested the patch on different operating > > > systems, with the following results, hoping it may assist those > > > interested in this issue: > > > > > > Command: ./ffmpeg -lavfi > > > "testsrc2=size=300x200:rate=25:duration=500,format=yuv420p,sdlvsink" > > > -f null /dev/null > > > > In addition to this, I wonder if adding a vsink for each different > > output device is the correct way. > > > > We have a movie source which can be used to read from > > libavformat/libavdevice, probablhy we should have a movie sink to be > > used to write to libavformat/libavdevice, meaning that a single sink > > would enable access to all the supported libavformat/libavdevice > > outputs. > > > > I started having a look in that direction a looot of time ago. This > > was never finalized because I was not sure about ways to pass options > > to encoders and muxers, and about dealing with a variable number of > > outputs, I'm attaching this very old proof-of-concept patch for > > reference. > > > > This approach would be possibly much more complex, but should provide > > a single bridge in place of having a different sink for every output > > device or muxer. > > > > > Pointless as real plan is to get rid of immature libavdevice API. > > Using the libavdevice API can be somewhat confusing, especially regarding concepts like mux and demux.
> > > > _______________________________________________ > > 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". > > > _______________________________________________ > 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". _______________________________________________ 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".
