Hi,
Here are the patches against xawtv-3.35. Be aware that this bit of hackery is
far from perfect: it causes the capture rate to be visibly jerky at times,
since the video capture thread is trying to sync to a time line that advances
in rather large steps, and is at the mercy of the system's scheduler. The
audio time line is just inherently jittery.
In fact, the more I think about it, the more I'm convinced that a
multithreaded capture architecture is simply a bad idea, and can't be made to
work reliably. A two thread design, with a realtime priority thread doing
video and audio capture, and a low priority thread doing the encoding, should
work much better. In my opinion, ffmpeg's capture code would be a good
starting point to get a decent video capture app up and running with minimum
hacking.
Anyway, there are two patches - for some reason, the only way I could get the
source to patch correctly was to use:
$ cd xawtv-3.35
$ patch -p 1 -l -u < capture.diff
$ patch -p 1 -l -u < grab.diff
I'm not sure why I need the -p 1, since the patches refer to the xawtv-3.35
directory. Oh, well.
Here goes:
--- xawtv-3.35/src/capture.c Wed Feb 7 17:21:53 2001
+++ xawtv-3.35-patched/src/capture.c Thu Feb 22 14:08:01 2001
@@ -172,6 +172,19 @@
return NULL;
}
+long long audio_msecs=0;
+
+long long au_getmsecs()
+{
+ return audio_msecs;
+}
+
+void au_setmsecs(long long n)
+{
+ audio_msecs=n;
+}
+
+
static void*
record_audio_thread(void *arg)
{
@@ -199,6 +212,7 @@
fifo_put(&h->afifo,buf);
h->bytes += size;
h->ausec = (long long)h->bytes * 1000000 / h->bytes_per_sec;
+ au_setmsecs(h->ausec/1000);
}
fifo_put(&h->afifo,NULL);
if (debug)
--- xawtv-3.35/src/grab.c Wed Feb 7 16:52:24 2001
+++ xawtv-3.35-patched/src/grab.c Thu Feb 22 13:45:16 2001
@@ -227,6 +227,8 @@
jpeg_list,
};
+extern long long au_getmsecs();
+
int
grabber_sw_rate(struct timeval *start, int fps, int count)
{
@@ -237,9 +239,8 @@
if (-1 == fps)
return 1;
- gettimeofday(&now,NULL);
- msecs = now.tv_usec/1000 - start->tv_usec/1000;
- msecs += now.tv_sec*1000 - start->tv_sec*1000;
+ msecs=au_getmsecs();
+
frames = msecs * fps / 1000;
if (debug > 1)
fprintf(stderr,"rate: msecs=%d fps=%d -> frames=%d |"
@@ -417,4 +418,5 @@
}
return buf;
}
> Subject: Re: [V4L] Audio/video sync in xawtv
> Date: Thu, 1 Mar 2001 16:53:20 -0500
> From: Thomas Hargrove <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
>
> I spent a good few days trying to get xawtv to produce good a/v sync
> with no
> success. I know for a fact that my computer was fast enough because it
> was
> a dual pIII w/ 512 mb and a 10k ultra160 drive. I had pretty much given
> up
> on xawtv.
>
> Where can I get your modified source?
>
> BTW: I tried a SB16 pci and a SBLive.
>
> --Tom
> Subject: Re: [V4L] Audio/video sync in xawtv
> Date: Thu, 1 Mar 2001 22:12:14 -0500
> From: Benedict Bridgwater <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
>
>
> I'd have thought that since AVI files don't store timestamps, there's no
> other way to tie the video/audio streams together than to sync one to
> the other (and assume that the capturing process did the same). If you
> rely on the video/audio samples/sec rates being exact and therefore
> being able to sync to absolute time, you're bound to drift, because
> nothing ever is perfect. It's not so much a matter of having a crappy
> sound card, as having a crappy a/v file format (AVI) that doesn't store
> timestamps or any other sync information.
>
> Could you post your patch?
>
> Ben
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
