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

[Shiqi Zhu]

On Thu, 13 Jun 2024 at 04:14, Paul B Mahol <onemda at gmail.com> wrote:
>
> On Wed, Jun 12, 2024 at 9:52 PM Stefano Sabatini <stefasab at 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 at remlab.net>
> > wrote:
> > > > Le 7 juin 2024 12:53:51 GMT+03:00, Michael Niedermayer <
> > michael at 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.
>
>
Using the libavdevice API can be somewhat confusing, especially
regarding concepts like mux and demux.

> >
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> >
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".