Created attachment 32195 [details]
mpeg video from the ffmepg test suite

 This doesn't seem to happen on sparc-linux .

 The problem looks to be in mpeg2dec since 
gst-launch-0.8 filesrc location=01.mpg ! ffdemux_mpeg ! mpeg2dec ! sdlvideosink
# segfaults
gst-launch-0.8 filesrc location=01.mpg ! ffdemux_mpeg ! ffdec_mpegvideo !
sdlvideosink # works
gst-launch-0.8 filesrc location=01.mpg ! mpegdemux ! ffdec_mpegvideo !
sdlvideosink # doesn't segfault

Created attachment 33267 [details]
paper over some problem

this patch papers over some of them problem

Can you explain the patch to me?

Not really.  All I know is that it stops a segfault.  I haven't figured out why
though.  That's why I say is papers over the problem.

It could introduce a memleak.

Tried the mpeg in current Totem, doesn't play and gets tons of:
(totem:9122): GStreamer-WARNING **: element internal_thread claimed state-change
success,but state didn't change to PLAYING. State is PAUSED (NONE_PENDING
pending), fix the element

just tried this video in totem, image is here. no warning on the console

*** Bug 164377 has been marked as a duplicate of this bug. ***

(Today's cvs. Played around a bit more with this bug adding some debug spew
around gstdata and gstbuffer)

The segfault happens here in gstmpeg2dec.c (~880):
        if (info->discard_fbuf && info->discard_fbuf->id) {
          GST_WARNING ("Before gst_buffer_unref");
          gst_buffer_unref ((GstBuffer *) info->discard_fbuf->id);
        }

Specifically it segfaults when trying to g_free(GST_BUFFER_DATA(buffer)) inside
the gst_buffer_default_free function. buffer->data gone wrong somewhere..Hope
this can give more insight

  mpeg2dec(31865) gstmpeg2dec.c(882):gst_mpeg2dec_chain: Before gst_buffer_unref
GST_BUFFER(31865) gstdata.c(239):gst_data_unref: 0x1002d8e8 1->0
GST_BUFFER(31865) gstdata.c(241):gst_data_unref: (data->free 0xfed2f80)
GST_BUFFER(31865) gstdata.c(243):gst_data_unref: After return_if_fail
GST_BUFFER(31865) gstdata.c(246):gst_data_unref: After gst_atomic_int_dec_and_test
GST_BUFFER(31865) gstdata.c(250):gst_data_unref: zero = true
GST_BUFFER(31865) gstdata.c(252):gst_data_unref: about to data (0x1002d8e8)
data->free (0xfed2f80)
GST_BUFFER(31865) gstbuffer.c(95):gst_buffer_default_free:
gst_buffer_default_free 0x1002d8e8
GST_BUFFER(31865) gstbuffer.c(102):gst_buffer_default_free:
!GST_BUFFER_FLAG_IS_SET(buffer) (0x1002d8e8)
GST_BUFFER(31865) gstbuffer.c(104):gst_buffer_default_free: before g_free
(GST_BUFFER_DATA((buffer) (0x3083c008)))

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 31865)]
_int_free (av=0xfdceb84, mem=0x3083c008) at malloc.c:4192
4192    malloc.c: No such file or directory.
        in malloc.c
(gdb) x 0xfed2f80
0xfed2f80 <gst_buffer_default_free>:    0x9421ffe0
(gdb) x 0x3083c008
0x3083c008:     0x10101010

I've just rearranged the way the mpeg2dec element does management of its
buffers. Can you please re-test with current CVS of gst-plugins?

The ffmpeg test video plays fine here, but that's on x86.

Tried with last night's cvs..
With this 
./bin/gst-launch-0.8 --gst-debug-no-color --gst-debug-level=5 dvdreadsrc
device=/dev/hdc title=2 ! dvddemux ! mpeg2dec ! fakesink &> dvd-log

I get a segfault (the same as in comment #11). I also get a segfault while
trying to play the ffmpeg test video attached in this bug (although I _do_ see
the first couple of frames in this case) : ./gst-launch-0.8 filesrc
location=/tmp/ffmpeg.mpeg ! ffdemux_mpeg ! mpeg2dec ! sdlvideosink &> video-log

I'll attach the trace of the segmentation fault of this dvd and of the video file

Created attachment 37146 [details]
Log of the core dump on the dvd (gzipped)

Created attachment 37147 [details]
Log of the core dump on the ffmpeg test file (gzipped)

Reopening bug, as it looks like the problem is still there.

 Cheers
  -Tim

Ok. Investigating a bit more, it turned out to be a miscompilation of libmpeg2
with gcc-3.3 on powerpc.
Compiling libmpeg2 with gcc-3.4 (no changes of CFLAGS which are set to -O3 by
default) "cures" it here and I'm happily running all of the commands above.

[For the record gcc-3.3 and -O0 on libmpeg2 gives me an ICE so I can't tell if
it  can be fixed by "lessening" the optimization flag on gcc-3.3]
 
James, can you confirm it fixes things for you as well, so we can close this?

 I'll try compiling libmpeg2 without altivec with gcc 3.3 and compiling libmpeg2
with gcc 3.4 or gcc 4.0.  I think this is a bad combination of gcc 3.3 and
altivec.  I should have thought of that earlier.

 Both solutions worked.  I'm submitting a bug with a patch to get the debian
package of libmpeg2 fixed.

 More digging revealed that altivec is not enabled when libmpeg2 is compiled
with gcc 3.4.