[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