<br><br><div><span class="gmail_quote">On 6/26/06, <b class="gmail_sendername">Julien Le Cléach</b> <<a href="mailto:julien.lecleach-ste-exterieure@fr.thalesgroup.com">julien.lecleach-ste-exterieure@fr.thalesgroup.com</a>

> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Could it be buffering on the receiving on end?<br><br>i don't use vlc caching (emitting and receiving).

<br>do you think it could be a matter of network configuration ?<br><br>--<br>This is the vlc-devel mailing-list, see <a href="http://www.videolan.org/vlc/">http://www.videolan.org/vlc/</a><br>To unsubscribe, please read 

<a href="http://developers.videolan.org/lists.html">http://developers.videolan.org/lists.html</a> </blockquote></div> okay, I'll go out on a limb here, but please see this a possible scenario, not neccessarly a correct one.

1. Transcoding adds delay. 2. Creating the packets and filling them with data takes time. 3. Transit between the hosts takes time. 4. Receving packets a getting data takes time 5. Buffering before displaying anything adds time.

All of these points will add som added delay, wether it is as much as 2s I dont know, I doubt it. But I'll let somebody more experienced with VLC and how big default buffers etc are, clarify or even tear down my scenario completly.

<br clear="all"><br>-- <br>Best regards / Mvh<br>Jan Pedro Tumusok<br><br>Another fella told me, he had a sister who looked just fine.<br>Instead of bein' my deliv'rance, she had a strange resemblance<br>To a cat named Frankenstein