Recherche avancée

Sur d’autres sites (8057)

• AWS lambda SAM deploy error - Template format error : Unresolved resource dependencies

  1er juin 2022, par mozenge

  I have am trying to deploy an aws lambda function using the SAM cli. I have some layers defined in the sam template. Testing locally using sam local start-api works quite well. The but deploying using the sam deploy --guided command throws the following error
Error: Failed to create changeset for the stack: sam-app, ex: Waiter ChangeSetCreateComplete failed: Waiter encountered a terminal failure state: For expression "Status" we matched expected path: "FAILED" Status: FAILED. Reason: Template format error: Unresolved resource dependencies [arn:aws:lambda:us-west-1:338231645678:layer:ffmpeg:1] in the Resources block of the template

  


  The SAM template is as follows

  


  AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  video-processor-functions

  Functions to generate gif and thumbnail from uploaded videos
  
# More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
Globals:
  Function:
    Timeout: 3
    Tracing: Active

Resources:
  VideoProcessorFunctions:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      CodeUri: src/
      Handler: app.lambdaHandler
      Runtime: nodejs14.x
      # timeout in seconds - 2 minutes
      Timeout: 120
      Layers:
        - !Ref VideoProcessorDepLayer
        - !Ref arn:aws:lambda:us-west-1:338231645678:layer:ffmpeg:1
      Architectures:
        - x86_64
      Events:
        HelloWorld:
          Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
          Properties:
            Path: /hello
            Method: get

  VideoProcessorDepLayer:
    Type: AWS::Serverless::LayerVersion
    Properties:
      LayerName: mh-video-processor-dependencies
      Description: Dependencies for sam app [video-processor-functions]
      ContentUri: dependencies/
      CompatibleRuntimes:
        - nodejs14.17
      LicenseInfo: 'MIT'
      RetentionPolicy: Retain

Outputs:
  # ServerlessRestApi is an implicit API created out of Events key under Serverless::Function
  # Find out more about other implicit resources you can reference within SAM
  # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api
  HelloWorldApi:
    Description: "API Gateway endpoint URL for Prod stage for Hello World function"
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
  VideoProcessorFunctions:
    Description: "Generate GIF and Thumnail from Video"
    Value: !GetAtt VideoProcessorFunctions.Arn
  VideoProcessorFunctionsIamRole:
    Description: "Implicit IAM Role created for MH Video Processor function"
    Value: !GetAtt VideoProcessorFunctionsRole.Arn



  


  Any ideas what i'm doing wrong ?

  


• Why does OpenCV read video faster than FFMPEG ?

  17 septembre 2022, par tadejsv

  I noticed that OpenCV reads video frames almost 2x faster than FFMPEG.

  


  Why is that ? I thought all OpenCV does is call FFMPEG under the hood, possibly adding its own overhead.

  


  Here's the code I use to obtain these results

  


  import cv2
import time
import numpy as np

cap = cv2.VideoCapture("BigBuckBunny.mp4", apiPreference=cv2.CAP_FFMPEG)
frames = int(cap.get(cv2.CAP_PROP_FRAME_COUNT))

start = time.perf_counter()
while True:
    ret, frame = cap.read()
    if ret is False:
        break
    assert frame.shape == (720, 1280, 3)
    assert frame.dtype == np.uint8
end = time.perf_counter()

print(f"{frames/(end-start):.1f} frames per second")
# Output: 692.3 frames per second

cap.release()


  


  For FFMPEG (using the python-ffmpeg library :

  


  import ffmpeg
import numpy as np
import time

vid_info = ffmpeg.probe("BigBuckBunny.mp4")['streams'][1]
frames = int(vid_info['nb_frames'])

process1 = (
    ffmpeg
    .input("BigBuckBunny.mp4")
    .output('pipe:', format='rawvideo', pix_fmt='bgr24')
)
print(process1.compile())
# Output: ['ffmpeg', '-i', 'BigBuckBunny.mp4', '-f', 'rawvideo', '-pix_fmt', 'bgr24', 'pipe:']


process1 = process1.run_async(pipe_stdout=True)

start = time.perf_counter()
while True:
    in_bytes = process1.stdout.read(1280 * 720 * 3)
    if not in_bytes:
        break
    frame = np.frombuffer(in_bytes, np.uint8).reshape([720, 1280, 3])
end = time.perf_counter()
print(f"{frames/(end-start):.1f} frames per second")
# Output: 373.6 frames per second
process1.wait()


  


  Here's information about the video ( 10 minutes length)

  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'BigBuckBunny.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isomavc1mp42
    creation_time   : 2010-01-10T08:29:06.000000Z
  Duration: 00:09:56.47, start: 0.000000, bitrate: 2119 kb/s
  Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default)
    Metadata:
      creation_time   : 2010-01-10T08:29:06.000000Z
      handler_name    : (C) 2007 Google Inc. v08.13.2007.
      vendor_id       : [0][0][0][0]
  Stream #0:1(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1991 kb/s, 24 fps, 24 tbr, 24k tbn, 48 tbc (default)
    Metadata:
      creation_time   : 2010-01-10T08:29:06.000000Z
      handler_name    : (C) 2007 Google Inc. v08.13.2007.
      vendor_id       : [0][0][0][0]


  


  And FFMPEG and OpenCV versions :

  


  ffmpeg version 4.4.2-0ubuntu0.22.04.1 Copyright (c) 2000-2021 the FFmpeg developers


  


  opencv-python-headless        4.6.0.66


  


• configure : Make MSVC version grabbing more robust

  13 juin, par Martin Storsjö

  configure : Make MSVC version grabbing more robust
  When running plain "cl", to get the MSVC version, it prints the
  
  version header on stderr, while the usage instructions are printed
  
  on stdout. Usually, the version on stderr gets flushed first,
  
  so "head -n1" gets the line it expects, but some times (in particular
  
  when running MSVC wrapped in wine), it can get the usage line
  
  first.
  Redirect stdout to /dev/null, so we only grab the version among
  
  the lines printed to stderr. This should make the version number
  
  grabbing more robust.
  At least all relevant versions of MSVC seem to print this specifically
  
  to stderr, not stdout (so we don't risk to miss it) ; checked down
  
  to MSVC 2010.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] configure