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>