After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 659687 - avimux FPE crash
avimux FPE crash
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.3
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-09-21 10:40 UTC by RaubTieR
Modified: 2013-11-13 17:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
avimux: reject some sanity check failing audio caps (843 bytes, patch)
2011-09-21 11:07 UTC, Mark Nauwelaerts
none Details | Review

Description RaubTieR 2011-09-21 10:40:54 UTC
I am developing a video rendering app, on Ubuntu 10.10, using gstreamer-0.10 and gstreamer-plugins-good-0.10.30. My pipeline is: 
multijpegsrc -> ffdec_mjpeg -> ffmpegcolorspace -> videoflip -> textoverlay -> textoverlay -> textoverlay -> tee(src) -> ffenc_mp4 -> (video_0)avimux -> filesink, tee(src1) -> queue -> xvimagesink; filesrc -> wavparse -> audioconvert -> ffenc_mp2 -> (audio_0)avimux. 
Where multijpegsrc is an adapted version of multifilesrc, which uses another file-choosing algorithm corresponding to my needs, but overall effect of working element is the same.
An FPE occures only when rendering seem to reach the end (100% progress). Disabling sound fixes FPE, adding zero-division-preventing condition to avimux's code also does.

some GDB stuff:
Program terminated with signal 8, Arithmetic exception.
  • #0 gst_avi_mux_audsink_set_fields
    at gstavimux.c line 726
  • #0 gst_avi_mux_audsink_set_fields
    at gstavimux.c line 726
  • #1 gst_avi_mux_stop_file
    at gstavimux.c line 1838
  • #2 gst_avi_mux_do_one_buffer
    at gstavimux.c line 2068
  • #3 gst_avi_mux_collect_pads
    at gstavimux.c line 2084
  • #4 gst_collect_pads_check_collected
    at gstcollectpads.c line 1126
  • #5 gst_collect_pads_event
    at gstcollectpads.c line 1232
  • #6 gst_avi_mux_handle_event
    at gstavimux.c line 1913
  • #7 gst_pad_send_event
    at gstpad.c line 5043
  • #8 gst_pad_push_event
    at gstpad.c line 4899
  • #9 gst_base_transform_sink_event
    at gstbasetransform.c line 1710
  • #10 gst_pad_send_event
    at gstpad.c line 5043

Comment 1 Mark Nauwelaerts 2011-09-21 11:07:20 UTC
Created attachment 197142 [details] [review]
avimux: reject some sanity check failing audio caps

Attached patch is avoid later division-by-zero by rejecting caps leading to some unexpected field values.

However, afaics from current code, that field should not end up 0 with some mpeg caps, so it also leads to wondering what (else) is going on here (in particular with caps ?, and some debug logging should help with that)
Comment 2 Sebastian Dröge (slomo) 2011-09-21 11:15:47 UTC
Just guessing but currently the muxer would accept "audio/mpeg" without any mpegversion field or anything for example because of the incomplete caps compatibility check in pads (subset vs. non-empty intersection). Patch looks good as a last resort though
Comment 3 Mark Nauwelaerts 2011-09-21 11:40:30 UTC
It would not accept that easily; there are checks at least requiring channels and rate fields, and also the format fourcc should end up with something valid (which is also unlikely without mpegversion field).
Comment 4 Tim-Philipp Müller 2013-01-22 09:30:10 UTC
(In reply to comment #2)
> Just guessing but currently the muxer would accept "audio/mpeg" without any
> mpegversion field or anything for example because of the incomplete caps
> compatibility check in pads (subset vs. non-empty intersection). Patch looks
> good as a last resort though

Can this still happen in 1.0, or can we close this as OBSOLETE now?

Can't reproduce this with audiotestsrc ! avenc_mp2 ! avimux ! fakesink.
Comment 5 Mark Nauwelaerts 2013-11-13 17:19:56 UTC
I have never been clear on how this could happen, also now.

So would move to OBSOLETE (and actually do so).

If some more information can be provided, particularly some way to reproduce, feel free to reopen.