Recherche avancée

Sur d’autres sites (6210)

• Revert "avcodec : add FF_CODEC_CAP_INIT_CLEANUP for all codecs which use ff_mpv_common...

  24 décembre 2020, par Andreas Rheinhardt

  Revert "avcodec : add FF_CODEC_CAP_INIT_CLEANUP for all codecs which use ff_mpv_common_init()"
  This mostly reverts commit 4b2863ff01b1fe93d9a518523c9098d17a9d8c6f.
  
  Said commit removed the freeing code from ff_mpv_common_init(),
  
  ff_mpv_common_frame_size_change() and ff_mpeg_framesize_alloc() and
  
  instead added the FF_CODEC_CAP_INIT_CLEANUP to several codecs that use
  
  ff_mpv_common_init(). This introduced several bugs :
  a) Several decoders using ff_mpv_common_init() in their init function were
  
  forgotten : This affected FLV, Intel H.263, RealVideo 3.0 and V4.0 as well as
  
  VC-1/WMV3.
  
  b) ff_mpv_common_init() is not only called from the init function of
  
  codecs, it is also called from AVCodec.decode functions. If an error
  
  happens after an allocation has succeeded, it can lead to memleaks ;
  
  furthermore, it is now possible for the MpegEncContext to be marked as
  
  initialized even when ff_mpv_common_init() returns an error and this can
  
  lead to segfaults because decoders that call ff_mpv_common_init() when
  
  decoding a frame can mistakenly think that the MpegEncContext has been
  
  properly initialized. This can e.g. happen with H.261 or MPEG-4.
  
  c) Removing code for freeing from ff_mpeg_framesize_alloc() (which can't
  
  be called from any init function) can lead to segfaults because the
  
  check for whether it needs to allocate consists of checking whether the
  
  first of the buffers allocated there has been allocated. This part has
  
  already been fixed in 76cea1d2ce3f23e8131c8664086a1daf873ed694.
  
  d) ff_mpv_common_frame_size_change() can also not be reached from any
  
  AVCodec.init function ; yet the changes can e.g. lead to segfaults with
  
  decoders using ff_h263_decode_frame() upon allocation failure, because
  
  the MpegEncContext will upon return be flagged as both initialized and
  
  not in need of reinitialization (granted, the fact that
  
  ff_h263_decode_frame() clears context_reinit before the context has been
  
  reinited is a bug in itself). With the earlier version, the context
  
  would be cleaned upon failure and it would be attempted to initialize
  
  the context again in the next call to ff_h263_decode_frame().
  While a) could be fixed by adding the missing FF_CODEC_CAP_INIT_CLEANUP,
  
  keeping the current approach would entail adding cleanup code to several
  
  other places because of b). Therefore ff_mpv_common_init() is again made
  
  to clean up after itself ; the changes to the wmv2 decoder and the SVQ1
  
  encoder have not been reverted : The former fixed a memleak, the latter
  
  allowed to remove cleanup code.
  Fixes : double free
  
  Fixes : ff_free_picture_tables.mp4
  
  Fixes : ff_mpeg_update_thread_context.mp4
  
  Fixes : decode_colskip.mp4
  
  Fixes : memset.mp4
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/h261dec.c
  • [DH] libavcodec/h263dec.c
  • [DH] libavcodec/mpeg12dec.c
  • [DH] libavcodec/mpeg4videodec.c
  • [DH] libavcodec/mpegvideo.c
  • [DH] libavcodec/msmpeg4dec.c
  • [DH] libavcodec/rv10.c

• What google cloud service can be used to process files stored in Firebase Cloud Storage with FFmpeg ? [closed]

  1er mai 2021, par uponly

  I am building a ReactJs app and I am trying to figure out a way to process files (images, videos, and audio of any type) that are stored in my Firebase storage bucket using FFmpeg. Currently, I have set up the functionality for allowing the user to upload files to my storage bucket, and a corresponding URL link is stored in a document in Firestore.

  


  Ideally, I'd love to do this with Cloud Functions HTTP triggers because I have all of that setup already. It would be nice to just call an HTTP trigger to process the file after it has been uploaded. However, after a bit of research, my current understanding is to somehow deploy my app using a flexible Google App Engine environment because apparently, it is the only way to set a manual timeout in case I have to process a long, high-quality video, for example. Thus I wouldn't be able to use Cloud Functions because there is a very short timeout period which may lead to the files not being fully processed.

  


  Here is the user flow I am trying to achieve, which may help make things more clear :

  


  

  1. [Done] The user uploads a file (image, audio, or video) to Firebase cloud storage. A URL is also stored in their corresponding user document in Firestore.

  


  2. [Here and the steps onward are what I am trying to achieve] After the file has been stored, I'd like to kick off some sort of function that grabs the newly stored file and begin to process it in the cloud.

  


  3. Store the newly processed file back into the Cloud Storage bucket

  


  4. Allow the user to preview the processed file (by streaming it ideally, if possible).

  


  


  In steps 2 and onward, I am just generally confused about what Google service I should be using to process my file in the cloud with FFmpeg. As well as how I can connect it to my React app, client-side. If I have to go the Google App Engine route, how do I go about connecting app engine to my React App such that I don't have to build my app and deploy it, as my app is still in development ?

  


  This is not a coding question so I apologize if this is the wrong place to post in. I am new to all this, any and all help is greatly appreciated. Thank you.

  


• avcodec/encode : Fix check for allowed LJPEG pixel formats

  6 avril 2021, par Andreas Rheinhardt

  avcodec/encode : Fix check for allowed LJPEG pixel formats
  The pix_fmts of the LJPEG encoder already contain all supported pixel
  
  formats (including the ones only supported when strictness is unofficial
  
  or less) ; yet the check in ff_encode_preinit() ignored this list in case
  
  strictness is unofficial or less. But the encoder presumed that it is
  
  always applied and blacklists some of the entries in pix_fmts when
  
  strictness is > unofficial. The result is that if one uses an entry not
  
  on that list and sets strictness to unofficial, said entry passes both
  
  checks and this can lead to segfaults lateron (e.g. when using gray).
  Fix this by removing the exception for LJPEG in ff_encode_preinit().
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/encode.c