a-schild / jave2

The JAVE (Java Audio Video Encoder) library is Java wrapper on the ffmpeg project
GNU General Public License v3.0
1.2k stars 246 forks source link

semaphore and execotor usage problem #255

Closed rayacode closed 5 months ago

rayacode commented 5 months ago

I can't find "- Use proper class for semaphore, thanks to leeychee" Where you did this in the code does this suppose to solve any problem by using the semaphore??

I'm making a multi-threaded Audio Video converter with Javafx, using Serivce < t> class, the situation is this,
ex: there is max 3 for semaphor i add 3 files to program and hit start all button while they are converting all three i add one more file and again i hit start so that file get in but not starting rather waiting for seampohr to release one of those 3 that are already converting, semaphore release if they are succeeded or failed, or cancelled, and 4rth file starts converting, till now everything works perfectly, but when i hit cancel all which a foreach goes through all converts tasks and calls cancel on each of them, then again when i hit start all , rather from those 4 files only three of them starts all of them starts together. my service class has task innerclass as usual of javafx concurency, inside the task call method i acquire a permit from semaphore, after it i try{ convert} finally{semaphore.release} then in a overridden cancel(bool mayInterruptIfRunning) i abortEncoding, i also have executor, with 10 nThreads, and each task gets there on instantiating. if i don't use semaphore or executor everything works fine with cancelling, also i get interrupted exception sometimes when i hit cancel restarts so fast from the jave2 and i can't catch it! it's from wait() and also when this happens although service state is in cancel state, and encoder is aborted, but progressProperty shows that updating which means encode continues, it may also not showing progressProperty updating, but still there is ffempeg task in widows task manager, and program can't close even with even onclose setted to shutdown executor. i need force close ffempeg from taskmanager myself. also after aborting or quiting i get first, InvocationTargetException then nullpointer on encoder object which i tried to catch by all sort of ways in my code but not possible, encoder get null inside jave2 or somehow or for second time if abort already happened it cause like this!!

please also give me some guide of how jave proccess multi tasking, and if there is a way to let client of library customize it the way client needs it or have direct access to process

rayacode commented 5 months ago

I resolved the issue in my Convert class which usage of encode is implemented i tried to print out encoders and decoders supported by encoder sometime back like this before calling encode method System.out.println("getVideoEncoders:\n " + Arrays.toString(encoder.getSupportedEncodingFormats())); System.out.println("getSupportedEncodingFormats:\n " + Arrays.toString(encoder.getSupportedEncodingFormats())); System.out.println("getVideoDecoders:\n " + Arrays.toString(encoder.getVideoDecoders())); System.out.println("getSupportedDecodingFormats:\n " + Arrays.toString(encoder.getSupportedDecodingFormats())); System.out.println("AudioEncoders:\n " + Arrays.toString(encoder.getAudioEncoders())); System.out.println("getAudioDecoders:\n " + Arrays.toString(encoder.getAudioDecoders()));

now when i got there to settup some logs i deleted them and multitasking issue resolved!!!!! it’s possible that these method calls were causing some form of conflict or resource contention in a multithreaded environment by the way they are wrapper on ffempeg maybe calling ffempeg before encode creates the problem, maybe good idea to have thread safe ProcessWrapper and letting client to have access to it or provides custom ProccessWrapper

a-schild commented 5 months ago

In the DefaultFFMPEGLocator class we have this: synchronized (DefaultFFMPEGLocator.class)

With this we handle the management of the executable wich is extracted from the jar and put in the tmp folder. We have not received reports of other concurrent usage problems.