[FFmpeg-devel] [POC] SDL display lavfi sink

[Aurelien Jacobs]

On Sun, Dec 26, 2010 at 07:24:31PM +0100, Michael Niedermayer wrote:
> On Sun, Dec 26, 2010 at 06:50:09PM +0100, Aurelien Jacobs wrote:
> > On Sat, Dec 25, 2010 at 03:16:17AM +0100, Stefano Sabatini wrote:
> > > On date Friday 2010-12-03 19:03:46 +0100, Luca Barbato encoded:
> > > > On 12/1/10 6:50 PM, Stefano Sabatini wrote:
> > > > 
> > > > >Maybe someone can suggest a better widget library supporting multiple
> > > > >windows (or even better implement a corresponding sink).
> > > > 
> > > > You might use:
> > > > 
> > > > - X11 (a pain)
> > > > - XCB (different pain)
> > > > - Evas+Ecore (I'm thinking about adding a ffplay replacing it already)
> > > 
> > > Updated version, which avoids the SDL crash. Anyway since SDL only
> > > supports one window this can't work with ffplay (but can be used with
> > > ffmpeg, useful for checking how the transcoding is doing).
> > 
> > Having some SDL code in lavfi sounds pretty wrong to me.
> > I think it would fit better as a sdl "muxer" in libavdevice (the same
> > way we already have x11 and v4l "demuxer").
> > Then we could have a vsink_device which would use any available
> > video "muxer" from libavdevice.
> 
> it belongs to some sort of libvo

Well, I thought that's what libavdevice was supposed to be(come).
For now, libavdevice combines:
  libao
  libai (audio input)
  libvi (video input)
So it seems quite natural to add libvo features in there.

> and should be closer to libavfilter than the demuxer layer IMHO

I agree that the current mapping of libavdevice to the muxer/demuxer API
is probably not enough to have full featured audio and video input and
output. So at some point, libavdevice should probably be detached from
the libavformat API, and grow it's own API.

But anyway, inluding SDL output in libavfilter, and thus linking lavfi
to libSDL (and then libGL, libx11, libv4l, libasound, etc...) sounds
wrong to me. IIRC, it was the original reason to split libavdevice out
of libavformat.

Aurel