Fixing dropped frames in digital video
Occasionally, when capturing DV, data is generated faster than it can be saved, thus audio and video frames are dropped. The resulting small gaps in the recording are noticeable at playback time as footage appears sped up and choppy, AV-sync being lost occasionally. For most people, those recordings are unwatchable.
Obviously the lost data cannot be recovered. The symptoms however – stuttering and uncomfortable playback speed – can be remedied somewhat by interpolating the missing audio frames. Assuming a file with a nominal framerate of 25 FPS that had every second frame dropped, this can easily be achieved using mplayer for playback at half speed:
mplayer -af scaletempo=stride=16:overlap=.25:search=10 -speed 0.5 -fps 25 example.dvThe important piece is the scaletempo filter, which can change audio speed without altering the pitch. Without it, speech played at half its original speed has more resemblance to Goa’uld utterances than to real-world language. Unfortunately, this approach is limited by the sampling theorem: If too many audio frames are missing, the result will sound like it was created using a bad mobile phone.
Though missing video frames could also be interpolated to smooth jerky movements, simply duplicating frames is adequate for real-world usage. The following shell script utilizes mplayer and mencoder to interpolate audio and duplicate video frames, creating a file that should be easier on viewers’ eyes and ears than the original – broken – recording.
mplayer -af scaletempo=stride=16:overlap=.25:search=10 -speed 0.5 -fps 25 example.dv -vc null -vo null -ao pcm:waveheader:file=example.wav && mencoder -fps 12.5 -ofps 25 -ovc copy -oac copy -o example-fixed.dv example.dv -audiofile example.wav && rm example.wavFor an example recording processed using this method, see the video of the Fickileaks talk me and fotografiona gave at the Spackeriade; the original file was missing about every second frame.
Sieht nützlich aus!
When I had the pleasure to capture video for a school project, I needed to tweak a while before getting rid of dropped frames. But they never had a pattern as in your case, where ever nth frame is dropped. But I always captured from an analog source and this was when the Athlon XP was top notch and had totalely no clue about encoding.
What I would like to know is why you even had difficulties capturing, when the source was digital and PAL. Isn’t this just an compressed video which you stream from a cassette? This doesn’t sound like there would be much bandwidth needed. Or did you re-encode simultaneously?
Also: Even if your captcha is efficient, it has a flaw. It’s german.
Das Fühl, im Nachhinein im eigenen Kommentar sofort 9001 Typos zu finden, nachdem man abgeschickt hat.
The difficulties I encountered have likely been caused by an automagic backup service whose untimely activation considerably limited the receiving system’s abilities. I do not know if the problem was in processing speed or bus throughput. Lesson learned: Shut down everything that is not needed for recording.