[FFmpeg-trac] #773(avcodec:new): Decoding H.264 gets stuck with Win XP, w32threads, and custom AVCodecContext.get_buffer
FFmpeg
trac at avcodec.org
Fri Dec 16 20:47:32 CET 2011
#773: Decoding H.264 gets stuck with Win XP, w32threads, and custom
AVCodecContext.get_buffer
----------------------------------+-----------------------------------
Reporter: andreasg | Owner:
Type: defect | Status: new
Priority: normal | Component: avcodec
Version: 0.9 | Resolution:
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
----------------------------------+-----------------------------------
Comment (by reimar):
I don't know who implemented that code and based on what, but it is just
broken.
There are gems like this I can't see what purpose they would serve:
pthread_mutex_lock(&win32_cond->mtx_broadcast);
pthread_mutex_unlock(&win32_cond->mtx_broadcast);
However more serious the waiter_count is decremented at the wrong place.
If you look at pthread_cond_wait the WaitForSingleObject is outside of all
locks.
This means if somehow all threads leaving that function would be delayed
for some time, you could use pthread_cond_signal to arbitrarily increase
the value of the semaphore, even though there was never more than one
thread waiting.
As a consequence pthread_cond_wait would never be waiting anymore after
that and from there it is only downhill.
I can't really (easily at least) explain a hang with that though, there
should at least some other things go wrong first.
The method presented here:
http://research.microsoft.com/pubs/64242/implementingcvs.pdf looks like it
might at least work, even if performance is not exactly good.
Seems their hope of people not repeating mistakes was not exactly
justified though.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/773#comment:1>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list