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

[Shiqi Zhu]

On Thu, 13 Jun 2024 at 03:52, 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.
>
Indeed, the mechanism of libavfilter is more robust, providing
essential mechanisms like format_query. These are crucial for
implementing media graph mechanisms (equivalent to DirectShow's graph
and GStreamer's pipeline concepts).

Therefore, gradually replacing libavdevice with sink-filter should be
a relatively gentle approach.

> 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.
>
I carefully reviewed your patch, and I currently have similar
functionality in my code. Here are my thoughts:

Using a filter as a bridge to connect to the avdevice allows for
setting the device type and basic information through parameters and
options.

However, the formats supported by devices are often variable. During
format negotiation, it's necessary to extend AV_APP_TO_DEV_xxx for
each device to implement queries for format, sampling rate, channels,
etc. This can be quite labor-intensive.

Using a filter as a sink can better address this issue.


> _______________________________________________
> 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".