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 <[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
