Le septidi 7 ventôse, an CCXXIII, Michael Niedermayer a écrit : > i think the case i tested had HAVE_W32THREADS set > also theres HAVE_OS2THREADS
I suspect my question was too vague. If I understand correctly, HAVE_THREADS = HAVE_PTHREADS || HAVE_W32THREADS || HAVE_OS2THREADS Am I right? My main question is: do we have supported case where we do not HAVE_THREADS at all? As a side note, I notice the current code for running demuxers in threads is protected by HAVE_PTHREADS instead of HAVE_THREADS initially because of this: # commit 47b812e9cec3e0b29799b71009585ea77133eef0 # Author: Anton Khirnov <an...@khirnov.net> # Date: 2012-06-11 15:34:12 +0200 # # avconv: support only native pthreads. # # Our w32pthreads wrapper has various issues and is only supposed to be # used in libavcodec. Does anyone know what "issues" this is about? I just ran a quick and dirty test and it seems to work with i686-w64-mingw32 cross-compiler and wine (I had to move windows.h after ffmpeg.h in ffmpeg_dxva.c for some reason). It would be nice if someone would test this more carefully. The basic reason I ask is that this kind of issue is that any application reading from a live stream and doing something else at the same time has similar kind of problems. We need some kind of really working non-blocking or input-driven API, and if we do not want to rewrite 90% of the demuxers, we will need threads. Regarding the patch itself, if you consider the series ok, you can pull this from my tree: a92193f lavd/alsa: set frame_size field. 508d6a2 ffmpeg: allow to set the thread message queue size. d92c6d8 ffmpeg: notify when the thread message queue blocks. Thanks. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
