[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
    > 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

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

    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, 
    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
<hr noshade size=1>
<table frame="vsides" width="100%">
      <small><b>Luis Rodero Merino</b></small><br>
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
      <small>Area de Telemática</small><br>
      <a href="http://gsyc.escet.urjc.es"><small>Grupo de Sistemas y
      <a href="http://www.urjc.es">
         <img border=0 align ="middle"
src="file:///usr/share/pixmaps/logoURJC.gif" alt="logoURJC"></img>
-------------- 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