Re: Video4linux-list digest, Vol 1 #225 - 12 msgs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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:  Audio/video sync in xawtv
> Date: Thu, 1 Mar 2001 16:53:20 -0500
> From: Thomas Hargrove <ciagon@xxxxxxxxxxxxxxx>
> Reply-To: video4linux-list@xxxxxxxxxx
> To: video4linux-list@xxxxxxxxxx
>
> 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:  Audio/video sync in xawtv

> Date: Thu, 1 Mar 2001 22:12:14 -0500
> From: Benedict Bridgwater <bennyb@xxxxxxxxx>
> Reply-To: video4linux-list@xxxxxxxxxx
> To: video4linux-list@xxxxxxxxxx
>
>
> 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





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux