[gst-devel] streaming over mobile IP and multicast IP
Luis Rodero
lrodero at gsyc.escet.urjc.es
Wed Jan 15 12:57:01 CET 2003
El mié, 15-01-2003 a las 17:48, Wim Taymans escribió:
> The raw file data coming from filesrc doesn't have any timestamps. I
Exactly.
> don't know if udpsink/udpsrc are set up to pace data based on the
> timestamps, but they should be, and then you would put mp3parse between
UDPsink is able to pace data based on timestamps, provided there is a
plugin in front of it that generates those timestamps (currently no
plugin exists that can timestamp but not decode mp3 data AFAIK). You
also have to be aware that UDP drops packets when the network is
flooded.
I am getting lost here, sorry. I assumed that udpsink -> udpscr do not
make any changes in the data stream (they are transparent, udpsrc
delivers exactly the same stream of bits that udpsink receives). If they
are, what is the difference for the mad plugin?, I mean, the mad plugin
receives just the same data through the udp plugins that it would
receive directly from filesrc, does not?. So, why it is not possible for
tha mad plugin to do just the same with the data? (sure these are quite
basic questions, but I am a bit confused at this stage...).
By the way, a very basic question: is the scheduler who decides when to
pull the data from a plugin to push it to the next one? if so, how does
the scheduler know when to pull and push the data?. Or maybe is that the
next plugin is who pulls the data from the previous plugin whenever it
needs?.
Adding timestamps to mp3parse wouldn't be hard.
So, a solution would be to parse the data to insert time stamps in the
sender, and to 'un'parse the data in the receiver?, oh, uf...
(ey, willy, just between yo and me, maybe there is another solution
easier? ;-) )
> filesrc and udpsink. Then the issue becomes one of global clock
> management, which wtay will have to answer.
There is currently no gstreamer support for syncing clocks accros
machines, it is however possible to create a new clock that does this
or one could sync the clocks at a lower layer with ntp or so.
about the multi-receiver case: I don't think it is supported yet
about capsnego over udp: udp does (minimal) capsnego, it serializes the
caps over a TCP socket to the receiver. This also explains why the
multi-receiver case doesn't work too well...
uh? what are caps, please?.
thanks again,
Luis
Wim
--
Wim Taymans <wim.taymans at chello.be>
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
--
<br>
<hr noshade size=1>
<table frame="vsides" width="100%">
<tr>
<td>
<small><b>Luis Rodero Merino</b></small><br>
<a
href="mailto:lrodero at gsyc.escet.urjc.es"><small>lrodero at gsyc.escet.urjc.es</small></a>
<hr noshade size=1>
<a href="http://www.urjc.es"><small>Universidad Rey Juan
Carlos</small></a><br>
<small>Area de Telemática</small><br>
<a href="http://gsyc.escet.urjc.es"><small>Grupo de Sistemas y
Comunicaciones</small></a><br>
</td>
<td>
<center>
<a href="http://www.urjc.es">
<img border=0 align ="middle"
src="file:///usr/share/pixmaps/logoURJC.gif" alt="logoURJC"></img>
</a>
</center>
</td>
</tr>
</table>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: Esta parte del mensaje esta firmada digitalmente
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20030115/f6e74b57/attachment.pgp>
More information about the gstreamer-devel
mailing list