- 14 Sep, 2014 4 commits
-
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
- 13 Sep, 2014 18 commits
-
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
Fix leak on error, fix mismatched free function on success.
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
- 12 Sep, 2014 8 commits
-
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Felix Abecassis authored
-
Felix Abecassis authored
-
Felix Abecassis authored
A deadlock could occur in an high load situation where the vout and the decoder are taking excessive amounts of time. The vout thread repeatedly call ThreadDisplayPicture in its main loop until it returns an error, while keeping the picture pool locked. If no picture was recently received, the vout will redisplay the current picture (a "refresh") by calling ThreadDisplayRenderPicture with is_forced=true. If this refresh is excessively long, the vout thread will be stuck in a refresh loop. The decoder cannot make any progress since the picture pool lock is hold and the vout won't be polling for control commands, yielding a total deadlock of the program. This situation can be reproduced artificially by sleeping in the decoder and decreasing variable VOUT_REDISPLAY_DELAY. A simple solution to this issue is to exit the ThreadDisplayPicture loop after refreshing. Since a refresh typically occurs when no new pictures are received from the decoder, this should not decrease performance.
-
KO Myung-Hun authored
WinCreateMsgQueue() changes FPU cw but does not restore it. This causes SIGFPE later. Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
-
Jean-Baptiste Kempf authored
-
- 11 Sep, 2014 10 commits
-
-
Rémi Denis-Courmont authored
This is already taken care of by avcodec_open2().
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-
Rémi Denis-Courmont authored
-