Trouble with giostreamsrc

[W. Michael Petullo]

I am trying to move an application from giosrc to giostreamsrc.  
However, I have not been able to get my giostreamsrc pipeline to  
work. Everything worked fine when I was using giosrc with a URI.

When I run the application with the GST_DEBUG environment variable  
set, I see the error "No stream given yet." This happens as the  
application tries to change the pipeline's state to playing.

The strange thing is that I added a check right before the state  
change that reads the stream property from the giostreamsrc element  
using g_object_get and confirms that it is a G_IS_INPUT_STREAM. The  
check does not complain. However, something sets the stream back to  
NULL after I call gst_element_set_state (see "FIRST CHECK" and  
"SECOND CHECK" below).

I've run my application through valgrind and did not see any memory  
issues, though I have not yet ruled that out entirely.

I am using gstreamer-plugins-base 0.10.22.

My code follows:

GInputStream* g_gst_mp3_input_stream_new (GInputStream *src_stream)
{
         GstStateChangeReturn sret;
         GstState state;
         GGstMP3InputStream *stream;

         stream = G_GST_MP3_INPUT_STREAM (g_object_new  
(TYPE_G_GST_MP3_INPUT_STREAM,
                                                    NULL));

         stream->priv->pipeline = gst_pipeline_new ("pipeline");

         stream->priv->src     = gst_element_factory_make  
("giostreamsrc", "src");
         stream->priv->decode  = gst_element_factory_make  
("decodebin", "decode");
         stream->priv->convert = gst_element_factory_make  
("audioconvert", "convert");
         stream->priv->encode  = gst_element_factory_make ("lame",  
"encode");
         stream->priv->sink    = gst_element_factory_make ("appsink",  
"sink");

         gst_bin_add_many (GST_BIN (stream->priv->pipeline),
                           stream->priv->src,
                           stream->priv->decode,
                           stream->priv->convert,
                           stream->priv->encode,
                           stream->priv->sink,
                           NULL);

         if (gst_element_link (stream->priv->src, stream->priv-
 >decode) == FALSE) {
                 g_warning ("Error linking source and decode elements");
         }

         g_assert (G_IS_INPUT_STREAM (src_stream));
         g_object_set (G_OBJECT (stream->priv->src), "stream",  
src_stream, NULL);

         /* quality=9 is important for fast, realtime transcoding: */
         g_object_set (G_OBJECT (stream->priv->encode), "quality", 9,  
NULL);
         g_object_set (G_OBJECT (stream->priv->encode), "bitrate",  
128, NULL);
         g_object_set (G_OBJECT (stream->priv->encode), "vbr", 0, NULL);
         g_signal_connect (stream->priv->decode, "new-decoded-pad",  
G_CALLBACK (new_decoded_pad_cb), stream);

         g_object_set (G_OBJECT (stream->priv->sink), "emit-signals",  
TRUE, "sync", FALSE, NULL);
         gst_app_sink_set_max_buffers (GST_APP_SINK (stream->priv-
 >sink),
                                       GST_APP_MAX_BUFFERS);
         gst_app_sink_set_drop (GST_APP_SINK (stream->priv->sink),  
FALSE);

         g_signal_connect (stream->priv->sink, "new-buffer",  
G_CALLBACK (g_gst_input_stream_new_buffer_cb), stream);

/* MY FIRST CHECK: NO PROBLEM: */
gpointer foo;
g_warning ("CHECK 1");
g_object_get (G_OBJECT (stream->priv->src), "stream",  &foo, NULL);
g_assert (G_IS_INPUT_STREAM (foo));
g_assert (src_stream == foo);

         sret = gst_element_set_state (stream->priv->pipeline,  
GST_STATE_PLAYING);
         if (GST_STATE_CHANGE_ASYNC == sret) {
                 if (GST_STATE_CHANGE_SUCCESS !=  
gst_element_get_state (GST_ELEMENT (stream->priv->pipeline), &state,  
NULL, 5 * GST_SECOND)) {
                         g_warning ("State change failed for stream.");
                 }
         } else if (sret != GST_STATE_CHANGE_SUCCESS) {
                 g_warning ("Could not read stream.");
         }

/* MY SECOND CHECK: FAILS, FOO == NULL! */
g_warning ("CHECK 2");
g_object_get (G_OBJECT (stream->priv->src), "stream",  &foo, NULL);
g_warning ("NULL == foo %d", NULL == foo);
g_assert (G_IS_INPUT_STREAM (src_stream));
g_assert (G_IS_INPUT_STREAM (foo));
g_assert (src_stream == foo);

         g_assert (G_IS_SEEKABLE (stream));
         return G_INPUT_STREAM (stream);
}

Mike

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

Am Sonntag, den 05.07.2009, 23:49 -0400 schrieb W. Michael Petullo:

> I am trying to move an application from giosrc to giostreamsrc.  
> However, I have not been able to get my giostreamsrc pipeline to  
> work. Everything worked fine when I was using giosrc with a URI.
>
> When I run the application with the GST_DEBUG environment variable  
> set, I see the error "No stream given yet." This happens as the  
> application tries to change the pipeline's state to playing.
>
> The strange thing is that I added a check right before the state  
> change that reads the stream property from the giostreamsrc element  
> using g_object_get and confirms that it is a G_IS_INPUT_STREAM. The  
> check does not complain. However, something sets the stream back to  
> NULL after I call gst_element_set_state (see "FIRST CHECK" and  
> "SECOND CHECK" below).
>
> I've run my application through valgrind and did not see any memory  
> issues, though I have not yet ruled that out entirely.
>
> I am using gstreamer-plugins-base 0.10.22.

Could you file a bug for this at http://bugzila.gnome.org and assign me
to it? I know what the problem is and will work on that soonish :)

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[W. Michael Petullo]

>> I am trying to move an application from giosrc to giostreamsrc.
>> However, I have not been able to get my giostreamsrc pipeline to
>> work. Everything worked fine when I was using giosrc with a URI.
>>
>> When I run the application with the GST_DEBUG environment variable
>> set, I see the error "No stream given yet." This happens as the
>> application tries to change the pipeline's state to playing.
>>
>> The strange thing is that I added a check right before the state
>> change that reads the stream property from the giostreamsrc element
>> using g_object_get and confirms that it is a G_IS_INPUT_STREAM. The
>> check does not complain. However, something sets the stream back to
>> NULL after I call gst_element_set_state (see "FIRST CHECK" and
>> "SECOND CHECK" below).
>>
>> I've run my application through valgrind and did not see any memory
>> issues, though I have not yet ruled that out entirely.
>>
>> I am using gstreamer-plugins-base 0.10.22.
>
> Could you file a bug for this at http://bugzila.gnome.org and  
> assign me
> to it? I know what the problem is and will work on that soonish :)

Oh, good -- I thought I was losing my mind!

I created the bug, but could not assign it to you.

See:

http://bugzilla.gnome.org/show_bug.cgi?id=587896

Mike

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[W. Michael Petullo]

>>> I am trying to move an application from giosrc to giostreamsrc.
>>> However, I have not been able to get my giostreamsrc pipeline to
>>> work. Everything worked fine when I was using giosrc with a URI.
>>>
>>> When I run the application with the GST_DEBUG environment variable
>>> set, I see the error "No stream given yet." This happens as the
>>> application tries to change the pipeline's state to playing.
>>>
>>> The strange thing is that I added a check right before the state
>>> change that reads the stream property from the giostreamsrc element
>>> using g_object_get and confirms that it is a G_IS_INPUT_STREAM. The
>>> check does not complain. However, something sets the stream back to
>>> NULL after I call gst_element_set_state (see "FIRST CHECK" and
>>> "SECOND CHECK" below).
>>>
>>> I've run my application through valgrind and did not see any memory
>>> issues, though I have not yet ruled that out entirely.
>>>
>>> I am using gstreamer-plugins-base 0.10.22.

>> Could you file a bug for this at http://bugzila.gnome.org and
>> assign me
>> to it? I know what the problem is and will work on that soonish :)

[...]

> http://bugzilla.gnome.org/show_bug.cgi?id=587896

I'm coming back to the mailing list because Sebastian fixed several  
issues in the giostream element. I'm not sure this would be considered  
the same bug, but I am still having trouble. If appropriate, I will  
reopen bug #587896.

I've attached a simplified program that operates similarly to how my  
application does. The only big difference is that I don't provide a  
"new-buffer" callback to appsink (whereas my application does).  
Despite this, the test program seems to exhibit the same behavior as  
my application:

./a.out short.mp3, a very short MP3 (2-3 seconds):
Seems to work. Prints "done."

./a.out typical.mp3, an MP3 of typical length:
Seemingly endless:
[...]
0:00:27.070157260 18595  0x82e04c0 INFO              GST_PADS gstpad.c:
1805:gst_pad_link_prepare: trying to link id3demux197:src and  
id3demux198:sink
0:00:27.070805108 18595  0x82e04c0 INFO              GST_PADS gstpad.c:
1942:gst_pad_link: linked id3demux197:src and id3demux198:sink,  
successful
0:00:27.071398759 18595  0x82e04c0 INFO      GST_ELEMENT_PADS  
gstelement.c:882:gst_element_get_static_pad: no such pad 'src' in  
element "id3demux198"
0:00:27.158970528 18595  0x82e04c0 INFO     typefindfunctions  
gsttypefindfunctions.c:906:mp3_type_find_at_offset: audio/mpeg  
calculated 86  =  100  *  5 / 5  *  (10000 - 1325) / 10000
0:00:27.236719538 18595  0x82e04c0 INFO               default  
gsttypefindhelper.c:186:helper_find_peek: typefind function returned:  
unexpected
0:00:27.288706606 18595  0x82e04c0 INFO      GST_ELEMENT_PADS  
gstelement.c:639:gst_element_add_pad:<id3demux198> adding pad 'src'
0:00:27.290270213 18595  0x82e04c0 INFO   GST_ELEMENT_FACTORY  
gstelementfactory.c:399:gst_element_factory_create: creating element  
"id3demux"
0:00:27.291146023 18595  0x82e04c0 INFO      GST_ELEMENT_PADS  
gstelement.c:639:gst_element_add_pad:<GstTagDemux@0x840d4f8> adding  
pad 'sink'
0:00:27.291785211 18595  0x82e04c0 INFO      GST_ELEMENT_PADS  
gstelement.c:885:gst_element_get_static_pad: found pad id3demux199:sink
0:00:27.292784500 18595  0x82e04c0 INFO            GST_STATES  
gstelement.c:2150:gst_element_continue_state:<id3demux199> completed  
state change to READY
0:00:27.293315853 18595  0x82e04c0 INFO            GST_STATES  
gstelement.c:2163:gst_element_continue_state:<id3demux199> posting  
state-changed NULL to READY
[...]

./a.out foo.ogg, a typical OGG Vorbis file:
[...]
0:00:00.485567715 18590  0x8b9d768 WARN              oggdemux  
gstoggdemux.c:2377:gst_ogg_demux_read_chain:<oggdemux0> page is not  
BOS page
0:00:00.492683705 18590  0x8b9d768 WARN              oggdemux  
gstoggdemux.c:2399:gst_ogg_demux_read_chain:<oggdemux0> no chain was  
found
0:00:00.493087387 18590  0x8b9d768 WARN              oggdemux  
gstoggdemux.c:2758:gst_ogg_demux_find_chains:<oggdemux0> error: can't  
get first chain
0:00:00.493919616 18590  0x8b9d768 INFO      GST_ERROR_SYSTEM  
gstelement.c:1675:gst_element_message_full:<oggdemux0> posting  
message: Could not demultiplex stream.
0:00:00.494615236 18590  0x8b9d768 INFO      GST_ERROR_SYSTEM  
gstelement.c:1698:gst_element_message_full:<oggdemux0> posted error  
message: Could not demultiplex stream.
0:00:00.495798068 18590  0x8b9d768 WARN              oggdemux  
gstoggdemux.c:3151:gst_ogg_demux_loop:<oggdemux0> error: Internal data  
stream error.
0:00:00.496323554 18590  0x8b9d768 WARN              oggdemux  
gstoggdemux.c:3151:gst_ogg_demux_loop:<oggdemux0> error: stream  
stopped, reason error
0:00:00.496935084 18590  0x8b9d768 INFO      GST_ERROR_SYSTEM  
gstelement.c:1675:gst_element_message_full:<oggdemux0> posting  
message: Internal data stream error.
0:00:00.497469789 18590  0x8b9d768 INFO      GST_ERROR_SYSTEM  
gstelement.c:1698:gst_element_message_full:<oggdemux0> posted error  
message: Internal data stream error.
0:00:00.498426615 18590  0x8ac94c0 INFO            GST_STATES gstbin.c:
2355:gst_bin_change_state_func:<pipeline> child 'src' changed state to  
3(PAUSED) successfully
0:00:00.499175593 18590  0x8ac94c0 INFO            GST_STATES gstbin.c:
1659:gst_bin_get_state_func:<pipeline> getting state
0:00:00.499767568 18590  0x8ac94c0 INFO            GST_STATES  
gstelement.c:1898:gst_element_get_state_func:<pipeline> waiting for  
element to commit state
0:00:05.499873727 18590  0x8ac94c0 INFO            GST_STATES  
gstelement.c:1902:gst_element_get_state_func:<pipeline> timed out

** (a.out:18590): WARNING **: State change failed for stream.

** (a.out:18590): WARNING **: done


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[W. Michael Petullo]

I forgot to add the attachment to the previous message.

Mike


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

Am Mittwoch, den 08.07.2009, 18:59 -0700 schrieb W. Michael Petullo:

> >>> I am trying to move an application from giosrc to giostreamsrc.
> >>> However, I have not been able to get my giostreamsrc pipeline to
> >>> work. Everything worked fine when I was using giosrc with a URI.
> >>>
> >>> When I run the application with the GST_DEBUG environment variable
> >>> set, I see the error "No stream given yet." This happens as the
> >>> application tries to change the pipeline's state to playing.
> >>>
> >>> The strange thing is that I added a check right before the state
> >>> change that reads the stream property from the giostreamsrc element
> >>> using g_object_get and confirms that it is a G_IS_INPUT_STREAM. The
> >>> check does not complain. However, something sets the stream back to
> >>> NULL after I call gst_element_set_state (see "FIRST CHECK" and
> >>> "SECOND CHECK" below).
> >>>
> >>> I've run my application through valgrind and did not see any memory
> >>> issues, though I have not yet ruled that out entirely.
> >>>
> >>> I am using gstreamer-plugins-base 0.10.22.
>
> >> Could you file a bug for this at http://bugzila.gnome.org and
> >> assign me
> >> to it? I know what the problem is and will work on that soonish :)
>
> [...]
>
> > http://bugzilla.gnome.org/show_bug.cgi?id=587896
>
> I'm coming back to the mailing list because Sebastian fixed several  
> issues in the giostream element. I'm not sure this would be considered  
> the same bug, but I am still having trouble. If appropriate, I will  
> reopen bug #587896.
>
> I've attached a simplified program that operates similarly to how my  
> application does. The only big difference is that I don't provide a  
> "new-buffer" callback to appsink (whereas my application does).  
> Despite this, the test program seems to exhibit the same behavior as  
> my application:

That's a different bug, not sure where :) For some reason decodebin
tries to link a million id3demux elements...

Could you file a bug for this?

Also, in your sample code you should really a) run a main loop after the
state change and b) have a bus watch that handles bus messages...

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

Am Donnerstag, den 09.07.2009, 13:36 +0200 schrieb Sebastian Dröge:

> Am Mittwoch, den 08.07.2009, 18:59 -0700 schrieb W. Michael Petullo:
> > >>> I am trying to move an application from giosrc to giostreamsrc.
> > >>> However, I have not been able to get my giostreamsrc pipeline to
> > >>> work. Everything worked fine when I was using giosrc with a URI.
> > >>>
> > >>> When I run the application with the GST_DEBUG environment variable
> > >>> set, I see the error "No stream given yet." This happens as the
> > >>> application tries to change the pipeline's state to playing.
> > >>>
> > >>> The strange thing is that I added a check right before the state
> > >>> change that reads the stream property from the giostreamsrc element
> > >>> using g_object_get and confirms that it is a G_IS_INPUT_STREAM. The
> > >>> check does not complain. However, something sets the stream back to
> > >>> NULL after I call gst_element_set_state (see "FIRST CHECK" and
> > >>> "SECOND CHECK" below).
> > >>>
> > >>> I've run my application through valgrind and did not see any memory
> > >>> issues, though I have not yet ruled that out entirely.
> > >>>
> > >>> I am using gstreamer-plugins-base 0.10.22.
> >
> > >> Could you file a bug for this at http://bugzila.gnome.org and
> > >> assign me
> > >> to it? I know what the problem is and will work on that soonish :)
> >
> > [...]
> >
> > > http://bugzilla.gnome.org/show_bug.cgi?id=587896
> >
> > I'm coming back to the mailing list because Sebastian fixed several  
> > issues in the giostream element. I'm not sure this would be considered  
> > the same bug, but I am still having trouble. If appropriate, I will  
> > reopen bug #587896.
> >
> > I've attached a simplified program that operates similarly to how my  
> > application does. The only big difference is that I don't provide a  
> > "new-buffer" callback to appsink (whereas my application does).  
> > Despite this, the test program seems to exhibit the same behavior as  
> > my application:
>
> That's a different bug, not sure where :) For some reason decodebin
> tries to link a million id3demux elements...
>
> Could you file a bug for this?

...if it doesn't work after this change:

commit b9c79380aa07e3cf2c00a190bbbcb0b0c252df96
Author: Sebastian Dröge <[hidden email]>
Date:   Thu Jul 9 13:45:13 2009 +0200

    gio: Make sure that we have the correct stream position when
starting

Note that your application blocks forever after the pipeline has
finished because of no bus usage, etc :)

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[W. Michael Petullo]

>> That's a different bug, not sure where :) For some reason decodebin
>> tries to link a million id3demux elements...
>>
>> Could you file a bug for this?
>
> ...if it doesn't work after this change:
>
> commit b9c79380aa07e3cf2c00a190bbbcb0b0c252df96
> Author: Sebastian Dröge <[hidden email]>
> Date:   Thu Jul 9 13:45:13 2009 +0200
>
>    gio: Make sure that we have the correct stream position when
> starting
>
> Note that your application blocks forever after the pipeline has
> finished because of no bus usage, etc :)

The above change fixed all of my problems. I misread your note above,  
so I filed bug. I thought you wanted one filed for the purpose of the  
release notes (generally Bugzilla is cited in the change log). The  
following bug exists for Sebastian's review and should be closed after  
you read it:

https://bugzilla.gnome.org/show_bug.cgi?id=588205

Thanks!

Mike
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

Am Donnerstag, den 09.07.2009, 16:46 -0700 schrieb W. Michael Petullo:

> >> That's a different bug, not sure where :) For some reason decodebin
> >> tries to link a million id3demux elements...
> >>
> >> Could you file a bug for this?
> >
> > ...if it doesn't work after this change:
> >
> > commit b9c79380aa07e3cf2c00a190bbbcb0b0c252df96
> > Author: Sebastian Dröge <[hidden email]>
> > Date:   Thu Jul 9 13:45:13 2009 +0200
> >
> >    gio: Make sure that we have the correct stream position when
> > starting
> >
> > Note that your application blocks forever after the pipeline has
> > finished because of no bus usage, etc :)
>
> The above change fixed all of my problems. I misread your note above,  
> so I filed bug. I thought you wanted one filed for the purpose of the  
> release notes (generally Bugzilla is cited in the change log). The  
> following bug exists for Sebastian's review and should be closed after  
> you read it:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=588205

That's nice to hear :)

Why exactly are you using the giostreamsrc and a custom GInputStream
btw?

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[W. Michael Petullo]

>>>> That's a different bug, not sure where :) For some reason decodebin
>>>> tries to link a million id3demux elements...
>>>>
>>>> Could you file a bug for this?
>>>
>>> ...if it doesn't work after this change:
>>>
>>> commit b9c79380aa07e3cf2c00a190bbbcb0b0c252df96
>>> Author: Sebastian Dröge <[hidden email]>
>>> Date:   Thu Jul 9 13:45:13 2009 +0200
>>>
>>>    gio: Make sure that we have the correct stream position when
>>> starting
>>>
>>> Note that your application blocks forever after the pipeline has
>>> finished because of no bus usage, etc :)
>>
>> The above change fixed all of my problems. I misread your note above,
>> so I filed bug. I thought you wanted one filed for the purpose of the
>> release notes (generally Bugzilla is cited in the change log). The
>> following bug exists for Sebastian's review and should be closed after
>> you read it:
>>
>> https://bugzilla.gnome.org/show_bug.cgi?id=588205
>
> That's nice to hear :)
>
> Why exactly are you using the giostreamsrc and a custom GInputStream
> btw?

I just refactored my media server (dmapd / libdmapsharing) and found that
using giostreamsrc instead of giosrc was more convenient. This allows my
media database to provide a GInputStream that libdmapsharing can then
either send directly with libsoup or inject a transcoding pipeline before
sending. In my case, moving the transcoding process from the media
database (that has no itea of what type of client is connecting) to
libdmapsharing (which does) is very beneficial.

Mike


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel