Recherche avancée

Sur d’autres sites (6066)

• How to process and upload large video files directly to cloud with ffmpeg but without fragmented MP4 ?

  9 avril 2024, par volume one

  I am using ffmpeg via fluent-ffpmeg for Node.js to process videos uploaded by users.

  


  The problem I have is if a user uploades a huge movie file, say 8GB in size, then I don't want to store the file on the server as it will soon reach full capacity of space.

  


  I thought a way to tackle this was to stream the output from ffmpeg straight to cloud storage like AWS S3. The only way to do this (I believe) is using a PassThrough() stream :

  


  import PassThrough from 'node:stream' ;
import FFMpeg from 'fluent-ffmpeg' ;

  


  let PassThroughStream = new PassThrough() ;

  


           FFMpeg('/testvideo.mp4')
                .videoCodec('libx264')
                .audioCodec('libmp3lame')
                .size(`640x480`)
                // Stream input requires manually specifying input format
                .inputFormat('mp4')
                // Stream output requires manually specifying output formats
                .format('mp4')
                // Must be fragmented for stream to work. This causes duration problem.
                .outputOptions('-movflags dash')
                .pipe(PassThroughStream, {end: true})


  


  When the video is created using fragmented MP4, there is no duration associated with the file which means it has no length metadata. That makes playback difficult in a browser and is unacceptable :

  


  

  


  The only way I have been able to get a proper length property set in the file's metadata is by not using fragmented MP4 (that is the -movflags dash part in the code above). By not using this, I cannot stream the output directly to cloud storage - I have to save the file somewhere locally first.

  


  I think I am missing something but don't know what. How could this be solved ? I want to process and write the output to AWS S3 without storing the file locally without creating a fragmented MP4.

  


• avutil/mem : limit alignment to maximum simd align

  3 décembre 2023, par Timo Rothenpieler

  avutil/mem : limit alignment to maximum simd align
  FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
  
  which then end up heap-allocated.
  
  By declaring any variable in a struct, or tree of structs, to be 32 byte
  
  aligned, it allows the compiler to safely assume the entire struct
  
  itself is also 32 byte aligned.
  This might make the compiler emit code which straight up crashes or
  
  misbehaves in other ways, and at least in one instances is now
  
  documented to actually do (see ticket 10549 on trac).
  
  The issue there is that an unrelated variable in SingleChannelElement is
  
  declared to have an alignment of 32 bytes. So if the compiler does a copy
  
  in decode_cpe() with avx instructions, but ffmpeg is built with
  
  — disable-avx, this results in a crash, since the memory is only 16 byte
  
  aligned.
  Mind you, even if the compiler does not emit avx instructions, the code
  
  is still invalid and could misbehave. It just happens not to. Declaring
  
  any variable in a struct with a 32 byte alignment promises 32 byte
  
  alignment of the whole struct to the compiler.
  This patch limits the maximum alignment to the maximum possible simd
  
  alignment according to configure.
  
  While not perfect, it at the very least gets rid of a lot of UB, by
  
  matching up the maximum DECLARE_ALIGNED value with the alignment of heap
  
  allocations done by lavu.
  

  • [DH] libavutil/mem.c
  • [DH] libavutil/mem_internal.h

• avutil/mem : limit alignment to maximum simd align

  3 décembre 2023, par Timo Rothenpieler

  avutil/mem : limit alignment to maximum simd align
  FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
  
  which then end up heap-allocated.
  
  By declaring any variable in a struct, or tree of structs, to be 32 byte
  
  aligned, it allows the compiler to safely assume the entire struct
  
  itself is also 32 byte aligned.
  This might make the compiler emit code which straight up crashes or
  
  misbehaves in other ways, and at least in one instances is now
  
  documented to actually do (see ticket 10549 on trac).
  
  The issue there is that an unrelated variable in SingleChannelElement is
  
  declared to have an alignment of 32 bytes. So if the compiler does a copy
  
  in decode_cpe() with avx instructions, but ffmpeg is built with
  
  — disable-avx, this results in a crash, since the memory is only 16 byte
  
  aligned.
  Mind you, even if the compiler does not emit avx instructions, the code
  
  is still invalid and could misbehave. It just happens not to. Declaring
  
  any variable in a struct with a 32 byte alignment promises 32 byte
  
  alignment of the whole struct to the compiler.
  This patch limits the maximum alignment to the maximum possible simd
  
  alignment according to configure.
  
  While not perfect, it at the very least gets rid of a lot of UB, by
  
  matching up the maximum DECLARE_ALIGNED value with the alignment of heap
  
  allocations done by lavu.
  

  • [DH] libavutil/mem.c
  • [DH] libavutil/mem_internal.h