Congratulations! It's not everyday that I read a technical description that causes me to cringe to the point of physical discomfort. I'm impressed. Now, please don't take this personally, but this is simply the wrong thing to do. Dropping audio, or "padding" it is definitely going to be noticable. I heard off-by-one errors, resulting in just _one_ sample being set to zero, causing audible clicks on buffer boundaries. Think of what you're doing to the frequency spectrum, around the edges of the padding: basically, you're introducing a lot of high frequency noise at the point of transition. Dropping samples causes a discontinuity in the time domain, which translates to, again, high frequency noise in the frequency domain. If you're looking for a quick and dirty approach, you're far better off dropping or repeating the occasional video frame, instead. I guess the absolutely correct, anal retentive thing to do would be to keep the video time line as the capture's main time line, and resample the audio to stretch or squeeze it, so it tracks the video. Not very easy to do without introducing some aliasing artifacts, but certainly possible in real time. The only tricky part is determining by how much to stretch. On the flip side, this approach will, indeed, maintain perfect synchronization. I just feel that the tradeoff is unaaceptable. Ori Justin Schoeman wrote: > > > If you want a quick-and-dirty synch technique that works very well, try > qtrec (http://www.ee.up.ac.za/~justin/v4l2/). The current version may > not even compile, but the synch technique works great. How it works: > > 1) Calculate exactly how many audio samples there should be per video > frame. > 2) Wait for a valid video frame. > 3) The moment the frame is complete use GETISPACE on the dsp to > determine how much audio data is available. > 4a) If the are fewer samples available than are required per frame, then > read what samples are available, and pad the rest by duplicating the > last value. > 4b) If there are more than twice the number of samples required, then > drop one frame worth of audio. > 4c) if (!4a || 4b) read one frame's worth of audio data. > 5) Write video and audio to output. > > (Note that the maximum audio correction at one time is 20ms - which is > barely audible.) > > As I said, this is quick-and-dirty, but it works very well. Last night > I recorded a 1 1/2 hour movie without any noticeable synch problems (and > no noticeable audio defects). In fact, to test it, I have forcibly set > the dsp rare off by as much as + and - 25% - the audio sounded as though > it was pitch-shifted, but was still pretty good. > > -justin > > _______________________________________________ > Video4linux-list mailing list > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list
