program crashes after g_main_loop_run()
tim at centricular.com
Sun Apr 6 08:56:58 PDT 2014
On Sun, 2014-04-06 at 06:29 -0700, leon wrote:
> I load pcap file and push the h.264 stream to the buffer.
> the callbacks functions:
There's a pcap source element in gst-plugins-bad, for what it's worth,
which reads from a .pcap file and outputs the packet data.
> static gboolean *read_data*(gst_app_t *app)
> struct pcap_pkthdr *header;
> const u_char *data;
> u_char *RTP_ptr;
> int returnValue = pcap_next_ex(pcap, &header, &data);
> if (returnValue >= 0)
> RTP_ptr= (u_char *)data + 42; // pointer to the start of RTP + H.264
> size = (header->caplen)-42; //prt: holds the actual data (destination)
> buffer =gst_buffer_new_wrapped (RTP_ptr,size);
This looks problematic.
The gst_buffer_new_wrapped() API reference says: "Creates a new buffer
that wraps the given data. The memory will be freed with g_free and will
be marked writable."
Here is the pcap_next_ex() reference [*]: "If the packet was read
without problems, ... the pointer pointed to by the pkt_data argument is
set to point to the data in the packet. The ... packet data are not to
be freed by the caller, and are not guaranteed to be valid after the
next call to pcap_next_ex(), pcap_next(), pcap_loop(), or
pcap_dispatch(); if the code needs them to remain valid, it must make a
copy of them."
(Even if that function returned a malloced pointer, which it does not,
there would be two more problems with that: when the buffer is unreffed
by the pipeline some time later (a) gstreamer will call g_free on a
buffer that was allocated with plain malloc instead of g_malloc() which
may or may not be a problem; and (b) that gstreamer will call g_free()
on RTP_ptr while the malloced region would be RTP_ptr - 42 or so, but
you could fix that by using _wrapped_full()).
Anyway, try this instead:
buffer = gst_buffer_new_wrapped (g_memdup (RTP_ptr, size), size);
Tim Müller, Centricular Ltd - http://www.centricular.com
More information about the gstreamer-devel