[FFmpeg-devel] [PATCH 1/2] ffmpeg: allow to set the thread message queue size.
george at nsup.org
Thu Feb 26 19:56:06 CET 2015
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
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
# commit 47b812e9cec3e0b29799b71009585ea77133eef0
# Author: Anton Khirnov <anton at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel