Help with TV capture (mplayer/brooktree/audigy)
jakemsr at jakemsr.com
Mon Apr 25 00:50:21 PDT 2005
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
> 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
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 at jakemsr.com>
More information about the freebsd-multimedia