Streaming freezes start again freezes...

[paxito]

I am trying to stream from my desktop PC to my laptop using videolan.

I can set it up properly and stream via UDP unicast.

Experiencing some freezes I tried to play with buffers on both client and server side with no success (tried large buffering of several seconds)...

Any other parameter I should tune differently?

Thanks

[DaMightyWhighty]

I experience same problem, but im using HTTP port, larger buffers help.. but feed still freezes

[Steph]

Same problem here, streaming tv from desktop pc to wifi laptop, works perfect with udp unicast at 3000kbit/s, but with http and mms it works only up to 384kbit/s, higher than that the client says "computer too slow" (the cpu usage is very low on both machines). But if I run the client (and the server) on the desktop pc it works fine, so there's some networking bug or something. I tried the reverse, server on laptop and client on desktop, same problem. The network data throughput doesn't go beyond 50 kByte/s with http and mms, strange.

I've tried it with an ethernet cable instead of wifi, didn't make any difference.

The problem with udp is that there's constantly traffic on the wifi, even if I'm not running the client, and wifi is slow enough as it is. I'd prefer video on demand with http or mms.

Any suggestions appreciated.

http://steph.highvoltageweb.com

[Guest]

I having the same problem here. With UDP I can stream at upto 12000kbps with perhaps one or two "late picture skiped"s as it starts up. However, using HTTP or MMSH/MMS, VLC seems to refuse to send data any faster than 0.5% of my 100Mbps connection.

When copying a large file across the same connection, the usage will go up to ~60% with the stream still running fine. Also, when viewing the stream with both Windown Media Player and VLC on the client, the usage will double so that both instances run with no problems.

This is the same with all firewalls turned off. The stream always runs with no problems when viewed with a second instance of VLC on the server.

Both computers are using Windows XP SP2, I am using VLC 0.8.0 because of Firewire/DV issues, but I think I had the same problem with 0.8.1, I just hadn't looked into it.

[Sandrift]

I am having just about same problem!

When streaming directly to my laptop via UDP Unicast, it streams perfectly without problem.

When trying to stream with http, it is very choppy, plays for a half second, and then chops up, rince and repeat.


Does anyone have a fix for this? I would like to be able to stream to more then 1 computer at a time using http. I own a small resort with 15 units, and 4 condo's, and would like to offer up a video on my network to the guests like a type of travel guide, and video lan seems to be the best thing out that doesnt need very special materals.


Thanks Much
Chris

[Guest]

Forgot to mention, When streaming with UDP, stream will go over 300k/s+++ and plays smooth,

With HTTP (TCP), it will not go over 50k/s and that is when it is choppy, tryed fiddeling also with the settings, cannot fix problem.

Router is linksys WRT54G
Choppy with HTTP/TCP using both wired and wireless PC's. Server is wired.

[erant]

What can I say, the forum is full with the same problem.
I assume this has to do with some bug in the vlc since there is absolutlly no difference when using on a local network (with 2 machines that are both Dual Xeon) or using over the internet with the worst connection.

More then 384kbs starts the problem over MMSH or HTTP (even worse).

I have no problem using the UDP or even writng a software that will distribute the udp stram on demand.

My only problem with this protocol is what is the home user will have a router at home. In this case he will need to forward the udp ports to his local ip and this is out of the question.

My idea to start resolving this issue is to use the clue of the first post that it works fine on the same machine.
I will run ATHREAL to see exactlly what are the traffic shape and delays, and then try to build some wrapper software that will buffer and move the traffic on her own.

I don't understand how such a nice developed software with such a big investment in technology and no develper have responded to even one of the many posts here. This does gives the impression that we have a big problem here.

[goelectric]

Has anyone got a solution to this yet?

I notice the last post is June 2005 - and now its October 2005 and I am seeing the same problems - bandwidth flatlines at about 400kbit/s when using mms or http to stream.

[the-savior]

which codec do you use?

[goelectric]

which codec do you use?

Hi, its on an XP server (sp2) and I am using div3 and mp3 - here's the sout command line:-

:sout=#transcode{vcodec=DIV3,vb=1024,scale=1,acodec=mp3,ab=64,channels=2}:duplicate{dst=display,dst=std{access=mmsh,mux=asfh,url=192.168.1.14:4321}}

[erant]

Its been a long time and no idea for the solution of this problem.
I have managed to eliminate the problem that the player will stop, after few errors of "computer too slow" by changing the clock refrence counter to arround 5ms and enable the clock - (Prefrences - advance)

This does not solves the main core of the problem that on any two ways comunication (tcp,http,mms) the network module can not handle more then 384kbs.

Just to focus things so mybe some one will have a chance to resove this issue I can cover few things:
1. the delay of the netwrok is meanningless. you will have the same problem with two computers on the same network with 1ms delay and with 300 ms delay.

2. if you run it on the same machine it works fine with no problems, using Ethreal to snife the network traffic does not show any traffic on the network (server and client on the same pc) so basically the network is the problem.

3. There is no connection to the encoder you are using - the same problem is relevant to all of them with no exception.

4. The network on the client side will not go higer then arround 400kbs, only for few seconds in the beggining.

If you are using a windows media player instead - he will buffer every few seconds, the important thing is that: when the video keeps playing after the buffering, it will continue from where it stoped, basically after few minutes you will be far from real-time since a huge delay can happen.
This shows that the vlc server does hold a big buffer for the missing data.

5. setting big buffers does not change the problem,

It all shows like something is wrong with the network module that handles the traffic, the fact that you can download a file using http in 5mbs speeds with no problem shows that there is no real reason why the vlc can not do it.
The difference between the udp type is that in here the client keep on sending ACK (Aknolegments) to the server for the packets he gets and this triggers the server to send the next packets. the logic is that in order to get a smooth video the server needs to send amount of data which is 2 * delay (round trip) * Average baud-rate.
This way you will always have correct amount of video to play until the next packets will come.

One thing that might have to do with this problem is the size of the Send and Recieve buffer size. we had a similar problem on a player we developed years ago.
There is a function called SetSockOpt() that can set those buffers for sockets, but in the prefrences there is no interface for those parameters.

For know if there is someone who think he can fix this issue we will pay 1000$ for that fix, since as far as we see no one have the motivation to fix this bug or even admit he exist.

I have seen many replays in the internet of vlc developers that actually responded that your "computer is too slow".
Just too eliminate this as well we get the same problem on Quad XEON 3GHZ for client and for server.

This small bug basically turn this extreemly good software to a worthless server for the internet enviroment. since udp and one way traffic can not handle "Home Routers" fire walls, etc.

Regards
Eran T
CEO StreamTechGaming Ltd
ERAN@streamtechgaming.com

[md]

This problem has been solved today in SVN trunk.

[goelectric]

Fantastic that is has been fixed. Apologies for my ignorance but how do I get a binary with the fix in? What is SVN trunk?

[md]

The easiest way is to download the next nightly build from http://nightlies.videolan.org/build/win32
(it's not there yet since they're automatically built during night time)

[m.e]

I'm still having the same problem with http. Can someone confirm that it actually has been solved?

[goelectric]

Hi,

I've tested the build fromSunday (vlc-0.8.4-test1-20051023-1134-win32.exe) and it works great with mms: (which uses http).

This is on windows xp sp 2 with vlc to Windows media player over lan and WiFi at 2kbs.

Best regards

steve.

[md]

I'm still having the same problem with http. Can someone confirm that it actually has been solved?

Could you please provide more information:

What VLC version are you using? What's your hardware, OS ? What are you streaming? Which command or GUI interface options are you using?

FYI, in our environment, the fixed version is able to correctly stream HDTV video at 20 Mbit/s over HTTP conneciton from both UNIX and Windows XP SP2 machines.

[Guest]

It seems to work fine now. I must have done something else wrong. Sorry

[m.e]

The above was me.

Thanks for fixing the problem.

[vio]

I can see that the issue is sovled, but I still have this issue. I'm running VideoLAN Server 0.5.4+cvs20031028 (Aug 24 2005) with the following parameters: vlc -d /root/test.avi --sout '#duplicate{dst=standard{access=mmsh,mux=asfh,url=:8080,sap,name="OriginalStream"}, dst="transcode{vcodec=WMV3,vb=100,scale=0.5,fps=10}:standard{access=mmsh,mux=asfh,url=:8081,sap,name="TranscodedStream"}"}' --no-sout-audio --loop to play a test movie.
The bandwidth used for the transcoded stream is 50kbps and for the original stream is 500kbps.

How I can solve this issue? What I can change? Can U help me?