On date Tuesday 2009-04-14 18:55:33 -0400, AliReza Khoshgoftar Monfared encoded: > On Tue, Apr 14, 2009 at 2:26 PM, Stefano Sabatini < > [email protected]> wrote: > > > On date Tuesday 2009-04-14 13:13:13 -0400, AliReza Khoshgoftar Monfared > > encoded: > > > On Tue, Apr 14, 2009 at 11:12 AM, Stefano Sabatini < > > > [email protected]> wrote: > > > > > > > On date Saturday 2009-04-11 20:45:20 -0400, AliReza Khoshgoftar > > Monfared > > > > encoded: > > [...] > > > I have the locks now, but it still seems that my version of ffmpeg.c is > > not > > > completely threadsafe, as it fails in some of the tests. > > > Right now, I have locks around the functions mentioned in the previous > > post. > > > Do I still need to put locks around all avcodec_find_*()'s and allocation > > > functions?(I saw in an old post somebody told they are also non-safe)And > > if > > > yes, do they need to be the same mutex as the previous one? > > > > Ugh, reading again the post I finally realized what you did, no > > doesn't look like a good idea to wrap ffmpeg.c into a function, this > > may cause problems especially if you try to find things which hasn't > > still been allocated, or worse many threads trying to register all the > > components at the same times. You can still do that introducing locks > > but it sound ugly and a maintainability hell. > > > > system(ffmpeg_command); > > > > should work just fine for what you want to do. [...] > Hi, > > Thanks for the reply, > You are absolutely right. > But I am not still sure whether I can use ffmeg directly with system, as I > have to do some further changes in my wrapper and enable midstream changes > of some parameters like bit rate, frame rate, etc.(Is there a solution to > still use ffmpeg.c even in this case?)
You can change the parameters passed to each ffmpeg process. > Also, even with using ffmpeg directly, I still need a lot of changes, as I > need to get rid of the globals in ffmpeg.c (that cause problems in threaded > environment) Using system every single forked ffmpeg process has its own memory space, so no conflict may happen. Of course if you need to share data this can't work. > Anyway, it is still doable to get back to ffmpeg.c as my wrapper can be > easily modified to replace the ffmpeg.c file. > The question however, is do I still lack locks (around avcodec_find_*, and > allocation functions), or you think the problem is with wrapping around > ffmpeg? Once the initialization is done I think it should be safe to use the *_find_* functions concurrently. > I haven't done many changes to ffmpeg.c, and technically, I have just > renamed its main function, and also lcoalized all its global variables. > Also about the library register functions, I have put locks around them, to > make sure not all threads register the libraries at the same time. Does this > registering need to be done only once, even if you have many threads? (In > that case, instead of putting a lock, I can take out the registering > functions out, and call them only once for all threads) Yes, the initialization should be done just once, then at the end of the registration a flag is set to true and further calls to the init functions will immediately return, but you should avoid of having two threads to enter a registration function at the same time during the first call. [...] Regards _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
