Date: Sun, 22 Mar 1998 10:01:29 -0500 From: Randall Hopper <rhh@ct.picker.com> To: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br>, Amancio Hasty <hasty@rah.star-gate.com> Cc: multimedia@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Fxtv vs Stable Message-ID: <19980322100129.35396@ct.picker.com> In-Reply-To: <199803220221.NAA18775@godzilla.zeta.org.au>; from Bruce Evans on Sun, Mar 22, 1998 at 01:21:39PM %2B1100 References: <199803220221.NAA18775@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Joao Carlos Mendes Luis: |// /* If TDEC is on, may be a while before old trash gets written on */ |// if ( c->fps != c->fps_max ) |// memset( c->drv_buf, '\0', |// g.w * g.h * c->pix_geom_list[ c->pix_geom_idx ].Bpp ); | |Why do you need to clear the buffer ? I alluded to this in my last msg: |decimation is enabled. At that time, it clears out the driver buffer so |that you don't see a stale last frame from the last capture up until the |first frame of the requested capture finally comes along. "Fxtv" doesn't need to do it necessarily. It just needs to be done. Otherwise, the frame residing in the driver buffer for potentially up to a full second will be the one from the last capture, potentially minutes or hours old. A stale buffer is fine if app is processing the frame on interrupt, but when it knows there's no way it can keep up, having signals issues 30X/sec is pointless extra overhead just for bookkeeping the first frame. Better to just sample as fast as possible up to 30X/sec, and clear the buffer before starting. Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980322100129.35396>