Re: [FFmpeg-devel] [PATCH] avfilter: add sdlvsink for video display

[Paul B Mahol <onemda@gmail.com>]

On Wed, Jun 12, 2024 at 9:52 PM Stefano Sabatini <stefasab@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 <remi@remlab.net>
> wrote:
> > > Le 7 juin 2024 12:53:51 GMT+03:00, Michael Niedermayer <
> michael@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-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.
>


Pointless as real plan is to get rid of immature libavdevice API.


>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".