From owner-freebsd-multimedia@FreeBSD.ORG Sat Apr 23 22:03:45 2005 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 CBDE216A4DB for ; Sat, 23 Apr 2005 22:03:45 +0000 (GMT) Received: from mail231.csoft.net (resin.csoft.net [63.111.22.86]) by mx1.FreeBSD.org (Postfix) with SMTP id D61DD43D1F for ; Sat, 23 Apr 2005 22:03:44 +0000 (GMT) (envelope-from jakemsr@jakemsr.com) Received: (qmail 24096 invoked from network); 23 Apr 2005 22:09:33 -0000 Received: from unknown (HELO puff.jakemsr.gom) (63.111.27.87) by mail231.csoft.net with SMTP; 23 Apr 2005 22:09:33 -0000 Received: (from jakemsr@jakemsr.com) by puff.jakemsr.gom (mini_sendmail/1.3.5 16nov2003); Sat, 23 Apr 2005 15:03:41 PDT (sender jakemsr@puff.jakemsr.gom) Date: Sat, 23 Apr 2005 15:03:41 -0700 From: Jacob Meuser To: FreeBSD-multimedia@freebsd.org Message-ID: <20050423220341.GC28367@puff.jakemsr.gom> Mail-Followup-To: FreeBSD-multimedia@freebsd.org References: <20050423063848.67278.qmail@exxodus.fedaykin.here> <20050423085656.77398.qmail@web41208.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050423085656.77398.qmail@web41208.mail.yahoo.com> User-Agent: Mutt/1.4.2i Subject: Re: Help with TV capture (mplayer/brooktree/audigy) X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2005 22:03:45 -0000 On Sat, Apr 23, 2005 at 01:56:56AM -0700, Arne Wörner wrote: > --- Mario Sergio Fujikawa Ferreira wrote: > > > > > > 2) Every few seconds the video > > > > > > stream seems to choke; thus, > > > > > > giving me an effect similar > > > > > > to the famous interlaced > > > > > > "blinders effect" so I added a > > > > > > deinterlacer filter > > > > > > > > > > Sync detection problems perhaps. > > > > Is there anything I can do to improve that? Perhaps, > > a harder filter looking for those? I fear that such harder > > filtering will just decrease performance; thus, increasing > > the choking effect. > > > > Bear in mind that I do not mind 100% CPU occupancy for as > > long as, I can get good quality TV capture with good audio. :) > > > I mentioned, that the bktr does not issue a signal for every > expected frame. So I use my own code, that becomes impatient, when I do not notice this with the cards I use too often. my code (as well as fxtv and xawtv) uses METEORSSIGNAL, and I get all the expected frames. the only hitch is that it seems every once in a while, it seems bktr spits out 2 signals for one frame. I wouldn't be surprised if the RISC commands in bktr could be improved some though. that's what puts the two fields together into a frame. > the next frame is due, so that it just takes it (I use this old > mmap access method). I think, that way I get at least the right > frame rate and possibly even the right frame (maybe the signal > gets lost or so...). bktr comes pretty close to 30000/1001 FPS for NTSC capture. actually it seems to be just a tiny bit fast, but I believe this also has to do with the signal it's receiving, as some stations behave slightly differently. I don't have any experience with PAL. IMO the best thing to would would be to use some kind of ring buffer. grab all frames that come in at whatever time and output them at the right rate. drop frames when the buffer is too full and clone them if the buffer is too low. hopefully the dropping/ cloning is minimal, or simply stop if the buffer is too full/low. Now, I may be partial, but I get the best quality captures with transcode CVS: transcode -i /dev/bktr0 -y ffmpeg,null -F mpeg2 --encode_fields b \ -J hqdn3d=pre,pp=de -o out nb: --encode_fields b is for ntsc "bottom first" fields. it would be nice if someone wrote an OSS import module for transcode. --