<br><br><div><span class="gmail_quote">On 7/12/06, <b class="gmail_sendername">Jean-Paul Saman</b> <<a href="mailto:jean-paul.saman@planet.nl">jean-paul.saman@planet.nl</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;">
Albert Marti wrote:<br>><br>><br>> On 7/12/06, *Jean-Paul Saman* < <a href="mailto:jean-paul.saman@planet.nl">jean-paul.saman@planet.nl</a><br>> <mailto:<a href="mailto:jean-paul.saman@planet.nl">jean-paul.saman@planet.nl
</a>>> wrote:<br>><br>>     Michael Chan wrote:<br>>      > Dear all,<br>>      ><br>>      >   What if I have a network that can provide a 1GB capacity and assume<br>>      > that the PC I/O port is fast enough to transfer the stream to decode
<br>>      > module?  Can I reduce the buffer in such situation?<br>>      >   Besides, Is the capture from video signal (said video capture from<br>>      > 1394 input) also follow the same behaviour?  I test that there are 1
<br>>      > second delay from the video cam to the display in my pc.  Anyway to<br>>      > reduce the delay?<br>>     Use another value for --dv-caching=10000, for instance. However since<br>>     1394 sends data at 400 Mbps over the link, you need a really _fast_ PC
<br>>     (>2GHz CPU) or LARGE buffer to not drop data at the input.<br>><br>>     Gtz,<br>>     Jean-Paul Saman.<br>><br>>      ><br>><br>>     --<br>>     This is the vlc mailing-list, see 
<a href="http://www.videolan.org/vlc/">http://www.videolan.org/vlc/</a><br>>     To unsubscribe, please read <a href="http://www.videolan.org/support/lists.html">http://www.videolan.org/support/lists.html</a><br>><br>
><br>><br>> I guess that this buffer is needed because the CPU needs enough time to<br>> process all the packets. I guess also that this buffer has a minimum<br>> safe value to work with a medium fast PC.<br>
><br>> Then, without having any knowledge about the VLC code/architecture,<br>> could be possible to modify this buffer to a small value, recompile VLC<br>> and run it on a really _fast_PC to reduce this latency?
<br>><br>> Has this any sense?<br><br>You don't need to recompile for adjusting buffers in vlc. Just use the<br>modules caching option. For input DV you need --dv-caching=<value> for<br>file input --file-caching=<value>, for UDP input --udp-caching=<value>,
<br>etc.<br><br>On the stream output chain it is the same. For UDP out adjust<br>--sout-udp-caching=<value><br><br>Hope this helps.<br><br>Gtz,<br>Jean-Paul Saman.<br><br>--<br>This is the vlc mailing-list, see <a href="http://www.videolan.org/vlc/">
http://www.videolan.org/vlc/</a><br>To unsubscribe, please read <a href="http://www.videolan.org/support/lists.html">http://www.videolan.org/support/lists.html</a><br><br></blockquote></div><br>
As I mentioned before I already adjusted those parameters in the server
(--sout-upd-caching 0) and in the client (:udp-caching=0) without any
result.<br>
<br>
I'm guessing because there is always a minimum buffering that vlc is doing internally (at level of code)<br>
<br>
I guess also this buffering is done to give some time to the CPU to process the stream.<br>
<br>
My question was regarding that internall buffering, if modifing the
code, an assuming that you run VLC in a really fast pc, would work.<br>
<br>
<br>
Is it clear enough?<br>
<br>
Thanks<br>
<br>
ALbert<br>
<br>
<br>
<br>