[MPlayer-dev-eng] video pipes
attila
attila at pai.kinali.ch
Sun Jul 18 10:32:57 CEST 2004
Guette Tag :)
On Tue, Mar 23, 2004 at 12:03:42AM +0100, Thomas Comiotto wrote:
> I'm trying to put together a small video broadcasting solution with mplayer as
> playlist-based player and pdp as realtime video mixing component. Therefore I
> need a way to pipe a/v from mplayer to pd. I am well aware that currently
> there's no standardized solution to this problem (except of the
> vloopback-hack or buying one capture card per channel and routing a/v via
> hardware ports - unfortunately I can't afford that) but nevertheless I need
> to come up with a solution. Before I start hacking on an output filter that
> fits my needs I wanted to ask you to run your checks on what I possibly would
> come up with - maybe there's a solution that I didn't think about yet or what
> I plan to do is just plain bullshit, you never know...
Hmm.. i think you are a candidate for -vo shm. Unfortunately this
vo module wasn't yet approved and is thus not in the cvs.
Please check the archives of -dev-eng (it was send before march,
february or january iirc)
I'll bug Alex to check it and commit it.
> Disclaimer: I am _very_ new to video programming, but basically have rather
> decent programming skills.
Video programming isnt that much different from normal stuff, you
just need to be very carefull what you do with your video data
as every memcpy is a huge waste of cpu time. Also using YUV 4:2:0
or 4:2:2 instead of RGB (which is by definition 4:4:4)
is a good thing [tm]
> Hacks (video):
> PDP can read raw video data from a FIFO pipe. Currently the supported formats
> are
> V12 yuv data : [type bitmap/yv12/320x240]
> rgb data : [type bitmap/rgb/320x240]
>
> I ran a quick test with mplayer's -vo yuv4mpeg filter and the named pipe
> approach sort of works, but besides a jittering audio channel because of
> having mplayer waiting for pdp to pull the last frame of the stack before
> pushing the next one to the stack I loose mplayer's seeking/transport
> functionality when using this -vo filter. Of course we still want to be able
> to do basic transport functions in the player. Is there a way of using
> multiple output filters simultanously, feeding a pipe in the background while
> still displaying an x-window and do seeking and the like?
No, current vo design disallows this (too many global variables)
and afaik also vf_vo (the interface from the vf change to vo) isnt
prepared to handle more than one output module.
Video chain splitting should be done at vf level anyways (IMHO).
Rich did start for G2 this work (see his vp design) but afaik the
whole G2 development stopped for now.
> What alternatives to the named pipe approach or possibly streaming locally via
> udp/rtp (too expensive) do I have? Does anyone of you have some deeper
> insights in what the status of exchanging video data between *nix apps is at
> the moment?
Maybe vls/vlc would be worth a look, they implement a server/client for
video streaming over a network (although i never tried it).
> Audio:
> There seems to be no jack output module for mplayer available. Is anyone
> working on that or would this also have to be done for piping the audio data
> to pd?
JACK is now supported.
> I hope someone can give me some hints on solving this one...
HTH
Sorry for the late answer
Attila Kinali
More information about the MPlayer-dev-eng
mailing list