Recherche avancée

Sur d’autres sites (9011)

• How to send ffmpeg based HTTP stream to CloudFront [on hold]

  5 octobre 2017, par Tarun Maheshwari

  I have a live streaming server, where media is available as HTTP / RTMP / HLS format.
  I am able to access it and play from my desktop using following links.

   rtmp://52.xx.xx.192/live/tarun1 (RTMP)
  
   http://52.xx.xx.192:8080/hls/movie.m3u8 (HLS)
  
   http://52.xx.xx.190:7090/stream (HTTP)

  I want to forward any of the above streams to CloudFront with these steps.

• AWS Lambda and Fluent FFMPEG error "cannot read property "isStream" of undefined"

  29 mai 2021, par Travis Lee

  so here's the goal : convert a .webm file hosted in an S3 into a gif and upload that to a new bucket. This all works fine when run locally, but when trying to translate it into a lambda, fluent-ffmpeg throws errors when it runs the command.

  


  Here's the code snippet :

  


  ffmpeg(new URL(vid))
  .outputOptions("-vf", "scale=320:-1:flags=lanczos,fps=14")
  .on('progress', () => {
      console.log('progress');
  })
  .on('end', () => {
     //Do stuff with the result when it is done
  })
  .output(newKey)
  .run(newKey);


  


  in this snippet, "vid" is a presigned GET url for an S3 bucket containing the .webm video file, and "newKey" is the name of the new bucket (and a temporary writeStream/File that is created in the lambda to store the new .gif file until we upload it to S3 - not super relevant to this issue).

  


  What should happen (and does locally) is that a new output is created containing the converted .gif file

  


  What happens when it is deployed in a lambda is that it reaches the .outputOptions call and throws a type error saying that it cannot read property isStream of undefined.

  


  At first glance, this seems like I simply don't have FFMPEG installed in the lambda, but I do. I have tried with the prebuilt layer using NodeJS 10 found here : https://serverlessrepo.aws.amazon.com/applications/us-east-1/145266761615/ffmpeg-lambda-layer ,
with a NodeJS 12 layer that was built by some engineers here previously, and tried building a NodeJS 14 FFMPEG layer myself and using that. I tried for all three using no configuration and letting it call the PATH ffmpeg, using the FFMPEG_PATH and FFPROBE_PATH environment variables set to either what was specified in the previous layers, or what I made it in the newly built one, and even manually setting the path to the executables using the setFfmpegPath and setFfprobePath functions found on the fluent-ffmpeg object.

  


  Lastly, I even tried bundling the executables in with the actual lambda code itself and uploading it through an S3, trying all three above methods of getting it to point to the correct paths once again to no avail.

  


  I'm seriously in need of help if anyone else has encountered something similar or just might know what is going on. I'm at wit's end here trying to figure this out.

  


• avformat/hls : Check local file extensions

  3 juin 2017, par Sysiphus

  avformat/hls : Check local file extensions
  This reduces the attack surface of local file-system
  
  information leaking.
  It prevents the existing exploit leading to an information leak. As
  
  well as similar hypothetical attacks.
  Leaks of information from files and symlinks ending in common multimedia extensions
  
  are still possible. But files with sensitive information like private keys and passwords
  
  generally do not use common multimedia filename extensions.
  
  It does not stop leaks via remote addresses in the LAN.
  The existing exploit depends on a specific decoder as well.
  
  It does appear though that the exploit should be possible with any decoder.
  
  The problem is that as long as sensitive information gets into the decoder,
  
  the output of the decoder becomes sensitive as well.
  
  The only obvious solution is to prevent access to sensitive information. Or to
  
  disable hls or possibly some of its feature. More complex solutions like
  
  checking the path to limit access to only subdirectories of the hls path may
  
  work as an alternative. But such solutions are fragile and tricky to implement
  
  portably and would not stop every possible attack nor would they work with all
  
  valid hls files.
  Developers have expressed their dislike / objected to disabling hls by default as well
  
  as disabling hls with local files. There also where objections against restricting
  
  remote url file extensions. This here is a less robust but also lower
  
  inconvenience solution.
  
  It can be applied stand alone or together with other solutions.
  
  limiting the check to local files was suggested by nevcairiel
  Found-by : Emil Lerner and Pavel Cheremushkin
  
  Reported-by : Thierry Foucu <tfoucu@google.com>
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/hls.c