[Bug 752431] mpg123audiodec: fix handling of sample rate change during playback

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=752431

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |t.i.m at zen.co.uk
         Resolution|---                         |FIXED
   Target Milestone|git master                  |1.5.90
            Summary|mpg123audiodec: Rate change |mpg123audiodec: fix
                   |of underlying media doesn't |handling of sample rate
                   |communicate caps upstream.  |change during playback

--- Comment #1 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
Not sure I fully understand how this is supposed to work exactly, but the patch
clearly makes this work properly, so I've merged this for now:

 commit 8e488e5e490f0eb0bf6573fc7c9d557428ba8e7d
 Author: Jason Litzinger <jlitzinger at control4.com>
 Date:   Wed Jul 15 10:44:02 2015 -0600

    mpg123: fix handling of sample rate change during playback

    If the sample rate of the media changes, the resulting flush will
    clear the has_next_audioinfo flag, and the caps won't be sent
    downstream.

    https://bugzilla.gnome.org/show_bug.cgi?id=752431


Just after I pushed it, it occured to me that the purpose of the
has_next_audioinfo=FALSE in the flush function was probably to reset it in case
of a seek, for example. So on second thought, perhaps we should still reset it
to FALSE if 'hard' is TRUE, and otherwise not:

commit f3b18a29bf4c11bfb6609fb8e029af3603bb1030
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Mon Aug 17 11:50:28 2015 +0100

    mpg123: still reset pending audio info on hard flush

    Follow-up to previous commit.

    https://bugzilla.gnome.org/show_bug.cgi?id=752431


This still seems to make the original issue work as well.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.