Recherche avancée

Sur d’autres sites (7357)

• Curator of the Samples Archive

  13 mai 2011, par Multimedia Mike — General

  Remember how I mirrored the world-famous MPlayerHQ samples archive a few months ago ? Due to a series of events, the original archive is no longer online. However, me and the people who control the mplayerhq.hu domain figured out how to make samples.mplayerhq.hu point to samples.multimedia.cx.

  That means... I’m the current owner and curator of our central multimedia samples repository. Such power ! This should probably be the fulfillment of a decade-long dream for me, having managed swaths of the archive, most notably the game formats section.

  How This Came To Be

  If you pay any attention to the open source multimedia scene, you might have noticed that there has been a smidge of turmoil. Heated words were exchanged, authority was questioned, some people probably said some things they didn’t mean, and the upshot is that, where once there was one project (FFmpeg), there are now 2 projects (also Libav). And to everyone who has wanted me to mention it on my blog— there, I finally broke my silence and formally acknowledged the schism.

  For my part, I was just determined to ensure that the samples archive remained online, preferably at the original samples.mplayerhq.hu address. There are 10 years worth of web links out there pointing into the original repository.

  Better Solution

  I concede that it’s not entirely optimal to host the repository here at multimedia.cx. While I can offer a crazy amount of monthly bandwidth, I can’t offer rsync (invaluable for keeping mirrors in sync), nor can the server provide anonymous FTP or allow me to offer accounts to other admins who can manage the repository.

  The samples archive is also mirrored at samples.libav.org/samples. I understand that service is provided by VideoLAN. Right now, both repositories are known to be static. I’m open to brainstorms about how to improve the situation.

• Issue with yt-dlp and FFMPEG Converting Webm to MP4 for 360 video : Unsupported channel layout "ambisonic 1"

  22 janvier 2024, par William L W L

  I am trying to convert .webm files to mp4. These are 360 videos that have been downloaded using yt-dlp.

  


  I have been using this command successfully, but it does not work on an M2 macbook pro. It works fine on PC.

  


  ffmpeg -y -i "/Users/x/Movies/Tropical_Rainforest_360.webm" -c:v libx265 -preset fast -crf 21 -vf "scale=4096x4096:out_range=full" -pix_fmt yuvj420p -aspect 1:1 -movflags faststart "/Users/x/Movies/Tropical_Rainforest_360.mp4"


  


  The error messages are as follows :

  


  [aac @ 0x12ae1fea0] Unsupported channel layout "ambisonic 1"
[aac @ 0x12ae1fea0] Qavg: nan
[aost#0:1/aac @ 0x12ae1fc30] Error while opening encoder - maybe incorrect parameters such as bit_rate, rate, width or height.
Error while filtering: Invalid argument
[swscaler @ 0x110dd0000] deprecated pixel format used, make sure you did set range correctly
[swscaler @ 0x120158000] deprecated pixel format used, make sure you did set range correctly
[swscaler @ 0x130208000] deprecated pixel format used, make sure you did set range correctly
    Last message repeated 1 times
[out#0/mp4 @ 0x600003f8c480] Nothing was written into output file, because at least one of its streams received no packets.
frame=    0 fps=0.0 q=0.0 Lsize=       0kB time=N/A bitrate=N/A speed=N/A    
Conversion failed!



  


  Context : I work in an educational setting which caters for vulnearble pupils. We cannot use Youtube in real time, this is mainly due to adverts or suggested videos that may trigger our pupils. Some children have mental health issues. Some children have also not been outdoors for several months/years due to medical conditions. We use 360 videos and VR to help bring the outside world inside, The YoutubeVR app is not an option since there is no way to install adblockers.

  


  The same script above works fine on a PC virtual machine which I can remote into from my Mac.

  


• lavu : fix memory leaks by using a mutex instead of atomics

  14 novembre 2014, par wm4

  lavu : fix memory leaks by using a mutex instead of atomics
  The buffer pool has to atomically add and remove entries from the linked
  
  list of available buffers. This was done by removing the entire list
  
  with a CAS operation, working on it, and then setting it back again
  
  (using a retry-loop in case another thread was doing the same thing).
  This could effectively cause memory leaks : while a thread was working on
  
  the buffer list, other threads would allocate new buffers, increasing
  
  the pool’s total size. There was no real leak, but since these extra
  
  buffers were not needed, but not free’d either (except when the buffer
  
  pool was destroyed), this had the same effects as a real leak. For some
  
  reason, growth was exponential, and could easily kill the process due
  
  to OOM in real-world uses.
  Fix this by using a mutex to protect the list operations. The fancy
  
  way atomics remove the whole list to work on it is not needed anymore,
  
  which also avoids the situation which was causing the leak.
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DBH] libavutil/buffer.c
  • [DBH] libavutil/buffer_internal.h