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 <[email protected]>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 <[email protected]> > > > 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 > > [email protected] > > https://lists.mplayerhq.hu/mailman/listinfo/libav-user > > > _______________________________________________ > libav-user mailing list > [email protected] > https://lists.mplayerhq.hu/mailman/listinfo/libav-user > _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
