Recherche avancée

Sur d’autres sites (9104)

• FFmpeg - Concatenate all videos with similar file name ?

  24 décembre 2017, par Pan Hart

  Is there any way to use ffmpeg to concatenate all video files that have the exact same file name for the specified first few characters ?

  For example, if I set it to match the first 5 characters, it will match and concatenate video_1.flv, video_2.flv, video_3.flv and so on.

  But, at the same time, it can also match and concatenate tests_1.flv, tests_2.flv, tests_3.flv and so on.

  Any help will be appreciated !

• How to prevent gray overlays, transparency issues, and similar shader defects when using gl-transition filters

  29 janvier 2021, par Soren Wray

  I compiled and installed a local build of ffmpeg with support for gl-transition adapted from the official guide for Ubuntu. The build is configured with all relevant packages and seems to be working as intended. See the code samples at the end.

  


  I know the gl-transition filter is installed due to ./ffmpeg -v 0 -filters | grep gltransition, which outputs :

  


  T.. gltransition      VV->V      OpenGL blend transitions

  


  All sources were tested with the custom command string : ./ffmpeg -i ~/PATH/TO/INPUT1.mp4 -i ~/PATH/TO/INPUT2.mp4 -filter_complex "gltransition=duration=3:offset=1:source=/PATH/TO/EFFECT.glsl" -y ~/PATH/TO/OUTPUT.mp4, which is for a 3 second transition effect (duration=3), starting at 1 second (offset=1).

  


  I've been testing the code sources for various transition effects listed in the gl-transition gallery and have encountered some unusual gray overlays at the transition points, likely having to do with alpha channel transparency. In many cases, there are also shader or animation defects, e.g. with windowslice.glsl rendering only 1 slice when there are supposed to be 10, or again with WaterDrop.glsl, which simply fades out the clip in place of the intended ripple effect. Most complex animations seem to default to this monotonous gray overlay. I provide a gif example below for the GlitchedMemories.glsl transition.

  


  Example of Glitched Memories

  


  I couldn't locate any other reports of this particular issue online. The documentation for gl-transitions is sorely lacking and the Stack Exchange network has very little information about this custom filter. I don't know how to fix the problem. It could have something to do with the codec or pixel format used, or some quirk of my build, but the technical details are beyond me.

  


  Please note my compilation and configuration steps, perhaps the error is there :

  


  sudo apt-get update -qq && sudo apt-get -y install autoconf automake build-essential cmake git-core libass-dev libfreetype6-dev libgnutls28-dev libsdl2-dev libtool libunistring-dev libva-dev libvdpau-dev libvorbis-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev pkg-config texinfo wget yasm zlib1g-dev

mkdir -p ~/ffmpeg_sources ~/bin

sudo apt-get install nasm libx264-dev libx265-dev libnuma-dev libvpx-dev libfdk-aac-dev libmp3lame-dev libopus-dev

cd ~/ffmpeg_sources && wget -O ffmpeg-snapshot.tar.bz2 https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 && tar xjvf ffmpeg-snapshot.tar.bz2

cd ~/ && git clone https://github.com/transitive-bullshit/ffmpeg-gl-transition.git


  


  Open ~/ffmpeg-gl-transition/vf_gltransition.c in an editor and delete line : # define GL_TRANSITION_USING_EGL // remove this line if you don't want to use EGL

  


  cd ~/ffmpeg_sources/ffmpeg && cp ~/ffmpeg-gl-transition/vf_gltransition.c libavfilter/

git apply ~/ffmpeg-gl-transition/ffmpeg.diff

PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \
    --prefix="$HOME/ffmpeg_build" \
    --pkg-config-flags="--static" \
    --extra-cflags="-I$HOME/ffmpeg_build/include" \
    --extra-ldflags="-L$HOME/ffmpeg_build/lib" \
    --extra-libs="-lpthread -lm" \
    --bindir="$HOME/bin" \
    --enable-gpl \
    --enable-opengl \
    --enable-gnutls \
    --enable-libass \
    --enable-libfdk-aac \
    --enable-libfreetype \
    --enable-libmp3lame \
    --enable-libopus \
    --enable-libvorbis \
    --enable-libvpx \
    --enable-libx264 \
    --enable-libx265 \
    --disable-shared \
    --enable-static \
    --enable-runtime-cpudetect \
    --enable-filter=gltransition \
    --extra-libs='-lGLEW -lglfw' \
    --enable-nonfree && \
PATH="$HOME/bin:$PATH" make

source ~/.profile


  


• h264_mp4toannexb : Try to avoid four byte startcodes

  14 décembre 2019, par Andreas Rheinhardt

  h264_mp4toannexb : Try to avoid four byte startcodes
  According to the H.264 specifications, the only NAL units that need to
  
  have four byte startcodes in H.264 Annex B format are SPS/PPS units and
  
  units that start a new access unit. Before af7e953a, the first of these
  
  conditions wasn't upheld as already existing in-band parameter sets
  
  would not automatically be written with a four byte startcode, but only
  
  when they already were at the beginning of their input packets. But it
  
  made four byte startcodes be used too often as every unit that is written
  
  together with a parameter set that is inserted from extradata received a
  
  four byte startcode although a three byte start code would suffice
  
  unless the unit itself were a parameter set.
  FATE has been updated to reflect the changes. Although the patch leaves
  
  the extradata unchanged, the size of the extradata according to the FATE
  
  reports changes. This is due to a quirk in ff_h2645_packet_split which
  
  is used by extract_extradata : If the input is Annex B, the first zero of
  
  a four byte startcode is considered a part of the last unit (if any).
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/h264_mp4toannexb_bsf.c
  • [DH] tests/ref/fate/h264-bsf-mp4toannexb
  • [DH] tests/ref/fate/h264_mp4toannexb_ticket2991
  • [DH] tests/ref/fate/h264_mp4toannexb_ticket5927
  • [DH] tests/ref/fate/h264_mp4toannexb_ticket5927_2
  • [DH] tests/ref/fate/segment-mp4-to-ts