serverlesspub / ffmpeg-aws-lambda-layer

FFmpeg/FFprobe AWS Lambda layer
Other
401 stars 106 forks source link

Silently failing with fluent-ffmpeg #7

Open galipmedia opened 4 years ago

galipmedia commented 4 years ago

I am using this layer on one lambda function absolutely fine. But no matter what I try if I setup another lambda function with the exact same layers attached (my node_modules and this layer) it fails silently on any call. It just completely ignores the fluent-ffmpeg functions as if they are not there. I am completely baffled. I can see ffmpeg and ffprobe are there using fs readDirSync. I have tried deploying it as a second application so it gets a new arn and it still fails with 0 errors. Can anyone help me?

MatteoGioioso commented 4 years ago

I think I have the same problem. I have noticed a lot of timeouts. Increasing the lambda memory helped a lot, but we are still experiencing a lot of timeout. Not sure if caused by ffmpeg or this layer itself.

thiagocardoso1988 commented 4 years ago

I don't think I understood the problem. I'm currently using this layer alongside with fluent-ffmpeg with (almost) no problems.

I just added this in my serverless.yml, on the function that I need

  file_uploaded:
    handler: src/handlers/events/files.handle_upload
    timeout: 600
    memorySize: 2048
    events:
      - s3:
          bucket: "uploader-${self:provider.stage}"
          event: s3:ObjectCreated:*
    layers:
      - ${file(serverless.env.yml):${opt:stage}.env.FFMPEG_LAYER_ARN}

in my env file, I declared this layer:

local:
  region: us-east-1
  env:
    FFMPEG_LAYER_ARN: 'arn:aws:lambda:us-east-1:******:layer:ffmpeg:1'
dankentfield commented 4 years ago

I have also noticed this. When I run it as a child process it just stalls and does nothing - no logging (even with debug set) until the lambda times out. I tried upping the memory to the max but that made no difference.

I am doing a simple copy of the audio to the file system and it should be extremely fast and low RAM, its just not working. I also have tested my command locally and they work. This layer did previously work but it seems to have stopped for some reason.

dankentfield commented 4 years ago

@galipmedia did you manage to get this working?

I also tried re-deploying this but it didn't work for me either.

dankentfield commented 4 years ago

My last comment on this (Sorry for triple posting).

@galipmedia try changing to using child_process.spawnSync instead of child_process.spawn. It could be previous child processes are being preserved between invocations and causing this issue. Doing this resolved my issues.

Here's my stack overflow Q&A on this.

marknorrapscm commented 3 years ago

@dk03 Thankyou for this. I was experiencing the same issue and had been using spawn rather than spawnSync. I had been listening for both the close and exit events from ffmpeg and I think the issue with the process hanging likely was related to an old child process still being active within the Lambda container.

For any future readers, there is no need to apply event listeners when using spawnSync. I was listening for "exit" and "close" when using spawn, like this:

return new Promise((resolve, reject) => {
    const ffmpegParams = createFfmpegParams(targetSecond, thumbnailPath);
    const process = spawn(ffmpegPath, ffmpegParams);

    process.on("close", function (code) {
        resolve();
    });

    process.on("exit", function (code) {
        resolve();
    });

    process.on("error", function (err) {
        reject();
    });
});

Whereas, with spawnSync - which does not return the child process and will not proceed until the spawned process has completed, hence no need for event listeners - the code is much simpler:

const ffmpegParams = createFfmpegParams(targetSecond, thumbnailPath);
spawnSync(ffmpegPath, ffmpegParams);

Hopefully this is of use to future readers.