From owner-freebsd-multimedia@FreeBSD.ORG Mon Jul 14 09:56:40 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 8F99937B401 for ; Mon, 14 Jul 2003 09:56:40 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BFB743F85 for ; Mon, 14 Jul 2003 09:56:39 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h6EHMccU027630; Mon, 14 Jul 2003 13:22:39 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h6EGteXd014286; Mon, 14 Jul 2003 09:55:40 -0700 (PDT) (envelope-from jmg) Date: Mon, 14 Jul 2003 09:55:40 -0700 From: John-Mark Gurney To: Andrew Gordon Message-ID: <20030714165540.GU35337@funkthat.com> Mail-Followup-To: Andrew Gordon , multimedia@freebsd.org References: <20030714064137.GT35337@funkthat.com> <20030714152113.O81987-100000@server.arg.sj.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030714152113.O81987-100000@server.arg.sj.co.uk> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE 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: multimedia@freebsd.org Subject: Re: AW: BSD video capture emulation question X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.1 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: Mon, 14 Jul 2003 16:56:40 -0000 Andrew Gordon wrote this message on Mon, Jul 14, 2003 at 16:29 +0100: > > On Sun, 13 Jul 2003, John-Mark Gurney wrote: > > > > If the mbuf code seperated it out, this MIGHT be a possibility, I'm > > pretty sure we don't want to run into some of the problem with resource > > contention on mbufs.. Also, the buffer space may need more fine > > management... The idea of a sink sending a packet that a source fills > > also is kinda wierd (necessary for some dma operations).. > > There seems to be some lack of clarity in these discussions about what > level of API you are trying to create. There's at least two > possibilities: > > a) The low-level API for shifting bulk data and timing information > between hardware devices and/or processing modules. Here the > device drivers and encoders/decoders are the providers and consumers > of the API, and we're inevitably talking about a kernel interface. > > b) A higher level API to control the 'plumbing'. Here, user-interface > programs are the consumer of the API, with the details of the > bulk transfer mechanisms being hidden below the API. [...] > Then there's your stated aim that things like USB videocams shouldn't have > to be implemented with all the logic in the kernel (an aim I agree with > BTW). So, you end up with several different APIs for the core data > transfer, with scope for a unifying higher-layer API on top. But it's a > lot of work.... Thank you for clarifing this for everyone. Yes, I plan to try to address both a and b of above. Right now my priority is a since that will get most hardware available, but b is necessary in order to properly and fully support userland devices. B is also necessary because I plan to implement a in such a way that programmers will kill me if b doesn't come around. The reason I say this is that the hardware interface will probably have five different fd's for a card like an MJPEG card. Remebering what ioctl's for what fd is to be simplifed by b. I have recently changed the verbage of: http://people.freebsd.org/~jmg/videobsd.html to make this more clear. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."