GNOME Bugzilla – Bug 707238
videomixer: Broken EOS handling
Last modified: 2016-01-17 17:31:51 UTC
According to Sebastian on irc, videomixer was supposed to fill until the segment stop when all collectpads were EOS. The problem is there is no hint of such a code in videomixer, which makes me wonder if somebody removed that or what. The code in fill_queues seems needlessly complicated, and videomixer doesn't even realize all its collectpads are EOS in certain cases. I could fix it if I knew what we actually wanted. From my point of view, if we decide that we want videomixer to "fill the void", we should at least have a property to either disable that, or tell it to use the last computed frame instead of the background. Our use case (editing) really doesn't work well with black frames :) I'll wait for opinions before further development.
Indeed there is no code that "fills the void". Instead it goes EOS as soon as all pads are EOS or if we're beyond segment.stop. What's the case where it doesn't do this for you? I think the default behaviour should be to fill the segment until the end. If segment.stop is -1 it should stop as soon as all streams are EOS. Having a property to optionally EOS as soon as possible if all streams are EOS instead of waiting for the segment to end sounds ok too. So few things to do here: 1) Fix the bug you noticed 2) Let videomixer fill the segment 3) Have property to disable that
OK I'll do that thanks :)
Created attachment 254022 [details] [review] First patch addressing the bug It doesn't make sense, if the pad is indeed EOS, to set EOS to FALSE in that part of the loop.
Created attachment 254023 [details] [review] Updates the patch Ooops I was on friend's computer, here is the real commit sorry :)
Comment on attachment 254023 [details] [review] Updates the patch True, now this just leaves the other problem(s) mentioned in this bug
Does any of this apply to videoaggregator/compositor as well? If not, I'd suggest to resolve as WONTFIX or OBSOLETE.
We can close this yes, I'll close as WONTFIX as the bug still exists in videomixer2, anyone reading this should consider using compositor if they have thread safety issues with videomixer2 (or even if they don't)