splitmuxsink arbitrary close

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

splitmuxsink arbitrary close

cottrelld
Hi.

I have a pipeline with a tee.  One of the tee channels is a motion detector.   Upon detecting motion, it fires up another tee channel with a splitmuxsink.

When motion is stoped, we want to close splitmuxsink.  I've tried just removing it, and also tried sending an EOS, but it simply closes the file and leaves it in an unplayable state.  

In addition, I try to be able to readd the splitmuxsink in the future when we need it again, but it doesn't seem to want to work as normal.  

Is there a way to gracefully end the last video correctly?  And is the splitmuxsink designed to be able to be removed and added at will?

Thanks!
-David
Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink arbitrary close

Jan Schmidt-6
On 23/07/15 15:25, cottrelld wrote:
> Hi.
>
> I have a pipeline with a tee.  One of the tee channels is a motion detector.
> Upon detecting motion, it fires up another tee channel with a splitmuxsink.
>
> When motion is stoped, we want to close splitmuxsink.  I've tried just
> removing it, and also tried sending an EOS, but it simply closes the file
> and leaves it in an unplayable state.

EOS is a valid way to close the stream and end the file, but you need to
wait until the splitmuxsink posts EOS on its bus to know that that has
actually completed - simply sending the EOS event on the sink pad(s) and
changing the state to NULL won't give it a chance to process the EOS fully.

> In addition, I try to be able to readd the splitmuxsink in the future when
> we need it again, but it doesn't seem to want to work as normal.

There may be a bug around being reusable - I'm not sure that's been
properly tested yet. splitmuxsink is pretty new.

> Is there a way to gracefully end the last video correctly?  And is the
> splitmuxsink designed to be able to be removed and added at will?

Cheers,
Jan.

>
> Thanks!
> -David
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/splitmuxsink-arbitrary-close-tp4672799.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink arbitrary close

cottrelld
Thanks for the fast reply.  Some further questions:

1.  I tried to send EOS and wait but it didn't result in a valid video.

My pipeline is like this:    otherstuff | tee | queue | x264enc | splitmuxsink

I first put a block on the src pad of the queue.  In the callback,  I send an EOS on the sink pad of the queue.  

The in-progress last video get's written, but it's not valid.  it has non-zero length but nothing can open it.  The rest of the videos created by the splitmuxsink before that are fine.  Note, I'm not releasing the block from the queue src at all right now, and I'm not removing the splitmuxsink.  I left it running to see if it'd close the video ok.

Should I be sending it someplace else?  I notice the send_eos in splitmuxsink sends it on the peer of the multiqueue... 

2.  How do you capture the EOS on the splitmuxsink bus?

When you say I should wait for splitmuxsink to post EOS on its bus, do you mean setup a callback like the following:
 gst_bus_add_watch (GST_ELEMENT_BUS (m_writeSink), bus_cb_writeSink, m_loop);

If so, I don't get any callbacks on that.

Thanks for the help,
-David



On Thu, Jul 23, 2015 at 2:54 AM, Jan Schmidt-6 [via GStreamer-devel] <[hidden email]> wrote:
On 23/07/15 15:25, cottrelld wrote:
> Hi.
>
> I have a pipeline with a tee.  One of the tee channels is a motion detector.
> Upon detecting motion, it fires up another tee channel with a splitmuxsink.
>
> When motion is stoped, we want to close splitmuxsink.  I've tried just
> removing it, and also tried sending an EOS, but it simply closes the file
> and leaves it in an unplayable state.

EOS is a valid way to close the stream and end the file, but you need to
wait until the splitmuxsink posts EOS on its bus to know that that has
actually completed - simply sending the EOS event on the sink pad(s) and
changing the state to NULL won't give it a chance to process the EOS fully.

> In addition, I try to be able to readd the splitmuxsink in the future when
> we need it again, but it doesn't seem to want to work as normal.

There may be a bug around being reusable - I'm not sure that's been
properly tested yet. splitmuxsink is pretty new.

> Is there a way to gracefully end the last video correctly?  And is the
> splitmuxsink designed to be able to be removed and added at will?

Cheers,
Jan.

>
> Thanks!
> -David
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/splitmuxsink-arbitrary-close-tp4672799.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



If you reply to this email, your message will be added to the discussion below:
http://gstreamer-devel.966125.n4.nabble.com/splitmuxsink-arbitrary-close-tp4672799p4672809.html
To unsubscribe from splitmuxsink arbitrary close, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink arbitrary close

Sérgio Agostinho
Hey, 

Some thoughts

1 - 
If you're only sending the eos on the callback of the block probe, I would expect data flow to be blocked upstream of the queue's src pad by that time. The EOS event is serialized with data so I don't think there's a way for it to reach splitmuxsink.

What I would do is to place a probe on the splitmuxsink sink pad, with the flag GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM and then verify the EOS in the callback with 

GstPadProbeReturn 
eos_cb(GstPad *pad, GstPadProbeInfo * info, gpointer user_data)
{

  if (GST_EVENT_TYPE (GST_PAD_PROBE_INFO_DATA (info)) != GST_EVENT_EOS)
      return GST_PAD_PROBE_PASS; 
 
  //you've received the EOS do whatever you need to do here
  return GST_PAD_PROBE_REMOVE;
}

and send the EOS on queue's sink pad. 

Cheers

2015-07-23 22:26 GMT+02:00 cottrelld <[hidden email]>:
Thanks for the fast reply.  Some further questions:

1.  I tried to send EOS and wait but it didn't result in a valid video.

My pipeline is like this:    otherstuff | tee | queue | x264enc | splitmuxsink

I first put a block on the src pad of the queue.  In the callback,  I send an EOS on the sink pad of the queue.  

The in-progress last video get's written, but it's not valid.  it has non-zero length but nothing can open it.  The rest of the videos created by the splitmuxsink before that are fine.  Note, I'm not releasing the block from the queue src at all right now, and I'm not removing the splitmuxsink.  I left it running to see if it'd close the video ok.

Should I be sending it someplace else?  I notice the send_eos in splitmuxsink sends it on the peer of the multiqueue... 

2.  How do you capture the EOS on the splitmuxsink bus?

When you say I should wait for splitmuxsink to post EOS on its bus, do you mean setup a callback like the following:
 gst_bus_add_watch (GST_ELEMENT_BUS (m_writeSink), bus_cb_writeSink, m_loop);

If so, I don't get any callbacks on that.

Thanks for the help,
-David



On Thu, Jul 23, 2015 at 2:54 AM, Jan Schmidt-6 [via GStreamer-devel] <[hidden email]> wrote:
On 23/07/15 15:25, cottrelld wrote:
> Hi.
>
> I have a pipeline with a tee.  One of the tee channels is a motion detector.
> Upon detecting motion, it fires up another tee channel with a splitmuxsink.
>
> When motion is stoped, we want to close splitmuxsink.  I've tried just
> removing it, and also tried sending an EOS, but it simply closes the file
> and leaves it in an unplayable state.

EOS is a valid way to close the stream and end the file, but you need to
wait until the splitmuxsink posts EOS on its bus to know that that has
actually completed - simply sending the EOS event on the sink pad(s) and
changing the state to NULL won't give it a chance to process the EOS fully.

> In addition, I try to be able to readd the splitmuxsink in the future when
> we need it again, but it doesn't seem to want to work as normal.

There may be a bug around being reusable - I'm not sure that's been
properly tested yet. splitmuxsink is pretty new.

> Is there a way to gracefully end the last video correctly?  And is the
> splitmuxsink designed to be able to be removed and added at will?

Cheers,
Jan.

>
> Thanks!
> -David
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/splitmuxsink-arbitrary-close-tp4672799.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



If you reply to this email, your message will be added to the discussion below:
http://gstreamer-devel.966125.n4.nabble.com/splitmuxsink-arbitrary-close-tp4672799p4672809.html
To unsubscribe from splitmuxsink arbitrary close, click here.
NAML



View this message in context: Re: splitmuxsink arbitrary close
Sent from the GStreamer-devel mailing list archive at Nabble.com.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink arbitrary close

cottrelld
The sending of the EOS closes out the file if I just sent it by itself without the block (Half way there!).  But I can't get the sink in order to place the probe and capture the callback.  How do you obtain the sink pad on the splitmuxsink?  I get null back from gst_element_get_static_pad in the code below.  

>> What I would do is to place a probe on the splitmuxsink sink pad, with the flag GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM and then verify the EOS in the callback with 

(Note, I also tried to obtain the actual sink in hopes of getting the pad off that, but the sink property is only the provided sink. )


void PipelineManager::stopPipeline_writerImpl()
{
  g_print("stopPipeline_writerImpl, stopping\n");

  if (!gPipelineMgr->m_writeSink) {
    g_critical("stopPipeline_writerImpl: m_writeSink is NULL!!\n");
    exit(-1);
  }

  // Block all transmissions past m_queueWriterTee
  GstPad* writerSinkPad = gst_element_get_static_pad(gPipelineMgr->m_writeSink, "sink");
  if (!writerSinkPad) {
    g_critical("stopPipeline_writerImpl: Could not obtain the writer sinkpad!!\n"); // <---- fails here!
    exit(-1);
  }

  gst_pad_add_probe(writerSinkPad,
                    (GstPadProbeType)(GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM),
                    writer_eos_cb,
                    m_loop,
                    NULL);
  gst_object_unref(writerSinkPad);

  // Send an EOS on the queue
  GstPad* queueSinkPad = gst_element_get_static_pad (gPipelineMgr->m_queueWriterTee, "sink");
  gst_pad_send_event(queueSinkPad, gst_event_new_eos ());
  gst_object_unref(queueSinkPad);

  g_print("stopPipeline_writerImpl, done...\n");
}


Thanks again for your help!
-David

Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink arbitrary close

cottrelld
In reply to this post by Sérgio Agostinho
I'm currently using a timer to wait for a second instead of capturing the EOS.  Any idea what could be missing?  Thanks,
-David

On Sun, Jul 26, 2015 at 10:25 AM, David Cottrell <[hidden email]> wrote:
The sending of the EOS closes out the file if I just sent it by itself without the block (Half way there!).  But I can't get the sink in order to place the probe and capture the callback.  How do you obtain the sink pad on the splitmuxsink?  I get null back from gst_element_get_static_pad in the code below.  

>> What I would do is to place a probe on the splitmuxsink sink pad, with the flag GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM and then verify the EOS in the callback with 

(Note, I also tried to obtain the actual sink in hopes of getting the pad off that, but the sink property is only the provided sink. )


void PipelineManager::stopPipeline_writerImpl()
{
  g_print("stopPipeline_writerImpl, stopping\n");

  if (!gPipelineMgr->m_writeSink) {
    g_critical("stopPipeline_writerImpl: m_writeSink is NULL!!\n");
    exit(-1);
  }

  // Block all transmissions past m_queueWriterTee
  GstPad* writerSinkPad = gst_element_get_static_pad(gPipelineMgr->m_writeSink, "sink");
  if (!writerSinkPad) {
    g_critical("stopPipeline_writerImpl: Could not obtain the writer sinkpad!!\n"); // <---- fails here!
    exit(-1);
  }

  gst_pad_add_probe(writerSinkPad,
                    (GstPadProbeType)(GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM),
                    writer_eos_cb,
                    m_loop,
                    NULL);
  gst_object_unref(writerSinkPad);

  // Send an EOS on the queue
  GstPad* queueSinkPad = gst_element_get_static_pad (gPipelineMgr->m_queueWriterTee, "sink");
  gst_pad_send_event(queueSinkPad, gst_event_new_eos ());
  gst_object_unref(queueSinkPad);

  g_print("stopPipeline_writerImpl, done...\n");
}


Thanks again for your help!
-David


Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink arbitrary close

Jan Schmidt-6
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


On 04/08/15 04:25, cottrelld wrote:
> I'm currently using a timer to wait for a second instead of
> capturing the EOS.  Any idea what could be missing?  Thanks,
> -David

The 'EOS' you're looking for is the bus message that comes on the
splitmuxsink bus. Once the filesink inside splitmuxsink receives the
EOS event you send, it will send an EOS message on the bus.

- - Jan.

>
> On Sun, Jul 26, 2015 at 10:25 AM, David Cottrell <[hidden email]
> </user/SendEmail.jtp?type=node&node=4672957&i=0>> wrote:
>
> The sending of the EOS closes out the file if I just sent it by
> itself without the block (Half way there!).  But I can't get the
> sink in order to place the probe and capture the callback.  How do
> you obtain the sink pad on the splitmuxsink?  I get null back from
> gst_element_get_static_pad in the code below.
>
>>> What I would do is to place a probe on the splitmuxsink sink
>>> pad,
> with the flag GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM and then verify
> the EOS in the callback with
>
> (Note, I also tried to obtain the actual sink in hopes of getting
> the pad off that, but the sink property is only the provided sink.
> )
>
>
> *void PipelineManager::stopPipeline_writerImpl()* {
> g_print("stopPipeline_writerImpl, stopping\n");
>
> if (!gPipelineMgr->m_writeSink) {
> g_critical("stopPipeline_writerImpl: m_writeSink is NULL!!\n");
> exit(-1); }
>
> // Block all transmissions past m_queueWriterTee GstPad*
> writerSinkPad =
> gst_element_get_static_pad(gPipelineMgr->m_writeSink, "sink"); if
> (!writerSinkPad) { g_critical("stopPipeline_writerImpl: Could not
> obtain the writer sinkpad!!\n"); // <---- fails here! exit(-1); }
>
> gst_pad_add_probe(writerSinkPad,
>
> (GstPadProbeType)(GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM),
> writer_eos_cb, m_loop, NULL); gst_object_unref(writerSinkPad);
>
> // Send an EOS on the queue GstPad* queueSinkPad =
> gst_element_get_static_pad (gPipelineMgr->m_queueWriterTee,
> "sink"); gst_pad_send_event(queueSinkPad, gst_event_new_eos ());
> gst_object_unref(queueSinkPad);
>
> g_print("stopPipeline_writerImpl, done...\n"); }
>
>
> Thanks again for your help! -David
>
>
>
> ----------------------------------------------------------------------
- --
>
>
View this message in context: Re: splitmuxsink arbitrary close
> <http://gstreamer-devel.966125.n4.nabble.com/splitmuxsink-arbitrary-cl
ose-tp4672799p4672957.html>
>
>
Sent from the GStreamer-devel mailing list archive
> <http://gstreamer-devel.966125.n4.nabble.com/> at Nabble.com.
>
>
> _______________________________________________ gstreamer-devel
> mailing list [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCgAGBQJVw1hJAAoJEEqdx1eGJfOefg8P/3E5gB2MjD26DhUDVziZl8Wq
pI6ygJdXgffafMaMH20EutHRAMrcYVjM+dTtghis5SULtyQwzf+FVobajoLJEki6
uvJMWcQWPDjotH9oSmFd14ALXIGxdKzOMj1a1vGDS/3ysDJf4Gbtnj6odRt9RIRY
9WdtuhXhtq+BUGKH7Gr+NPrzg649UPuqhFSAkG5cWPY9/+T5ctW06qnxjHgD64XE
jkbwZ5kghsLItuy0X4thJ8mPOLa12KT+WO4IcyVdyeyJXjV+W8HafXu/Nx8wMAY3
ZMw3OBoR0lZoG7t26n3FXsL6eNmHAwvGNaCJFQmb4wFfSKa9lUVF9FB4DG9UbskG
n9CQT5h4fhWqILsLAwp65A6ThwU+5r1nawRCv8VZwFratvuy0BubYu6inznFCAS4
5Cw8dAXfav8FXsfddsnDxuH9uJLuQp5gWZZ1kzcyggSHPKoA73D5QQOaMmqY5HCV
XMHmGWuPy4/6SwhQTS76IdmINRyToDcGKnribWAbm7f/g8e/EVV9ZSX2qz0xtTvs
WJ5DPcfB9HhWF/e/32NRZioOuv8evi8ejdlyK05yBD1oCXzkEwIQy+da9HI9sMQm
6lqR6E5f4r0yhMTTySz0XHHgyXYRGNLjOveaSu1qV24McYLXWm9n1g6kxUiD3aeF
b3osTUMfvyFYDBzNBWJX
=7Wo7
-----END PGP SIGNATURE-----
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink arbitrary close

cottrelld
Still working on this...

I have 2 issues I'm working through and could really use a hand:

1) Issue 1 (Biggest issue): Sending the EOS in the way you suggested stops the whole pipeline.

  // Send an EOS on the writer queue to stop it gracefully
  GstPad* queueSinkPad = gst_element_get_static_pad (gPipelineMgr->m_queueWriterTee, "sink");
  gst_pad_send_event(queueSinkPad, gst_event_new_eos ());
  gst_object_unref(queueSinkPad);

Sending the EOS gracefully closes the video, but then the whole pipeline stops.  I wrote a simple echo filter and added it on another leg of the tee, it just outputs a counter every second.  After I sent the EOS as above, the echofilter stops outputing!  I'm trying to just close down my writer leg of the tee.  Any idea why sending an EOS on one of the tee's queues would halt everything in the pipeline even across the tee?

2) Issue 2: I'm not sure how to capture the EOS you mentioned.  I tried to get the sink from splitmuxsink but can't.  I tried putting a listener for pad creation, and I only see the video pad in the callback come through.   I'm currently just waiting 1 second and then close it down, but it'd be smoother if I could figure out how to capture the EOS that the splitmuxsink's sink sends out upon processing my EOS.  Note, I verified that things stop before I manually remove the writer part of the tee by setting it from 1 second to 100.  Could you give me a pointer to something that listens on the splitmuxsink's bus as you mentioned?

Thanks for your patience and help!
-David

Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink arbitrary close

cottrelld
thaytan helped me understand #1 more (thanks!).

I now put a blocking probe on the src pad of the tee, and send the EOS on the sink pad of my queue.  splitmuxsink closes out the video file correctly.  It's still blocking everything in the app though, and he says it's because the tee is singlethreaded and blocked.  Thus i need to solve #2.

For #2 he suggests making a custom bin wrapping the tee channel contents, ghosting the pad so it can be linked to the tee, and overriding the handle_message vfunc to capture the EOS.  I'm going to take a crack at that...  If there's a different way it'd be awesome since this seems to be a common thing to need to do, but going to give it a shot.  

-David
Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink arbitrary close

ToanVnET
Hi, Can you share the way which you close splimuxsink element in code for me
?

I'm finding it for 5 days and my brain is going out.





--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel