[FFmpeg-devel] [PATCH 1/2] Audio Video Filtering using threads & semaphores
msiddaiah at rgbnetworks.com
Tue Jun 19 20:37:26 CEST 2012
I could avoid semaphores, if threads are created for every decoded frame and join the threads soon after filtering that decoded frame. For this there will be overhead for calling thread_create function for every decoded frame.
Instead created threads during "transcode_init" function and join the threads while exiting the transcode. For this scenario, race conditions are avoided using semaphores.
From: ffmpeg-devel-bounces at ffmpeg.org [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of Nicolas George
Sent: Tuesday, June 19, 2012 12:08 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 1/2] Audio Video Filtering using threads & semaphores
Le duodi 2 messidor, an CCXX, Manjunath Siddaiah a écrit :
> As decoder output goes to the filter, semaphores are posted for all
> the required filtering steps and encoders waits on semaphore for the
> filtering job to complete to take it's input.
I did not look at the code yet, but there is a question I want to ask
immediately: is there a reason you are using semaphores, i.e. an optional, barely standard and isolated feature, rather than using standard and integrated APIs (probably conditions)?
More information about the ffmpeg-devel