<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>

CC BY-SA 3.0
2014-04-24T15:34:57.260Z
Do note that you may still have motion artifacts and possibly audio sync issues where the removals occur.
AJ Henderson
CC BY-SA 3.0
2014-04-28T07:56:48.497Z
No audio sync issues, but I do have some motion artefacts. Still, it's good enough to me.
Simon Watiau
CC BY-SA 3.0
2014-04-24T09:55:58.280Z
2014-04-24T09:55:58.280Z
Simon Watiau
<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>

CC BY-SA 3.0
2018-03-16T06:44:25.887Z
*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.
Gyan
CC BY-SA 3.0
2014-03-14T15:39:31.560Z
2014-03-14T15:39:31.560Z
AJ Henderson
<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>

<ffmpeg>
remove black frames from vob files with ffmpeg
Simon Watiau
# 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/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;

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.  

---

