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 wrote: > > Le 7 juin 2024 12:53:51 GMT+03:00, Michael Niedermayer 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-hiccupzhu@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.