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

[Manjunath Siddaiah]

Hi,

What happened to this patch ?  Any new reviews for this patch.

Regards
Manjunath
-----Original Message-----
From: ffmpeg-devel-bounces at ffmpeg.org [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf Of Manjunath Siddaiah
Sent: Wednesday, June 20, 2012 11:19 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH 1/2] Audio Video Filtering using threads & semaphores

Ok, semaphores are replaced by POSIX mutexes and condition variables.
This time only changes are in ffmpeg.c and no configure file changes and remains the same.

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 3: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 :
> 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.

To avoid race conditions using POSIX threads, there are POSIX mutexes and conditions. They are an API designed along with the rest of the threading API and widely implemented.

Semaphores are an IPC API, and thus more expensive. They also are only an optional part of the Unix standard, and as such missing from some systems where POSIX threads are fully implemented.

Regards,

--
  Nicolas George