Recherche avancée

Sur d’autres sites (7467)

• Web-based video editor

  13 avril 2021, par Danny

  We have a web-based editor currently that allows users to build animated web apps. The apps are made up of shapes, text, images, and videos. Except for videos, all other elements can also be animated around the screen. The result of building a animated app is basically a big blob of JSON.

  



  The playback code for the web app is web-based as well. It takes the JSON blob and constructs the HTML, which ends up playing back in some sort of browser environment. The problem is that most of the time this playback occurs on lower-end hardware like televisions and set-top boxes.

  



  These performance issues go away if there is some way to be able to convert a digital sign to video. Then the STB/smart TV simply plays a video, which is much more performant than playing back animations in a web view.

  



  Given a blob of JSON describing each layer and how to draw each type of object, its animation points, etc, how could I somehow take that and convert it to video on the server ?

  



  My first attempt at this was using PhantomJS to load the playback page in a headless browser, take a series of screenshots, and then use ffmpeg to merge those screenshots into a video. That worked great so long as there is no video. But it does not work with video since there is no HTML5 video tag support in PhantomJS, and even if there was, I would lose any audio.

  



  The other way I was thinking of doing it would be to again load the playback page in PhantomJS, but turn off the video layers and leave them transparent, then take screenshots as a series of PNGs with transparency. I would then combine these with the video layers.

  



  None of this feels very elegant though. I know there are web-based video editors out there that basically do what I'm trying to accomplish, so how do they do it ?

  


• nodejs fluent-ffmpeg process is too slow

  22 août 2021, par snovosel

  I'm attempting to run the following ffmpeg command using fluent-ffmpeg and locally this command will take between 5-10 seconds. I have the same service deployed to a digital ocean server with 4CPU and 32GB of RAM as a test and the command will hang for sometimes up to 40 minutes. I'm uploading files 15mb-50mb in size as .mov files or .mp4 files. In all cases this has been too slow to be feasible... How can I begin to debug this ?

  


  const handleVideoResize = async (filePath) => {
  try {
    const { height, width } = await getVideoDimensions(filePath); // ffmpeg probe to get the dimensions

    const newWidth = 423;
    const newHeight = 534;

    const x = width - (newWidth / newHeight) * height;

    const destFilePath = path.resolve(`./tmp/final-${uuidv4()}.webm`);

    const outputStream = fs.createWriteStream(destFilePath);

    FFmpeg()
      .input(filePath)
      .input(path.resolve("assets/watermark.png"))
      .complexFilter([
        `[0]crop=${width - x}:${height},scale=${newWidth}:${newHeight}[a]`,
        "[1]scale=iw*0.2:-1[wm];[a][wm]overlay=x=(W-w)-15:y=(H-h)-15",
        `colorchannelmixer=aa=0.6[1]`
      ])
      .format("webm")
      .outputFormat("webm")
      .on("start", () => {
        printText("ffmpeg child process spawned ---");
      })
      .on("end", () => {
        printText("video stream finished");
      })
      .on("error", err => {
        printError("err ffmpeg", err);
      })
      .output(outputStream)
      .run();
  } catch (error) {
    printError("error handle video resize", error);
    return;
  }
};


  


• ffmpeg C API weird behaviour when running

  6 février 2023, par Turgut

  I have a c++ project which I've been using for a while (on a stable build now), recently I had a new debian setup a few days ago and I've set everything up. I set up ffmpeg like I always do and some of my other projects which also depend on ffmpeg seems to be working fine. I've checked ffplay and it works, along with the many different input videos I'm trying with. However, when I try to run the project mentioned, I get various weird behaviours on different videos. For example : some of them say moov atom not found, some of them throw a seg-fault, some of them just crashes the program without any warnings or segfaults or anything.

  


  Like I've said this is a fresh new debian build and the project is working just fine on other computers including this computer before I got a fresh debian (it was debian before aswell).

  


  Here is how I set up ffmpeg :

  


  

  1. Pull ffmpeg from it's github page and checkout to latest stable build branch (5.1)

  


  2. Sudo install dependencies like libx264-dev and nasm and a few more

  


  3. run ./configure --extra-libs="-lpthread -lm" --ld="g++" --disable-static --enable-shared --enable-gpl --enable-gnutls --enable-libfreetype --enable-nonfree --enable-libx264 --enable-opencl --enable-opengl

  


  4. run make, then sudo make install and finally sudo ldconfig.

  


  


  About the errors :

  


  

  • If I'm not getting a seg fault but the program just crashes without any errors, when I run valgrind it doesn't say anything (on .mp4 and .avi files mostly). So I ran with the --leak-check=full flag and get the following output (cropped some of it) :

  


  


  ...
==220709== 132 bytes in 1 blocks are possibly lost in loss record 323 of 386
==220709==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709==    by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE51E4: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BCB531: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49C7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 148 bytes in 1 blocks are possibly lost in loss record 327 of 386
==220709==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709==    by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE4FEA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BD4B2B: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49D1: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 148 bytes in 1 blocks are possibly lost in loss record 328 of 386
==220709==    at 0x483AB65: calloc (vg_replace_malloc.c:760)
==220709==    by 0x8C67DA0: g_malloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE4FEA: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE8589: g_type_register_fundamental (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BCFBF3: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49D6: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 184 bytes in 1 blocks are possibly lost in loss record 339 of 386
==220709==    at 0x483AD7B: realloc (vg_replace_malloc.c:834)
==220709==    by 0x8C67DE7: g_realloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6600.8)
==220709==    by 0x8BE3B76: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BE87AC: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BD67DE: g_param_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BD915A: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x8BC49DB: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6600.8)
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==220709== 
==220709== 1,502 (352 direct, 1,150 indirect) bytes in 1 blocks are definitely lost in loss record 368 of 386
==220709==    at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
==220709==    by 0x1D19819D: ???
==220709==    by 0x1D177ED3: ???
==220709==    by 0x1D18AAC9: ???
==220709==    by 0x1D1683B0: ???
==220709==    by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==220709==    by 0x40100E8: call_init (dl-init.c:30)
==220709==    by 0x40100E8: _dl_init (dl-init.c:119)
==220709==    by 0x4F82AEC: _dl_catch_exception (dl-error-skeleton.c:182)
==220709==    by 0x4014057: dl_open_worker (dl-open.c:758)
==220709==    by 0x4F82A8F: _dl_catch_exception (dl-error-skeleton.c:208)
==220709==    by 0x40138F9: _dl_open (dl-open.c:837)
==220709==    by 0x8D9B257: dlopen_doit (dlopen.c:66)
==220709== 
==220709== LEAK SUMMARY:
==220709==    definitely lost: 384 bytes in 3 blocks
==220709==    indirectly lost: 1,230 bytes in 20 blocks
==220709==      possibly lost: 1,352 bytes in 18 blocks
==220709==    still reachable: 189,789 bytes in 1,437 blocks
==220709==                       of which reachable via heuristic:
==220709==                         stdstring          : 1,845 bytes in 46 blocks
==220709==                         newarray           : 1,536 bytes in 16 blocks
==220709==         suppressed: 12 bytes in 1 blocks
==220709== Reachable blocks (those to which a pointer was found) are not shown.
==220709== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==220709== 
==220709== For lists of detected and suppressed errors, rerun with: -s
==220709== ERROR SUMMARY: 21 errors from 21 contexts (suppressed: 0 from 0)


  


  

  • As of writing this I've failed to replicate the error I got before about when I get a seg fault. As of now whether or not I get a segfault or not I'm getting the same output as above.

  


  


  What could be the reason for this ? Am I setting ffmpeg wrong ?