From owner-freebsd-multimedia@FreeBSD.ORG Fri Apr 28 02:30:58 2006 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org 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 9D42B16A400 for ; Fri, 28 Apr 2006 02:30:58 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 262E243D46 for ; Fri, 28 Apr 2006 02:30:58 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (k4b9ervugkpdh8lu@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.4/8.13.3) with ESMTP id k3S2Uqsh049213; Thu, 27 Apr 2006 19:30:52 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.4/8.13.3/Submit) id k3S2UpdO049212; Thu, 27 Apr 2006 19:30:51 -0700 (PDT) (envelope-from jmg) Date: Thu, 27 Apr 2006 19:30:51 -0700 From: John-Mark Gurney To: Danny Pansters Message-ID: <20060428023051.GO728@funkthat.com> Mail-Followup-To: Danny Pansters , Torfinn Ingolfsen , freebsd-multimedia@freebsd.org References: <20060427182528.35070.qmail@exxodus.fedaykin.here> <20060427205905.9ab1500f.torfinn.ingolfsen@broadpark.no> <20060427201316.GJ728@funkthat.com> <200604280156.07996.danny@ricin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604280156.07996.danny@ricin.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-multimedia@freebsd.org Subject: Re: FreeBSD Multimedia API and Google SOC2006 X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 02:30:58 -0000 Danny Pansters wrote this message on Fri, Apr 28, 2006 at 01:56 +0200: > On Thursday 27 April 2006 22:13, John-Mark Gurney wrote: > > Personally the V4Lx API's are at the wrong level for how far computers > > have advanaced... Any video api should be a userland library, that > > provides access to it... and not a kernel interface that is of > > limited use... This has the advantage that updates for new tuners and > > other stuff can happen easier and quicker... and more people are willing > > to touch the code... > > Yes. See also the saa code at purpe.com (for Philips SAA based TV boards) Yeh, I haven't looked at the code yet... > > My bktrau driver for the DViCO FusionHDTV5 Lite has a minimal kernel > > presence... the userland capture program uses the GPIO defines in bktr, > > the iic device driver for controlling the tuner and demodulator to > > control the capture.. This means my driver is under 1k lines of code.. > > iic is good. But still, considering the bktr legacy, it would still require The bktr legacy should be shot.. it's a terible interface, it isn't cross platform compatible, and should never EVER be used again... The specific interface that I'm talking about is that userland provides a physical address for video overlay... The userland should NEVER have to deal with physical bus addresses, and it ensure that it will never work on other arches like sparc64 where getting a physical address is a little more difficult... > something like v4l to tie together common functionality that's implemented > per-driver. Still, common iic routines that are wrapped into such a V4B > interface could benifit both the v4b umbrella driver as well as ease a driver > developer's job as well as ease an end user programmer's job (they may all be > the same person of course). nah, v4l (an ioctl interface) is too low level... > > > If there is need for a mechanism (sp?) to distinguish which API a > > > certain device can be operated with, an easy way would be to use a > > > naming convention. Example: /dev/video0 - use the V4L > > > API, /dev/bsdvideo0 - use the V4B API. Most likely, somebody else has a > > > better suggestion. > > There's probably going to be things that go in between of whatever you think > up anyway (if any appear at all. It's good to see drivers and multimedia > initiatives popping up lately, it's been silent too long). Yeh, though vendor support is still week... DViCO keeps saying they'll get me some more docs on the demodulator, but still hasn't gotten anything to me... > The bsdpwc (Phillips and logitec USB webcam) driver is based on the linux one > (it has a simple read() interface on the video0 device, which is implemented > as a V4L device but it has extra functions added (for example to pan and tilt > the camera). > > > I'd suggest NOT to use a kernel interface.. they are expensive to > > maintain, and harder to shoehorn things like USB web cams into... > > The more user space the better. And the more simple read() can be used the > better as well (it's 2006 not 1996). It just makes it much easier to grab and read() is a complicated interface to handle unless the card has an on board memory buffer... the bt848 and bt878 cards cannot easily handle a read interface w/o requiring large amounts of staticly allocated memory and an extra copy... read()'s biggest problem is the lack of multiple buffers... It'd be interesting to use writev to preload the next buffer, but of course, many programs you'd normally want to use (cat and dd) would need to be modified, which ruins the point of the read() interface... > work with the data and use individual frames. But a common interface will > have to take the form of a bunch of ioctls or be in a completely higher level > API altogether maybe, and then I'm thinking python or ruby for which common > functions can be easily put into different GUIs. Multimedia apps should be > expected to end up in a GUI in most cases and a common API should be made > with that in mind as well. This is what stalled my VideoBSD api work... writing all the necessary glue in C really sucks, and doing ioctl frameworks is complicated and a good way to have buggy code and kernel crashes... If I could write it in Python (and know that everyone would use it), I'd of completed the work.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."