Skip to content

audioresample: Various draining and timestamp tracking fixes

Sebastian Dröge requested to merge slomo/gst-plugins-base:audioresample-timestamp-tracking-draining into master 
commit f57bf8826908410820c4e947857b850da374f97b (HEAD -> audioresample-timestamp-tracking-draining, gitlab-slomo/audioresample-timestamp-tracking-draining)
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Tue May 26 22:51:06 2020 +0300

    audioresample: Drain resampler on discontinuities
    
    Otherwise we would lose the last few samples when resetting the
    resampler.

commit ab8d16e6054c7fa187a88a898302ceb01e6925e0
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Tue May 26 22:49:44 2020 +0300

    audioresample: Drain resampler and reset timestamp tracking on stream-start event too
    
    And also reset timestamp tracking on EOS events as more data might come
    afterwards with a new stream-start event. This keeps the code the same.

commit 6a568fb875a5fba1d47ef004e22555e781fcc756
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Tue May 26 22:45:41 2020 +0300

    audioresample: Drain the resampler and reset timestamp tracking on caps changes
    
    Especially when changing the sample rate our timestamp tracking will be
    completely off, but even otherwise we would usually lose the last few
    samples if we don't drain here as the resampler gets reset if anything
    but the sample rate changes.
    
    This is usually not a problem as the first buffer after a caps event
    usually has the discont flag set, but can cause problems if
     - the caps event is followed by a segment event, which then causes
       draining according to the new sample rate
     - the caps were changed because of rengotiation due to a reconfigure
       event and there is not discontinuity from upstream
    
    In both cases we would output buffers with completely wrong timestamps.

Merge request reports