The VideoLAN Forums

Hi Folks,

sorry to bother you but i got stuck and i didn´t find any clues in the forum so far.
i am trying to stream a file over HTTP but somehow it doesn´t work properly.
I am using vlc 0.7.0 on windows and when i stream a file (DivX 3.11 avi in ths case) the server seems to stream it correctly as i see from the control panel. When i try to connect to that stream with VLC as client i get the Movie for about a second and then the player stands still.
When i connect with a browser it tries to download the running stream but wont play anything.
I am pretty sure this is some error i make while starting or connecting to the stream...
So if someone would tell me the correct syntax of the startup on both machines i would appreciate that.

Details:
Sever: VLC on Win2K on IP 172.16.1.1
Client: VLC on Win2K on IP 172.16.1.3
File: C:\Video\Movie avi

Another question: Do i have to install an Webserver on the servermachine as well ? I guess not but i am not really sure about that ....

Oh, and while you are on it, can someone tell me the params for MMS Streaming as well ..with that i wasn´t able to get some results at all.

I Think VLC rocks and i would like to use it but that i am not capable of using HTTP / MMS streaming (Due to my limited knwoledge i guess )
drives me crazy..
So Thank you very much for your Time and Help

Lex

Could it be a bandwith problem ?

And no, you don't need to install a web server, VLC does use it's own simple web server to provide the stream.
Using a web browser to view the stream won't work as well because the web server won't understand that the stream is in fact a video so will just try to download it as a file. You could however install the Mozilla plugin for VLC to achieve that.

For streaming to WMP in MMSH, have a look at this thread:
viewtopic.php?t=255&highlight=wmp

Could it be a bandwith problem ?

I've tested vlc 2 vlc streaming yesterday (both on Winxp, vlc 0.7) and tried all kind of ways. And got same problems as stated only on http interface. On http streaming system froze. Maybe there's something wrong with http...

Anyone doing this sucessfuly on http interface ?

Regards,

Robert.

I had the same problem with vlc 0.7.0 under Red Hat 9.0 with a Celeron 700MHz.
I have downloaded the file and vlc displays it locally without any problem.
I also tried an other opensource player: it can display the file via http.
Thus, it's not due to ...
==> a bad file
==> a bad bandwidth
==> a computer too slow

I can reported 3 cases:

Case 1)
----------
vlc --noaudio --http-caching 10000 http://www.archive.org/download/BlackKn ... Knight.avi

The 3 following lines are repeated 4 times before the display starts:
access_http input debug: HTTP server replied: 206
[00000365] access_http input debug: stream size is 16945556
[00000365] access_http input debug: seeking to position 36548
I guess that means the cache is being filled...

Then the display starts and video is played during approximatively 1s and FREEZES.

Immediatly, some traces like these appear in the message window:
access_http input debug: HTTP server replied: 206
[00000361] access_http input debug: stream size is 16945556
[00000364] main video output warning: late picture skipped (5365577)
[00000364] main video output warning: late picture skipped (5338964)
[00000364] main video output warning: late picture skipped (5337576)
[00000364] main video output warning: late picture skipped (5310960)
[00000364] main video output warning: late picture skipped (5270980)
[00000364] main video output warning: late picture skipped (5244263)
[00000363] ffmpeg decoder error: more than 5 seconds of late video -> dropping frame (computer too slow ?)
[00000361] access_http input debug: seeking to position 106140

Case 2) Cache size increased...
-----------------------------------------
vlc --noaudio --http-caching 100000
http://www.archive.org/download/BlackKn ... Knight.avi

Before display will start, the 3 lines mentionned in case 1 are displayed during a long time.
This appears to be consistent: a bigger cache is being filled.

Then display starts, video is played during about 5s and FREEZES.
I guess the display freezes when the cache is empty.

Then the same messages appear than in case 1.

Case 3) Audio is enabled
-----------------------------------------
vlc --http-caching 10000
http://www.archive.org/download/BlackKn ... Knight.avi

In this case, I have no display at all !!

The traces are a mixing of filling cache messages like these:

[00000361] main input debug: probing 4 candidates
[00000142] main module debug: using network module "ipv4"
[00000142] main module debug: unlocking module "ipv4"
[00000361] access_http input debug: HTTP server replied: 206
[00000361] access_http input debug: stream size is 16945556

AND messages like these

main private warning: will skip 3420 bytes, slow
[00000365] main audio output warning: computed PTS is out of range (5784447), clearing out
[00000365] main audio output warning: PTS is out of range (5784489), dropping buffer
[00000365] main audio output warning: output PTS is out of range (5878512), clearing out
[00000365] main audio output warning: PTS is out of range (5722102), dropping buffer
[00000365] main audio output warning: PTS is out of range (5659685), dropping buffer
[00000365] main audio output warning: PTS is out of range (5597269), dropping buffer
[00000365] main audio output warning: PTS is out of range (5534853), dropping buffer

Moreover, at vlc exit (properly, with the quit button of the wxWindows interface) I get:
[00000068] main module debug: unlocking module "float32_mixer"
[00000361] main input debug: no more selected ES
Segmentation fault

!!!

First (bad ?) idea to discuss ...
-------------------------------------
All is occuring as if VLC would required a lot of CPU time to process HTTP.

So much time is required that
- when the cache is empty, the "HTTP packets" are not processed in time and VLC drop the buffer they contain which are presented to late
- when audio processing is added, time for treatment of HTTP packets is increased again and nothing at all can be displayed

Is it possible that the addition of HTTP module causes the loss of the real time decoding capability or something like that ?

Emmanuel DUFOUR.

I'm having a similar problem under Mac OS X 10.3 (Panther). All videos play fine, except when http streaming. I'm hooked up with gigabit ethernet to a webserver on the LAN, so bandwidth isn't a problem. It works just fine under the previous version (0.6.2), so I think it's a problem in 0.7.0.

Is there anyone to confirm if it is really a bug in 0.7.0 version or a configuration problem ?
In this case, is it easy to fix ?

Emmanuel DUFOUR.

About the detailed problem with http://www.archive.org/download/BlackKn ... Knight.avi, it is the expected behaviour of VLC.

Due to the architecture of VLC (streaming client and server), it can only read a file at its designed (playing) speed so if your bandwith is not enough to play the file then you'll only be able to play what's been cached at the beginning then VLC will start (and continue) to discard all data because it is arriving too late.

To summarize, VLC doesn't just display the data when it arrives... VLC knows (from the data contained in the file) at which rate the file is supposed to be viewed (or streamed) and tries to play it at this speed and if it can't then it just skips the data hoping that the connection will get better and the data will be sent at the correct rate again.

Thank you for your honest answer.
I think the behaviour of VLC can be understood and is justified by the fact it is dedicated to video content i.e. data with real time properties.
But HTTP is known NOT to garantee such properties !

Could the VLC team plan to add an OPTIONNAL behaviour for HTTP ?
==> display the content when it is decoded preserving time sequencing but without controling real time.

Indeed, someone using HTTP must know vlc will only display what it will be able to display of the video with a message telling it's not his fault !!. The idea is: one picture each 2s is better than nothing at all.

Is it a huge task ?

Emmanuel DUFOUR.

It's a huge task, because it requires major internal changes. We would have to create a special 'large' buffer to save the already downloaded data into. I don't think it will happen soon.

I'm having this problem locally. Meaning VLC and Webserver on same machine, so network bandwidth shouldn't be a problem.

I have the same problem, from one machine to another and on teh same machine (back to itself)

CPU% is less than 50%, Network trafic is less than 5% (100mb).

it works fine if i set the stream (video+sound) to less than 512Kb/s any higher it only playes for a second then drops. it looks like a bandwidth problem but how can it be?

looking at the debug the the first frame is dropped, then it just keeps on dropping untill it either disconnects or finaly re-syncs.

instead of just dropping the frames why not play them anyway, allowing for say a maximum of 20ms lag.
id rather have lagged video than no video.

im on win2k SP4, vlc 0.7.1
im streaming from my Haupage (however you spell it) PVR, then using http for the output on port 8082.
it works great using UDB multicast, i can pick it up on all my Pcs, but i dont realy want to keep spamming my network 24/7 because most of the time ill be watching TV and wouldnt need it. HTTP looks like a good way round it... if i can get it at a decent quality.

sorry if this is an old thread, i just did a search and found this.

is there a quick fix for this?..

http stream bandwidth seems limited over network

Delvar: "it works fine if i set the stream (video+sound) to less than 512Kb/s any higher it only playes for a second then drops. it looks like a bandwidth problem "..

win32 vlc 0.7.2
http stream bandwidth seems limited to ~400Kbps for networked clients,
but clients on the localhost are not affected. (udp is also ok)

results in player problems when http stream is greater than 400Kb, and, the player (client) is on a different system than the server (streamer).

is this a known problem?