GNOME Bugzilla – Bug 753624
splitmuxsink: initialize mux_start_time properly
Last modified: 2015-10-02 14:43:52 UTC
Created attachment 309260 [details] [review] splitmuxsink: initialize mux_start_time properly mux_start_time refers to the running_time of the buffer that goes first in the output file. Normally this time is 0, so this variable is initialized to 0 during the state change to PAUSED. However, when dealing with dynamic pipelines and starting a recording while the pipeline has already run for a while, the running_time of the first buffer is > 0 and this causes a problem with detecting the end of the first file(s) when splitting by duration, because the code will later compare the threshold_time with (last buffer running_time - mux_start_time) and will get it wrong until mux_start_time advances enough to make this difference < threshold_time, creating empty files in the meantime.
Review of attachment 309260 [details] [review]: Thanks :)
Thanks, pushed: Author: George Kiagiadakis <george.kiagiadakis@collabora.com> Date: Wed Jul 22 17:45:12 2015 +0200 splitmuxsink: initialize mux_start_time properly mux_start_time refers to the running_time of the buffer that goes first in the output file. Normally this time is 0, so this variable is initialized to 0 during the state change to PAUSED. However, when dealing with dynamic pipelines and starting a recording while the pipeline has already run for a while, the running_time of the first buffer is > 0 and this causes a problem with detecting the end of the first file(s) when splitting by duration, because the code will later compare the threshold_time with (last buffer running_time - mux_start_time) and will get it wrong until mux_start_time advances enough to make this difference < threshold_time, creating empty files in the meantime. https://bugzilla.gnome.org/show_bug.cgi?id=753624