> I had especially a look at your capproc.cc, cause I'd liked to know if you've
> got a working A/V sync or not (because A/V sync in
> samples/qtvidcap/capproc.cpp was disabled/commented)
>
> A/V sync for avirec/avicap works like this:
>
> capproc.cpp::audcap()
>
> double timestamp_shift=(audioblock+m_pDsp->getSize())/abps;
> if(m_pProgress){
> m_pProgress->setTimestampShift(timestamp_shift);
> }
> ch.size = m_pDsp->read(ch.data, audioblock);
> int64_t ct = longcount();
> //double freq=550000.;
>
> //printf("ACT %d %d %f %f\n", audioblock, m_pDsp->getSize(), abps,
> timestamp_shift);
>
> #if 1
> if(starttime)
> ch.timestamp=double(ct-starttime)/(freq*1000.)-timestamp_shift;
> else
> ch.timestamp=0;
>
[cut]
>
> I just wanted to say: if vcr should have problems recording with perfect A/V
> sync for a long time (some hours), then you should look at that part of our
> source - or just ask me ;-)
>
I've just taken a good look at the timestamp_shift bit. I don't see how
this can fix an a/v sync problem that is supposed to get worse over
time though. It seems to me that all it does is change the offset of the
audio for the entire video capture, not so much to fix a slowly
incrementing syncing problem. I'm probably missing something here, but
this is how I think it works:
The timestamp for each bit of captured audio is calculated using the
same offset (starttime) each time. This, therefore, can't introduce syncing
problems. timestamp_shift can vary a little bit for each captured audio
fragment, but that change is not incremental. Then how can substracting
timestamp_shift from the timestamp fix incremental syncing problems?
Kind regards,
Bram
--
[EMAIL PROTECTED] - http://www.stack.nl/%7Ebrama/
/(bb|[^b]{2})/
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
