Recherche avancée

Sur d’autres sites (9276)

• Read S3 video file, process it with ffmpeg and upload to S3

  28 avril 2020, par Dario Rusignuolo

  I have a video stored in s3 bucket with authenticated-read ACL.

  



  I need to read and make a trailer with ffmpeg (nodejs)

  



  Here's the code I use to generate the trailer

  



  exports.generatePreview = (req, res) => {
    const getParams = {
        Bucket: S3_CREDENTIALS.bucketName,
        Key: req.params.key
    }
    s3.getSignedUrl('getObject', getParams, (err, signedRequest) => {
        console.log(signedRequest, err, 'getSignedUrl')
        ffmpeg(new URL(signedRequest))
            .size('640x?')
            .aspect('4:3')
        .seekInput('3:00')
        .duration('0:30')
        .then(function (video) {
            s3.putObject({ Bucket: S3_CREDENTIALS.bucketName, key: 'preview_' + req.body.key, Body: video }, function (err, data) {
                console.log(err, data)
            })
        });
});


  



  }

  



  Unfortunately, the constructor path seems not to read remote url. If I try to execute an ffmpeg command line with the same signedurl (i.e. ffmpeg -i "https://[bucketname].s3.eu-west-1.amazonaws.com/[key.mp4]?[signedParams]" -vn -acodec pcm_s16le -ar 44100 -ac 2 video.wav)

  



  The error I get is that the signedRequest url 'The input file does not exist'

  



  It seems fs.readFileSync https is not supported even if I try the request with http with the same result. fs.readFileSync(signedurl) => gives the same result

  



  How to overcome this issue ?

  


• avformat/flacenc : Only update streaminfo if it has changed

  12 avril 2020, par Andreas Rheinhardt

  avformat/flacenc : Only update streaminfo if it has changed
  An AVStream's codecpar is supposed to be filled by the caller before
  
  avformat_write_header() ; if the CodecParameters change, the caller
  
  should signal this via packet side data, but not touch the AVStream's
  
  codecpar.
  The FLAC muxer checks for packet side data containing updated extradata,
  
  yet if nothing has arrived by the time the trailer is written, the
  
  already written extradata is overwritten by the very same extradata
  
  again, unless the output is unseekable, in which case a warning that the
  
  FLAC header can't be rewritten is emitted.
  This commit changes this by only trying to rewrite the extradata if a
  
  new streaminfo arrived via packet side data. Only then is a warning
  
  emitted in case the output is unseekable.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/flacenc.c

• avformat/mux : Make uncoded frames av_packet_unref() compatible

  9 août 2019, par Andreas Rheinhardt

  avformat/mux : Make uncoded frames av_packet_unref() compatible
  Currently uncoded frames (i.e. packets whose data actually points to an
  
  AVFrame) are not refcounted. As a consequence, calling av_packet_unref()
  
  on them will not free them, but may simply make sure that they leak by
  
  losing the pointer to the frame.
  This commit changes this by actually making uncoded frames refcounted.
  
  In order not to rely on sizeof(AVFrame) (which is not part of the public
  
  API and so must not be used here in libavformat) the packet's data is
  
  changed to a (padded) buffer containing just a pointer to an AVFrame.
  
  Said buffer is owned by an AVBuffer with a custom free function that
  
  frees the frame as well as the buffer. Thereby the pointer/the AVBuffer
  
  owns the AVFrame.
  Said ownership can actually be transferred by copying and resetting
  
  the pointer, as might happen when actually writing the uncoded frames
  
  in AVOutputFormat.write_uncoded_frame() (although currently no muxer
  
  makes use of this possibility).
  This makes packets containing uncoded frames compatible with
  
  av_packet_unref(). This already has three advantages in interleaved mode :
  
  1. If an error happens at the preparatory steps (before the packet is
  
  put into the interleavement queue), the frame is properly freed.
  
  2. If the trailer is never written, the frames still in the
  
  interleavement queue will now be properly freed by
  
  ff_packet_list_free().
  
  3. The custom code for moving the packet to the packet list in
  
  ff_interleave_add_packet() can be removed.
  It will also simplify fixing further memleaks in future commits.
  Suggested-by : Marton Balint <cus@passwd.hu>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/mux.c