Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
Locked
12
12
Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
 
|
Hi folks, I'm relatively new to gstreamer (couple of months) but have a reasonable level of understanding. I was initially using these versions: gstreamer-0.10.34
gst-plugins-base-0.10.34 gst-plugins-good-0.10.29 gst-plugins-bad-0.10.22 I found that seek of audio files (aac, mp3) with playbin2 did not work.
However, with a manual pipeline, seek succeeds. The problem appears to be that playbin2 does not automatically plug in the parsers (aacparse, mpegaudioparse). If my manual pipeline contains these elements, seek succeeds; without them, seek fails.
Looking on the GStreamer website http://gstreamer.freedesktop.org/news/, I saw the note in the latest 0.10 release that said: decodebin/playbin2 now plug parsers by defaultSo I decided to upgrade to the 2012-02-21 release. However, I found that playbin2 still does not autoplug the audio parsers in this release. Bummer. So, first question:
"Is there any way to encourage playbin2 to autoplug the audio parsers?" and "Is this a known issue, and is there a known workaround?" Either way: now that I've done the work to upgrade, I'd like to keep the updated components -- however, I am now seeing a bug with aacparse regarding newsegments:
# gst-launch filesrc location=/media/Honesty.aac ! id3demux ! aacparse ! custom_audio_decoder_and_sink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... 0:00:00.282161885 2561 0x812f188 WARN tagdemux gsttagdemux.c:680:gst_tag_demux_chain:<id3demux0> Downstream did not handle newsegment event as it should
0:00:00.282425516 2561 0x812f188 WARN basesrc gstbasesrc.c:2625:gst_base_src_loop:<filesrc0> error: Internal data flow error. 0:00:00.282490123 2561 0x812f188 WARN basesrc gstbasesrc.c:2625:gst_base_src_loop:<filesrc0> error: streaming task paused, reason not-linked (-1)
ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2625): gst_base_src_loop (): /GstPipeline:pipeline0/GstFileSrc:filesrc0:
streaming task paused, reason not-linked (-1) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... This exact command worked correctly (and this pipeline would seek) with the previous version (version numbers listed at the top)
Also to note: this command does still work fine: # gst-launch filesrc location=/media/Honesty.aac ! id3demux ! custom_audio_decoder_and_sink except that seek does not work without the parser element.
So, second question: "Are there any known issues with aacparse regarding newsegment handling" Thank You, Eric _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
One update: I determined that with the new version, this pipeline works: gst-launch filesrc location=/media/Honesty.aac ! aacparse ! custom_audio_decoder_and_sink i.e. no demux, but yes parser.
Is this as expected? This leaves the remaining question: Is there a way to nudge playbin2 into inserting the parser *instead* of the id3demux element? Thanks, Eric On Tue, Jun 19, 2012 at 11:30 AM, Eric Montellese <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
In reply to this post by Eric Montellese
On Tue, 2012-06-19 at 11:30 -0400, Eric Montellese wrote:
Hi Eric, haven't really loked at all details of your mail, but you should probably assume that seeking in mp3 files has worked out of the box, at least with decodebin2/playbin2 and our default decoders, in about any version of GStreamer. If that's not the case for you, it's probably because you get a different decoder plugged than most people (we used to implement the seeking for such formats in the decoders, now that task has moved to the parsers, although it should still be supported by decoders for backwards compatibility reasons.) Make sure you have the mad element (for mp3 decoding) and the faad element (for aac decoding) installed. > Looking on the GStreamer > website http://gstreamer.freedesktop.org/news/, I saw the note in the > latest 0.10 release that said: > decodebin/playbin2 now plug parsers by default > So I decided to upgrade to the 2012-02-21 release. > > However, I found that playbin2 still does not autoplug the audio > parsers in this release. Bummer. So, first question: > > "Is there any way to encourage playbin2 to autoplug the audio > parsers?" > and > "Is this a known issue, and is there a known workaround?" It should work. However, it might not work with third party decoders that assume a rank that's higher or the same as the parsers (we kind of overlooked that possibility, and none one of those third parties seem to have noticed either; it's fixed in git though, now parsers are preferred irrespective of ranks). > Either way: now that I've done the work to upgrade, I'd like to keep > the updated components -- however, I am now seeing a bug with aacparse > regarding newsegments: > > # gst-launch filesrc location=/media/Honesty.aac ! id3demux ! > aacparse ! custom_audio_decoder_and_sink > Setting pipeline to PAUSED ... > Pipeline is PREROLLING ... > 0:00:00.282161885 2561 0x812f188 WARN tagdemux > gsttagdemux.c:680:gst_tag_demux_chain:<id3demux0> Downstream did not > handle newsegment event as it should > 0:00:00.282425516 2561 0x812f188 WARN basesrc > gstbasesrc.c:2625:gst_base_src_loop:<filesrc0> error: Internal data > flow error. > 0:00:00.282490123 2561 0x812f188 WARN basesrc > gstbasesrc.c:2625:gst_base_src_loop:<filesrc0> error: streaming task > paused, reason not-linked (-1) > ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: > Internal data flow error. > Additional debug info: > gstbasesrc.c(2625): gst_base_src_loop > (): /GstPipeline:pipeline0/GstFileSrc:filesrc0: > streaming task paused, reason not-linked (-1) > ERROR: pipeline doesn't want to preroll. > > This exact command worked correctly (and this pipeline would seek) > with the previous version (version numbers listed at the top) I'm surprised this worked before, it's a somewhat weird pipeline. I would have expected it to error out if there isn't actually an ID3 tag (I'm assuming there usually isn't). Either way, the "newsegment issue" isn't a bug in aacparse, but related to id3demux not getting linked to aacparse. As the error message implies, there is an issue with elements not getting linked. In this particular case, that seems to be a bug in aacparse's get_caps() function. It appears to be fixed in git. Doesn't seem to be an issue with more normal pipelines such as filesrc ! typefind ! aacparse ! .. or filesrc ! aacparse ! .. as far as I can tell. Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
Tim, thanks for the reply. Knowing that seek was implemented in the decoders in older versions of gstreamer clears up some of my confusion.
However, when I dug into the code deeper, I found that the seek event is not being delivered to the sink at all (which in this case would be necessary since the sink and decoder are one element) -- instead the seek event is going to the pad connected to the sink's sink pad (how's that for a confusing sentence?). In other words, it is going to the source pad of the element just upstream of the sink.
Is there a reason for that (other than to save a hand-off), or could I modify the bin code to send the seek event to the sink element itself? Of course, that would require me to implement seek within the decoder; and given that it is already implemented within the parser, that would be a foolish waste of effort if it's possible to avoid.
So, back to the original problem: getting playbin to plug a parser automatically. I found that aacparse has its rank set to: GST_RANK_PRIMARY + 1 Our decoder/sink was set to GST_RANK_PRIMARY + 2 -- so I deleted the "+2" and ran again with playbin2. Lo and behold, aacparse is autoplugged!... however, seek is still not working... so close and yet no cigar.
The pipeline created by playbin2 now looks like this: filesrc ! typefind ! id3demux ! aacparse ! inputselector ! audiotee ! streamsynchronizer ! aqueue ! identity ! the_custom_decoder_and_sink
I'm digging through here now to try and determine where the seek command is getting rejected. In the meantime, any guesses? This pipeline also produces the id3demux->aacparse warning:
0:00:00.307036432 2287 0x8130758 WARN tagdemux gsttagdemux.c:680:gst_tag_demux_chain:<id3demux0> Downstream did not handle newsegment event as it should but in this case, it continues playing (but not seeking). Perhaps I'll see if I can pull the fix for that issue from git. Happen to know where it went in? (if not, I can search, of course, but simpler if someone happens to be familiar with it)
-- Finally, regarding the issue with id3demux not linking to aacparse: I used id3demux because that was what was getting automatically plugged by playbin2 (and I wanted to create a similar pipeline during my testing). As we've seen, removing it does appear to work. Any idea why playbin2 is autoplugging?
Unfortunately running gstreamer out of git isn't an option for this project, which requires stability (otherwise I would :) Thanks again for the help,
Eric
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
I should also add that the test stream I am using does indeed have an id3 tag. I don't care to read it in this case, but of course need to handle streams that contain them.
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
In reply to this post by Eric Montellese
On Wed, 2012-06-20 at 11:34 -0400, Eric Montellese wrote:
Hi, > However, when I dug into the code deeper, I found that the seek event > is not being delivered to the sink at all (which in this case would be > necessary since the sink and decoder are one element) -- instead the > seek event is going to the pad connected to the sink's sink pad (how's > that for a confusing sentence?). In other words, it is going to the > source pad of the element just upstream of the sink. > Is there a reason for that (other than to save a hand-off), or could I > modify the bin code to send the seek event to the sink element itself? It should already go to the sink. The appliction should do gst_element_seek_simple (pipeline, ...), which does a gst_element_send_event (pipeline, gst_event_new_seek (..)) internally. The pipeline then passes that seek event to the bins which are sinks, which in turn also pass it down the object hierachy on the sink side. This all goes via the send_event vfunc. Ultimately the event ends up in your sink, where the default send_event vfunc pushes it upstream into the pipeline, so it gets pushed to the peer element's src pad. You can of course implement your own vfunc and handle the seek event yourself in your sinkdecoder if you like. Cheers -Tim > > Of course, that would require me to implement seek within the decoder; > and given that it is already implemented within the parser, that would > be a foolish waste of effort if it's possible to avoid. > > > So, back to the original problem: getting playbin to plug a parser > automatically. > > > I found that aacparse has its rank set to: GST_RANK_PRIMARY + 1 > > > Our decoder/sink was set to GST_RANK_PRIMARY + 2 -- so I deleted the > "+2" and ran again with playbin2. Lo and behold, aacparse is > autoplugged!... however, seek is still not working... so close and > yet no cigar. > > > The pipeline created by playbin2 now looks like this: > filesrc ! typefind ! id3demux ! aacparse ! inputselector ! audiotee ! > streamsynchronizer ! aqueue ! identity ! the_custom_decoder_and_sink > I'm digging through here now to try and determine where the seek > command is getting rejected. In the meantime, any guesses? > > > This pipeline also produces the id3demux->aacparse warning: > 0:00:00.307036432 2287 0x8130758 WARN tagdemux > gsttagdemux.c:680:gst_tag_demux_chain:<id3demux0> Downstream did not > handle newsegment event as it should > > > but in this case, it continues playing (but not seeking). Perhaps > I'll see if I can pull the fix for that issue from git. Happen to > know where it went in? (if not, I can search, of course, but simpler > if someone happens to be familiar with it) > > > -- > Finally, regarding the issue with id3demux not linking to aacparse: > I used id3demux because that was what was getting automatically > plugged by playbin2 (and I wanted to create a similar pipeline during > my testing). As we've seen, removing it does appear to work. Any > idea why playbin2 is autoplugging? > > > Unfortunately running gstreamer out of git isn't an option for this > project, which requires stability (otherwise I would :) > > > > > Thanks again for the help, > Eric > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
OK, I figured out the problem there. gstpad.c function gst_pad_push_event() around line 5267 (at least in this version) peerpad = GST_PAD_PEER (pad); ...followed by... result = gst_pad_send_event (peerpad, event);
So the event is going to the sink's peer instead of the sink itself. It turns out that the problem is that the custom audio sink does not have the "send_event" function defined.
Because of that, gst_element_send_event() in gstelement.c (called by gstbin.c) is choosing the default_send_event() since oclass->send_event is not defined. I had been looking for the seek event to arrive in the class's "event" function, and hadn't implemented the "send_event" function. A quick hack to define it shows it being called correctly.
It seems confusing that a received seek event should come in on the "send_event" -- what's the reason for that? -- Meanwhile,
I'm still trying to determine why seek is failing with the new playbin2 pipeline
I edited the test stream and removed the id3 tags, so that playbin2 doesn't autoplug the id3demux. So the pipeline now looks like this: filesrc ! typefind ! aacparse ! inputselector ! audiotee ! streamsynchronizer ! aqueue ! identity ! the_custom_decoder_and_sink
The seek command gets sent to the source pad of the "identity" element (because of my missing send_event() as explained above), and every part of the pipeline upstream are gstreamer built-ins.
Any thoughts? Thank you, Eric On Wed, Jun 20, 2012 at 12:01 PM, Tim-Philipp Müller <[hidden email]> wrote: On Wed, 2012-06-20 at 11:34 -0400, Eric Montellese wrote: _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
I determined what is going on (but still not sure how to fix it): With playbin2 on my "host" machine (a standard ubuntu install), playbin2 plugs in the faad decoder within the decodebin. The seek event traverses the pipeline from sink to source and gets handled by the faad decoder within decodebin
With playbin2 on my "target" machine (hardware requires use of the custom audio sink), playbin2 plugs in the aacparse element within the decodebin. When the seek event traverses the pipeline, it is received by decodebin which appears to skip the aacparse element entirely. Instead it goes through the typefind element and into the source, which then fails to perform the seek due to a failure in the GST_QUERY_CONVERT call (haven't dug into exactly why yet -- but appears to be a type mismatch?)
This explains why the manual pipeline works, but the playbin2 pipeline doesn't... the critical element is being skipped with playbin2. So, the big question remaining is: Why is the decodebin not sending the SEEK event to the aacparse element within it?
Any pointers as I dig through this are appreciated! Thanks, Eric
On Wed, Jun 20, 2012 at 12:49 PM, Eric Montellese <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
On Wed, 2012-06-20 at 21:51 -0400, Eric Montellese wrote:
Hi Eric, > With playbin2 on my "target" machine (hardware requires use of the > custom audio sink), playbin2 plugs in the aacparse element within the > decodebin. When the seek event traverses the pipeline, it is received > by decodebin which appears to skip the aacparse element entirely. > Instead it goes through the typefind element and into the source, > which then fails to perform the seek due to a failure in > the GST_QUERY_CONVERT call (haven't dug into exactly why yet -- but > appears to be a type mismatch?) > This explains why the manual pipeline works, but the playbin2 pipeline > doesn't... the critical element is being skipped with playbin2. > > So, the big question remaining is: Why is the decodebin not sending > the SEEK event to the aacparse element within it? What you describe sounds quite normal to some extent. A parser, decoder or demuxer would on receiving a seek event typically send it upstream first, to see if there's another element that can handle it. In your case that won't be the case, and the convert stuff is filesrc trying to convert the TIME seek to a BYTE offset, which it can't. So far so much as expected. So I think you have to look in the debug log what happens after that. Just to confirm - your doing a seek in TIME format, right? Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
In time format, yes. Why is it that in a manual pipeline the seek command is handled by the parser, but in a bin, the parser is skipped? If it is indeed expected that the src element should handle this event, the next step I guess would be to determine why the convert query is failing. The debug log here doesn't show the query traversing as I would have expected (although I haven't checked the source yet to see what debug prints are in place). What is the expected path of the convert query? Thanks, _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
On Thu, 2012-06-21 at 09:55 -0400, Eric Montellese wrote:
> Why is it that in a manual pipeline the seek command is handled by the > parser, but in a bin, the parser is skipped? > > If it is indeed expected that the src element should handle this event It is expected that it (the source) does not handle it in this case. That doesn't mean the event won't be sent there first to try. Perhaps you could make a GST_DEBUG=*:5 log starting from when you do the seek. Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
Ugh, this bug keeps moving out from under foot. In gathering the log, I looked through it for the aacparse element, and determined that it's *not* part of the pipeline created when using my seek test app.
The seek test app uses gst_parse_launch to run "playbin2" What's confusing is that calling gst-launch with "playbin2" *does* add the aacparse element. I had been assuming that the two cases would act identically and had been using the "dot" output from the gst-launch command to get a graphical look at the pipeline during debug. As it turns out, that was not accurate..
So, the new question is: Why is the pipeline created by playbin2 different when it is created using gst_parse_launch than when it is created by gst-launch? And, as before: how do I encourage playbin2 to autoplug the parser? (particularly in the gst_parse_launch case)
Thanks Eric _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
On Thu, 2012-06-21 at 13:00 -0400, Eric Montellese wrote:
> So, the new question is: Why is the pipeline created by playbin2 > different when it is created using gst_parse_launch than when it is > created by gst-launch? I find it hard to believe that it is in fact different :) > And, as before: how do I encourage playbin2 to autoplug the parser? > (particularly in the gst_parse_launch case) If you create a playbin2 element, don't use gst_parse_launch(), use gst_element_factory_make("playbin2", NULL). If you're using gst_parse_launch() because it's more convenient to set properties that way, use gst_util_set_object_arg() instead to set them. Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
It's surprising to me as well. I have two log files - one from gst-launch and one from gst_parse_launch. The one from gst-launch contains many references to aacparse; the one from gst_parse_launch does not. Both command lines are identical (just playbin2 and the uri parameter).
Unfortunately the method in which playbin2 is being instantiated (with gst_parse_launch) is dictated by the customer. It may be possible to convince them to modify this, but ideally it would be best to be able to work within that framework.
Regardless, I'll try out your suggestion to see if it has an effect. Any other ideas though for gst_parse_launch with playbin2? Thanks,
Eric log files are here, for reference: http://www.mediafire.com/?sf809r7jx78x8
On Thu, Jun 21, 2012 at 1:22 PM, Tim-Philipp Müller <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
Unfortunately, creating playbin2 using gst_element_factory_make() has no effect (still no aacparse in the pipe).
I also uploaded png files showing the pipeline in each case.
(the link again is: http://www.mediafire.com/?sf809r7jx78x8) I can get the id3demux element out of there by removing the id3 tags from the files, but the placement or not of the aacparse element is a mystery.
Thanks, Eric _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
On Thu, 2012-06-21 at 14:08 -0400, Eric Montellese wrote:
> I can get the id3demux element out of there by removing the id3 tags > from the files, but the placement or not of the aacparse element is a > mystery. Try changing the pad template of your decodersink so that it only accepts audio/mpeg,mpegversion={2,4},framed=true (other fields the same) and audio/mpeg,mpegversion=1,parsed=true (other fields the same) Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
Tim,
I'm new to this piece of gstreamer -- to confirm, the below is what I did. Is this what you intended? //in the _setcaps() function. (only the related code is copied)
name = gst_structure_get_name (structure); if (!strcmp (name, "audio/mpeg") || !strcmp (name, "audio/x-mpeg")) { gst_structure_get_int (structure, "mpegversion", &mpegversion);
switch (mpegversion) { case 2: case 4: { // I added this. Is this as intended? gboolean framed; gst_structure_get_boolean (structure, "framed", &framed);
if (!framed) { return FALSE; } // end added stuff } } }Doing this, I get no audio playing -- so I'm guessing that's not what you intended :)
Thanks, Eric On Thu, Jun 21, 2012 at 2:21 PM, Tim-Philipp Müller <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
On Thu, 2012-06-21 at 16:26 -0400, Eric Montellese wrote:
> I'm new to this piece of gstreamer -- to confirm, the below is what I > did. Is this what you intended? > //in the _setcaps() function. (snip) Ah, no. Grep for GST_STATIC_PAD_TEMPLATE, which your code likely has. It's where you set the caps that show up as pad template caps in gst-inspect. Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
Ah yes, I see now. Thank you.
Unfortunately that element does not have this implemented; but other elements do, so I will follow their example. Thanks, Eric On Thu, Jun 21, 2012 at 4:35 PM, Tim-Philipp Müller <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Unable to seek audio files with playbin2; manual seek also broken in plugins-good-0.10.31
|
|
IT WORKS!
Thank you muchly. I owe you a beer or three. Eric On Thu, Jun 21, 2012 at 4:40 PM, Eric Montellese <[hidden email]> wrote: Ah yes, I see now. Thank you. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |