Opened 4 years ago

Closed 4 years ago

#4600 closed defect (needs_more_info)

Handle leak when opening video files

Reported by: fortune Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords: leak
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Hi

I'm using the delphi ffmpeg components (http://www.delphiffmpeg.com/) which make use of ffmpeg dlls to encode and decode video.

I've already reported this problem to the author of the delphi components but he says the problem lies with the ffmpeg dlls and there's nothing he can do.

The problem is that the handle count (as viewed via task manager) keeps increasing whenever a video file is opened. This only happens on multithreaded CPUs and appears to be thread related. If the application runs for long enough it will eventually crash due to the handle leak.

A workaround that I've found is to force the application to only use a single CPU via the SetProcessAffinityMask? function:
SetProcessAffinityMask?(GetCurrentProcess?, 1)
This works but the performance suffers due to only one cpu being used.

To reproduce this problem download the FFVCL trial from:
http://www.delphiffmpeg.com/downloads/

Included in the trial is the [MemoryPlayerDemo?].exe demo file that uses ffmpeg DLLs. Start it and watch the task manager handle count when opening a video file. You'll see that it keeps increasing. Setting the process affinity to use one CPU stops the problem.

I hope you can help!

Thanks

Change History (4)

comment:1 Changed 4 years ago by cehoyos

  • Keywords leak added

Please provide valgrind output for reports about memory leaks.
Can the issue also be reproduced without Delphi? If not, why not?
Please confirm that you tested current FFmpeg git head.

comment:2 follow-up: Changed 4 years ago by heleppkes

It looks like these binaries are built with some kind of pthreads emulation library, which are known to leak handles. You can avoid this by building the binaries with ffmpegs native w32threads support instead.

comment:3 in reply to: ↑ 2 Changed 4 years ago by fortune

Replying to heleppkes:

It looks like these binaries are built with some kind of pthreads emulation library, which are known to leak handles. You can avoid this by building the binaries with ffmpegs native w32threads support instead.

Thanks for the reply.

The DLLs in use are the ones on this page:
http://www.delphiffmpeg.com/downloads/

It doesn't matter which version as they all seem to have the leak issue.

I'm not sure how these were built. Is there somewhere on the web where I can find versions of these DLLs that have been built with native w32threads?

comment:4 Changed 4 years ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to closed

Please reopen this ticket if you can provide valgrind output and / or tested with w32threads.

Note: See TracTickets for help on using tickets.