Recherche avancée

Sur d’autres sites (7518)

• Feeding raw image bytes into ffmpeg rawvideo fails with Invalid buffer size on linux only

  13 février 2021, par cherouvim

  I have a nodejs program which generates raw (rgb24) image(s), which I then pipe into ffmpeg so it saves as png or mp4. My code looks like this :

  


  const fs = require("fs");
// ...
const outputBuffer = Buffer.alloc(outputPngWidth * 3 * outputPngHeight);
// ... write data into outputBuffer
fs.writeSync(process.stdout.fd, outputBuffer);


  


  I then do the following in CLI :

  


  node generate | ffmpeg -f rawvideo -pixel_format rgb24 -video_size 1000x1000 -i - test.png


  


  Alternatively, if I generate lots of images from my program, I do this to generate the video file :

  


  node generate | ffmpeg -f rawvideo -pixel_format rgb24 -video_size 1000x1000 -r 60 -i - -codec:v libx265 test.mp4


  


  On windows this works flawlessly. On linux (either on Ubuntu 20 VM, or Ubuntu 20 installed directly on a physical machine), it consistently fails with :

  


  pipe:: corrupt input packet in stream 0
[rawvideo @ 0x55f5256c8040] Invalid buffer size, packet size 65536 < expected frame_size 3000000
Error while decoding stream #0:0: Invalid argument


  


  If I split this in 2 phases like so, then it works perfectly on linux as well :

  


  node generate > test.raw
cat test.raw | ffmpeg -f rawvideo -pixel_format rgb24 -video_size 1000x1000 -i - test.png


  


  By looking at the error "packet size 65536 < expected frame_size 3000000" it seems that node's fs.writeSync only sends 65536 bytes at a time, but ffmpeg expects 3000000 bytes (that is 1000 width * 1000 height * 3 channels).

  &#xA;

  If I reduce my image size to something small, e.g 50x50 or 100x100, then it works. As soon as x * y * 3 exceeds 65536, it fails (eg. 160x160 fails with "packet size 65536 < expected frame_size 76800" because 160 * 160 * 3 = 76800).

  &#xA;

  What I've tried so far to solve the issue without luck :

  &#xA;

  &#xA;
  • Force node to spit out the whole buffer at once :

  &#xA;

  &#xA;

  fs.writeSync(process.stdout.fd, outputBuffer, 0, outputBuffer.length);


  &#xA;

  &#xA;
  • All suggestions of Add a big buffer to a pipe between two commands with various linux commands to buffer between node and ffmpeg.

  &#xA;

  • Use Ubuntu 18 instead of 20.

  &#xA;

  • Use node 12 instead of 15.

  &#xA;

  • Figure out a way to change the chunk size in https://nodejs.org/api/fs.html

  &#xA;

  &#xA;

  Is there a way to overcome this ?

  &#xA;

• 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).

• 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

  &#xA;

  Here I leave the command that I am using :

  &#xA;

  .\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


  &#xA;

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

  &#xA;

  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


  &#xA;

  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

  &#xA;

  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

  &#xA;