Recherche avancée

Sur d’autres sites (8116)

• 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 ?

  


• add libaribb24 ARIB STD-B24 caption decoder

  14 janvier 2019, par Jan Ekström

  add libaribb24 ARIB STD-B24 caption decoder
  * Outputs ASS lines with basic coloring and font scaling for each
  
    given region.
  
  * Sets the default style to the resolution of the subtitle plane
  
    (for example, 960x540 / 36pt font for profile A).
  
  * Has options to :
  
    * Disable ruby text (which is coded as regions which have
  
      half-height text in libaribb24).
  
      Enabled by default as without positioning ruby text only
  
      confuses as it is usually coded in the beginning of the decoded
  
      subtitle line.
  
    * Set the working directory, in which libaribb24 will read
  
      configuration as well as into which it may save broadcast extra
  
      symbols as PNG.
  
      Unset by default.
  The unconventional library check can be explained by the library's
  
  current master branch being licensed as LGPLv3, but at the time of
  
  writing the latest official release is still licensed under GPLv3.
  Thus, one either has to wait for the following release, or enable
  
  GPLv3.
  

  • [DH] Changelog
  • [DH] configure
  • [DH] doc/decoders.texi
  • [DH] libavcodec/Makefile
  • [DH] libavcodec/allcodecs.c
  • [DH] libavcodec/avcodec.h
  • [DH] libavcodec/codec_desc.c
  • [DH] libavcodec/libaribb24.c
  • [DH] libavcodec/profiles.c
  • [DH] libavcodec/profiles.h
  • [DH] libavcodec/version.h

• arm : vp9itxfm : Skip empty slices in the first pass of idct_idct 16x16 and 32x32

  9 janvier 2017, par Martin Storsjö

  arm : vp9itxfm : Skip empty slices in the first pass of idct_idct 16x16 and 32x32
  This work is sponsored by, and copyright, Google.
  Previously all subpartitions except the eob=1 (DC) case ran with
  
  the same runtime :
                                       Cortex A7       A8       A9      A53
  
  vp9_inv_dct_dct_16x16_sub16_add_neon :   3188.1   2435.4   2499.0   1969.0
  
  vp9_inv_dct_dct_32x32_sub32_add_neon :  18531.7  16582.3  14207.6  12000.3
  By skipping individual 4x16 or 4x32 pixel slices in the first pass,
  
  we reduce the runtime of these functions like this :
  vp9_inv_dct_dct_16x16_sub1_add_neon :     274.6    189.5    211.7    235.8
  
  vp9_inv_dct_dct_16x16_sub2_add_neon :    2064.0   1534.8   1719.4   1248.7
  
  vp9_inv_dct_dct_16x16_sub4_add_neon :    2135.0   1477.2   1736.3   1249.5
  
  vp9_inv_dct_dct_16x16_sub8_add_neon :    2446.7   1828.7   1993.6   1494.7
  
  vp9_inv_dct_dct_16x16_sub12_add_neon :   2832.4   2118.3   2266.5   1735.1
  
  vp9_inv_dct_dct_16x16_sub16_add_neon :   3211.7   2475.3   2523.5   1983.1
  
  vp9_inv_dct_dct_32x32_sub1_add_neon :     756.2    456.7    862.0    553.9
  
  vp9_inv_dct_dct_32x32_sub2_add_neon :   10682.2   8190.4   8539.2   6762.5
  
  vp9_inv_dct_dct_32x32_sub4_add_neon :   10813.5   8014.9   8518.3   6762.8
  
  vp9_inv_dct_dct_32x32_sub8_add_neon :   11859.6   9313.0   9347.4   7514.5
  
  vp9_inv_dct_dct_32x32_sub12_add_neon :  12946.6  10752.4  10192.2   8280.2
  
  vp9_inv_dct_dct_32x32_sub16_add_neon :  14074.6  11946.5  11001.4   9008.6
  
  vp9_inv_dct_dct_32x32_sub20_add_neon :  15269.9  13662.7  11816.1   9762.6
  
  vp9_inv_dct_dct_32x32_sub24_add_neon :  16327.9  14940.1  12626.7  10516.0
  
  vp9_inv_dct_dct_32x32_sub28_add_neon :  17462.7  15776.1  13446.2  11264.7
  
  vp9_inv_dct_dct_32x32_sub32_add_neon :  18575.5  17157.0  14249.3  12015.1
  I.e. in general a very minor overhead for the full subpartition case due
  
  to the additional loads and cmps, but a significant speedup for the cases
  
  when we only need to process a small part of the actual input data.
  In common VP9 content in a few inspected clips, 70-90% of the non-dc-only
  
  16x16 and 32x32 IDCTs only have nonzero coefficients in the upper left
  
  8x8 or 16x16 subpartitions respectively.
  This is cherrypicked from libav commit
  
  9c8bc74c2b40537b0997f646c87c008042d788c2.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/arm/vp9itxfm_neon.S
  • [DH] tests/checkasm/vp9dsp.c