Recherche avancée

Sur d’autres sites (9664)

• Scripting FFmpeg to move text in y co-ordinate by some delta at specific time-codes

  27 février 2019, par distro.obs

  I’m using the basic drawtext command like this

  ffmpeg -i output.mp4 -vf \
  
  'drawtext=textfile='textfile.txt':x=0:y=0 \
  
  :fontsize=30:fontcolor=white:borderw=3 \
  
  :bordercolor=black:box=0' output.mp4"

  which puts stationary text at location (x, y) = (0,0)

  What I want to do is move this text by 10 points in y plane at certain time codes.

  at 00:00:10, y would be 0
  
  at 00:00:11, y would be 10
  
  at 00:00:43, y would be 20
  
  ...
  
  ...
  
  at 00:10:44, y would be 30

  so the ’y’ co-ordinate has a fix increment of 10 at ’keytimes’

  Is there a way to do that ?

• ffmpeg watermark without background [closed]

  22 décembre 2022, par Edwin Pitters

  I have a problem, I am trying to add a watermark to my videos with ffmpeg using a gtx 1060 graphics card, the process works well and very fast, the problem is that the watermark appears with a black background , the image has no background, it is transparent, the problem happens only when I use the nvidia graphics card, because if I do the process with my processor the watermark is placed correctly as expected, so I am sure it is a problem in my configuration when running ffmpeg

  


  Here I leave the command that I am using :

  


  .\ffmpeg.exe -y -hide_banner -init_hw_device cuda=cuda -filter_hw_device cuda -hwaccel cuda -hwaccel_output_format cuda -i test.mp4 -i watermark.png -filter_complex "[1:v]colorchannelmixer=aa=0.3,scale=iw*0.6:-1,format=nv12,hwupload[img];[0:v][img]overlay_cuda=x='if(lt(mod(t\,16)\,8)\,W-w-W*10/100\,W*10/100)':y='if(lt(mod(t+4\,16)\,8)\,H-h-H*5/100\,H*5/100)'[out]" -map [out] -c:v h264_nvenc -b:v 6M -an -preset fast out_overlay.mp4


  


  If I use my processor with the following command, the guide mark without background is added, that is, as expected

  


  for %%a in ("*.m*") do ffmpeg -y -hide_banner -threads 4 -i "%%a" -preset ultrafast -vcodec libx264 -b:v 4000k -minrate 4000k -maxrate 4000k -bufsize 4000k -c:a aac -b:a 64k -pass 1 -f mp4 NUL && ffmpeg -y -hide_banner -threads 8 -i "%%a" -i watermark.png -preset ultrafast -vcodec libx264 -b:v 4000k -minrate 4000k -maxrate 4000k -bufsize 4000k -filter_complex "[1]colorchannelmixer=aa=0.3,scale=iw*0.8:-1[a];[0][a]overlay=x='if(lt(mod(t\,8)\,4)\,W-w-W*10/100\,W*10/100)':y='if(lt(mod(t+2\,8)\,4)\,H-h-H*10/100\,H*10/100)'" -c:a copy -tune film -movflags +faststart -pass 2 "watermark/%%a"
pause


  


  I also tried changing colorchannelmixer=aa=0.3 for lut=a=val*0.3 but it seems that this command is not having any effect

  


  I find that the image is well reviewed to discard, in fact I tried with other images also with a transparent background and I have the same result, a watermark but with a black background

  


• Announcing the World’s Worst VP8 Encoder

  5 octobre 2010, par Multimedia Mike — Outlandish Brainstorms, VP8

  I wanted to see if I could write an extremely basic VP8 encoder. It turned out to be one of the hardest endeavors I have ever attempted (and arguably one of the least successful).

  Results
  I started with the Big Buck Bunny title image :

  
  
  

  And this is the best encoding that this experiment could yield :

  
  
  

  Squint hard enough and you can totally make out the logo. Pretty silly effort, I know. It should also be noted that the resultant .webm file holding that single 400×225 image was 191324 bytes. When FFmpeg decoded it to a PNG, it was only 187200 bytes.

  The Story
  Remember my post about a naive SVQ1 encoder ? Long story short, I set out to do the same thing with VP8. (I wanted to the same thing with VP3/Theora for years. But take a good look at what it would entail to create even the most basic bitstream. As involved as VP8 may be, its bitstream is absolutely trivial compared to VP3/Theora.)
  

  With the naive SVQ1 encoder, the goal was to create a minimally compliant SVQ1 encoded bitstream. For this exercise, I similarly hypothesized what it would take to create the most basic, syntactically correct VP8 bitstream with the least amount of effort. These are the overall steps I came up with :

  • Intra-only
  • Create a basic bitstream header that disables any extra features (no modification of default tables)
  • Use a static quantizer
  • Use intra 16×16 coding for each macroblock
  • Use vertical prediction for the 16×16 intra coding

  For coding each macroblock :

  • Subtract vertical predictor from each row
  • Perform forward transform on each 4×4 sub block
  • Perform forward WHT on luma plane DCT coefficients
  • Pack the coefficients into the bitstream via the Boolean encoder

  It all sounds so simple. But, like I said in the SVQ1 post, it’s all very much like carefully bootstrapping a program to run on a particular CPU, and the VP8 decoder serves as the CPU. I’m confident that I have the bitstream encoding correct because, at the very least, the decoder agrees precisely with the encoder about the numbers represented by those 0s and 1s.

  What’s Wrong ?
  Compromises were made for the sake of getting some vaguely recognizable image encoded in a minimally valid manner. One big stumbling block is that I couldn’t seem to encode an end of block (EOB) condition correctly. I then realized that it’s perfectly valid to just encode a lot of zero coefficients rather than signaling EOB. An encoding travesty, I know, and likely one reason that the resulting filesize is so huge.

  More drama occurred when I hit my first block that had all zeros. There were complications in that situation that I couldn’t seem to avoid. So I forced the first AC coefficient to be 1 in that case. Hey, the decoder liked it.

  As for the generally weird look of the decoded image, I’m thinking that could either be : A) an artifact of forcing 16×16 vertical prediction or ; or B) a mistake in the way that I transformed and predicted stuff before sending it to the decoder. The smart money is on a combination of both A and B.

  Then again, as the SVQ1 experiment demonstrated, I shouldn’t expect extraordinary visual quality when setting the bar this low (i.e., just getting some bag of bits that doesn’t make the decoder barf).