Flow of PAUSE request from gstreamer to upper QT application.
sathish
sathish1000 at gmail.com
Mon Dec 2 02:36:06 PST 2013
Thanks Sebastian for the reply,
I will raise the issue with phonon developers..
I have a few questions/doubts regarding your reply..
"However when shortly looking at the code I don't see it handling the
request-state message at all. This would need to be implemented. As
Phonon is a very high-level abstraction of a media playback API, I would
expect it to handle that internally without the application having to
worry about that"
>From the above statement, do you mean that GSTREAMER is processing the
request and sending it PHONON but PHONON is not handling it ??..
Or do you mean that PHONON should take full responsibilty and handle it. I
see this scenario less because when I used gst launch instead of QT, I was
able to CORK/PAUSE a player..
My second question is this..
The lines of interest are pasted below
> gst_element_post_message (GST_ELEMENT_CAST (psink),
> gst_message_new_request_state (GST_OBJECT_CAST (psink),
> GST_STATE_PAUSED));
I went through the gstreamer documetation to find what does
"gst_message_new_request_state ()" do ??
I got this reply.. "This message can be posted by elements when they want
to have their state changed. A typical use case would be an audio server
that wants to pause the pipeline because a higher priority stream is being
played."
But what does it exactly post on the bus.. Does it post the state
"GST_STATE_PAUSED" on the bus that needs handling ??
Thanks,
Sathish
On 2 December 2013 13:42, Sebastian Dröge-3 [via GStreamer-devel] <
ml-node+s966125n4663763h98 at n4.nabble.com> wrote:
> On Sa, 2013-11-30 at 03:16 -0800, sathish wrote:
>
> > Hi,
> >
> > I have a request to CORK/PAUSE from Pulseaudio. This initiates the
> function
> > "gst_pulsering_stream_event_cb" in program pulsesink.c. I have pasted
> the
> > function below..
> >
> > static void
> > gst_pulsering_stream_event_cb (pa_stream * p, const char *name,
> > pa_proplist * pl, void *userdata)
> > {
> > GstPulseSink *psink;
> > GstPulseRingBuffer *pbuf;
> >
> > pbuf = GST_PULSERING_BUFFER_CAST (userdata);
> > psink = GST_PULSESINK_CAST (GST_OBJECT_PARENT (pbuf));
> >
> > * if (!strcmp (name, PA_STREAM_EVENT_REQUEST_CORK)) {
> > /* the stream wants to PAUSE, post a message for the application. */
> > GST_DEBUG_OBJECT (psink, "got request for CORK");
> > gst_element_post_message (GST_ELEMENT_CAST (psink),
> > gst_message_new_request_state (GST_OBJECT_CAST (psink),
> > GST_STATE_PAUSED));
> > *
> > } else if (!strcmp (name, PA_STREAM_EVENT_REQUEST_UNCORK)) {
> > GST_DEBUG_OBJECT (psink, "got request for UNCORK");
> > gst_element_post_message (GST_ELEMENT_CAST (psink),
> > gst_message_new_request_state (GST_OBJECT_CAST (psink),
> > GST_STATE_PLAYING));
> > } else if (!strcmp (name, PA_STREAM_EVENT_FORMAT_LOST)) {
> > GstEvent *renego;
> >
> > if (g_atomic_int_get (&psink->format_lost)) {
> > /* Duplicate event before we're done reconfiguring, discard */
> > return;
> > }
> >
> > GST_DEBUG_OBJECT (psink, "got FORMAT LOST");
> > g_atomic_int_set (&psink->format_lost, 1);
> > psink->format_lost_time = g_ascii_strtoull (pa_proplist_gets (pl,
> > "stream-time"), NULL, 0) * 1000;
> >
> > g_free (psink->device);
> > psink->device = g_strdup (pa_proplist_gets (pl, "device"));
> >
> > /* FIXME: send reconfigure event instead and let decodebin/playbin
> > * handle that. Also take care of ac3 alignment */
> > renego = gst_event_new_custom (GST_EVENT_CUSTOM_UPSTREAM,
> > gst_structure_new_empty ("pulse-format-lost"));
> >
> > #if 0
> > if (g_str_equal (gst_structure_get_name (st), "audio/x-eac3")) {
> > GstStructure *event_st = gst_structure_new
> ("ac3parse-set-alignment",
> > "alignment", G_TYPE_STRING, pbin->dbin ? "frame" : "iec61937",
> > NULL);
> >
> > if (!gst_pad_push_event (pbin->sinkpad,
> > gst_event_new_custom (GST_EVENT_CUSTOM_UPSTREAM,
> event_st)))
> > GST_WARNING_OBJECT (pbin->sinkpad, "Could not update
> alignment");
> > }
> > #endif
> >
> > if (!gst_pad_push_event (GST_BASE_SINK (psink)->sinkpad, renego)) {
> > /* Nobody handled the format change - emit an error */
> > GST_ELEMENT_ERROR (psink, STREAM, FORMAT, ("Sink format changed"),
> > ("Sink format changed"));
> > }
> > } else {
> > GST_DEBUG_OBJECT (psink, "got unknown event %s", name);
> > }
> > }
> >
> >
> > This request (highlited part) needs to communicated to my upper level QT
> > application.
> >
> > QT communicates with GSTREAMER through "PHONON - GSTREAMER BACKEND"..
> >
> > I am exactly not sure how the message posted in the function
> > "gst_pulsering_stream_event_cb" in program pulsesink.c reaches the
> > phonon-gstreamer backend and proceeds then on.
> >
> > In short, how to find which function catches the bus message.
> >
> > I had tried to look at PHONON source code.. I could deduce to this
> position
> > only..
> >
> > I feel that function "MediaObject::handleBusMessage(const Message
> &message)"
> > is called. Can anybody tell whether this correct or a way to validate
> how
> > this can be verified ??
> This is probably not the best place to ask about issues with Phonon and
> its GStreamer backend, you probably better ask the developers of that.
>
> However when shortly looking at the code I don't see it handling the
> request-state message at all. This would need to be implemented. As
> Phonon is a very high-level abstraction of a media playback API, I would
> expect it to handle that internally without the application having to
> worry about that.
>
> --
> Sebastian Dröge <[hidden email]<http://user/SendEmail.jtp?type=node&node=4663763&i=0>>
>
> Centricular Ltd - http://www.centricular.com
> Expertise, Straight from the Source
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email] <http://user/SendEmail.jtp?type=node&node=4663763&i=1>
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> *signature.asc* (985 bytes) Download Attachment<http://gstreamer-devel.966125.n4.nabble.com/attachment/4663763/0/signature.asc>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://gstreamer-devel.966125.n4.nabble.com/Flow-of-PAUSE-request-from-gstreamer-to-upper-QT-application-tp4663723p4663763.html
> To unsubscribe from Flow of PAUSE request from gstreamer to upper QT
> application., click here<http://gstreamer-devel.966125.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4663723&code=c2F0aGlzaDEwMDBAZ21haWwuY29tfDQ2NjM3MjN8MTE0NTQ4OTIwMA==>
> .
> 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: http://gstreamer-devel.966125.n4.nabble.com/Flow-of-PAUSE-request-from-gstreamer-to-upper-QT-application-tp4663723p4663779.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131202/10033fdd/attachment.html>
More information about the gstreamer-devel
mailing list