Created attachment 301598 [details]
./tsswitchtest <short-file.ts>

i have a scenario where i wanna dynamically switch the input of a gst-rtsp-server streaming mpeg ts (with h.264 + aac es inside) from a ts stream delivered over a socket to a still image in case the input stream is lost.

so i destilled this into a minimal test case reading a ts from a file in an appsrc's need-data callback and then removing the appsrc and replacing it with testsources when the file is played completely.

so basically i have this pipeline (except with appsrc instead of filesrc)

gst-launch-1.0 filesrc location=test.ts ! queue name=ts_queue ! tsparse name=tsparse set-timestamps=TRUE ! tsdemux name=d d. ! queue ! faad ! audioconvert ! alsasink  d. ! queue ! h264parse ! avdec_h264 ! autovideosink

and replace it with

gst-launch-1.0 videotestsrc ! capsfilter ! x264enc ! mpegtsmux name=m audiotestsrc ! capsfilter ! faac ! m. m. ! queue name=ts_queue ! tsparse name=tsparse set-timestamps=TRUE ! tsdemux name=d d. ! queue ! faad ! audioconvert ! alsasink  d. ! queue ! h264parse ! avdec_h264 ! autovideosink

i did lots of experiments trying to get the timestamps right to achieve a seamless transition but I suspect some bugginess because there are also

(tsswitchtest:10281): GStreamer-WARNING **: gstpad.c:4802:store_sticky_event:<ts_queue:sink> Sticky event misordering, got 'segment' before 'caps'

the testsources seem to produce the buffers with the correct timestamps because they show up as
tsparse mpegtsparse.c:789:drain_pending_buffers:<tsparse> Pushing buffers - startTS 0:00:13.874543898 duration 0:00:00.119712000 16168 bytes
...
but then after each drain line, there are several
GST_PADS gstpad.c:4102:gst_pad_chain_list_default:<tsparse:sink> chaining each group in list as a merged buffer
and faad will eventually error out because it can't decode the stream