From owner-freebsd-multimedia@FreeBSD.ORG Thu Dec 4 13:18:25 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 D712416A4CE for ; Thu, 4 Dec 2003 13:18:25 -0800 (PST) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F2D843FDF for ; Thu, 4 Dec 2003 13:18:24 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 16445 invoked from network); 4 Dec 2003 21:18:23 -0000 Received: from unknown (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Dec 2003 21:18:23 -0000 Received: from hydrogen.funkthat.com (efezkl@localhost.funkthat.com [127.0.0.1])hB4LIMgP090459; Thu, 4 Dec 2003 13:18:23 -0800 (PST) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id hB4LIMhB090458; Thu, 4 Dec 2003 13:18:22 -0800 (PST) Date: Thu, 4 Dec 2003 13:18:22 -0800 From: John-Mark Gurney To: Andrew Gordon Message-ID: <20031204211821.GJ54398@funkthat.com> Mail-Followup-To: Andrew Gordon , multimedia@freebsd.org References: <200312030524.hB35OpJ28562@jwlab.FEITH.COM> <20031203175701.GA54398@funkthat.com> <20031204002502.X49643@server.arg.sj.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031204002502.X49643@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: Hauppauge PVR-250 / 350 Driver 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: Thu, 04 Dec 2003 21:18:26 -0000 Andrew Gordon wrote this message on Thu, Dec 04, 2003 at 00:37 +0000: > > > This isn't really the case for the PVR-250 / 350. The MPEG program > > > stream from the card contains both sound and video. > > > > Yeh, And I did say most.. :) I was thinking that if the card does > > something special with sound, like integrate it into a codec stream, > > then the sound capture could/should? be set as a parameter of that > > device that does the integration... Because I assume that the card > > can only captuer sound as part of the mpeg codec stream? (going to > > check the specs). > > > > Do people think that sound should be brought under it's umbrela? > > I don't want to delay it too much by expanding the scope.. Just getting > > video is going to be difficult enough.. > > Well, some means of supporting sound alongside video is certainly > required: if the API doesn't handle sound explicitly, then it needs to > convey the necessary timing information so that the sound can be handled > via separate APIs without losing synchronisation. Well, if the sound is completely encoded in the codec stream, then videobus would not know about it... I do plan on doing kernel side timestamp tagging of frames so that the upper layers will be able to get this info. The only problem with this is that the timestamps may not agree with the sound card unless the soundcard/code also does time stamping since the local clock could run (and often do) at different rates than the sound sampling code... > For many kinds of device, all you need is to report the delay through the > device (and it's associated driver buffering). However, some kinds of > device don't have constant delay and timestamps are required. Devices > such as the MPEG capture card mentioned earlier are a problem to fit into > such a scheme, as although the video will come out nicely timestamped (and > the audio likewise), there may not be a means to relate those timestamps > to real-time (ie. you can achieve A/V-sync between A and V streams > captured on the card as designed, but it's hard to synchronize with sound > captured on a standard sound-card at the same time, for example). Yeh, It's a sticky problem that I don't want to completely ignore it, but from my point of view, about the only thing I can do is to timestamp against the local clock, anymore requires significant fingers in each subsystem's pie to be doable... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."