Date: Mon, 25 Apr 2005 00:50:19 -0700 From: Jacob Meuser <jakemsr@jakemsr.com> To: freebsd-multimedia@freebsd.org Subject: Re: Help with TV capture (mplayer/brooktree/audigy) Message-ID: <20050425075019.GA1378@puff.jakemsr.gom> In-Reply-To: <20050425021058.48738.qmail@exxodus.fedaykin.here> References: <20050421021909.28497.qmail@exxodus.fedaykin.here> <20050421102551.12ebb916.steve@sohara.org> <20050421095950.GB3188@puff.jakemsr.gom> <20050425021058.48738.qmail@exxodus.fedaykin.here>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 24, 2005 at 11:10:36PM -0300, Mario Sergio Fujikawa Ferreira wrote: > On Thu, Apr 21, 2005 at 02:59:28AM -0700, Jacob Meuser wrote: > > On Thu, Apr 21, 2005 at 10:25:51AM +0100, Steve O'Hara-Smith 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. > > > > this can be tweaked a bit. > > > > look for SYNC_LEVEL in the driver. try ADC_CRUSH instead of ADC_SYNC_T. > > > > to me, it is a bit less interlaced looking. the linux bttv uses either > > ADC_CRUSH or 0 for this, BTW. > > I'm building a kernel right now with this modification to > > /usr/src/sys/dev/bktr/bktr_core.c > > Any other indications on what we could do INSIDE the driver > to make more reliable, some improvements at the signal handling...etc? compare the RISC routines to the bttv (linux) and btwincap (windows) drivers. there are some differences. for example, the chroma comb filter appears to be implemented a bit differently in bttv as compared to bktr. however, I don't have any specific suggestions; I really don't know much about RISC programming. > I am not advocating adding a ring buffer there since that > it is more appropriate for application level than kernel driver > interface. Though it is alwaays something to propose in both > FreeBSD-arch and FreeBSD-multimedia the original meteor(4) had one. there are definitions in ioctl_meteor.h for the interface. there's a kernel option to allocate memory for the buffers. but it doesn't exist. I agree though, that whether this belongs in kernel- or user-space is debatable. I would imaging Julian's plans will require some kind of bufferring, if for nothing but sync correction. > I am open for suggestions. Let me know if there are other > hacks you think would be helpful. I'll have to learn RISC first ;) -- <jakemsr@jakemsr.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050425075019.GA1378>