[FFmpeg-devel] [PATCH 1/2] Audio Video Filtering using threads & semaphores

[Manjunath Siddaiah]

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.

Regards
Manjunath

-----Original Message-----
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)?

Regards,

--
  Nicolas George