Making mmssrc asynchronous

[Johan Thelin]

Hello all,

I'm facing an issue with the non-asynchronous mmssrc and need to
resolve it (at least for the connection phase). My basic plan is to:

1. Split the connection phase of libmms into two parts -
attempt_connect and is_connected, where the first initialises the
connection attempt and the second can be polled to monitor the state
of the socket. There must also be a way to cancel a connection attempt
here, to allow for changing the URL during a connection attempt.

2. Update mmsrc to this. Basically, manage state transitions manually,
responding ASYNC to the READY_TO_PAUSED transition and then start a
polling timer that waits for is_connected to return true.

Does this seem like a good way to go about this? What is the "correct"
way to handle polling in a gstreamer source? etc. Any input is most
welcome.

Best regards,

--
Johan Thelin M.Sc.E.E.
Senior Software Developer

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: [phone]
Skype: jothpelagicore
E-Mail: [hidden email]
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Wim Taymans]

On 04/04/2011 11:19 AM, Johan Thelin wrote:

> Hello all,
>
> I'm facing an issue with the non-asynchronous mmssrc and need to
> resolve it (at least for the connection phase). My basic plan is to:
>
> 1. Split the connection phase of libmms into two parts -
> attempt_connect and is_connected, where the first initialises the
> connection attempt and the second can be polled to monitor the state
> of the socket. There must also be a way to cancel a connection attempt
> here, to allow for changing the URL during a connection attempt.
>
> 2. Update mmsrc to this. Basically, manage state transitions manually,
> responding ASYNC to the READY_TO_PAUSED transition and then start a
> polling timer that waits for is_connected to return true.

ASYNC state changes are only for sinks so you can't use them for
this purpose. It's also totally not needed to return ASYNC.

You might want to take a look at how the async connections are done
in rtspsrc here:
http://cgit.freedesktop.org/~wtay/gst-plugins-good/log/?h=progress

It uses the progress messages to inform the app of the async progress.
Also check out the design docs for the progress messages.

Wim

> Does this seem like a good way to go about this? What is the "correct"
> way to handle polling in a gstreamer source? etc. Any input is most
> welcome.
>
> Best regards,
>

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

[Johan Thelin]

On 4 April 2011 11:23, Wim Taymans <[hidden email]> wrote:

> On 04/04/2011 11:19 AM, Johan Thelin wrote:
>> I'm facing an issue with the non-asynchronous mmssrc and need to
>> resolve it (at least for the connection phase). My basic plan is to:
>>
>> [...]
>
> You might want to take a look at how the async connections are done
> in rtspsrc here:
> http://cgit.freedesktop.org/~wtay/gst-plugins-good/log/?h=progress
>
> It uses the progress messages to inform the app of the async progress.
> Also check out the design docs for the progress messages.

Great input! Thanks. Solving the issue that way looks like a complete
rewrite of the source to me. What I have done in the code attached, is
that I have put the initial mmsx_connect call in a GstTask. This
prevents the mmssrc from locking up the event loop for a long time at
this point (which was my major issue for the moment).

However, there are two issues:

I do not read the data using a GstTask, so I suppose a server dropping
of the radar while listening to it would probably still lock the
application.

In the finalize method, I have a situation where I might have a live
GstTask (which is blocking on a socket). Trying to do a gst_task_join
will freeze the application here, so that is not an option. For the
moment, I simply do nothing - which I suspect is a leak.

Best regards,

--
Johan Thelin M.Sc.E.E.
Senior Software Developer

Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: [phone]
Skype: jothpelagicore
E-Mail: [hidden email]

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