Advanced search

On other websites (4516)

• Ffmpeg possible sws_scale memory leak

  5 December 2024, by Expressingx

  I'm decoding whatever the camera codec is and then always encode it to H264 and more specifically qsv if it is supported. Currently having 2 cameras to test. One is H264 encoding and one is rawvideo. The problem comes with rawvideo. The pixel format is BGR24 and scaling to NV12

  



  I will simplify the code because it is as any other example.

  



  avcodec_send_packet()
// while
avcodec_receive_frame()

// if frame is not EAGAIN convert BGR24 to NV12
if (_pConvertContext == null)
{
    _pConvertContext = CreateContext(sourcePixFmt, targePixFmt);
}

if (_convertedFrameBufferPtr == IntPtr.Zero)
{
    int buffSize = ffmpeg.av_image_get_buffer_size(targePixFmt, sourceFrame->width, sourceFrame->height, 1);
    _convertedFrameBufferPtr = Marshal.AllocHGlobal(buffSize);
     ffmpeg.av_image_fill_arrays(ref _dstData, ref _dstLinesize, (byte*)_convertedFrameBufferPtr, targePixFmt, sourceFrame->width, sourceFrame->height, 1);
}

return ScaleImage(_pConvertContext, sourceFrame, targePixFmt, _dstData, _dstLinesize);


  



  And ScaleImage method

  



  ffmpeg.sws_scale(ctx, sourceFrame->data, sourceFrame->linesize, 0, sourceFrame->height, dstData, dstLinesize);

AVFrame* f = ffmpeg.av_frame_alloc();

var data = new byte_ptrArray8();
data.UpdateFrom(dstData);
var linesize = new int_array8();
linesize.UpdateFrom(dstLinesize);

f->data = data;
f->linesize = linesize;
f->width = sourceFrame->width;
f->height = sourceFrame->height;
f->format = (int)targePixelFormat;

return f;


  



  After that sending the scaled frame to the encoder and receiving it and writing the file. After that I call av_frame_free(&frame) on the frame returned from the method. But when I set breakpoint I can see the address of the frame is the same even after calling av_frame_alloc() and cleaning everytime. And I think this is the reason for the memory leak. If I do deep clone of the f before returning it everything is fine. Why is that happening while the same logic works fine with the other camera?

  


• Back porting ffmpeg.dll from electron for windows xp by disassembling

  28 July 2024, by Oosuke Ren

  I've recently gotten into a really interesting project of having a fully functional (and as futuristic as possible) physical retro gaming machine with windows xp. I had found One Core Api that successfully works to allow for some programs to work that otherwise wouldn't have. One of them is electron (5.0.13). Thanks to a vast testing between a VM with the kernel extender and a vanilla XP, I found out that the only thing stopping me from succeeding is because it's dependent on an EXTREMELY specific version/fork of ffmpeg (Chromium fork of ffmpeg 4.1) . Due to that being a relatively old fork/version, the build tools/links for some of the stuff are nonexistent right now, so even if I do have the fork locally with all the instructions, I can't build it. (and if I do I have to patch Win Vista+ Api functions, with one custom stub dll I have)

  


  AcquireSRWLockExclusive InitializeConditionVariable SleepConditionVariableSRW InitOnceBeginInitialize InitOnceComplete InitializeSRWLock ReleaseSRWLockExclusive WakeAllConditionVariable WakeConditionVariable

  


  Since I can't custom build ffmpeg I have to patch it's calls by redirecting them to my custom dll that includes these back ported functions and more.

  


  I tried many different ways => IDA Pro, Ghidra, objconv, currently am the closest with "DLL to C"

  


  Ida Pro and Ghidra seem to not be creating assembly code that I'd be able to assemble back after patching.

  


  objconv produces a really accurate disassembly, but the issue is it doesn't have an assembler. And the produced .asm won't assemble with Fasm, masm or nasm

  


  As for DLL to C-> successfully created a quite presentable VS project, the project successfully compiles with only one warning, the byte sizes is quite similar, the problem is => the functions are getting wrongly directed (towards wrong functions in my dll- and thus the ones needed are undefined) And this is too deep to be able to tell if it's a VS version issue, wrong code implementation or if just DLL to C has wrongly disassembled the logic.

  


  Question is, is my last option remaining to manually edit the HEXES of the Import Address Table and Import Names so they get redirected? (the problem is my knowledge in Assembly isn't too good, so I'm not sure if that's all I'd have to do, and even if so, I have a feeling I'd mess up the Virtual Addresses or something.

  


• Revision 37011: Un petit test pour voir si ffmpeg2theora est dispo sur le serveur (pour ...

  6 April 2010, by kent1@… — Log

  Un petit test pour voir si ffmpeg2theora est dispo sur le serveur (pour l’utiliser au cas où plus tard)