Threads safe issue with ffmpeg.c

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Threads safe issue with ffmpeg.c

AliReza Khoshgoftar Monfared
Dear All,

For an academic project, I have recently wrote a wrapper function around
ffmpeg.c's main, and has created dll's, and .libs under mingw, and I am
using this function under MSVC++.

In the normal cases nothing is wrong. I can call the function in my code,
and decode/encdoe any video just as ffmpeg's command line does.

But in a more complicated case, I launch two threads (using POSIX Pthreads)
each of them just change the format of a different file.

When I run the program, the behavior is strange, and threads mess up each
others work.

To me, it seems ffmpeg.c is not thread safe.

I did some searches, and saw that these function in ffmpeg.c are not thread
safe:

    avcodec_register_all();
    avdevice_register_all();
    av_register_all();
    avcodec_open();

I put a mutex over each of them, wherever they were used (I used SDL Mutexes
for this purpose, as I saw ffmpeg developers already use them in ffplay.c)
I also put tricks to make sure the library iniltialization functions (the
first three of the list above) are performed only once.


Though I did all of these, still in the multithread case, my function (which
is nothing but a call to ffmpeg.c' main) still behaves strangely, and
threads mess up each other.

Can any of you help in this case, and instruct me how can I make all my
operations completely thread-safe?
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Reply | Threaded
Open this post in threaded view
|

Re: Threads safe issue with ffmpeg.c

cyril comparon
Hi,
Looks to me that ffmpeg.c could perfectly be thread-safe if each instance of
it had its own copy of its global variables. You might be able to achieve
this by storing all global variables of ffmpeg.c into a "struct ffmpeg_app".
To me, such indirection is mandatory to match your needs.
HTH,
Cyril

2009/3/1 AliReza Khoshgoftar Monfared <[hidden email]>

> Dear All,
>
> For an academic project, I have recently wrote a wrapper function around
> ffmpeg.c's main, and has created dll's, and .libs under mingw, and I am
> using this function under MSVC++.
>
> In the normal cases nothing is wrong. I can call the function in my code,
> and decode/encdoe any video just as ffmpeg's command line does.
>
> But in a more complicated case, I launch two threads (using POSIX Pthreads)
> each of them just change the format of a different file.
>
> When I run the program, the behavior is strange, and threads mess up each
> others work.
>
> To me, it seems ffmpeg.c is not thread safe.
>
> I did some searches, and saw that these function in ffmpeg.c are not thread
> safe:
>
>    avcodec_register_all();
>    avdevice_register_all();
>    av_register_all();
>    avcodec_open();
>
> I put a mutex over each of them, wherever they were used (I used SDL
> Mutexes
> for this purpose, as I saw ffmpeg developers already use them in ffplay.c)
> I also put tricks to make sure the library iniltialization functions (the
> first three of the list above) are performed only once.
>
>
> Though I did all of these, still in the multithread case, my function
> (which
> is nothing but a call to ffmpeg.c' main) still behaves strangely, and
> threads mess up each other.
>
> Can any of you help in this case, and instruct me how can I make all my
> operations completely thread-safe?
> _______________________________________________
> libav-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/libav-user
>
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Reply | Threaded
Open this post in threaded view
|

Re: Threads safe issue with ffmpeg.c

AliReza Khoshgoftar Monfared
Hi,

Thanks a lot for your response,

I had another question regarding this thread safety.
Will it be sufficient if I take care of the global variables of ffmpeg.c in
a general structure, or I should also look for other globals in the other
libraries refered by ffmpeg.c (e.g. libavformat, etc...)

I mean, will changing ffmpeg.c be sufficient or the changes should be
applied to all refered libraries?


On Sun, Mar 1, 2009 at 3:10 AM, cyril comparon <[hidden email]>wrote:

> Hi,
> Looks to me that ffmpeg.c could perfectly be thread-safe if each instance
> of
> it had its own copy of its global variables. You might be able to achieve
> this by storing all global variables of ffmpeg.c into a "struct
> ffmpeg_app".
> To me, such indirection is mandatory to match your needs.
> HTH,
> Cyril
>
> 2009/3/1 AliReza Khoshgoftar Monfared <[hidden email]>
>
> > Dear All,
> >
> > For an academic project, I have recently wrote a wrapper function around
> > ffmpeg.c's main, and has created dll's, and .libs under mingw, and I am
> > using this function under MSVC++.
> >
> > In the normal cases nothing is wrong. I can call the function in my code,
> > and decode/encdoe any video just as ffmpeg's command line does.
> >
> > But in a more complicated case, I launch two threads (using POSIX
> Pthreads)
> > each of them just change the format of a different file.
> >
> > When I run the program, the behavior is strange, and threads mess up each
> > others work.
> >
> > To me, it seems ffmpeg.c is not thread safe.
> >
> > I did some searches, and saw that these function in ffmpeg.c are not
> thread
> > safe:
> >
> >    avcodec_register_all();
> >    avdevice_register_all();
> >    av_register_all();
> >    avcodec_open();
> >
> > I put a mutex over each of them, wherever they were used (I used SDL
> > Mutexes
> > for this purpose, as I saw ffmpeg developers already use them in
> ffplay.c)
> > I also put tricks to make sure the library iniltialization functions (the
> > first three of the list above) are performed only once.
> >
> >
> > Though I did all of these, still in the multithread case, my function
> > (which
> > is nothing but a call to ffmpeg.c' main) still behaves strangely, and
> > threads mess up each other.
> >
> > Can any of you help in this case, and instruct me how can I make all my
> > operations completely thread-safe?
> > _______________________________________________
> > libav-user mailing list
> > [hidden email]
> > https://lists.mplayerhq.hu/mailman/listinfo/libav-user
> >
> _______________________________________________
> libav-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/libav-user
>
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Reply | Threaded
Open this post in threaded view
|

Re: Threads safe issue with ffmpeg.c

Vadim Lebedev
In reply to this post by AliReza Khoshgoftar Monfared
I would suggest

to refactor a little bit the main of the ffmpeg so that


>  avcodec_register_all();
>    avdevice_register_all();
>    av_register_all();


are called ONCE  upon loaing of your DLL and npt inside of the  main


Thanks
Vadim
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Reply | Threaded
Open this post in threaded view
|

Re: Threads safe issue with ffmpeg.c

cyril comparon
Yep, in my opinion (anyone please correct me if I'm wrong), the libavxxx
libs are reentrant , which means you can use them concurrently , provided
each thread manipulates its own set of data.
The calls to the xxx_register_all() functions, due to they global nature,
must be mutexed to ensure that they are not called concurrently if your code
might attempt to do so.

2009/3/1 Vadim Lebedev <[hidden email]>

> I would suggest
>
> to refactor a little bit the main of the ffmpeg so that
>
>
> >  avcodec_register_all();
> >    avdevice_register_all();
> >    av_register_all();
>
>
> are called ONCE  upon loaing of your DLL and npt inside of the  main
>
>
> Thanks
> Vadim
> _______________________________________________
> libav-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/libav-user
>
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Reply | Threaded
Open this post in threaded view
|

Re: Threads safe issue with ffmpeg.c

Michael Tison
> Yep, in my opinion (anyone please correct me if I'm wrong), the libavxxx
> libs are reentrant , which means you can use them concurrently , provided
> each thread manipulates its own set of data.
> The calls to the xxx_register_all() functions, due to they global nature,
> must be mutexed to ensure that they are not called concurrently if your code
> might attempt to do so.

Here's a list of other functions that also need locking:
- avcodec_find_encoder()
- avcodec_find_decoder()
- av_find_stream_info()
- avcodec_close()
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Reply | Threaded
Open this post in threaded view
|

Re: Threads safe issue with ffmpeg.c

AliReza Khoshgoftar Monfared
In reply to this post by cyril comparon
Hi,

I did what you instructed .i.e. put all the global variables in a big
structure, and passed this structure as an input to every function using
these globals, but I these errors:

1 - for functions decode_interrupt_cb(), opt_new_audio_stream(),
opt_new_video_stream(), opt_new_subtitle_stream(), opt_vstats(), I get an
error syaing:

 error: 'void' must be the only parameter


This is because I have passed the above mentioned structure containing the
previous global variables as a second input to these functions. But I have
to do these, as these functions use the global variables, and I have to let
them see these globals by doing so.


2- For the structure definition

static const OptionDef options[]


in the last lines of ffmpeg.c, this inside the values of "options" there are
references to global variables, but they are not global anymore, so I give
the "undeclared" error for them. (Since this structure is a constant, I
don't wanna put it in my globals structure, besides, and I am not even sure
doing so, will solve this part of the problem.)

So, is there any idea on these two issues?
I am on the verge of sloving the problem of global variables and making
ffmpeg.c thread safe, but I'm stuck with these two issues.

Thanks in Advance,
Alireza


On Sun, Mar 1, 2009 at 4:10 AM, cyril comparon <[hidden email]>wrote:

> Hi,
> Looks to me that ffmpeg.c could perfectly be thread-safe if each instance
> of
> it had its own copy of its global variables. You might be able to achieve
> this by storing all global variables of ffmpeg.c into a "struct
> ffmpeg_app".
> To me, such indirection is mandatory to match your needs.
> HTH,
> Cyril
>
> 2009/3/1 AliReza Khoshgoftar Monfared <[hidden email]>
>
> > Dear All,
> >
> > For an academic project, I have recently wrote a wrapper function around
> > ffmpeg.c's main, and has created dll's, and .libs under mingw, and I am
> > using this function under MSVC++.
> >
> > In the normal cases nothing is wrong. I can call the function in my code,
> > and decode/encdoe any video just as ffmpeg's command line does.
> >
> > But in a more complicated case, I launch two threads (using POSIX
> Pthreads)
> > each of them just change the format of a different file.
> >
> > When I run the program, the behavior is strange, and threads mess up each
> > others work.
> >
> > To me, it seems ffmpeg.c is not thread safe.
> >
> > I did some searches, and saw that these function in ffmpeg.c are not
> thread
> > safe:
> >
> >    avcodec_register_all();
> >    avdevice_register_all();
> >    av_register_all();
> >    avcodec_open();
> >
> > I put a mutex over each of them, wherever they were used (I used SDL
> > Mutexes
> > for this purpose, as I saw ffmpeg developers already use them in
> ffplay.c)
> > I also put tricks to make sure the library iniltialization functions (the
> > first three of the list above) are performed only once.
> >
> >
> > Though I did all of these, still in the multithread case, my function
> > (which
> > is nothing but a call to ffmpeg.c' main) still behaves strangely, and
> > threads mess up each other.
> >
> > Can any of you help in this case, and instruct me how can I make all my
> > operations completely thread-safe?
> > _______________________________________________
> > libav-user mailing list
> > [hidden email]
> > https://lists.mplayerhq.hu/mailman/listinfo/libav-user
> >
> _______________________________________________
> libav-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/libav-user
>
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
Reply | Threaded
Open this post in threaded view
|

Re: Threads safe issue with ffmpeg.c

SyRenity
In reply to this post by Michael Tison
Hi.

Sorry for barging in - to summarize are these all the functions that need to
be thread safe when working with libavcodec/format?

avcodec_register_all();
avdevice_register_all();
av_register_all();
avcodec_open();

avcodec_find_encoder()
avcodec_find_decoder()
av_find_stream_info()
avcodec_close()

Thanks.



2009/3/2 Michael Tison <[hidden email]>

> > Yep, in my opinion (anyone please correct me if I'm wrong), the libavxxx
> > libs are reentrant , which means you can use them concurrently , provided
> > each thread manipulates its own set of data.
> > The calls to the xxx_register_all() functions, due to they global nature,
> > must be mutexed to ensure that they are not called concurrently if your
> code
> > might attempt to do so.
>
> Here's a list of other functions that also need locking:
> - avcodec_find_encoder()
> - avcodec_find_decoder()
> - av_find_stream_info()
> - avcodec_close()
> _______________________________________________
> libav-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/libav-user
>
_______________________________________________
libav-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user