[gst-devel] Not at all related to 0.11 [Was: The 1.0 plan]

[Tiago Katcipis]

On Thu, Nov 18, 2010 at 3:40 PM, Tiago Katcipis <katcipis at inf.ufsc.br>wrote:

>
>
> 2010/11/18 Sebastian Dröge <sebastian.droege at collabora.co.uk>
>
>> On Thu, 2010-11-18 at 13:00 -0200, Tiago Katcipis wrote:
>>
>> >
>> >
>> >         That's all possible but the problem with that is, that a) the
>> >         state
>> >         change from NULL->READY happens synchronous in GStreamer and
>> >         that b)
>> >         basesrc wants to know the file size in READY already,
>> >         otherwise it will
>> >         never activate random access mode.
>> >
>> >
>> > Well if it must be synchronous running the main loop on another Thread
>> > does not to seem to be an option. What is done on gst_bus_poll seems
>> > to fit here:
>> >
>> > 1 - the caller on the set_state will get blocked on the call
>> > 2 - inside the call we mount the file and do all the stuff async using
>> > the main_loop_run to block the caller
>> > 3 - after everything is done we get out of the run call and give to
>> > the basesrc the file size
>> >
>> > this way we can use the async GIO API, mount the file for the user
>> > giving a "sync" operation to the set_state caller. But this approach
>> > is pretty simple, if you guys still not implemented it... it is
>> > because it has something pretty bad on it... it is because the same
>> > problem that can happen on gst_bus_poll?
>>
>> That would work in theory but the problem here is, that GStreamer does
>> not require any running GLib main loop on the main context by policy.
>>
>>
> does not require, but if we create it? the user does not need to know that
> a main loop has been created, and if the mainloop on the main context
> already exists...we use it.
>
> but i agree that it is ugly and your suggestion seems to be better...make
> the transition of states async:
> https://bugzilla.gnome.org/show_bug.cgi?id=586939
>
> so my question now is... is there any planning on doing this? because if it
> is not going to be done, even if it is not beautiful (like gst_bus_poll) it
> seems to be better to let the user "ask" the plugin to mount everything to
> him instead of having to catch a message "not-mounted" and them having to
> mount (asynchronously...a pain in the ass) and them setting the pipeline to
> play again.
>
>
>
Is anything going to be done about this on gstreamer 0.11/1.0 ?
like async changes, that would make possible to write a better giosrc
plugin.

Here at my job we work a lot with network sources, on the past we used
gnomevfssrc and now we are using giosrc, but its usage is ugly (gnomevfssrc
is deprecated but was more easy to use),

I'm really interested on helping to make it better, but there is no use on
writing a solution that wont be accepted on gstreamer.

another problem related to async state changes is setting a pipeline that is
using giosrc with a network source (tested with ssh) to NULL when the
connection is down, the sync call to set_state to NULL blocks the
application...for a long long time.

eg:
- im playing ssh://myfile
- ops, connection is down...stopped playback
- i call set_state(NULL) - (if i call a seek i will block too)
- i got blocked for a long long time (this made our server to freeze
completely)

it seems that having async set_state calls would be a good idea when working
with network sources. There is no good way to now if everything is fine
before calling a set_state that can block for a long time (there is no
feedback about the status of the connection).

i would like to help making giosrc better, but on the 0.11/1.0 plan i didn't
see anything about it.

sorry for the bad english.

best regards,
Katcipis


>
> best regards,
> Katcipis
>
>
>>
>> ------------------------------------------------------------------------------
>>
>> Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>> Spend less time writing and  rewriting code and more time creating great
>> experiences on the web. Be a part of the beta today
>> http://p.sf.net/sfu/msIE9-sfdev2dev
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>>
>
>
> --
> http://www.getgnulinux.org/windows
>



-- 
http://www.getgnulinux.org/windows
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101123/bb84bdb8/attachment.htm>