atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title><![CDATA[WAITWUT?!?]]></title>
  <link href="http://www.waitwut.info/atom.xml" rel="self"/>
  <link href="http://www.waitwut.info/"/>
  <updated>2013-07-24T22:10:28-03:00</updated>
  <id>http://www.waitwut.info/</id>
  <author>
    <name><![CDATA[Tiago Stürmer Daitx]]></name>
    
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>

  
  <entry>
    <title type="html"><![CDATA[Desktop streaming with FFmpeg for lower latency]]></title>
    <link href="http://www.waitwut.info/blog/2013/06/09/desktop-streaming-with-ffmpeg-for-lower-latency/"/>
    <updated>2013-06-09T15:22:00-03:00</updated>
    <id>http://www.waitwut.info/blog/2013/06/09/desktop-streaming-with-ffmpeg-for-lower-latency</id>
    <content type="html"><![CDATA[<p>Compared to <a href="http://www.waitwut.info/blog/2013/06/07/desktop-streaming-with-vlc/" title="Desktop streaming with VLC">VLC</a>, desktop streaming through <a href="http://www.ffmpeg.org/" title="FFmpeg is a complete, cross-platform solution to record, convert and stream audio and video.">FFmpeg</a> allowed me to reduce latency to a minimum, usually less than a second. To achieve such latencies I also had to rely on <a href="http://ffmpeg.org/ffplay.html" title="FFplay is a very simple and portable media player using the FFmpeg libraries and the SDL library.">FFplay</a> instead of <a href="http://www.videolan.org/vlc/" title="VLC media player">VLC</a> as a client.</p>

<h2>tl;dr</h2>

<p>For smallest possible latency:</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ ffmpeg -f x11grab -s 1600x900 -r 50 -vcodec mpeg2video -b:v 8000 -f mpegts udp://192.168.0.10:1234</span></code></pre></td></tr></table></div></figure>


<p>Using rtp gives second best latency</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ ffmpeg -f x11grab -s 1600x900 -r 50 -vcodec mpeg2video -b:v 8000 -f rtp rtp://192.168.0.10:1234</span></code></pre></td></tr></table></div></figure>


<p>Much higher quality with a bit higher latency:</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ ffmpeg -f x11grab -s 1600x900 -r 50 -vcodec libx264 -preset ultrafast -tune zerolatency -crf 18 -f mpegts udp://localhost:1234</span></code></pre></td></tr></table></div></figure>


<p>For lowest CPU usage and even higher latency (screen rate reduced to 5 fps):</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ ffmpeg -f x11grab -s 1600x900 -r 5 -vcodec libx264 -preset ultrafast -tune zerolatency -crf 18 -f mpegts udp://localhost:1234</span></code></pre></td></tr></table></div></figure>


<p>For Windows use <code>dshow</code> instead of <code>x11grab</code> (that&rsquo;s from [examples][ I saw, I didn&rsquo;t actually test it).</p>

<p>Remember to replace 1600x900 with your own screen resolution &ndash; on Linux <code>xrandr</code> is a handy way to figure that out.</p>

<p>On the client side run <code>ffplay udp://192.168.0.10:1234</code>.</p>

<h2>Motivation</h2>

<p>As in the <a href="http://www.waitwut.info/blog/2013/06/07/desktop-streaming-with-vlc/" title="Desktop streaming with VLC">previous article</a> I&rsquo;m looking for a way to share my desktop (read-only) with a broader audience. I was particularly interested in seeing how fast I could push it, given the reports I have read about very low latency streaming.</p>

<p>Keep reading for the full report.</p>

<!-- more -->


<h2>Machine specs</h2>

<p>Same as <a href="http://www.waitwut.info/blog/2013/06/07/desktop-streaming-with-vlc/" title="Desktop streaming with VLC">last time</a>, everything was tested on a Sony Vaio VPC-SA35GB, Core i5 processor, running Fedora 18 x64 on a single screen with resolution 1600x900.</p>

<h2>Latency</h2>

<p>As <a href="http://www.waitwut.info/blog/2013/06/07/desktop-streaming-with-vlc/" title="Desktop streaming with VLC">previously</a>, latency is a factor of client and server settings. <a href="http://www.ffmpeg.org/" title="FFmpeg is a complete, cross-platform solution to record, convert and stream audio and video.">FFmpeg</a> was able to provide much better latency in both sides than <a href="http://www.videolan.org/vlc/" title="VLC media player">VLC</a>. Audio is still an issue and makes latency way higher and depending on the combination it&rsquo;s completely out of sync with video. For this reason everything was tested with no audio stream whatsoever.</p>

<p>On x264 latency is highly dependend on the encoder settings. <strong>Reducing latency is possible, but reduces quality</strong>. This means that we have to use higher bandwidth to keep a similar quality in low latency scenarios.</p>

<p><strong>A highly recommended way to lower bandwidth and CPU usage is by using lower screen resolutions.</strong></p>

<h2>Server side codecs</h2>

<p>I only tested mpeg2 and x264 codecs.</p>

<h3>mpeg2video</h3>

<p>mpeg2 stream through UDP or RTP provided the most responsive stream I could achieve. Quality is way lower than x264 for the same bit rate and CPU usage was about the same, but responsiveness was really good. Not close to real time, more like VNC over the internet (100+ milliseconds), but way better than anything I had achieved so far.</p>

<p>I really need a proper way to compare how much delay I&rsquo;m getting in such low-latency settings, if you know how, please share it on the comments and I will redo my tests.</p>

<h3>x264</h3>

<p>One way to improve latency in x264 is using higher fps for encoding. This increases the ammount of frames available for the encoding process and allows the data to be sent out much earlier. One easy way to see the difference is changing the fps from 50 to 5.</p>

<p>For low latency, I found an excellent discussion of x264 capabilities at <a href="http://x264dev.multimedia.cx/archives/249" title="Introducing low latency for x264 by Dark Shikari">this post</a> which I higly recommend. Check the comments for actual settings, there were some <em>really</em> good comments there. There are discussions about how to calculate latency, required bandwidth, suggest settings, how some options affect quality and/or latency, and much more. The <a href="http://mewiki.project357.com/wiki/X264_Settings" title="a comprehensive guide to options in x264">x264 settings wiki page</a> provides a very good reference for x264 options and the <a href="http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#Encoder_latency" title="improving x264 latency">x264 encoder latency</a> shows how to calculate the actual latency.</p>

<p>One problem with very low latencies is bandwidth. In order to achieve it the encoder may only process very few frames before sending them out, so any x264 optimization that requires a lot of frames has to be disabled to keep buffering to a minimum, because of that quality will be much lower given the same bandwidth. For desktop streaming we can only lower bandwidth so much before text becomes unreadable.</p>

<p>Most comments (<a href="http://x264dev.multimedia.cx/archives/249#comment-2408">this</a>, <a href="http://x264dev.multimedia.cx/archives/249#comment-2505">this</a>, and <a href="http://x264dev.multimedia.cx/archives/249#comment-2509">this</a>) suggest using <code>crf</code> with the proper <code>vbv-maxrate</code> and <code>vbv-bufsize</code>. For desktop streaming I found out that this works well for high bandwidth scenarios, for they introduce some annoying artifacts on the stream under low bandwidth. I would stick with <code>qp</code> in place of <code>crf</code> otherwise &ndash; note that using <code>qp</code> means we can&rsquo;t set any <em>vbv</em> options (they are simply ignored).</p>

<p>I didn&rsquo;t notice any particular difference using <code>intra-refresh</code> and <code>slice-max-size</code> with <code>zerolatency</code> enabled. Also <code>vbv-maxrate</code> and <code>vbv-bufsize</code> have to be carefully picked when using <code>crf</code>, too low and I ended up with vbv overflow problems. I decided to keep all <em>vbv</em> settings out, the x264 seemed to pick sane defaults for both. Of course, all that might be due to the late hour of the night. Let me know if you think different.</p>

<p>In case a 1 second or higher latency is acceptable, do not use <code>-tune zerolatency</code> and rely instead in <code>intra-refresh</code>, <code>slice-max-size</code>, <code>vbv-maxrate</code>, <code>vbv-bufsize</code>, and/or more demanding presets like <code>fast</code> or <code>slower</code>. This will reduce the required bandwidth and produce a much higher quality video while still keeping latency in the range of 1 to 5 seconds.</p>

<h3>Conclusion</h3>

<p><a href="http://www.ffmpeg.org/" title="FFmpeg is a complete, cross-platform solution to record, convert and stream audio and video.">FFmpeg</a> allows us to achieve very low latency with high quality, the only downside being higher bandwidth usage. The client also plays an important role, so stick with faster players such as <a href="http://ffmpeg.org/ffplay.html" title="FFplay is a very simple and portable media player using the FFmpeg libraries and the SDL library.">FFplay</a>.</p>

<hr />

<h4>References</h4>

<p>I relied on the following guides for testing out the various codecs:
 * [Grab the desktop with FFmpeg][]
 * <a href="http://ffmpeg.org/trac/ffmpeg/wiki/StreamingGuide" title="FFmpeg Streaming Guide">FFmpeg streaming guide</a>
 * <a href="http://x264dev.multimedia.cx/archives/249" title="Introducing low latency for x264 by Dark Shikari">The awesome post introducing low latency for x264 by Dark Shikari</a></p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Desktop streaming with VLC]]></title>
    <link href="http://www.waitwut.info/blog/2013/06/07/desktop-streaming-with-vlc/"/>
    <updated>2013-06-07T17:45:00-03:00</updated>
    <id>http://www.waitwut.info/blog/2013/06/07/desktop-streaming-with-vlc</id>
    <content type="html"><![CDATA[<p>Stream your desktop with VLC using the command line.</p>

<h2>tl;dr</h2>

<p>For smallest possible latency:</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ cvlc screen:// --screen-fps=25 --live-caching=10 --sout "#transcode{vcoded=mp2v,vb=256,fps=25,acodec=none}:std{access=udp{caching=10},mux=raw,dst=192.168.0.10:1234}"</span></code></pre></td></tr></table></div></figure>


<p>On the client side run <code>vlc udp://@:1234</code>.</p>

<p>For lowest CPU usage:</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ cvlc screen:// --screen-fps=5 --live-caching=100 --sout "#transcode{venc=x264{preset=ultrafast,tune=zerolatency,qp=10,nr=1000},vcodec=x264,vb=100,fps=5,acodec=none}:std{access=http,mux=ts,dst=/stream}"</span></code></pre></td></tr></table></div></figure>


<p>On the client side run <code>vlc http://&lt;host&gt;:8080/stream</code></p>

<h2>Motivation</h2>

<p>While investigating ways to share my desktop for remote presentations I found out that VLC is able to stream my desktop. I figured out that it might be a good alternative to read-only VNC sessions for some settings and got into testing it in my local network. I also did a simple comparison of it against <a href="http://www.karlrunge.com/x11vnc/" title="x11vnc a VNC server for real X displays">x11vnc</a>.</p>

<p>Now, some VLC setup.</p>

<!-- more -->


<h2>Machine specs</h2>

<p>Everything was tested on a Sony Vaio VPC-SA35GB, Core i5 processor, running Fedora 18 x64 on a single screen with resolution 1600x900.</p>

<h2>Latency</h2>

<p>I experienced latency as high as 20 seconds and as low as half a second (maybe even less, I had no way to measure something that low). Latency depends on: audio, client cache, server codec settings, muxing type, transport protocol, and server transport cache.</p>

<h3>Audio</h3>

<p>Unless you can live with a higher latency, it is highly recommended to disable audio. I have seen latency grow from 3 seconds to 10+ seconds because I enable audio. There might be some optimum combination of options on the codecs to get a smaller latency with audio, but I didn&rsquo;t try it &ndash; let me know if you do know or try it.</p>

<h3>Client side latency</h3>

<p>It&rsquo;s really importante to properly configure the client cache in order to reduce latency. The actual value will depend on the network: a smaller cache leads to lower delays but clients might stagger and the result will seem like an even bigger latency; a bigger cache will help solving staggering problems but video delays will get higher. I recommend you test it beforehand, if at all possible try to emulate your slowest client in the network.</p>

<p>On a private Wifi network I usually set the client cache from 20 ms to 100 ms.</p>

<h3>Server side latency</h3>

<p>The x264 codec can intruce a high latency depending on the preset chosen. In all examples I used the ultrafast preset, there are <a href="http://mewiki.project357.com/wiki/X264_Settings" title="a comprehensive guide to options in x264">other presets available</a>.</p>

<p>Muxing also introduces latency. The TS muxer is the usual choice for network streaming, since it was build to be resilient to data loss. The problem is that it introduces (at least) around 1-2 seconds of latency. The other option is to use the RAW muxer, but only few codecs support that: according to the <a href="https://www.videolan.org/streaming-features.html" title="Streaming features list: video, audio, muxing, transport">VLC streaming features</a> it is supposed to work with mp1v, mp2v, and mp4v. I was only ble to get mp1v and mp2v working with it, mp4v did not work.</p>

<p>The protocol also affects how much latency you get. In my tests HTTP was slower than UDP by at least 2 seconds. UDP also allows the server to configure caching, with enables really slow latency when combined with the right codec and muxer.</p>

<h2>VLC server codecs</h2>

<p>I tested 4 video codecs: x264, mp4v, mp2v, and mp1v.</p>

<h3>x264</h3>

<p>On a static screen, x264 gave me the lowest bandwidth, using around 30 kbit/s, but it also got over 2.5 mbit/s with high dynamic content &ndash; eg. playing a video. Latency can be kept as low as 3 seconds for UDP and 5 seconds for HTTP by using the proper preset (ultrafast). CPU usage was usually steady, but from times to time there were peaks even on static content. CPU usage didn&rsquo;t change much when the screen changed by a small ammount. Overall CPU usage by x264 seemed to be lower than all other tested codecs.</p>

<h3>mp4v, mp2v, and mp1v</h3>

<p>Bandwidth for static screen:</p>

<p> <strong>mp4v:</strong> 1 mbit/s ❘ <strong>mp2v:</strong> 512 kbit/s ❘ <strong>mp1v:</strong> 64 kbit/s</p>

<p>High dynamic content (video) demands a much higher bandwidth: 4~5 mbit/s using the settings bellow. mp1v demanded the most CPU, while mp4v demanded the least amount of CPU. mp2v stayed in the middle ground.</p>

<h3>Frames per second ###</h3>

<p>Minimum fps exist for both mp1v and mp2v codecs: you must use at least 25 fps, see <a href="http://wiki.videolan.org/MPEG-1#MPEG-1_and_2" title="MPEG-1 and 2 wiki page">MPEG-1 and 2 wiki page</a>. Otherwise I recommend sticking to 5 fps for mp4v and x264, this allows the fewest CPU usage while providing good feedback for the clients &ndash; for some reason VLC clients did not respond well when I set fps lower than 5.</p>

<h2>Server side examples</h2>

<p>For the smalest latency (&lt; 1 second) and medium to high CPU usage the mp2v+UDP+RAW+noaudio combination provided the best choice. Use it on a network where you know latency and data loss to be low. I was able to set client cache to 30 ms in a private Wifi network. mp1v can be used instead of mp2v, but it uses more CPU and seems to provide lower video quality.</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ cvlc screen:// --screen-fps=25 --live-caching=10 --sout "#transcode{vcoded=mp2v,vb=256,fps=25,acodec=none}:std{access=udp{caching=10},mux=raw,dst=192.168.0.10:1234}"</span></code></pre></td></tr></table></div></figure>


<p>BTW, you might get a message from VLC complaining that UDP should be used with TS muxer, ignore it. According to the <a href="https://www.videolan.org/streaming-features.html" title="Streaming features list: video, audio, muxing, transport">VLC streaming features</a> it is a valid combination.</p>

<p>For lowest CPU usage, HTTP streaming with x264, no audio, and 5 fps did a great job. I got ~5 seconds latency with a client cache of 100 ms.</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ cvlc screen:// --screen-fps=5 --live-caching=100 --sout "#transcode{venc=x264{preset=ultrafast,tune=zerolatency,qp=10,nr=1000},vcodec=x264,vb=100,fps=5,acodec=none}:std{access=http,mux=ts,dst=/stream}"</span></code></pre></td></tr></table></div></figure>


<p>Or use mp4v</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ cvlc screen:// --screen-fps=5 --sout "#transcode{vcodec=mp4v,vb=64,fps=5,acodec=none}:std{access=http,mux=ts,dst=/stream}"</span></code></pre></td></tr></table></div></figure>


<p>Use UDP streaming to get an even lower latency (~3 secs) with the same low CPU usage</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ cvlc screen:// --screen-fps=5 --sout "#transcode{vcodec=mp4v,acodec=none,fps=5}:std{access=udp,mux=ts,dst=192.168.0.1:2345}"</span></code></pre></td></tr></table></div></figure>


<p>To add audio from Pulseaudio use</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ cvlc screen:// --screen-fps=5 --input-slave=pulse:// --sout "#transcode{vcodec=mp4v,acodec=mp3,vb=64,ab=32,fps=5,audio-sync}:std{access=udp,mux=ts,dst=192.168.0.1:2345}"</span></code></pre></td></tr></table></div></figure>


<p>See more streaming and codec options on the <a href="https://www.videolan.org/doc/streaming-howto/en/ch03.html" title="VLC - Chapter 3: Advanced streaming using the command line">VLC streaming howto</a> and <a href="http://wiki.videolan.org/Codec" title="VLC codecs list">VLC codecs wiki page</a>.</p>

<h2>Watching the stream</h2>

<p>Watch a HTTP stream</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ vlc http://&lt;host>:8080/stream</span></code></pre></td></tr></table></div></figure>


<p>Watch a UDP stream</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>$ vlc udp://@:2345</span></code></pre></td></tr></table></div></figure>


<h2>Comparison with VNC</h2>

<p>I did a very simple comparison using the default <a href="http://www.karlrunge.com/x11vnc/" title="x11vnc a VNC server for real X displays">x11vnc</a> settings and <a href="http://remmina.sourceforge.net" title="Remmina VNC client">Remmina</a>.</p>

<p><strong>Latency:</strong>
VNC session latency was in the order of milliseconds while VLC was on the order of seconds for most scenarios.</p>

<p><strong>Bandwidth:</strong>
VNC used as much as 32 mbit/s for bandwidth in high content settings and around 30 kbits/s on static content. VLC streaming never got past 5 mbit/s (remember it was constrained to 5 fps), but static content might take 1 mbit/s or more depending on the codec &ndash; there&rsquo;s the option to use UDP multicast if the network allows for it.</p>

<p><strong>Content quality:</strong>
VNC has the highest quality. VLC quality is highly dependent on the coded, from the highest quality to lowest: x264, mp4v, mp2v, and mp1v.</p>

<p><strong>CPU usage:</strong>
VNC kept CPU usage to a minimum. VLC depends on the selected codec, but it&rsquo;s usually way higher than VNC.</p>

<p><strong>Encryption:</strong>
VNC allows connection encryption and VLC allows <a href="https://www.videolan.org/doc/streaming-howto/en/ch03.html" title="VLC - Chapter 3: Advanced streaming using the command line">streaming over HTTPS</a>.</p>

<p><strong>Authentication:</strong>
VNC allows for password and/or certificate authentication. VLC streaming provides <a href="https://www.videolan.org/doc/streaming-howto/en/ch03.html" title="VLC - Chapter 3: Advanced streaming using the command line">basic HTTP authentication</a> &ndash; it is highly recommended that HTTPS is enabled as well, otherwise the user and password will be sent without encryption.</p>

<h2>Conclusion</h2>

<p>It seems that it is feasible to rely on VLC streaming for presentations under some settings. Latency seems to be the biggest issue, so be sure that your audience and presentation style can handle delays as high as 20 seconds.</p>

<p>Using HTTP also enables any browser (with the proper plugin) to access the presentation as well. VNC also supports browser, either using the java plugin (I find that a hassle) or a HTML5 client such as <a href="http://kanaka.github.io/noVNC/%E2%80%8E" title="HTML5 VNC Client">noVNC</a> (requires server support or a WebSocket proxy).</p>

<p>Remember that VNC can use better compression algorithms and both server and client can limit the color depth to limit bandwidth usage. This means each client can be configured in a way to make better use of the available network &ndash; of course, the server must be able to support the client settings.</p>

<h2>Future</h2>

<p>Those tests were all run in a private wifi network. I intent to do some testing over slower networks to compare VNC sharing and VLC streamming in terms of quality and reliability.</p>

<p>I have also been playing with ffmpeg directly and results are even better than VLC. <strong>Update:</strong> see <a href="http://www.waitwut.info/blog/2013/06/09/desktop-streaming-with-ffmpeg-for-lower-latency/" title="Desktop streaming with FFmpeg for lower latency">Desktop streaming with FFmpeg for lower latency</a></p>

<p>Keep posted.</p>

<hr />

<h4>References</h4>

<p>I first found about desktop streaming using VLC in <a href="http://blog.nostdal.org/2012/10/vlc-h264-desktop-and-audio-recording-or.html" title="VLC H264 desktop and audio recording or streaming via HTTP on Linux">lnostdal&rsquo;s blog</a>. From there I learned about the various streaming options in the <a href="https://www.videolan.org/doc/streaming-howto/en/ch03.html" title="VLC - Chapter 3: Advanced streaming using the command line">VLC streaming howto</a>. The <a href="https://www.videolan.org/streaming-features.html" title="Streaming features list: video, audio, muxing, transport">VLC streaming features</a> described both available and valid combinations of video, audio, muxing type, and transport method. Codec names and a simple transcoding example are described at <a href="http://wiki.videolan.org/Codec" title="VLC codecs list">VLC codecs wiki page</a>. I found everything I needed about the x264 codec options at the <a href="http://mewiki.project357.com/wiki/X264_Settings" title="a comprehensive guide to options in x264">x264 settings wiki page</a>.</p>

<p><a href="https://plus.google.com/109931565080058432516/posts/hrUGwzJ6UNt">My original post on Google+</a> and a nice guide for <a href="http://grok.lsu.edu/article.aspx?articleid=14625">desktop streaming using VLC GUI wizard</a> posted not long ago.</p>
]]></content>
  </entry>
  
</feed>