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 <david at elarm.com>:

> 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] <http:///user/SendEmail.jtp?type=node&node=4672822&i=0>> 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:///user/SendEmail.jtp?type=node&node=4672809&i=0>
>> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> >
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=4672809&i=1>
>> 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
>> <http://gstreamer-devel.966125.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> ------------------------------
> View this message in context: Re: splitmuxsink arbitrary close
> <http://gstreamer-devel.966125.n4.nabble.com/splitmuxsink-arbitrary-close-tp4672799p4672822.html>
> Sent from the GStreamer-devel mailing list archive
> <http://gstreamer-devel.966125.n4.nabble.com/> at Nabble.com.
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150724/bae20783/attachment.html>