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

[Michael Niedermayer]

On Sun, Dec 26, 2010 at 11:01:56PM +0100, Aurelien Jacobs wrote:
> 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.

libavdevice is part of the (de)muxer layer, you cannot implement libvo in there
without considerable unneeded complexity. Passing slices direct rendering and
all this from filters over codecs into muxers is just not sane
and putting libavfilters in libavdevice is a nightmare of unrelated code in one
lib.
and changing libavdevice to something else isnt happening (iam not seeing
patches iam not seeing commits and it would reposition libavdevice in the
dependancy chain which is a mess to do in more than 1 commit
besides we do not know if it is even possible to implement its functionality
elsewhere)



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

Whatever people like but there is no relation to libvo which belongs close
to libavfilters API and not close to the demuxer API and theres no reason to
tie libvo work to a idea of a redesign of libavdevice


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

use dlopen()

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101227/19d5dc36/attachment.pgp>