Save an MPEG2 compressed file from live stream

[Sérgio Agostinho]

>From the information provided here
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPad.html#gst-pad-send-event
I can only conclude that something else is holding the lock off that pad.
Maybe someone more experienced can provide hints on the usual things that
normally acquire locks on pads.

On exit, call gtk_main_quit() then add a callback on the filesink sink pad:

Once again, I don't think you should be invoking gtk_main_quit()  while
you're still doing things in your pipeline.

gst_pad_add_probe (pad, GST_PAD_PROBE_TYPE_BLOCK|GST_PAD_PROBE_TYPE_EVENT_
> DOWNSTREAM, (GstPadProbeCallback) cb_pad_event, data, NULL);

EOS is a serialized event that travels with data. If you're blocking the
filesink sink pad, I find it very strange you're receiving even receiving
the EOS.

  return GST_PAD_PROBE_DROP;

You're dropping the pad regardless of whether or not the event is an EOS.
You're basically dropping the pad as soon as you receive a buffer or any
event.

data->mux_pad = pad;

Should you not be incrementing the reference counter for this?

2015-01-05 16:06 GMT+01:00 Paul Barber <paul.barber at oncology.ox.ac.uk>:

> Happy New Year to all (this thread is continued since before Christmas)
>
> Sérgio Agostinho wrote:
> >From what you describe the EOS callback is returning. It is locking
> somewhere else.
>
> After another look and tidy up I see the call that locks is
> gst_pad_send_event()
> It also locks if I try to send the event from another pad elsewhere in the
> pipeline.
> The debug output looks like a loop of repeated EOS events:
> 0:00:06.529580866 22492       0x6f78f0 DEBUG              GST_EVENT
> gstevent.c:300:gst_event_new_custom: creating new event 0xc75a40 eos 28174
> 0:00:06.529586525 22492       0x6f78f0 DEBUG               GST_PADS
> gstpad.c:4550:store_sticky_event:<mpegpsmux0:src> pad is EOS
> 0:00:06.529591227 22492       0x6f78f0 DEBUG               GST_PADS
> gstpad.c:4845:gst_pad_push_event:<mpegpsmux0:src> We're EOS
> 0:00:06.529595976 22492       0x6f78f0 DEBUG              mpegpsmux
> mpegpsmux.c:512:mpegpsmux_collected:<mpegpsmux0> Pads collected
> 0:00:06.529600104 22492       0x6f78f0 DEBUG             GST_MEMORY
> gstmemory.c:138:gst_memory_init: new memory 0xa2d430, maxsize:4 offset:0
> size:4
> 0:00:06.529605836 22492       0x6f78f0 DEBUG             GST_MEMORY
> gstmemory.c:88:_gst_memory_free: free memory 0xa2d430
> These 6 lines are repeated again and again ...
>
> I tried gst_element_send_event() instead, this does not lock, and the EOS
> is received, but this does not solve the original problem of some bad files
> being created by filesink.
>
> RECAP:
> I have a GTK window with g_signal_connect for "key_press_event" to end
> the program when Esc is pressed.
> The mux sink pad is a request pad so I add a callback for pad-added on
> the mux before the pipeline is linked up:
> g_signal_connect (data->mux, "pad-added", G_CALLBACK (cb_new_mux_pad),
> data);
>
> In this callback, keep a pointer to mux sink pad for later:
> static void cb_new_mux_pad (GstElement *element, GstPad *pad, GstAppData
> *data)
> {
>      data->mux_pad = pad;
> }
>
> Set pipeline to play and then run gtk_main()
>
> On exit, call gtk_main_quit() then add a callback on the filesink sink pad:
> pad = gst_element_get_static_pad (data->filesink, "sink");
> gst_pad_add_probe (pad,
> GST_PAD_PROBE_TYPE_BLOCK|GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM,
> (GstPadProbeCallback) cb_pad_event, data, NULL);
> gst_object_unref (pad);
>
> Send an EOS into the mux sink pad we already have a reference to:
> gst_pad_send_event (data->mux_pad, gst_event_new_eos ());
>
> In the probe pad callback, just set some flag (data->EOS) that we can
> check for it later:
> static GstPadProbeReturn cb_pad_event (GstPad *pad, GstPadProbeInfo
> *info, GstAppData *data)
> {
>    GstEvent *event;
>    event = GST_PAD_PROBE_INFO_EVENT(info);
>    if (event->type == GST_EVENT_EOS){
>        data->EOS = TRUE;
>    }
>    return GST_PAD_PROBE_DROP;
> }
> _______________________________________________
> 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/20150107/afc380d6/attachment.html>