[gstreamer-bugs] [Bug 606657] New: mpegtsmux crashes with h264parse in byte-stream mode

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=606657
  GStreamer | gst-plugins-bad | git

           Summary: mpegtsmux crashes with h264parse in byte-stream mode
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: ext-veli-matti.nurmenniemi at nokia.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Created an attachment (id=151181)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=151181)
Custom traces from tsmuxtream.c (around line 430: memcpy())

mpegtsmux crashes if h264parse output-format property is set to 1 (Bytestream
Format) and added into pipeline to convert raw NAL unit format type of h264
stream (from MP4 container) into byte-stream format (suitable for MPEG2-TS
container).


This can be reproduced with the following pipeline:

filesrc location=h264.mp4 ! qtdemux name=demux  demux.video_00 ! queue !
h264parse output-format=1 ! mux.sink_0  demux.audio_00 ! queue ! mux.sink_1
mpegtsmux name=mux ! filesink location=transcoded.ts


Callstack:

16 memcpy()  0x004da071    <- Segmentation fault
15 tsmux_stream_get_data() /usr/include/bits/string3.h:52 0x005b1d78 (should be
tsmuxstream.c:430) 
14 tsmux_write_stream_packet() /gst-plugins-bad/gst/mpegtsmux/tsmux/tsmux.c:787
0x005b0709    
13 mpegtsmux_collected() /gst-plugins-bad/gst/mpegtsmux/mpegtsmux.c:660
0x005aeae8    
12 gst_collect_pads_check_collected()
/GStreamer/libs/gst/base/gstcollectpads.c:1139 0x00411bd7    
11 gst_collect_pads_chain() /GStreamer/libs/gst/base/gstcollectpads.c:1367
0x00413ae7    
10 gst_pad_chain_data_unchecked() /GStreamer/gst/gstpad.c:4122 0x003146d5    
9 gst_pad_push_data() /GStreamer/gst/gstpad.c:4351 0x00315240    
8 gst_queue_push_one() /GStreamer/plugins/elements/gstqueue.c:1083 0x003c6174   
7 gst_queue_loop() /GStreamer/plugins/elements/gstqueue.c:1185 0x003c6174    
6 gst_task_func() /GStreamer/gst/gsttask.c:238 0x0033bea5    
5 default_func() /GStreamer/gst/gsttaskpool.c:70 0x0033d7a7    
4 <symbol is not available> 0x0077a9af    
3 <symbol is not available> 0x0077937f    
2 start_thread()  0x0038d80e    
1 clone()  0x005318de    


If ffmux_mpegts is used instead of mpegtsmux, everything goes smoothly; e.g.
pipeline: 

location=h264.mp4 ! qtdemux name=demux  demux.video_00 ! queue ! h264parse
output-format=1 ! mux.video_0  demux.audio_00 ! queue ! mux.audio_0
ffmux_mpegts name=mux ! filesink location=transcoded.ts


See attached trace files without h264parse byte-stream mode (no crash) and with
byte-stream mode (crash).

Code snippet from tsmuxstream.c (note added traces):
...
    /* Take as much as we can from the current buffer */
    avail = stream->cur_buffer->size - stream->cur_buffer_consumed;
    cur = stream->cur_buffer->data + stream->cur_buffer_consumed;
    if (avail < len) {
      memcpy (buf, cur, avail);
      tsmux_stream_consume (stream, avail);

      buf += avail;
      len -= avail;
    } else {
      g_printf( "avail >= len (buf=0x%08x, cur=0x%08x, avail=%d, len=%u)\n",
buf, cur, avail, len ); //hack trace
      memcpy (buf, cur, len); //430: crashes here!!
      g_printf( "memcpy ok\n" ); //hack trace
      tsmux_stream_consume (stream, len);

      len = 0;
    }
...

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.