Recherche avancée

Sur d’autres sites (3633)

• tests/dnn : Make DNN tests regular libavfilter tests

  15 décembre 2021, par Andreas Rheinhardt

  tests/dnn : Make DNN tests regular libavfilter tests
  They test libavfilter internal API, so they should be libavfilter
  
  test programs (which implies : linked statically to libavfilter
  
  to access internal APIs and linked normally (statically or dynamically
  
  depending upon the build configuration) against all the other libs).
  Right now, they are always linked statically against all libs,
  
  which is a significant size waste compared to shared libs as all
  
  of libavcodec has been pulled in despite not being really used.
  
  This also leads to linking failures on systems for which av_export_avutil
  
  is intended : libavcodec does not expect to be linked statically
  
  against the library providing avpriv_(cga|vga16)_font in this case.
  
  This is fixed by this commit.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavfilter/Makefile
  • [DH] libavfilter/tests/.gitignore
  • [DH] libavfilter/tests/dnn-layer-avgpool.c
  • [DH] libavfilter/tests/dnn-layer-conv2d.c
  • [DH] libavfilter/tests/dnn-layer-dense.c
  • [DH] libavfilter/tests/dnn-layer-depth2space.c
  • [DH] libavfilter/tests/dnn-layer-mathbinary.c
  • [DH] libavfilter/tests/dnn-layer-mathunary.c
  • [DH] libavfilter/tests/dnn-layer-maximum.c
  • [DH] libavfilter/tests/dnn-layer-pad.c
  • [DH] tests/Makefile
  • [DH] tests/dnn/.gitignore
  • [DH] tests/dnn/Makefile
  • [DH] tests/dnn/dnn-layer-avgpool-test.c
  • [DH] tests/dnn/dnn-layer-conv2d-test.c
  • [DH] tests/dnn/dnn-layer-dense-test.c
  • [DH] tests/dnn/dnn-layer-depth2space-test.c
  • [DH] tests/dnn/dnn-layer-mathbinary-test.c
  • [DH] tests/dnn/dnn-layer-mathunary-test.c
  • [DH] tests/dnn/dnn-layer-maximum-test.c
  • [DH] tests/dnn/dnn-layer-pad-test.c
  • [DH] tests/fate/dnn.mak

• What is causing "unspecified pixel format" and "Error opening filters !" error in ffmpeg ?

  19 février 2019, par SJAndersonLA

  I’m writing an mp4 to HLS transcoding process that works as intended on files smaller than 7 gigabytes (sample size is 100 videos). When attempting to transcode anything larger than 7GB, it crashes.

  The command :

  ffmpeg 
  
    -i large_file.mp4 -y 
  
    -vf scale=w=1920:h=1080:force_original_aspect_ratio=decrease 
  
    -c:a aac 
  
    -ar 48000 
  
    -c:v h264 
  
    -profile:v main 
  
    -crf 20 
  
    -sc_threshold 0 
  
    -g 48 
  
    -keyint_min 48 
  
    -hls_time 4 
  
    -hls_playlist_type vod 
  
    -b:v 5000k 
  
    -maxrate 5350k 
  
    -bufsize 7500k 
  
    -b:a 192k 
  
    -hls_segment_filename /1080p_%03d.ts 
  
    -threads 0 
  
    /tmp/output-ef42dc65-1d3d-4682-b32b-68d7c712fb9c-raw-test/1080p.m3u8

  The error :

  ffmpeg version 3.2.12-1\x7edeb9u1 Copyright (c) 2000-2018 the FFmpeg developers
  
    built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  
    configuration: --prefix=/usr --extra-version='1~deb9u1' --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libebur128 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  
    libavutil      55. 34.101 / 55. 34.101
  
    libavcodec     57. 64.101 / 57. 64.101
  
    libavformat    57. 56.101 / 57. 56.101
  
    libavdevice    57.  1.100 / 57.  1.100
  
    libavfilter     6. 65.100 /  6. 65.100
  
    libavresample   3.  1.  0 /  3.  1.  0
  
    libswscale      4.  2.100 /  4.  2.100
  
    libswresample   2.  3.100 /  2.  3.100
  
    libpostproc    54.  1.100 / 54.  1.100
  
  [mov,mp4,m4a,3gp,3g2,mj2 @ 0x555888d821c0] Could not find codec parameters for stream 0 (Video: h264 (avc1 / 0x31637661), none, 1280x720, 3856 kb/s): unspecified pixel format
  
  Consider increasing the value for the 'analyzeduration' and 'probesize' options
  
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'large_file.mp4':
  
    Metadata:
  
      major_brand     : isom
  
      minor_version   : 512
  
      compatible_brands: isomiso2avc1mp41
  
      encoder         : Lavf58.26.101
  
    Duration: 05:56:12.51, start: 0.000000, bitrate: 4061 kb/s
  
      Stream #0:0(und): Video: h264 (avc1 / 0x31637661), none, 1280x720, 3856 kb/s, 29.99 fps, 30 tbr, 100k tbn, 200k tbc (default)
  
      Metadata:
  
        handler_name    : VideoHandler
  
      Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 194 kb/s (default)
  
      Metadata:
  
        handler_name    : SoundHandler
  
  [buffer @ 0x555888d88180] Unable to parse option value "-1" as pixel format
  
      Last message repeated 1 times
  
  [buffer @ 0x555888d88180] Error setting option pix_fmt to value -1.
  
  [graph 0 input from stream 0:0 @ 0x555888d81e40] Error applying options to the filter.
  
  Error opening filters!

  The error says to try increasing analyzeduration and probesize, which I set to max value (based on an answer from this post), however that didn’t seem to change the behavior. I also suspected that the file was corrupted, but the fact that this is failing for all files larger than 7GB makes it more difficult to suggest its something not related to the size of the mp4.

• avcodec, avformat : deprecate anything related to side data merging

  16 mars 2017, par wm4

  avcodec, avformat : deprecate anything related to side data merging
  This patch deprecates anything that has to do with merging/splitting
  
  side data. Automatic side data merging (and splitting), as well as all
  
  API symbols involved in it, are removed completely.
  Two FF_API_ defines are dedicated to deprecating API symbols related to
  
  this : FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in
  
  libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates
  
  AVFMT_FLAG_KEEP_SIDE_DATA in libavformat.
  Since it was claimed that changing the default from merging side data to
  
  not doing it is an ABI change, there are two additional FF_API_ defines,
  
  which stop using the side data merging/splitting by default (and remove
  
  any code in avformat/avcodec doing this) : FF_API_MERGE_SD in libavcodec,
  
  and FF_API_LAVF_MERGE_SD in libavformat.
  It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD
  
  are quickly defined to 0 in the next ABI bump, while the API symbols are
  
  retained for a longer time for the sake of compatibility.
  
  AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for
  
  most of the time it will still be defined. Keep in mind that no code
  
  exists that actually tries to unset this flag for any reason, nor does
  
  such code need to exist. Code setting this flag explicitly will work as
  
  before. Thus it’s ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once
  
  side data merging has been removed from libavformat.
  In order to avoid that anyone in the future does this incorrectly, here
  
  is a small guide how to update the internal code on bumps :
   next ABI bump (probably soon) :
  
    - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
  
    - define FF_API_MERGE_SD to 0, and remove all code covered by it
  
   next API bump (typically two years in the future or so) :
  
    - define FF_API_LAVF_KEEPSIDE_FLAG to 0, and remove all code covered
  
      by it
  
    - define FF_API_MERGE_SD_API to 0, and remove all code covered by it
  This forces anyone who actually wants packet side data to temporarily
  
  use deprecated API to get it all. If you ask me, this is batshit fucked
  
  up crazy, but it’s how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be
  
  set by default was rejected as an ABI change, so I’m going all the way
  
  to get rid of this once and for all.
  Reviewed-by : James Almer <jamrial@gmail.com>
  
  Reviewed-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] doc/APIchanges
  • [DH] libavcodec/avcodec.h
  • [DH] libavcodec/avpacket.c
  • [DH] libavcodec/utils.c
  • [DH] libavcodec/version.h
  • [DH] libavformat/avformat.h
  • [DH] libavformat/mux.c
  • [DH] libavformat/options_table.h
  • [DH] libavformat/utils.c
  • [DH] libavformat/version.h