GNOME Bugzilla – Bug 765736
multiqueue: playback with sparse stream deadlocks
Last modified: 2016-04-29 13:18:16 UTC
Created attachment 326958 [details] [review] Patch Basically, sq->max_size.visible is never increased for sparse streams in overruncb when empty queue has been found; This code inside single_queue_overrun_cb doesn't seem right /* check if we reached the hard time/bytes limits */ if (sq->is_eos || sq->is_sparse || IS_FILLED (sq, bytes, size.bytes) || IS_FILLED (sq, time, sq->cur_time)) { goto done; } If the queue is sparse it just skip the entire logic determining whether max_size.visible should be increased, deadlocking the demuxer. I think what should be done instead is that when determining if limits have bean reached, to ignore time for sparse streams, as the buffer may be far in the future.
This makes sense IMHO. sparse streams will only really cause issues in regards to time limits. Can you expand the comment before that line explaining that we only take into account the time limit for non-sparse streams ?
Created attachment 327019 [details] [review] Patch with expanded comment
commit efb1955ffb395759e92a2a49918f0e823bcf4dfa Author: Matej Knopp <matej.knopp@gmail.com> Date: Fri Apr 29 14:55:02 2016 +0200 multiqueue: Ignore time when determining whether sparse stream limits have been reached Basically, sq->max_size.visible is never increased for sparse streams in overruncb when empty queue has been found; If the queue is sparse it just skip the entire logic determining whether max_size.visible should be increased, deadlocking the demuxer. What should be done instead is that when determining if limits have been reached, to ignore time for sparse streams, as the buffer may be far in the future. https://bugzilla.gnome.org/show_bug.cgi?id=765736
A unit test for this would be superb (and shouldn't be too hard if you have a file / inputs to reproduce it with?) :)