amiaopensource / amiaopensource/vrecord
Dropped frames cause audio sync issues while capturing Video8/Hi8
- Linguagem predominante
- Shell
- Estrelas
- 204
- Forks
- 53
- Merge médio
- 3d 2h
- PRs com merge (30d)
- 10
Descrição
I’m currently attempting to digitize a number of Hi8 and Video8 tapes. These tapes are as-is from the camera; as such, there are imperfections in the originals recordings, including blank sections between clips and occasional damaged frames (particularly at the start of tapes and between clips). These discontinuities appear to be causing dropped frames—not ideal, but given that there’s not really much in there anyways to begin with, it’s something I’m okay with. Unfortunately, because of the high number of dropped frames—over 300 for certain tapes—**the audio gets thrown out sync quite significantly. This makes the portions that are captured correctly borderline unusable.**
I believe I’ve confirmed that the source of these dropped frames is the original media, as the frame drops happen at consistent points in the recording[s], and dropped frames aren’t exhibited when a different input is provided. Thus, **my concern is primarily with fixing the audio sync.** Right now, I see three possible options:
1. Drop the corresponding audio for the dropped frames. I thought this would already be the default behavior, but that doesn’t appear to be the case—[I couldn’t even find a corresponding option in `ffmpeg`](https://superuser.com/questions/1409384/forcing-ffmpeg-to-drop-audio-at-same-rate-it-drops-video), and `bmdcapture` didn’t seem to be any better.
2. Fix the dropped frames entirely. This would be ideal, but I’m not sure how involved this would be.
3. Abandon vrecord and use a different capture setup. Blackmagic Media Express also shows dropped frames and syncing issues; **VirtualDub2 does not seem to exhibit either dropped frames or syncing issues** when using Decklink Video Capture (though it does when using Blackmagic WDM Capture), but it crashes when attempting to encode using FFV1 instead of raw video/Lagarith/HuffYUV (probably for unrelated reasons.)
I’d obviously like to stick with vrecord; is either the first or second option viable? If so, is this something that would happen entirely upstream (either in `ffmpeg` or in `bmdcapture`), or is there something that should happen in vrecord? Is there another option I’m not seeing?
# Cases
| Original media | Capture method | Result |
|----------------|---------------------------------------------|------------------------------------------------------|
| Digital8 | DV (Firewire) | ✅ |
| Digital8 | Analog (S-Video) | ✅ No dropped frames |
| Hi8/Video8 | DV (Firewire), deck does digital conversion | ✅ Minimal bad Firewire packets, no audio sync issues |
| **Hi8/Video8** | **Analog (S-Video)** | **❌ Many dropped frames, audio sync issues** |
| Host OS | Capture Software | Result |
|---------|--------------------------------------|--------|
| macOS | vrecord | ❌ |
| macOS | Blackmagic Media Express | ❌ |
| Windows | Blackmagic Media Express | ❌ |
| Windows | VirtualDub2 (Blackmagic WMD Capture) | ❌ |
| Windows | VirtualDub2 (Decklink Video Capture) | ✅ |
# Hardware
- MacPro4,1 (Early 2009) running macOS High Sierra
- Blackmagic Intensity Pro 4K
- Sony GV-D800/GV-D200 (**S-Video with TBC**)
I/O constraints don’t appear to be an issue; the frame drops occur regardless what media I write to.
I saw #379; however, given I’m already using the unfiltered view and my deck has a TBC, I’m not sure it’s applicable.
# Software
## `ffmpeg`
```
ffmpeg version 4.4.1 Copyright (c) 2000-2021 the FFmpeg developers
built with Apple LLVM version 10.0.0 (clang-1000.10.44.4)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.4.1-with-options_2 --enable-shared --cc=clang --host-cflags= --host-ldflags= --enable-gpl --enable-libaom --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-libsnappy --enable-libtheora --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-demuxer=dash --enable-opencl --enable-videotoolbox --disable-htmlpages --enable-libopenjpeg --enable-librubberband --enable-libsrt --enable-libtesseract --enable-nonfree --enable-decklink --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/include
libavutil 56. 70.100 / 56. 70.100
libavcodec 58.134.100 / 58.134.100
libavformat 58. 76.100 / 58. 76.100
libavdevice 58. 13.100 / 58. 13.100
libavfilter 7.110.100 / 7.110.100
libswscale 5. 9.100 / 5. 9.100
libswresample 3. 9.100 / 3. 9.100
libpostproc 55. 9.100 / 55. 9.100
```
## Blackmagic Desktop Video
12.2.2, but 10.11.2 exhibited the same issues.
## Capture settings
```
# Set these variables to a valid option or leave as empty quotes (like "") to request each run.
STARTUP_VIEW="INPUTSETTINGS"
DEVICE_INPUT_CHOICE="0"
VIDEO_INPUT_CHOICE="S-Video"
AUDIO_INPUT_CHOICE="Analog"
CONTAINER_CHOICE="Matroska"
VIDEO_CODEC_CHOICE="FFV1 version 3"
FFV1_SLICE_CHOICE="30"
AUDIO_CODEC_CHOICE="24-bit PCM"
AUDIO_DEV_CHOICE="Built-in Line Input"
AUDIO_MODE_CODEC_CHOICE="24-bit PCM"
AUDIO_CHANNEL_CHOICE="Mono"
AUDIO_MODE_SR_CHOICE="96 kHz"
VIDEO_BIT_DEPTH_CHOICE="10 bit"
AUDIO_MAPPING_CHOICE="1 Stereo Track (From Channels 1 & 2)"
TIMECODE_CHOICE="none"
STANDARD_CHOICE="NTSC"
QCTOOLSXML_CHOICE="No"
FRAMEMD5_CHOICE="Yes"
EMBED_LOGS_CHOICE="Yes"
PLAYBACKVIEW_CHOICE="Unfiltered"
PLAYBACKVIEW_CHOICE_PASS="Unfiltered"
DIR=""
LOGDIR=""
INVERT_PHASE=""
DURATION="125"
PREFIX=""
USER_SUFFIX=""
NO_SUFFIX="false"
TECHNICIAN=""
AVFCTL_INPUT_CHOICE=""
DECKLINK_INPUT_CHOICE="Intensity Pro 4K"
DECKLINK_UTILITY_CHOICE="ffmpeg"
WAVEFORM_SCALE_CHOICE="digital"
MONITOR_AUDIO_CHOICE="Yes"
SIGNAL_VIEW_CHOICE="Broadcast Range"
DV_CONTAINER_CHOICE="DV"
DV_RESCUE_OPTION_S="false"
DV_RESCUE_OPTION_D="false"
DV_RESCUE_OPTION_T="false"
DV_RESCUE_OPTION_TC="false"
```
I’ve also tried using `bmdcapture` instead of `ffmpeg`; however, the issue persisted.
# Reference log
[tape_ffv1_vrecord_input.log](https://github.com/amiaopensource/vrecord/files/7831805/tape_ffv1_vrecord_input.log)
Guia de contribuição
Avaliação
Esta issue ainda não foi avaliada.