From owner-freebsd-multimedia@FreeBSD.ORG Fri Jul 11 07:11:47 2003 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD39837B401 for ; Fri, 11 Jul 2003 07:11:47 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C21C43F3F for ; Fri, 11 Jul 2003 07:11:47 -0700 (PDT) (envelope-from welchsm@earthlink.net) Received: from kermit.psp.pas.earthlink.net ([207.217.78.241]) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19ayci-0001G9-00; Fri, 11 Jul 2003 07:11:44 -0700 Received: from [207.217.78.16] by EarthlinkWAM via HTTP; Fri Jul 11 07:11:44 PDT 2003 Message-ID: <4339238.1057932704927.JavaMail.nobody@kermit.psp.pas.earthlink.net> Date: Fri, 11 Jul 2003 07:11:42 -0500 (GMT) From: Sean Welch To: John-Mark Gurney , Steve O'Hara-Smith Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Web Access Mail version 3.0 cc: multimedia@freebsd.org Subject: Re: BSD video capture emulation question X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Sean_Welch@alum.wofford.org List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2003 14:11:48 -0000 I'm glad to see some serious discussion on this. That's a lot of acronyms -- anyone care to explain to me what IOMMU, PIP, DTRT, and ISTM are? And what is a video sink? John-Mark, could you clarify your concept of the kernel/ userland split for a new video API? More particularly, what parts would be handled by the kernel and how do you envision the userland interacting with that part? Are we talking about creating a new device node (a la v4l) or a new way of interacting with existing device nodes? Sean -------Original Message------- From: John-Mark Gurney Sent: 07/11/03 01:50 AM To: Steve O'Hara-Smith Subject: Re: BSD video capture emulation question > > Steve O'Hara-Smith wrote this message on Fri, Jul 11, 2003 at 07:09 +0200: > On Thu, 10 Jul 2003 13:40:47 -0700 > John-Mark Gurney 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. Actually, this is very easy. I was first using svgalib to write my overlay program which gave me a userland buffer but NOT a physical address.. it was easy to pass this buffer to the driver and have it do the right thing. This is more complex on sparc64 machines that don't do a direct physical to PCI mapping but have an IOMMU, since you need to know more about the machine. > Conclusion the overlay areas have to be entities of some kind in > the in the multimedia infrastructure. To a certain extent yes... but there is work underway to properly handle device to device dma.. > 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. Then let them manage that.. :) > 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. Ummm.. you are talking about something completely different. I'm talking about the hardware aspect of it, not the software aspect.. > 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 ? Nope, you are thinking of pure software, and I have been talking about pure hardware wrt to the windowing scheme mentioned above. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." >