0

I am attempting to transfer some Video 8 tapes to my computer with ffmpeg and Audacity.

ffmpeg captures a rawvideo stream from an EasyCap dongle, and Audacity records from the line-in audio jack.

With ffmpeg's frame rate parameter set to 29.97, the output video ends up being shorter than the audio recording. At 25 frames per second, the video is significantly longer than the audio. Audacity's settings are simply default.

Shouldn't the parameters match up with NTSC's; 29.97 fps? Do you think ffmpeg or Audacity are on the wrong time scale, or both?

The rawvideo stream is sourced from the somagic-capture utility, shown in the script below.

Relevant line:

ffmpeg -pixel_format uyvy422 -s:v 720x480 -framerate 29.97 -f rawvideo \ 
-i $PIPE  -vf scale=w=720:h=540 -vcodec libx264 -preset ultrafast \
-c:a libfdk_aac -b:a 128k $OUTFILE > $FFMPEG_LOG 2>&1 &

I've also tried to record the audio stream with ffmpeg. This solves the sync problem, but is unreliable. The script for that attempt and the details are here: https://stackoverflow.com/questions/28359855/forcing-ffmpeg-to-capture-unreliable-alsa-audio-stream

Script for recording video, without audio, in ffmpeg:

#!/bin/sh

PIPE=/tmp/somagic-pipe
OUTFILEDIR=~/easycap/Videos/
LOGDIR=~/.somagic-log/
NOW=`date +"%m_%d_%Y_%H_%M_%S"`

OUTFILE=${OUTFILEDIR}fpv_video_${NOW}.mp4

mkdir $LOGDIR

FFMPEG_LOG=${LOGDIR}ffmpeg.log
SOMAGIC_LOG=${LOGDIR}somagic.log
MPLAYER_LOG=${LOGDIR}mplayer.log

rm $PIPE >/dev/null 2>&1
rm $OUTFILE >/dev/null 2>&1

rm $FFMPEG_LOG
rm $SOMAGIC_LOG
rm $MPLAYER_LOG

mkfifo $PIPE >/dev/null 2>&1

ffmpeg -pixel_format uyvy422 -s:v 720x480 -framerate 29.97 -f rawvideo \ 
-i $PIPE  -vf scale=w=720:h=540 -vcodec libx264 -preset ultrafast \
-c:a libfdk_aac -b:a 128k $OUTFILE > $FFMPEG_LOG 2>&1 & 

somagic-capture --ntsc -c --luminance=2 --lum-aperture=3 2> $SOMAGIC_LOG | \
tee $PIPE | \
mplayer -vf yadif,screenshot -demuxer rawvideo -rawvideo    \
"ntsc:format=uyvy:fps=30000/1001" -aspect 4:3 - 2> $MPLAYER_LOG

rm $PIPE >/dev/null 2>&1

Modified from this script: https://gist.github.com/Brick85/0b327ac2d3d45e23ed33

As suggested by stib, here's the output of ffprobe.

On the audio file:

peterbecich@Sirius:~/easycap$ ffprobe snapping.m4a 
ffprobe version 2.5.3 Copyright (c) 2007-2015 the FFmpeg developers
  built on Jan 11 2015 17:53:45 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --extra-libs=-ldl --prefix=/opt/ffmpeg --enable-avresample --disable-debug --enable-nonfree --enable-gpl --enable-version3 --enable-libpulse --enable-libopencore-amrnb --enable-libopencore-amrwb --disable-decoder=amrnb --disable-decoder=amrwb --enable-libx264 --enable-libx265 --enable-libfdk-aac --enable-libvorbis --enable-libmp3lame --enable-libopus --enable-libvpx --enable-libspeex --enable-libass --enable-avisynth --enable-libsoxr --enable-libxvid --enable-libvo-aacenc --enable-libvidstab
  libavutil      54. 15.100 / 54. 15.100
  libavcodec     56. 13.100 / 56. 13.100
  libavformat    56. 15.102 / 56. 15.102
  libavdevice    56.  3.100 / 56.  3.100
  libavfilter     5.  2.103 /  5.  2.103
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'snapping.m4a':
  Metadata:
    major_brand     : M4A 
    minor_version   : 512
    compatible_brands: isomiso2
    encoder         : Lavf54.20.4
  Duration: 00:19:06.78, start: 0.000000, bitrate: 189 kb/s
    Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 186 kb/s (default)
    Metadata:
      handler_name    : SoundHandler

On the video file:

peterbecich@Sirius:~/easycap$ ffprobe Videos/fpv_video_02_06_2015_16_34_09.mp4 
ffprobe version 2.5.3 Copyright (c) 2007-2015 the FFmpeg developers
  built on Jan 11 2015 17:53:45 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --extra-libs=-ldl --prefix=/opt/ffmpeg --enable-avresample --disable-debug --enable-nonfree --enable-gpl --enable-version3 --enable-libpulse --enable-libopencore-amrnb --enable-libopencore-amrwb --disable-decoder=amrnb --disable-decoder=amrwb --enable-libx264 --enable-libx265 --enable-libfdk-aac --enable-libvorbis --enable-libmp3lame --enable-libopus --enable-libvpx --enable-libspeex --enable-libass --enable-avisynth --enable-libsoxr --enable-libxvid --enable-libvo-aacenc --enable-libvidstab
  libavutil      54. 15.100 / 54. 15.100
  libavcodec     56. 13.100 / 56. 13.100
  libavformat    56. 15.102 / 56. 15.102
  libavdevice    56.  3.100 / 56.  3.100
  libavfilter     5.  2.103 /  5.  2.103
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Videos/fpv_video_02_06_2015_16_34_09.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.15.102
  Duration: 00:19:08.08, start: 0.000000, bitrate: 5352 kb/s
    Stream #0:0(und): Video: h264 (High 4:2:2) (avc1 / 0x31637661), yuv422p, 720x540, 5351 kb/s, 29.97 fps, 29.97 tbr, 11988 tbn, 59.94 tbc (default)
    Metadata:
      handler_name    : VideoHandler
Improve this question
2
  • 1
    Try using ffprobe on the two files–does that shed any insight into what's going on?
    – stib
    Commented Feb 7, 2015 at 4:16
  • Thanks. I don't know how to interpret the output, though.
    – Peter Becich
    Commented Feb 7, 2015 at 5:25

2 Answers 2

Reset to default
1

I can't say what's going wrong or if there's a change to the ffmpeg scripts that would help, but from a practical POV I can offer some advice on how to deal with what you have.

If the difference is due to drift, the fix is relatively simple. If it's due to dropped video frames or audio dropouts, it's probably not going to be fixable without a good bit of work.

The 'drift' scenario is this: you know they're out of sync at the end because you can see / hear the difference. Something near the end doesn't match up. So find that thing and identify its exact time relative to the start, in both the picture and sound. Reduce these times to absolute frames -- in this case numbers will be around 34000 or so at 30fps. Find the ratio of these two values and apply it in Audacity as a speed change percentage (with constant pitch, usually). Check that the audio event now occurs at the same time as the matching video event you noted. If you got it wrong, invert the ratio.

If after doing this you find places in the middle that are still out of sync, you're forced to apply this same technique in multiple segments, or to cut / move / blend the audio in sections. I don't envy you this task.

Improve this answer
0

The issue is apparently that ffmpeg cuts out dead space from captured video, and Audacity does not do likewise for audio. I've now noticed that ffmpeg's frame count stops incrementing over blank video.

I believe this problem also happens when using two separate ffmpeg processes to capture video and ALSA audio.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.