[Bug 752431] New: mpg123audiodec: Rate change of underlying media doesn't communicate caps upstream.

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 752431
           Summary: mpg123audiodec: Rate change of underlying media
                    doesn't communicate caps upstream.
    Classification: Platform
           Product: GStreamer
           Version: 1.4.1
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: jlitzinger at control4.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 307497
  --> https://bugzilla.gnome.org/attachment.cgi?id=307497&action=edit
Proposed fix

I mentioned this in IRC and was able to capture a stream (I'm not sure I can
attach it because it is a broadcast and I don't know the legalities of doing
so) that exhibited the problem.

The issue appears to be that, if the rate changes mid stream, the parser calls
the decoder's set_format, and has_next_audioinfo is set to TRUE.  This is good.

Next, the decoder flushes all frames (also good), and sets has_next_audioinfo
to FALSE.  This is bad, because the handle_frame logic fails to set the output
format, despite having a new format.

I've attached a proposed patch.  At first I thought this may be only useful for
testing, but, looking at the lifecycle of next_audioinfo, I think is valid. 
next_audioinfo is not cleared during a flush, and since this flag is bound
logically to that information, it shouldn't be either.

That said, it's (very) likely I've overlooked something, so feedback would be
great.

I apologize for the lack of unit test, if I can generate an mp3 file of public
domain audio that exhibits the issue I will do so.

I reproduced this with 1.2.4 and 1.4.5 using the mpg123audiodec.  I have not
yet tried master, but, the offending line of code still exists, so the problem
might be there?

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