Hey all I hope someone can please help, a friend is streaming off tv tuenr off HTTP and the audio is coming through MP3. I try to connect to the stream from HTTP but when I am viewing video after a few seconds the picture either freezes completely or the video screen automatically shuts down but more times than not the screen just freezes completely after a few seconds. My friend tried connecting to his own stream on another computer on his LAN and he said it plays video perfectly so I dont understand whats going on, we both have high speed DSL so I am confused as to why this is happening......we tried lowering settings but it still happens to me.....
Please help me if you can I would appreciate it alot thanks
Streaming off TVTuner over HTTP it Freezes after few second
-
narcan
I'm suffering the same problem as you are.
I'm streaming over HTTP via a DSL line and after a few seconds it will just freeze up.
Interestingly I've noticed that the % of CPU the VLC player on the server drops from 50% to 5% as soon as the video freezes up, which is saying that it seems to be a problem on that end rather than the client end.
This looks to happen as soon as a slight bit of lag is encountered and is throwing a big spanner in the works.
It will operate fine over my LAN.
This is via HTTP and I've tried mixing up the options as far as codecs and containers go but nothing seems to make a signifigant difference.
Anyone got any ideas ??
I'm streaming over HTTP via a DSL line and after a few seconds it will just freeze up.
Interestingly I've noticed that the % of CPU the VLC player on the server drops from 50% to 5% as soon as the video freezes up, which is saying that it seems to be a problem on that end rather than the client end.
This looks to happen as soon as a slight bit of lag is encountered and is throwing a big spanner in the works.
It will operate fine over my LAN.
This is via HTTP and I've tried mixing up the options as far as codecs and containers go but nothing seems to make a signifigant difference.
Anyone got any ideas ??
I believe kla has a good point.
"Most residential services employ A (for Asymmetric) DSL in which traffic from the home (the "uplink") flows at a slower rate than traffic into the home (the "downlink"). Downlink speeds are typically 1.2 Mbps (Megabits/second), with uplink speeds ranging from 256 to 384 Kbps (Kilobits/second). "
We get spoiled by the really good downlink speed, rarely consider the uplink.
On VLC, if you open the message window (View -- Messages), you'll probably see complaints (warnings or errors) about the video. WEhat's happenning is that the HTTP cache gets filled up, however long that takes, then the movie starts to play. Unfortunately, once playing has begun the uplink isn't fast enough, so the video cache at the client doesn't get replenished as fast as it's used up.
"Most residential services employ A (for Asymmetric) DSL in which traffic from the home (the "uplink") flows at a slower rate than traffic into the home (the "downlink"). Downlink speeds are typically 1.2 Mbps (Megabits/second), with uplink speeds ranging from 256 to 384 Kbps (Kilobits/second). "
We get spoiled by the really good downlink speed, rarely consider the uplink.
On VLC, if you open the message window (View -- Messages), you'll probably see complaints (warnings or errors) about the video. WEhat's happenning is that the HTTP cache gets filled up, however long that takes, then the movie starts to play. Unfortunately, once playing has begun the uplink isn't fast enough, so the video cache at the client doesn't get replenished as fast as it's used up.
-
Guest
The uplink speed is 256k
While theoretically the link has enough capacity to handle the stream as I've got the video at 96k and sound at 32k , VideoLAN is no good in this situation.
I was expecting that if at some stage the stream had finished before the server could send more information then it would wait, buffer the stream and then start playing again. Much like any other form of steam you are custom to on the internet. What I don't expect is that VideoLAN will fall over and stop sending the stream.
I've tried switching to using mms with WMP instead of http with videolan. This seems to hold on a little longer but after coming against a 2 - 3 second period of lag the server screw up and stop sending anything.
Here is the output from the VLC client on the server
While theoretically the link has enough capacity to handle the stream as I've got the video at 96k and sound at 32k , VideoLAN is no good in this situation.
I was expecting that if at some stage the stream had finished before the server could send more information then it would wait, buffer the stream and then start playing again. Much like any other form of steam you are custom to on the internet. What I don't expect is that VideoLAN will fall over and stop sending the stream.
I've tried switching to using mms with WMP instead of http with videolan. This seems to hold on a little longer but after coming against a 2 - 3 second period of lag the server screw up and stop sending anything.
Here is the output from the VLC client on the server
[/quote]main debug: new connection (203.217.xxx.xxx)
main debug: connection closed(203.217.xxx.xxx)
ts_dvbpsi debug: processing PAT version 4
main debug: unselecting ES 0x22
main debug: unlocking module "packetizer_mpegvideo"
main debug: thread 11220 joined (src/input/input_dec.c:203)
main debug: killing decoder fourcc `mpgv', 1 PES in FIFO
main debug: removing an input
main debug: unlocking module "ffmpeg"
mux_asf debug: removing input
main debug: unselecting ES 0x21
main debug: unlocking module "mpeg_audio"
main debug: thread 10692 joined (src/input/input_dec.c:203)
main debug: killing decoder fourcc `mpga', 0 PES in FIFO
main debug: removing an input
main debug: unlocking module "ffmpeg"
mux_asf debug: removing input
main warning: no more input stream for this mux
main debug: no more selected ES
ts_dvbpsi debug: new program: 4
mpeg_system warning: first packet for PID 32 received by TS demux
ts_dvbpsi debug: processing PMT for program 4 version 4
ts_dvbpsi debug: new PID 0x22 stream type 0x2
ts_dvbpsi debug: new PID 0x21 stream type 0x4
main debug: ES 20 has unknown type
main debug: selecting video ES 22
main debug: selecting ES 0x22
main debug: looking for packetizer module
main debug: probing 29 candidates
main debug: using packetizer module "packetizer_mpegvideo"
main debug: thread 11076 (decoder) created at priority 0 (src/input/input_dec.c:161)
main debug: selecting audio ES 21
main debug: selecting ES 0x21
main debug: looking for packetizer module
main debug: probing 29 candidates
main debug: using packetizer module "mpeg_audio"
main debug: thread 11060 (decoder) created at priority 2 (src/input/input_dec.c:161)
mpeg_system warning: first packet for PID 34 received by TS demux
packetizer_mpegvideo debug: waiting for sequence start
packetizer_mpegvideo debug: Size 704x576 fps=25.000
mpeg_audio: MPGA channels:2 samplerate:48000 bitrate:256
main debug: adding a new input
stream_out_transcode debug: creating audio transcoding from fcc=`mpga' to fcc=`mp3 '
main debug: looking for encoder module
main debug: probing 12 candidates
ffmpeg debug: libavcodec already initialized
ffmpeg debug: found encoder MPEG Audio layer 1/2/3
main debug: using encoder module "ffmpeg"
stream_out_duplicate debug: duplicated a new stream codec=mpga (es=32 group=4)
main error: cannot add a new stream (unsuported while muxing for this format)
stream_out_duplicate debug: - failed for output 0
main error: cannot create packetizer output
main debug: adding a new input
stream_out_transcode debug: creating video transcoding from fcc=`mpgv' to fcc=`DIV3'
main debug: looking for encoder module
main debug: probing 12 candidates
ffmpeg debug: libavcodec already initialized
ffmpeg debug: found encoder MS MPEG-4 Video v3
main debug: using encoder module "ffmpeg"
main debug: unlocking module "ffmpeg"
main debug: looking for encoder module
main debug: probing 12 candidates
ffmpeg debug: libavcodec already initialized
ffmpeg debug: found encoder MS MPEG-4 Video v3
main debug: using encoder module "ffmpeg"
stream_out_duplicate debug: duplicated a new stream codec=DIV3 (es=33 group=4)
main error: cannot add a new stream (unsuported while muxing for this format)
stream_out_duplicate debug: - failed for output 0
stream_out_transcode error: cannot add this stream
main debug: unlocking module "ffmpeg"
main debug: connection closed(203.217.xxx.xxx)
main debug: new connection (203.217.xxx.xxx)
main debug: new connection (203.217.xxx.xxx)
main debug: connection closed(203.217.xxx.xxx)
-
Guest
Yes same problem
I'm working out of town and im trying to stream my favorite cable channel to my notebook at my hotelroom where I got a 1.5 Mbit ADSL featuring a 384 KBit upstream. Even if I set the video bitrate to as low as 128 KBit MP4 and the audio to 40 KBit Mono MP3, the VLC will stall after a few seconds. I think its tied to bandwidth spikes.
Upon taking a look at the VLC message window I see tons of "PTS out of range messages" continously pouring in. The problem is, unlike other media players, VLC never recovers from this still is thus is pretty much unusable for me at the time.
Upon taking a look at the VLC message window I see tons of "PTS out of range messages" continously pouring in. The problem is, unlike other media players, VLC never recovers from this still is thus is pretty much unusable for me at the time.
There is a strictness parameter to damp out the spikes, I believe, though I've never played with it.
This is if you are using Transcoding, using the mpeg CODECs:
Open Settings -- Preferences
Check Advanced options
Open Modules -- encoder -- ffmpeg
Down the list a ways (you'll have to scroll down) is a video bitrate tolerance. I expect the default of 0 means "don't care". Perhaps try setting it to, say, 64 kbps, see what happens.
(You may also need to increase the cache sizes)
(With luck, this response may draw one of the real mpeg jocks in
This is if you are using Transcoding, using the mpeg CODECs:
Open Settings -- Preferences
Check Advanced options
Open Modules -- encoder -- ffmpeg
Down the list a ways (you'll have to scroll down) is a video bitrate tolerance. I expect the default of 0 means "don't care". Perhaps try setting it to, say, 64 kbps, see what happens.
(You may also need to increase the cache sizes)
(With luck, this response may draw one of the real mpeg jocks in
-
Guest
Ok, tried this. Also tried the strict parameter that ffmpeg is supposed to support. No avail. Looks like VLC is simply not capable of streaming over anything but 10 MBit. Sigh.There is a strictness parameter to damp out the spikes, I believe, though I've never played with it.
This is if you are using Transcoding, using the mpeg CODECs:
Open Settings -- Preferences
Check Advanced options
Open Modules -- encoder -- ffmpeg
Down the list a ways (you'll have to scroll down) is a video bitrate tolerance. I expect the default of 0 means "don't care". Perhaps try setting it to, say, 64 kbps, see what happens.
(You may also need to increase the cache sizes)
(With luck, this response may draw one of the real mpeg jocks in
It definitely works at lower rates, just haven't played with it enough. At work I'm running 640x480 30 fps real-time MPEG4 CCTV over a T1 connection that's also carrying separate audio and data traffic. I've not had a chance/reason to work with the strictness parameters, but do believe that the basic rate controls work as expected.
Hello
I agree with markfm. I am using vlc very comfortablely at 192 Kbps video and 32 Kbps audio. Absolutely no issues. I have also tried with 128 kbps video, 256 kbps , 384 kbps and 512 kbps. I am using it even through satellite links. It works very well. I suggest that you can try vlc first with audio streaming with a disk file at 64 Kbps and qualify your link for 64 Kbps operation. After doing audio streaming successfully, you can try low resolution video at 128 Kbps or 192 Kbps. You can see the performance of vlc
I agree with markfm. I am using vlc very comfortablely at 192 Kbps video and 32 Kbps audio. Absolutely no issues. I have also tried with 128 kbps video, 256 kbps , 384 kbps and 512 kbps. I am using it even through satellite links. It works very well. I suggest that you can try vlc first with audio streaming with a disk file at 64 Kbps and qualify your link for 64 Kbps operation. After doing audio streaming successfully, you can try low resolution video at 128 Kbps or 192 Kbps. You can see the performance of vlc
I have three to four server in different network ( all are through satellite) . I have two server types in which i run vlc streaming. The first one is Windows 2003 with all patch updates with 1 GB memory and 40 GB IDE harddisk. I run three different streaming from three different classrooms at 192 Kbps Video( mp4v), 32 Kbps(mpga) audio. We use osprey card to receive the first stream for the other two i receive the UDP unicast from two different machines using a web cam and multicast them from the server. In short from the server i am multicasting three stream (a) one using Osprey card (b) other two using UDP unicast receive and multicast from server
In the other configuration i have windows 2000 Professional server with 512 MB and stream two streams with 192 Kbps Video(mp4v) and 32(mpga) Kbps audio.
All of them work over satellite links and there working well. However on XP OS we did not have good results. Compare to Osprey card the Web cam based instances are good. Don't use 0.7.2 with osprey card.
I hope i have given all necessary information for experimentaion.
In the other configuration i have windows 2000 Professional server with 512 MB and stream two streams with 192 Kbps Video(mp4v) and 32(mpga) Kbps audio.
All of them work over satellite links and there working well. However on XP OS we did not have good results. Compare to Osprey card the Web cam based instances are good. Don't use 0.7.2 with osprey card.
I hope i have given all necessary information for experimentaion.
-
justintbaker
- New Cone
- Posts: 7
- Joined: 17 Aug 2004 19:15
- Location: St. Louis, MO
Hello
I agree, VLC is very capable of lower bandwidth networks (DSL and even modems!), provided one chooses appropriately audio and video bandwidth (ab, vb) settings on the server end. I've found that the ab + vb should be substantially lower than what you have available for uploading. The best results I've had over DSL or cable were vb=96, scale=0.25-0.5, ab=64, channels=1 -- which is to say, not terribly good, but definitely watchable if you're simply fiending for a certain show.
If the server bandwidth is much higher than the client can handle, the client VLC can react with strange behavior -- video freezes, no audio, etc.
Good luck.
I agree, VLC is very capable of lower bandwidth networks (DSL and even modems!), provided one chooses appropriately audio and video bandwidth (ab, vb) settings on the server end. I've found that the ab + vb should be substantially lower than what you have available for uploading. The best results I've had over DSL or cable were vb=96, scale=0.25-0.5, ab=64, channels=1 -- which is to say, not terribly good, but definitely watchable if you're simply fiending for a certain show.
If the server bandwidth is much higher than the client can handle, the client VLC can react with strange behavior -- video freezes, no audio, etc.
Good luck.
--------------------------------------------------
I've got same result but other problem.
Hello All,
I also have a provider with a lower bandwith up then down. What i normally also recommend is to lower the Aspect Ratio when transcoding to 0.5. Screen looks sharper when you use 256kbps up for video.
Can somebody help me with this :
I also use the streaming wizard to convert a video stream from my dreambox (a dvb s receiver) and send it out to the internet with 256kbps video wmv2 and 128kbps audio mp3. This all works fine.
When I'm at home i want to change this settings to 2048 kbps video and 256 kpbs audio. I start up my laptop and start streaming. After a few moments (2 sec) my wmp freezes and is re buffering. It starts playing again, and after 2 seconds it say;s it can't play the stream.
When i change the settingsback to 256kbps video and 128 kbps audio it works fine.
I checked this allready:
-On the VLC server i c with DU meter that my upload stream is not more then 512 Kbps. So if i stay below 512 Kpbs for both vidoe and audio i have no problems. When i go higher i get freezes.
-I checked speeds between my laptop and VLC server, it should be possible to have 3200 Kbps , i checked it with a file transfer.
-I'm using mms://192.168.1.10:7080 so I don;t go trough my router over the internet and back.
Looks like a transfer limiter on the VLC client.
Hope somebody can help me also
Take Care,
Tom
I also have a provider with a lower bandwith up then down. What i normally also recommend is to lower the Aspect Ratio when transcoding to 0.5. Screen looks sharper when you use 256kbps up for video.
Can somebody help me with this :
I also use the streaming wizard to convert a video stream from my dreambox (a dvb s receiver) and send it out to the internet with 256kbps video wmv2 and 128kbps audio mp3. This all works fine.
When I'm at home i want to change this settings to 2048 kbps video and 256 kpbs audio. I start up my laptop and start streaming. After a few moments (2 sec) my wmp freezes and is re buffering. It starts playing again, and after 2 seconds it say;s it can't play the stream.
When i change the settingsback to 256kbps video and 128 kbps audio it works fine.
I checked this allready:
-On the VLC server i c with DU meter that my upload stream is not more then 512 Kbps. So if i stay below 512 Kpbs for both vidoe and audio i have no problems. When i go higher i get freezes.
-I checked speeds between my laptop and VLC server, it should be possible to have 3200 Kbps , i checked it with a file transfer.
-I'm using mms://192.168.1.10:7080 so I don;t go trough my router over the internet and back.
Looks like a transfer limiter on the VLC client.
Hope somebody can help me also
Take Care,
Tom
Nothing special for server settings:
:sout=#transcode{vcodec=mp4v,vb=128,scale=1,acodec=mpga,ab=64,channels=2}:duplicate{dst=std{access=udp,mux=ts,url=192.168.2.3:1234}}
Would be a low rate video/audio stream --
mp4v video at 128K, mpga audio at 64K
UDP output
MPEG transport stream
addressed (point-to-point), to a client at 192.168.2.3, port 1234
Since I don't have strictness set high, and you have to allow for packet overhead, I wouldn't try for much more than the above on a 256k line.
Note that depending on your source, you may really need/want to reformat the output to squeeze it through a narrow WAN pipe. You can set the transcode frames per second in the latest nightly builds, to rate-reduce (say, 25 fps input output at 10 fps), and there's a video size setting (say, knock down a native 640x480 to a 320x240).
:sout=#transcode{vcodec=mp4v,vb=128,scale=1,acodec=mpga,ab=64,channels=2}:duplicate{dst=std{access=udp,mux=ts,url=192.168.2.3:1234}}
Would be a low rate video/audio stream --
mp4v video at 128K, mpga audio at 64K
UDP output
MPEG transport stream
addressed (point-to-point), to a client at 192.168.2.3, port 1234
Since I don't have strictness set high, and you have to allow for packet overhead, I wouldn't try for much more than the above on a 256k line.
Note that depending on your source, you may really need/want to reformat the output to squeeze it through a narrow WAN pipe. You can set the transcode frames per second in the latest nightly builds, to rate-reduce (say, 25 fps input output at 10 fps), and there's a video size setting (say, knock down a native 640x480 to a 320x240).
-
justintbaker
- New Cone
- Posts: 7
- Joined: 17 Aug 2004 19:15
- Location: St. Louis, MO
Sorry, rajuptb, but I'm running streaming using vlc not vls -- and I'm in Windows, so I don't think I have a configuration file (vls.cfg). I'm also fairly new at this, so I could be wrong.
In any case, here are the commands I use to stream my TV card over high-bandwidth and low-bandwidth connections:
HIGH BANDWIDTH:
vlc -vv dshow:\\ :dshow-vdev="Hauppauge WinTV Capture" :dshow-adev="Creative Sound Blaster PCI" :sout=#transcode{vcodec=DIV3,vb=512,scale=1,acodec=mpga,ab=96,channels=1}:duplicate{dst=std{access=udp,mux=ts,url=192.168.2.2:1234}}
LOW BANDWIDTH
vlc -vv dshow:// :dshow-vdev="Hauppauge WinTV Capture" :dshow-adev="Creative Sound Blaster PCI" :sout=#transcode{vcodec=DIV3,vb=96,scale=.25,acodec=mpga,ab=64,channels=1}:duplicate{dst=std{access=udp,mux=ts,url=192.168.2.2:1234}}
In any case, here are the commands I use to stream my TV card over high-bandwidth and low-bandwidth connections:
HIGH BANDWIDTH:
vlc -vv dshow:\\ :dshow-vdev="Hauppauge WinTV Capture" :dshow-adev="Creative Sound Blaster PCI" :sout=#transcode{vcodec=DIV3,vb=512,scale=1,acodec=mpga,ab=96,channels=1}:duplicate{dst=std{access=udp,mux=ts,url=192.168.2.2:1234}}
LOW BANDWIDTH
vlc -vv dshow:// :dshow-vdev="Hauppauge WinTV Capture" :dshow-adev="Creative Sound Blaster PCI" :sout=#transcode{vcodec=DIV3,vb=96,scale=.25,acodec=mpga,ab=64,channels=1}:duplicate{dst=std{access=udp,mux=ts,url=192.168.2.2:1234}}
Return to “VLC stream-output (sout)”
Who is online
Users browsing this forum: Google [Bot] and 14 guests