[FFmpeg-trac] #5123(avfilter:new): PAD filter works correctly only when vcodec is NOT H264
FFmpeg
trac at avcodec.org
Wed Jan 6 13:31:04 CET 2016
#5123: PAD filter works correctly only when vcodec is NOT H264
--------------------------------------+----------------------------------
Reporter: SarasotaSlim | Type: defect
Status: new | Priority: normal
Component: avfilter | Version: 2.8.3
Keywords: pad | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
--------------------------------------+----------------------------------
Summary of the bug: PAD filter works correctly only when vcodec is NOT
H264
How to reproduce: Try it, with one of each
{{{
% ffmpeg -i input ... output
ffmpeg version
built on ...
}}}
Patches should be submitted to the ffmpeg-devel mailing list and not this
bug tracker.
MyTemplate to grab 't-seconds' of a video file, starting 'ss-seconds'
into it
ffmpeg -i MOVIE.mkv -acodec copy -vcodec copy -t 60 -ss 240 MOVIE-
1min.mp4
So, I grabbed 180 secs (3 mins) of one of mine (it was ripped from a DVD
using MakeMKV...720x480, vcodec=MPEG2) :
ffmpeg -i Raising_Arizona(1987).mkv -acodec copy -vcodec copy -t
600 -ss 60 Raising_Arizona-3mins.mkv
For this next part, you need be sure you have a FULL distrib of FFMPEG for
Windows (that includes filters),
so if this next step fails because it can't find filters, get full version
(static pkg, which has filters inside) here:
http://ffmpeg.zeranoe.com/builds/ (Look for
the windows build section)
[ Problem initially found on Windows-10, using :
ffmpeg version N-77681-gb6c61b7 Copyright (c) 2000-2016 the FFmpeg
developers
[ On my Debian-family-based Linux, I have version 2.8.3 of FFMPEG, which I
also validated these findings against. ]
To pad, I followed this tutorial:
http://www.ehow.com/how_7623319_put-black-borders-ffmpeg.html
[ Some other FFMPEG pad info, such as this one, erroneously claim that you
first need to 'scale', but that makes NO sense at all! ]
http://superuser.com/questions/547296/resizing-videos-with-ffmpeg-
avconv-to-fit-into-static-sized-player
VLC can pad without scaling first, so FFMPEG should be able to, too. The
VLC clause needed is simply:
--sout=#transcode{vfilter=croppadd{paddtop=40,paddbottom=40}
and note that VLC, unlike FFMPEG, is transparent to what the initial/final
resolutions happen to be !
So using the pad-filter, I padded it via ffmpeg, from 720x480 to 720x540,
with extra 30 top and bottom. [ It took 7 minutes. ]
ffmpeg -i Raising_Arizona-3mins.mkv -filter:v
pad=720:540:0:30:black Raising_Arizona-ffmpeg-pad.mp4
Note that FFPEG's pad creates the output into H264 (whether you wanted
that or not).
Then, I did the same pad, using VLC. It took only 2 minutes. [ Note that
with VLC I'm using vcodec=mpeg4, not h264. To go to h264, takes 12 mins.]
vlc -vvv --extraintf logger --fullscreen --play-and-exit --no-osd
--no-sub-autodetect-file --log-verbose=2 --verbose-objects=+all
--sout=#transcode{vfilter=croppadd{paddtop=30,paddbottom=30},vcodec=mpeg4,vb=1000,
acodec=mpga,ab=96,channels=2,threads=2}:std{access=file,mux=mp4,dst="C:\Users\David
\mkv-files\Raising_Arizona-vlc-pad.mp4"}
"C:\Users\David\mkv-files\Raising_Arizona-3mins.mkv"
So I learned from this: Staying in MPEG2 or MPEG4 (until the final pass,
where h264 is required for us), is the way to go. It is MUCH faster.
i.e I learned that FFMPEG's PAD filter REQUIRES them to put the output
into h264 (which is what is slowing their padding time down). I also
found that when the INPUT file is already in h264, FFMPEG thinks it needs
a bunch more stuff, like "-pix_fmt"..which appears to be broken.
Also, VLC is totally transparent to what the initial/final resolutions
are, whereas FFMPEG requires you to phrase your request explicitly stating
the target resolution.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/5123>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list