Recherche avancée

Sur d’autres sites (13425)

• Drawtext Effects Clipping with Zoom in and Scale animation When combining with xfade wipe

  2 août 2023, par CRAIG

  The following ffmpeg drawtext command is meant to manipulate the text with a number of filters. First it adds a wipe, then a "grow" effect and a fade.

  


  The issue is when the wipe AND scale are together the end result is partially clipped and the wipe doesn't seem to fully reveal the text as it should be doing. Almost like the scale or wipe was delayed.

  


  I have two example commands one with an xfade wipe effect and one without below.

  


  The one with xfade wipe clips text and looks like it is messing with the timing in some way as if the scale doesn't have time to finish. If I remove the xfade wipe, the scale animation and fadein are fine.

  


  I have tried to put the xfade at the end, but it has caused me more issues.

  


  Command without xfade : (Final result is not clipped)

  


  ffmpeg   -f  lavfi  -i  color=c=black@0.0:s=129x129:r=30:d=0.137,format=rgba    -f  lavfi  -i  color=c=black@0.0:s=129x129:r=30:d=0.137,format=rgba  -filter_complex  "[1:v]drawtext=expansion=none:enable='between(t,0,0.138)':fontsize=97.7886:fontcolor=0xff0000ff:text='Of':shadowcolor=0x00ff3fff:shadowx=5.9:shadowy=5.9:borderw='2.95':bordercolor='0xa200ffff':x=(w-text_w)/2:y=(h-text_h)/2[1v];[0:v]settb=AVTB,format=rgba[0v];[1v]settb=AVTB,format=rgba[1v];[1v]scale='if(between(t,0,0+0.137),0.645+((t-0)*128.355/0.137),if(gte(t,0.137),129,129))':-1:eval=frame,fade=in:st=0:d=0.137[1v];[0v][1v]overlay=x=(W-w)/2:y=(H-h)/2:threads=1"  -copyts  -c:v  prores_ks  -profile:v  4  -pix_fmt  rgba  -movflags  faststart  -r  30  -t  0.137  -y  /home/encodertraffic/subtitles/mymovie.mov

  


  Command with xfade wipe :

  


  ffmpeg   -f  lavfi  -i  color=c=black@0.0:s=129x129:r=30:d=0.137,format=rgba    -f  lavfi  -i  color=c=black@0.0:s=129x129:r=30:d=0.137,format=rgba  -filter_complex  "[1:v]drawtext=expansion=none:enable='between(t,0,0.138)':fontsize=97.7886:fontcolor=0xff0000ff:text='Of':shadowcolor=0x00ff3fff:shadowx=5.9:shadowy=5.9:borderw='2.95':bordercolor='0xa200ffff':x=(w-text_w)/2:y=(h-text_h)/2[1v];[0:v]settb=AVTB,format=rgba[0v];[1v]settb=AVTB,format=rgba[1v];[0v][1v]xfade=transition=wiperight:duration=0.137:offset=0,settb=AVTB,setpts=PTS-STARTPTS[1v];[1v]scale='if(between(t,0,0+0.137),0.645+((t-0)*128.355/0.137),if(gte(t,0.137),129,129))':-1:eval=frame,fade=in:st=0:d=0.137[1v];[0v][1v]overlay=x=(W-w)/2:y=(H-h)/2:threads=1"  -copyts  -c:v  prores_ks  -profile:v  4  -pix_fmt  rgba  -movflags  faststart  -r  30  -t  0.137  -y  mymovie2.mov

  


  Here are a couple of screenshots comparing the two at the same timestamp (the very end).

  


  The one on the left is without the wipe, the one on the right at the same timestamp is with the wipe, but you can see the text is partially clipped, it isn't at the same sacale and it isn't at full brightness almost as if the something is delaying all aspects of each filter.

  


  

  


• avcodec/parser : move parsers list and related API to its own file

  21 juillet 2018, par James Almer

  avcodec/parser : move parsers list and related API to its own file
  And add it to the CONFIGURABLE_COMPONENTS list in Makefile. This way, changes
  
  to the new file will be tracked and the usual warning to suggest re-running
  
  configure will be shown.
  Reviewed-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] Makefile
  • [DH] configure
  • [DH] libavcodec/Makefile
  • [DH] libavcodec/parser.c
  • [DH] libavcodec/parsers.c

• ffmpeg : combining/ordering vidstab and crop filters

  30 juillet 2016, par ljwobker

  I have a workflow which essentially takes a raw video file, crops away portions of the frame that aren’t relevant, then performs a two-pass deshake filter using the vidstab filter. At the moment I’m running this as three distinct commands : one to do the crop, a second to do the vidstab "detect" pass, and a third to do the vidstab "transform" pass.

  My working script :

  # do the crop first and strip the audio
  
  nice -20 ffmpeg -hide_banner -ss $SEEK -i $INFILE -t $DURATION -preset veryfast -crf 12 -vf crop=0.60*in_w:in_h/9*8:0.22*in_w:0 -an -y $TEMP
  
  
  
  # now run the vidstab detection pass
  
  nice -20 ffmpeg -hide_banner -i $TEMP -vf vidstabdetect=stepsize=6:shakiness=10:accuracy=15:result=${INFILE}.trf -f null - 
  
  
  
  # now the vidstab transform, with unsharp and writing the overlay text
  
  nice -20 ffmpeg -hide_banner -i $TEMP -preset veryfast -crf 22 -vf \
  
  " \
  
  vidstabtransform=input=${INFILE}.trf:zoom=2:smoothing=60, 
  
  unsharp=5:5:0.8:3:3:0.4, 
  
  drawtext=fontfile=/Windows/Fonts/arialbd.ttf:text=$DIVE:enable='between(t,0,65)':fontcolor=black:fontsize=72:x=w*0.01:y=h*0.01,  
  
  null"\
  
    -y $OUTFILE

  What I can’t seem to figure out is how I can combine the first two filter passes into a single chain, which (at least in theory) would be a faster encode time, and at the very least would be simpler to maintain and would eliminate a pass of the encoder. What I tried to do was the second code block, which just builds a filterchain that combines the initial crop with the vidstab detection filter.

  # this is a combined filter for the crop and the vidstab detect
  
  nice -20 ffmpeg -hide_banner -ss $SEEK -i $INFILE -t $DURATION -preset veryfast -crf 12 -vf \
  
  " \
  
  crop=0.60*in_w:in_h/9*8:0.22*in_w:0,
  
  vidstabdetect=stepsize=6:shakiness=10:accuracy=15:result=${INFILE}.trf,
  
  null " \
  
  -an -r 30 -y $TEMP
  
  
  
  
  
  # now run the transcoding and the vidstab transform
  
  nice -20 ffmpeg -hide_banner -i $TEMP -preset veryfast -crf 22 -vf \
  
  " \
  
  
  
  vidstabtransform=input=${INFILE}.trf:zoom=2:smoothing=60, 
  
  unsharp=5:5:0.8:3:3:0.4, 
  
  drawtext=fontfile=/Windows/Fonts/arialbd.ttf:text=$DIVE:enable='between(t,0,65)':fontcolor=black:fontsize=72:x=w*0.01:y=h*0.01,  
  
  
  
  null"\
  
    -y $OUTFILE

  However, when I run this (and it runs) the final output video has most definitely NOT been effectively stabilized. The logs show that both the detect and the transform passes have been processed, it’s just that the output isn’t right.