[FFmpeg-trac] #5123(avfilter:closed): PAD filter works correctly only when vcodec is NOT H264
FFmpeg
trac at avcodec.org
Wed Jan 6 15:48:58 CET 2016
#5123: PAD filter works correctly only when vcodec is NOT H264
-------------------------------------+-------------------------------------
Reporter: | Owner:
SarasotaSlim | Status: closed
Type: defect | Component: avfilter
Priority: normal | Resolution:
Version: unspecified | needs_more_info
Keywords: pad | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by SarasotaSlim):
For the case of input codec being MPEG2 or 4, you are correct...when I
explicitly
add "-vcodec mpeg4', it will use that, and is much faster.
But, WHY does it default output to H264??? (which is 5 times slower).
I'd argue, you should logically do "-vcodec copy", since you do NOT allow
me to say that explicitly.
But, in the case of input vcodec of H264 (and requesting same for the
output),
it fails with:
[mov,mp4,m4a,3gp,3g2,mj2 @ 0000026895d2a6c0] Could not find codec
parameters for stream 0 (Video: h264 (avc1 / 0x31637661), none, 720x316
, 1580 kb/s): unspecified pixel format
Consider increasing the value for the 'analyzeduration' and 'probesize'
options
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'In_the_Cut-10mins.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf57.21.100
Duration: 00:10:00.00, start: 0.016000, bitrate: 1885 kb/s
Stream #0:0(und): Video: h264 (avc1 / 0x31637661), none, 720x316, 1580
kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 48k tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz, stereo,
s16p, 320 kb/s (default)
Metadata:
handler_name : SoundHandler
File 'In_the_Cut-ffmpeg-pad.mp4' already exists. Overwrite ? [y/N] y
[buffer @ 0000026895d2d0e0] Unable to parse option value "-1" as pixel
format
Last message repeated 1 times
[buffer @ 0000026895d2d0e0] Error setting option pix_fmt to value -1.
Say what???
Consider increasing the value for the 'analyzeduration' and
'probesize' options ????
Unable to parse option value "-1" as pixel format ???
Now THAT is what "makes no sense at all".
If your code can't reach into the input's metadata, as VLC seems to be
doing, it's broken.
(Back when I got those msgs, I tried adding "-pix_fmt yuv420p" but that
didn't cut it.)
So, I'm arguing that padding is totally unusable, in the case of H264.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/5123#comment:6>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list