Recherche avancée

Sur d’autres sites (14890)

• How to recover video from H264 frames and timestamps [closed]

  10 juin 2024, par kokosda

  My service receives H264 frames and some metadata related to them like Timestamp from MS Teams.

  


  Observations :

  


  

  • Those frames are inter-frame compressed.

  


  • Resolution of those frames can change.

  


  • Timestamps are like this one 39264692280552704. That represents year 125 if fed to .NET consturctor new DateTime(39264692280552704), so I need to add 1899 years to get a real date.

  


  • I can wrap the sequence to a playable mp4 container with ffmpeg -i input.h264 -c copy output.mp4, however it is not what I want because the resulting video plays too fast, like on fast forward. Thus, I would like those timestamps would be considered to recover a real timeline.

  


  


  I merged all the H264 frames in one file like input.h264 and saved all the timestamps in another file like metadata.json. In metadata.json, each object describes a single frame from input.h264.

  


  My question is how to recover the source video from frames and timestamps that I received from Teams ? Particularly, using FFMPEG.

  


• 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>
  

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

• mmaldec : fix problems with flush logic

  8 septembre 2015, par wm4

  mmaldec : fix problems with flush logic
  Don’t try to do a blocking wait for MMAL output if we haven’t even sent
  
  a single real packet, but only flush packets. Obviously we can’t expect
  
  to get anything back.
  Additionally, don’t send a flush packet to MMAL in the same case. It
  
  appears the MMAL decoder will sometimes hang in mmal_vc_port_disable()
  
  (called from ffmmal_close_decoder()), waiting for a reply from the GPU
  
  which never arrives. Either MMAL disallows sending flush packets without
  
  preceding real data, or it’s a MMAL bug.
  Signed-off-by : Luca Barbato <lu_zero@gentoo.org>
  

  • [DBH] libavcodec/mmaldec.c