Recherche avancée

Sur d’autres sites (5221)

• lavc/pthread_frame : Update user context in ff_frame_thread_free

  27 décembre 2019, par Linjie Fu

  lavc/pthread_frame : Update user context in ff_frame_thread_free
  Resolution/format changes lead to re-initialization of hardware
  
  accelerations(vaapi/dxva2/..) with new hwaccel_priv_data in
  
  the worker-thread. But hwaccel_priv_data in user context won't
  
  be updated until the resolution changing frame is output.
  A termination with "-vframes" just after the reinit will lead to :
  
      1. memory leak in worker-thread.
  
      2. double free in user-thread.
  Update user context in ff_frame_thread_free with the last thread
  
  submit_packet() was called on.
  To reproduce :
  
  ffmpeg -hwaccel vaapi(dxva2) -v verbose -i
  
      fate-suite/h264/reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12
  
      -f rawvideo -vsync passthrough -vframes 47 -y out.yuv
  Signed-off-by : Linjie Fu <linjie.fu@intel.com>
  
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DH] libavcodec/pthread_frame.c

• h264_mp4toannexb : Improve extradata overread checks

  14 décembre 2019, par Andreas Rheinhardt

  h264_mp4toannexb : Improve extradata overread checks
  Currently during parsing the extradata, h264_mp4toannexb checks for
  
  overreads by adding the size of the current unit to the current position
  
  pointer and comparing this to the end position of the extradata. But
  
  pointer comparisons and pointer arithmetic are only defined if it does not
  
  exceed the object it is used on (one past the last element of an array
  
  is allowed, too). In practice, this might lead to overflows. Therefore
  
  the check has been changed to use bytestream2_get_bytes_left() which
  
  means that the pointers get subtracted and the result gets compared to
  
  the available size.
  Furthermore, the error code has been fixed.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/h264_mp4toannexb_bsf.c

• How would I go about packaging an mp3 file into an mp4 container ?

  22 novembre 2020, par Jacob

  So here's the issue that I'm currently having. I need an audio player for iOS that will play mp3. Now at first glance this may seem like a trivial issue, just create an audio tag and give it the URL to the mp3 file. While this technically works, it's basically unusable since iOS needs to download the entire file before starting to play it. This results in a really long wait time when trying to play large mp3 files (could get close to a minute).
So the first thing I tried was to manually mimic the chunking that chrome does for playing mp3 files. I first sent a HEAD request to get the byte length of the audio file. Used that length / duration in seconds to get the average bytes per second and use that data to request chunks based on where the user seeks to. That didn't work since sometimes mp3 files contain metadata that throw off the calculation (like a cover image). Additionally, sometimes mp3 files use VBR (Variable Bit Rate) and then I'm well and truly screwed.

  



  So this lead me to thinking, Safari couldn't possibly require the end user to download an entire mp4 file before playing it. So I took an mp3 file, converted it to mp4 on an online converter and tested my theory out. Voila, it worked. Safari was streaming the mp4 file in chunks and the wait time went to close to 0. Alright, so now all I need to do is convert mp3 files to mp4 files. The problem now is, I have requirement not to use my server for converting these files. I want to offload this expensive operation to the client. After looking around for a bit I found a few wasm libraries to do this, great ! Nope. These wasm libraries are huge (24 MB) and would add an unacceptable amount to my already large bundles files. So this brings me to my question. Is there any way to "trick" safari into thinking that my mp3 file is mp4. What I've tried already :

  



  On input change event -> get the file -> clone it into a new Blob with a mimeType of video/mp4 and then upload that file to the server. Chrome plays this file no problem (probably because it detects it's an mp3 file), on Safari however it's unable to play the file.

  



  So my question is, is there any way to package the mp3 file in an mp4 container (Client Side !important) to "force" Safari into chunking the file.