[gstreamer-bugs] [Bug 403168] [ffmux_flv] crash on buffer after returning FLOW_ERROR previously

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=403168

  GStreamer | gst-ffmpeg | Ver: HEAD CVS


Tim-Philipp Müller changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
          Component|gst-plugins-base            |gst-ffmpeg
         Resolution|                            |FIXED
            Summary|Race conditions during      |[ffmux_flv] crash on buffer
                   |audioresample shutdown      |after returning FLOW_ERROR
                   |(segfault)                  |previously
   Target Milestone|HEAD                        |0.10.3




------- Comment #6 from Tim-Philipp Müller  2007-02-09 17:37 UTC -------
This is fixed for me now, with the following commits:

 2007-02-09  Tim-Philipp Müller  <tim at centricular dot net>

        * ext/lame/gstlame.c: (gst_lame_sink_event), (gst_lame_chain),
        (gst_lame_change_state):
        * ext/lame/gstlame.h:
          On receiving EOS, we try to push a last buffer with the remaining
          samples. Don't do that if we got an unclean flow return on the last
          gst_pad_push(), downstream might not handle this very gracefully
          (see #403168).

        * gst/mpegaudioparse/gstmpegaudioparse.c: (gst_mp3parse_chain):
          Pass flow returns upstream (helps #403168).

 2007-02-09  Tim-Philipp Müller  <tim at centricular dot net>

        * ext/ffmpeg/gstffmpegmux.c: (gst_ffmpegmux_request_new_pad),
        (gst_ffmpegmux_setcaps), (gst_ffmpegmux_collected):
          Only set the mux->opened flag after we've successfully written the
          header. This way we don't crash in mysterious ways if we can't write
          the header for some reason (e.g. due to having accepted caps the
          format doesn't really allow), then return a GST_FLOW_ERROR, and
          then still receive another buffer afterwards despite having
previously
          returned FLOW_ERROR (#403168).
          Also some minor logging improvements.

 2007-02-09  Tim-Philipp Müller  <tim at centricular dot net>

       * ext/ffmpeg/gstffmpegmux.c: (gst_ffmpegmux_register):
         ffmux_flv only accepts mpeg audio with a sample rate of 44100, 22050
         or 11025. Fix up the caps in the sink pad template accordingly, so
         that encoding piplines at least have a chance to automatically
         negotiate to one of the allowed rates.

Primarily an ffmux_flv bug I think, no idea why it crashes in audioresample for
you (may thrashed memory). Please re-open if you still get the crash with CVS
HEAD of everything (including core).


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email