Queries on how to stop and restart GstSplitMuxSink

[Howling wong]

Hi,

Just to report and ask for advice on some problems


  1.  Have managed to get splitmuxsink to  sort-of "work" in a dynamical pipeline (record on/off). Tried for several cycles on record on/off. Seems like it work and I am able to record the multiple files recording of 1 min for a few session...  However I do have some questions..
  2.
  3.  I am using format-location signal callback to name each file.. according to my naming format requirements.  I know I can read bus signal "splitmuxsink-fragment-closed/opened" for me to execute a name change but the signal seem to arrive pretty late(in my opinion) in my pipeline (sometimes it takes almost 9 -10 secs) after the new file was created. Is there some ways for me to improve the speed the message reaches the bus? Or it is normal?

      3. I have use split-now actions signal when command to stop recording arrive. After which I send a eos to my encoder in the dynamic branch (to be detached) and wait for it to reach my splitmuxsink, using somewhat like the code I used below. It appears to work but I have the muxer within the splitmuxsink complain that it could not multiplex stream.  Any idea of why this is so?

    4. However somehow the coding still works. I would just need to ignore the error messages when it float to the bus. Seem like things is working. Would there be any other side long terms effect?

   4.  I tried to trace the error using debug log (below show a snippet) and looking through the codes and come upon a theory that maybe the problem lies with clearing of buffer (when cmd to stop recording and pipeline is flushed) and that some previous buffer might not be cleared. Any ideas on my postulation?


0:00:40.199740000  1084 0xffff84004c00 INFO              GST_STATES gstelement.c:2669:_priv_gst_element_state_changed:<sink_1> notifying about state-changed PAUSED to READY (VOID_PENDING pending)
0:00:40.199739125  1084 0xffff6c017f00 WARN                   qtmux gstqtmux.c:1930:gst_qt_mux_send_buffer:<muxer_1> Failed to send buffer (0xffff4c023480) size 2154
0:00:40.199793250  1084 0xffff84004c00 INFO              GST_STATES gstbin.c:2962:gst_bin_change_state_func:<fsink> child 'sink_1' changed state to 2(READY) successfully
0:00:40.199809500  1084 0xffff6c017f00 WARN                   qtmux gstqtmux.c:5024:gst_qt_mux_add_buffer:<muxer_1> error: Failed to push sample.
0:00:40.199840875  1084 0xffff84004c00 INFO              GST_STATES gstbin.c:2513:gst_bin_element_set_state:<muxer_1> current PAUSED pending VOID_PENDING, desired next READY
0:00:40.199916250  1084 0xffff84004c00 INFO              aggregator gstaggregator.c:2384:gst_aggregator_src_pad_activate_mode_func:<muxer_1> Deactivating srcpad
0:00:40.199934000  1084 0xffff6c017f00 INFO        GST_ERROR_SYSTEM gstelement.c:2234:gst_element_message_full_with_details:<muxer_1> posting message: Could not multiplex stream.
0:00:40.199949125  1084 0xffff84004c00 INFO              aggregator gstaggregator.c:1400:gst_aggregator_stop_srcpad_task:<muxer_1> Stopping srcpad task
0:00:40.200022000  1084 0xffff6c017f00 INFO        GST_ERROR_SYSTEM gstelement.c:2261:gst_element_message_full_with_details:<muxer_1> posted error message: Could not multiplex stream.

Thanks

________________________________
From: Howling wong
Sent: Tuesday, April 5, 2022 4:12 PM
To: gstreamer-devel at lists.freedesktop.org <gstreamer-devel at lists.freedesktop.org>
Subject: Queries on how to stop and restart GstSplitMuxSink

Hi

I have some queries as with regards to how to stop the GstSplitMuxSink


  1.  Stopping it. I have split the files to be saved (each of 5 mins). The result is ok for the video files fulfilling the 5 mins interval but the last video (which is less than 5 mins) has size of 0 bytes. Nothing is being saved to it.

           I read up the forum to find that I would need to send eos event to the splitmuxsink when I want to stop it.                        Somehow or rather I could not get it right. Would like some pointers on how to stop (any additional stuff needs to            be done

          My source code(or pseudo code) below

         GstPadProbeReturn
         eos_cb(GstPad *pad, GstPadProbeInfo * info, gpointer user_data)
        {
               // blocking codes
               while(GST_EVENT_TYPE (GST_PAD_PROBE_INFO_DATA (info)) != GST_EVENT_EOS)
                         sleep(1);
               g_print("thread live: pad received eos \n");

               return GST_PAD_PROBE_REMOVE;
         }

        int main()
        {

         /*******************   do something   ************************/

         case RECORD_STOP:
                   GstPad* splitMuxPad = gst_element_get_static_pad(records->fsink, "video");
                  if (!splitMuxPad && !(records->fsink))
                  {
                            g_critical(" Could not obtain the splitmux and records->fsink sinkpad!!\n"); // <---- fails here!
                           exit(-1);
                   }

                  gst_pad_add_probe(splitMuxPad,
                                                      (GstPadProbeType)(GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM),
                                                      eos_cb,
                                                       NULL,
                                                      NULL);

                    // should i send eos event to splitmuxsink or the pad?
                     gst_pad_send_event(splitMuxPad, gst_event_new_eos());

                     gst_object_unref(splitMuxPad);

                   /****
                          Proceed on detaching other parts of the record bin
                   *****/

             }

       2. To start another cycle of recording and stop recording. The "working" method seem to be to destroy or unreference the Splitmuxsink and recreate splitmuxsink upon starting the recording. Is this true? Find it rather strange.

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220420/b837a1cd/attachment-0001.htm>