Date: Fri, 11 Jul 2003 07:09:16 +0200 From: Steve O'Hara-Smith <steve@sohara.org> To: John-Mark Gurney <gurney_j@efn.org> Cc: multimedia@freebsd.org Subject: Re: BSD video capture emulation question Message-ID: <20030711070916.5320dd5c.steve@sohara.org> In-Reply-To: <20030710204047.GC35337@funkthat.com> References: <7192223.1057850975979.JavaMail.nobody@kermit.psp.pas.earthlink.net> <20030710191329.GB44762@funkthat.com> <20030710222923.0ece3692.steve@sohara.org> <20030710204047.GC35337@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Jul 2003 13:40:47 -0700
John-Mark Gurney <gurney_j@efn.org> wrote:
JMG> Yes, I followed the bktr interface, but the bktr interface needs to
JMG> disappear ASAP! The bktr interface is very bad as we make FreeBSD
JMG> multiplatform. It lets the user supply the physical address when
JMG> doing video overlay to the video card. This should be handled by the
JMG> driver, not the userland app.
Hmm, that implies that the driver must know how to find the
overlay area that the userland app wants it to use - irrespective of the
video out driver in use.
Conclusion the overlay areas have to be entities of some kind in
the in the multimedia infrastructure.
JMG> > AFAICS what's needed is someone with some insight into what makes
JMG> > a good video API if FreeBSD is ever going to get one. The innards
JMG> > of things like ffmpeg and transcode are probably worth looking at
JMG> > as models.
JMG>
JMG> Hmmm. I'll have to look at that.
JMG>
JMG> But there is more than just codec handling. One of the features that
Oh sure - but seamless plumbing of codecs, sources and sinks is
a very desirable feature IMHO. This is the bit that these apps seem to
manage.
JMG> the Zoran card supports is the ability to have two sources (since as
JMG> external video and MJPEG playback) one in a window of the other. But
JMG> you need to only have one video clock running the output. This
JMG> should be handled by the video api so the drivers just write the raw
JMG> interface and the api does the manipulation of the driver.
Yep seamless plumbing - so somehow the PIP has to present as a video
sink and DTRT when you plumb the other video source into it - even if that
turns out to be the output of mplayer playing a VCD and not the expected
other bit from the card. If it can't do it the plumbing must fail.
ISTM the plumbing actions either require a smart plumber or a
dialogue between the interfaces being plumbed. The latter seems to fit
the UNIX device model better.
Are thinking in similar terms ?
--
C:>WIN | Directable Mirrors
The computer obeys and wins. |A Better Way To Focus The Sun
You lose and Bill collects. | licenses available - see:
| http://www.sohara.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030711070916.5320dd5c.steve>