Please describe the problem:
See the following python program which dynamicly change the mpegtsparse's "program-numbers" property.

This dynamic change is not working well : there is sometime a "GST_FLOW_NOT_LINKED" error while the new pad is added (when new program entry is added to the property) and rarely a segmentation fault while removing a pad (when a program is removed from the property).

Steps to reproduce:
See the attached python sample program. 
This sample program reads a MPTS stream from an UDP multicast address (you can use vlc to stream a MPTS file as a source)

Actual results:
-> many time the sample program is working well
-> but after a while, there is a GST_FLOW_NOT_LINKED error or a segmentation fault

Expected results:


Does this happen every time?


Other information:
The segmentation is rare so here is a stack trace obtained using gdb:
$ gdb --args python test_tsparse.py
register program 6905 counter: 1
pad added
linking
linked
[New Thread 0xb64ffb90 (LWP 14586)]
[Thread 0xb64ffb90 (LWP 14586) exited]
unregister program 6905
pad removed
[....]
register program 6905 counter:28
pad added
linking
linked
[New Thread 0xb64ffb90 (LWP 14587)]
[Thread 0xb64ffb90 (LWP 14587) exited]
unregister program 6905
pad removed

Program received signal SIGSEGV, Segmentation fault.

+ Trace 211960

$1 = (MpegTSParseProgram *) 0x30657372
(gdb) print tspad->program->streams
Cannot access memory at address 0x3065737e


In fact, I suppose this bug is due to concurrent accesses to the element data (MpegTSParse->programs) between the task thread and the application thread (trought the set_property).

I am working on a patch...