GNOME Bugzilla – Bug 759807
collectpads: Cannot use GST_STREAM_FLAG_SPARSE with mpegtsmux
Last modified: 2018-11-03 12:31:39 UTC
Setting GST_STREAM_FLAG_SPARSE to one of inputs of mpegtsmux stops both input streams. May be the cause is in libs/gst/base/gstcollectpads.c Here is a patch. With this patch GST_STREAM_FLAG_SPARSE works as expected. diff --git a/libs/gst/base/gstcollectpads.c b/libs/gst/base/gstcollectpads.c index 8edfe41..14f9926 100644 --- a/libs/gst/base/gstcollectpads.c +++ b/libs/gst/base/gstcollectpads.c @@ -1440,7 +1440,8 @@ gst_collect_pads_recalculate_waiting (GstCollectPads * pads) if (!GST_COLLECT_PADS_STATE_IS_SET (data, GST_COLLECT_PADS_STATE_WAITING)) { /* start waiting */ gst_collect_pads_set_waiting (pads, data, TRUE); - result = TRUE; + if (!GST_COLLECT_PADS_STATE_IS_SET (data, GST_COLLECT_PADS_STATE_LOCKED)) + result = TRUE; } } }
Do you have an example pipeline that reproduces this problem?
Problem in more details described here: http://stackoverflow.com/questions/34294755/mux-klv-data-with-h264-by-mpegtsmux The pipeline consists of two parts: main part: v4l2src input-src=Camera ! videorate drop-only=true ! 'video/x-raw, format=(string)NV12, width=1920, height=1088, framerate=25/1' ! ce_h264enc target-bitrate=6000000 idrinterval=25 intraframe-interval=60 ! queue ! mpegtsmux alignment=7 ! udpsink host=192.168.0.1 port=3000 -v klv part: appsrc ! mpegtsmux Main part without appsrc works well. So the point of interest is appsrc: Creation of appsrc: appSrc = gst_element_factory_make("appsrc", nullptr); gst_app_src_set_caps (GST_APP_SRC (appSrc), gst_caps_new_simple("meta/x-klv", "parsed", G_TYPE_BOOLEAN, TRUE, "sparse", G_TYPE_BOOLEAN, TRUE, nullptr)); g_object_set(appSrc, "format", GST_FORMAT_TIME, nullptr); addition appsrc: gst_bin_add(GST_BIN(pipeline), appSrc); gst_element_link(appSrc, mpegtsmux); Pushing data: void AppSrc::pushData(const std::string &data) { GstBuffer *buffer = gst_buffer_new_allocate(nullptr, data.size(), nullptr); GstMapInfo map; GstClock *clock; GstClockTime abs_time, base_time; gst_buffer_map (buffer, &map, GST_MAP_WRITE); memcpy(map.data, data.data(), data.size()); gst_buffer_unmap (buffer, &map); GST_OBJECT_LOCK (element); clock = GST_ELEMENT_CLOCK (element); base_time = GST_ELEMENT (element)->base_time; gst_object_ref (clock); GST_OBJECT_UNLOCK (element); abs_time = gst_clock_get_time (clock); gst_object_unref (clock); GST_BUFFER_PTS (buffer) = abs_time - base_time; GST_BUFFER_DURATION (buffer) = gst_util_uint64_scale_int (1, GST_SECOND, 1); gst_app_src_push_buffer(GST_APP_SRC(element), buffer); } Setting GST_STREAM_FLAG_SPARSE: GstEvent* stream_start = gst_event_new_stream_start("klv-04"); gst_event_set_stream_flags(stream_start, GST_STREAM_FLAG_SPARSE); GstPad* pad = gst_element_get_static_pad(GST_ELEMENT(element), "src"); gst_pad_push_event (pad, stream_start);
Hello, I felt exactly on the same issue (on branch master, up-to-date), and the proposed fix works for me. My pipeline is demuxing with tsdemux, do some processing on audio/video media and remux with mpegtsmux. It works well, with only audio/video pads. Pipeline does not wants to PREROLL when I add the subtitle demux/remux. But it works well, when I apply the patch. This bug is reproducible with gst-launch with the following pipeline : filesrc location=mpts.ts blocksize=1316 ! video/mpegts,systemstream=true ! tsdemux program-number=1025 name=d mpegtsmux alignment=7 name=m ! rndbuffersize min=1316 max=1316 ! filesink location=out.ts d.video_0078 ! queue max-size-bytes=10000000 max-size-time=0 max-size-buffers=0 ! mpegvideoparse ! avdec_mpeg2video ! deinterlace ! videoscale method=0 ! video/x-raw,width=320,height=240 ! x264enc bitrate=1024 ! h264parse ! m. d.audio_0082 ! queue max-size-bytes=10000000 max-size-time=0 max-size-buffers=0 ! mpegaudioparse ! avdec_mp2float ! audioconvert ! voaacenc bitrate=64000 ! aacparse ! m. d.subpicture_008d ! queue max-size-bytes=10000000 max-size-time=0 max-size-buffers=0 ! subpicture/x-dvb ! m. d.subpicture_008e ! queue max-size-bytes=10000000 max-size-time=0 max-size-buffers=0 ! subpicture/x-dvb ! m. I can provide the input stream if required.
Can someone attach a well formed "git format-patch" to this bug ?
Created attachment 323112 [details] [review] check the state is not locked We fall into infinite loop, if the pad is locked and we wait it to be waiting.
We fall into infinite loop, if the pad is locked and we wait it to be NO waiting.
Do you mean your last patch is incomplete ?
No, it is complete. I just describe the situation. Without this patch gstcollectpad can fall into infinite loop in some situations.
okay, thank you for your help anyway !
Created attachment 365446 [details] Attached is a test video file with a sparse metadata stream to demostrate that the suggested fix works. Without the suggested fix the pipeline blocks, otherwise data flows properly. gst-launch-1.0 filesrc location=/tmp/metadata_test.ts ! tsdemux name=demux ! queue ! h264parse ! mpegtsmux alignment=7 name=mux ! udpsink clients=127.0.0.1:12000 demux. ! 'meta/x-klv' ! queue ! mux.
This was tested against 1.12.0. Version 1.6 doesn't properly pace a file based source over a udp output. I would expect file -> file to work fine but did not test it myself.
I also just realized that the MISB document I reference in my code comment for patch 0001-Add-MPEG2-TS-descriptor-support-for-KLV-metadata.patch is incorrect. I references document MISB 0604 but it should be MISB ST1402. Sorry!
Sorry, previous comment was for a different bug
Can we get a unit test for this collectpads patch/bug? collectpads is effectively deprecated in favour of GstAggregator, and I'd prefer to not introduce regressions at this point so a unit test would be useful :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/147.