Recherche avancée

Sur d’autres sites (3641)

• http: Stop reading after receiving the whole file for non-chunked transfers

  11 août 2014, par Martin Storsjö

  http: Stop reading after receiving the whole file for non-chunked transfers
  Previously this logic was only used if the server didn’t
  
  respond with Connection : close, but use it even for that case,
  
  if the server response is non-chunked.
  Originally the http code has relied on Connection : close to close
  
  the socket when the file/stream is received - the http protocol
  
  code just kept reading from the socket until the socket was closed.
  
  In f240ed18 we added a check for the file size, because some
  
  http servers didn’t respond with Connection : close (and wouldn’t
  
  close the socket) even though we requested it, which meant that the
  
  http protocol blocked for a long time at the end of files, waiting
  
  for a socket level timeout.
  When reading over tls, trying to read at the end of the connection,
  
  when the peer has closed the connection, can produce spurious (but
  
  harmless) warnings. Therefore always voluntarily stop reading when
  
  the specified file size has been received, if not using a chunked
  
  transfer encoding. (For chunked transfers, we already return 0
  
  as soon as we get the chunk header indicating end of stream.)
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/http.c

• How to free an AVBuffer and prevent a memory leak, when created with FFmpeg.AutoGen

  27 février 2023, par FrostKiwi

  Regarding https://github.com/Ruslan-B/FFmpeg.AutoGen.Questions/issues/36.

  


  I am using FFmpeg.AutoGen to inject per-Frame Metadata into a video in my C# program via an H.264 SEI Message. Works great. To do so I use av_frame_new_side_data_from_buf(), which requires an AVBuffer to hold the SEI message, pointed at via an AVBufferRef. This behavior is achieved via the following block. ( Full source file referenced in the GitHub issue. )

  


  fixed (byte* pMessageData = message)
{
    AVBufferRef* MetaDataBuffer = ffmpeg.av_buffer_alloc((ulong)message.Length);
    MetaDataBuffer->data = pMessageData;
    AVFrameSideData* sideData = ffmpeg.av_frame_new_side_data_from_buf(&frame, AVFrameSideDataType.AV_FRAME_DATA_SEI_UNREGISTERED, MetaDataBuffer);
}


  


  This creates a memory leak, as the buffer is never freed. However, I do not understand how to actually free this buffer. I have tried av_free(), av_freep(), av_buffer_unref() in different orders, but have either gotten no effect at all, or an immediate exit of ffmpeg, without exception an exception being thrown.

  


  To add insult to injury, because the buffer is owned by the ffmpeg dll and not the C# process, the performance profiler is blind to this memory leak, reporting an unchanging heap size.

How can I properly free this buffer ?

  


• NVidia driver libraries in nvidia/cuda image

  16 février 2018, par Islam Sabyrgaliyev

  I want to run ffmpeg with cuvid hw-accelerated decoding in the container based on official nvidia/cuda image. Ffmpeg is not able to find libnvcuvid.so, although there are all required cuda libs.
  The output of ldconfig -p | grep libnv from the container :

  libnvrtc.so (libc6,x86-64) => /usr/local/cuda-9.0/targets/x86_64-linux/lib/libnvrtc.so
  
  libnvrtc-builtins.so (libc6,x86-64) => /usr/local/cuda-9.0/targets/x86_64-linux/lib/libnvrtc-builtins.so
  
  libnvidia-ptxjitcompiler.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.1
  
  libnvidia-opencl.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libnvidia-opencl.so.1
  
  libnvidia-ml.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  
  libnvidia-fatbinaryloader.so.390.12 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libnvidia-fatbinaryloader.so.390.12
  
  libnvidia-compiler.so.390.12 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libnvidia-compiler.so.390.12
  
  libnvidia-cfg.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libnvidia-cfg.so.1
  
  libnvgraph.so (libc6,x86-64) => /usr/local/cuda-9.0/targets/x86_64-linux/lib/libnvgraph.so
  
  libnvblas.so (libc6,x86-64) => /usr/local/cuda-9.0/targets/x86_64-linux/lib/libnvblas.so
  
  libnvToolsExt.so (libc6,x86-64) => /usr/local/cuda-9.0/targets/x86_64-linux/lib/libnvToolsExt.so

  Should I just copy libnvcuvid.so from the host ? Wouldn’t it break if underlying driver version changes ?