Streaming in ASF format got max. 400k bits/s only

[richardkfk]

I am using a AMD XP2200+ machine running Windows XP SP1 and VLC081 with Directx9.0 as the streaming server.

My streaming source is the ASKEY TV capture card.


If I stream the TV video using MPEG TS encapsulation and UDP over my 100BaseT LAN, I can set the mp4v codec's streaming bit rate to either 256, 384, 512,768, 1024, 2048, 3072.

I can use another notebook running VLC081 client to receive the MPEG2 TS in a very good quality using bit rate 3072kbps.


However, if I change the encapsulation method to Microsoft's ASF format and stream it using "mmsh and address 127.0.0.1:1234",
and the DIV3 video codec, I can also change the bit rate bettween 256, 384, ....,1024.2048,3072.

Then, I use Windows Media Player10 from my notebook to watch the TV over the 100BaseT LAN. In high video bit rate (eg. 1024kbps), the WMP player will play the video for a while and then stop for a while (eg. buffering....) and again and again.

I do discover that the max. bit rate on the LAN (eg. using a protocol analyser) is only 400k bits/s, no matter u change DIV3 codec's bit rate to
384, 512, 768, 1024...).



Is it becasue the DIV3 codec does not support a bitrate >400kbps ?

Any suggestion that I can use a Video Bit rate >=1024kbps in ASF encapsulation ?

My main purpose is to use the MPLayer9 or 10 to watch the TV over the LAN.

thanks !

-ricky321-

[richardkfk]

I also found that u can stream the TV captured video in
either 256, 512, 1024, 2048, 3072kbps using ASF encapsulation
onto a file and stored it onto the harddisk without any problem.
Those stored ASF files can be played back using Windows Media Player 9 or 10 later.

The only problem is that the max. bit rate is limited to 400k bits/s when u stream the TV capture video in either 512,768,1024,2048 ,3072kbps (Transcoder : DIV3 for video, MP3 for audio)
onto the LAN using UDP multicast address (eg. 239.240.241.242).

Is this a bug and when will it be fixed ?

thanks !

-ricky321-


-ricky321-

[Schneider]

absolutely the same thing: 400 kbps limit and buffering buffering buffering when someone tries to get stream over lan

but i can easly watch my stream localy through wmp9 (asf)

[siddis]

same problem here, I would really like to know a solution to this

[richardkfk@hotmail.com]

I read some discussion in the Forum before, and he had the same 400kbps limit when he use the VLC server running on Microsoft Windows XP.

Then he run VLC in Linux Operating System and he discovers that it works perfect.

May be u can try Linux instead of Microsoft window in order to get rid of the 400kbps limit.

-ricky321-

[Steph]

I have the exact same problem, over http and mms. Over udp it's fine though, even at 5000kb/s. I've tried with the stable version and also nightly build from 2005-04-18.

Other people have that problem too: viewtopic.php?t=8374

Steph
http://steph.highvoltageweb.com

[And-U]

May be u can try Linux instead of Microsoft window in order to get rid of the 400kbps limit.
-ricky321-

Why someone should switch from one OS to another while its bug in VLC and its not problem of ASF encapsulation, because if you'll choose MPEG TS then you'll get same, probably in first seconds you'll have full bandwidth but not more. And its not problem only with capture cards, if you'll stream simple file then you'l get same problem. I think its a bug of some HTTP/MMSH routines in VLC.

Developers, please fix it!!!

[goelectric]

Anyone found the solution to this yet?

[the-savior]

for me http-streaming with div3 or xing and mp3 works correct even if i use bitrates higher than 512kbps... i stream with a debian sarge system and vlc 0.8.4-test1 and the latest ffmpeg. i can watch the stream with no problems using winxp and wmp 10 (ffdshow installed)...
for me the described problem only exists if i use wmv encoding (look at my thread viewtopic.php?t=13034).

[Guest]

sorry - i mean xvid

[Guest]

So it works fine in Linux?

I really hate that I cant stream video over 400kbit with vlc, its just so low that the video is really ugly to watch

[md]

This problem has been solved today in SVN trunk.