Answers.Body: <p>This is the script I used to solve this.
  1/ It finds black frames and put them in a file
  2/ It reads the file and compute a (really long) command line which will remove those frame with the "select" filter.</p>
  
  <p>It's not beautiful, but it gets the job done!</p>
  
  <pre><code>ffmpeg -i "$1" -vf blackframe -an -f null - 2&gt;&amp;1 | ack  "(?&lt;=frame:)[0-9]*(?= )" -oh &gt; blacks.txt
  
  
  printf "ffmpeg -i \"$1\""
  printf " -f avi -c:v libx264 -c:a libmp3lame -crf 23 -preset veryslow"
  
  printf " -vf \"select="
  
  cat blacks.txt | while read a; do
  printf "not(eq(n\,$a))*"
  done
  printf "\""
  printf " "
  printf "$2"
  printf "\n"
  rm blacks.txt
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-04-24T15:34:57.260Z
Answers.Text: Do note that you may still have motion artifacts and possibly audio sync issues where the removals occur.
Answers.UserDisplayName: AJ Henderson
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-04-28T07:56:48.497Z
Answers.Text: No audio sync issues, but I do have some motion artefacts. Still, it's good enough to me.
Answers.UserDisplayName: Simon Watiau
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-04-24T09:55:58.280Z
Answers.LastActivityDate: 2014-04-24T09:55:58.280Z
Answers.UserDisplayName: Simon Watiau
Answers.Body: <p>What you experienced are called dropped frames.  These shouldn't be confused with drop frame video formats (such as 29.97fps NTSC video, which is otherwise known as 30 fps drop frame (because a frame is dropped to get 29.97 frames per second.) </p>
  
  <p>Dropped frames occur when the system capturing is not able to keep up with the rate of playback.  They are duration .04 because it is a single frame, which works out to around .04 seconds.</p>
  
  <p>Dropped frames are a relatively tricky issue to deal with as they interfere with the flow of the video and also the audio sync.  Even if you clip them out of the source material, it results in a spatial and auditory gap of .04 seconds that is often detectable by a viewer.  Due to this, the best practice is to re-capture if you experience dropped frames during capture.</p>
  
  <p>If re-capture isn't an option, your best bet is to interpolate a frame to fill the gap by averaging the preceding and proceeding frames of video.  This frame often doesn't come out super well, but it is still often less jarring than removing the frame entirely and allows the audio to continue normally (provided the audio didn't also cutout for the dropped frame).</p>
  
  <p>As a last resort, you can simply cut out the dropped frame, but as previously mentioned, this results in a .04 second gap in your footage and is non-ideal.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-16T06:44:25.887Z
Answers.Text: *because a frame is dropped to get 29.97 frames per second* -> no frames are dropped. Timecode runs at 30 fps, which differs from actual framerate so every 900 frames or so, one timecode label is skipped to preserve time sync i.e. 29:29 -> 30:01, skipping 30:00.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-03-14T15:39:31.560Z
Answers.LastActivityDate: 2014-03-14T15:39:31.560Z
Answers.UserDisplayName: AJ Henderson
Body: <p>I have a few <code>.vob</code> files with "black frames" (it seems that an issue during the acquisition from VHS did that).<br>
  I can get where these black frames occur with the command</p>
  
  <pre><code>ffmpeg -i source.vob  -vf blackdetect=d=0:pic_th=0.70:pix_th=0.10 -an -f null - 2&gt;&amp;1
  </code></pre>
  
  <p>which gives me </p>
  
  <pre><code>[...]
  [blackdetect @ 0x7fab5b40a3e0] black_start:137.68 black_end:137.72 black_duration:0.04
  [blackdetect @ 0x7fab5b40a3e0] black_start:161 black_end:161.04 black_duration:0.04
  [blackdetect @ 0x7fab5b40a3e0] black_start:181.96 black_end:182 black_duration:0.04
  [...]
  </code></pre>
  
  <p>(black_duration is always 0.04s for some reason)</p>
  
  <p>I've built a script that cuts the parts between black frames and creates one file for each.<br>
  basically, for the three lines above, it runs:  </p>
  
  <pre><code>ffmpeg -i "/Users/simon/Documents/projects/encodage VHS/source.vob" -ss 00:02:17.720 -t 23.28  -f avi -c:v libx264 -c:a libmp3lame -crf 0 -preset veryslow -vf "setpts=PTS-STARTPTS" 13.mpeg;
  ffmpeg -i "/Users/simon/Documents/projects/encodage VHS/source.vob" -ss 00:02:41.040 -t 20.92  -f avi -c:v libx264 -c:a libmp3lame -crf 0 -preset veryslow -vf "setpts=PTS-STARTPTS" 14.mpeg;
  </code></pre>
  
  <p>then I merge those files with the concat plugin of ffmpeg.</p>
  
  <p>My issue is: I'm sure the values I use to cut are right, but running the blackdetect filter again, I can see black frames at the beginning of some fragments.</p>
  
  <p>Do you know why I'm still getting those black frames ? Is there a better way to remove them than cut and concat? I'm using a Mac.</p>
  
Tags: <ffmpeg>
Title: remove black frames from vob files with ffmpeg
UserDisplayName: Simon Watiau
ThreadText: # remove black frames from vob files with ffmpeg
  
  (Asked by: username_0 on 2014-03-14)
  
  I have a few `.vob` files with "black frames" (it seems that an issue during the acquisition from VHS did that).  
  I can get where these black frames occur with the command
  
  ```
  ffmpeg -i source.vob  -vf blackdetect=d=0:pic_th=0.70:pix_th=0.10 -an -f null - 2>&1
  
  ```
  
  which gives me
  
  ```
  [...]
  [blackdetect @ 0x7fab5b40a3e0] black_start:137.68 black_end:137.72 black_duration:0.04
  [blackdetect @ 0x7fab5b40a3e0] black_start:161 black_end:161.04 black_duration:0.04
  [blackdetect @ 0x7fab5b40a3e0] black_start:181.96 black_end:182 black_duration:0.04
  [...]
  
  ```
  
  (black\_duration is always 0.04s for some reason)
  
  I've built a script that cuts the parts between black frames and creates one file for each.  
  basically, for the three lines above, it runs:
  
  ```
  ffmpeg -i "/Users/username_0/Documents/projects/encodage VHS/source.vob" -ss 00:02:17.720 -t 23.28  -f avi -c:v libx264 -c:a libmp3lame -crf 0 -preset veryslow -vf "setpts=PTS-STARTPTS" 13.mpeg;
  ffmpeg -i "/Users/username_0/Documents/projects/encodage VHS/source.vob" -ss 00:02:41.040 -t 20.92  -f avi -c:v libx264 -c:a libmp3lame -crf 0 -preset veryslow -vf "setpts=PTS-STARTPTS" 14.mpeg;
  
  ```
  
  then I merge those files with the concat plugin of ffmpeg.
  
  My issue is: I'm sure the values I use to cut are right, but running the blackdetect filter again, I can see black frames at the beginning of some fragments.
  
  Do you know why I'm still getting those black frames ? Is there a better way to remove them than cut and concat? I'm using a Mac.
  
  **Tags:** ffmpeg
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2014-04-24. Score: 0 | Accepted answer
  
  This is the script I used to solve this.
  1/ It finds black frames and put them in a file
  2/ It reads the file and compute a (really long) command line which will remove those frame with the "select" filter.
  
  It's not beautiful, but it gets the job done!
  
  ```
  ffmpeg -i "$1" -vf blackframe -an -f null - 2>&1 | ack  "(?<=frame:)[0-9]*(?= )" -oh > blacks.txt
  
  printf "ffmpeg -i \"$1\""
  printf " -f avi -c:v libx264 -c:a libmp3lame -crf 23 -preset veryslow"
  
  printf " -vf \"select="
  
  cat blacks.txt | while read a; do
  printf "not(eq(n\,$a))*"
  done
  printf "\""
  printf " "
  printf "$2"
  printf "\n"
  rm blacks.txt
  
  ```
  
  > **Comments:**
  > **username_1**: Do note that you may still have motion artifacts and possibly audio sync issues where the removals occur.  
  > **username_0**: No audio sync issues, but I do have some motion artefacts. Still, it's good enough to me.  
  
  ---
  
  ### Answer by username_1 on 2014-03-14. Score: 1
  
  What you experienced are called dropped frames. These shouldn't be confused with drop frame video formats (such as 29.97fps NTSC video, which is otherwise known as 30 fps drop frame (because a frame is dropped to get 29.97 frames per second.)
  
  Dropped frames occur when the system capturing is not able to keep up with the rate of playback. They are duration .04 because it is a single frame, which works out to around .04 seconds.
  
  Dropped frames are a relatively tricky issue to deal with as they interfere with the flow of the video and also the audio sync. Even if you clip them out of the source material, it results in a spatial and auditory gap of .04 seconds that is often detectable by a viewer. Due to this, the best practice is to re-capture if you experience dropped frames during capture.
  
  If re-capture isn't an option, your best bet is to interpolate a frame to fill the gap by averaging the preceding and proceeding frames of video. This frame often doesn't come out super well, but it is still often less jarring than removing the frame entirely and allows the audio to continue normally (provided the audio didn't also cutout for the dropped frame).
  
  As a last resort, you can simply cut out the dropped frame, but as previously mentioned, this results in a .04 second gap in your footage and is non-ideal.
  
  > **Comments:**
  > **username_2**: *because a frame is dropped to get 29.97 frames per second* -> no frames are dropped. Timecode runs at 30 fps, which differs from actual framerate so every 900 frames or so, one timecode label is skipped to preserve time sync i.e. 29:29 -> 30:01, skipping 30:00.  
  
  ---
  
  