#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
_______________________________________________
FFmpeg-trac mailing list
[email protected]
http://avcodec.org/mailman/listinfo/ffmpeg-trac
