The VideoLAN Forums

Upcoming 0.8.6 release has support for VP5/VP6 in .nsv. You can try it with a nightly build or wait a little longer for the final version to release..

It might help to switch to another video mode or disabling overlay. See my comments in:
viewtopic.php?t=28980

I am currently using VLC 0.8.5 and I have the latest FFdshow, ACFilter 1.11 and DivX 6.4 installed VLC uses internal codecs so FFdshow, ACFilter and DivX won't have an effect on things. No video or black output usually points to a driver/compatibility issue and has been reported in the forum before...

Always on top AND going fullscreen doesn't work and is a known issue:
http://trac.videolan.org/vlc/ticket/344

If it stops after 2 mins. it sounds like a liveliness (keep alive) issue. Similar issue existed with windows media rtsp: http://trac.videolan.org/vlc/ticket/329

try Waveout for audio instead of DirectX, that is known to "fix" the issue with SPDIF. You can find it in the Preferences, Audio, (select Advanced) Output Modules. Then save & restart.

On commandline/shortcut start with option: --high-priority. Or from the GUI you can go to Settings, Preferences, Advanced, there select increase priority of the process, Save and Close VLC & Restart.

Just a thought.. I had a similar problem when my video card cooler broke down and the card was overheating. Or when there was some other video application on the background.

This is problem still exists upto 0.8.6-test2a and is a known issue in trac:
https://trac.videolan.org/vlc/ticket/344

testKO.gxf reports an unusual start time which seems to confuse things, you'll see the VLC timecode/duration window have weird values then as well. See View, Messages for debug info: ffmpeg debug: - start time = 3600000000 ffmpeg debug: - duration = 1171040000 Profile.gxf and trailer.gxf have start ...

According to pengvado lavc indeed crashes with mbaff and non-mod32 so that is a ffmpeg bug/problem unfortunately.

ffmpeg warning: MBAFF + spatial direct mode is not implemented (h264@00B0EEF0) As far as I know this also occurs when the stream is encoded in interlaced mode with x264 (even encoded in temporal mode FFmpeg says spatial mode is not implemented so it doesn't seem to be able to distinguish this prope...

There was a suggestion in the other thread (something with keyboard/international settings) although that doesn't work for me. In the mean time I'm trying to write an alternative to use MSYS/MINGW environment (which is btw a lot faster to compile as well).

Most likely caused by the current cygwin problems. It seems to throw a lot of "cannot find" things caused by shell scripts not having proper end of line characters. See sticky thread:
viewtopic.php?t=27162

Cygwin compilation is severely broken. I vaguely remember your issue where I had to revert binutils package. That problem is described in the cygwin howto on the developers page and might be related: http://developers.videolan.org/vlc/cygwin-compile.txt NOTE: It is extremely important to DOWNGRADE b...

Revert GDB to a previous version, 20060706-2 is known to be broken (see the cygwin howto http://developers.videolan.org/vlc/cygwin-compile.txt). Also beware the current version of Cygwin has problems for compilation too so be very careful only to downgrade GDB and not anything else. See http://forum...

I also see a bug on the nightly build with the slider. When trying to select the first third of the movie the slider jumps about and cannot be accurately positioned (and sometimes disappears). This is a seperate slider problem and was an attempt to make the slider "click where you go" but...

It happens with the windows nightly too for me occasionally though I cannot reproduce it when I want to...

H.264 decoding takes a LOT of CPU and in most cases the system is just too slow.. VLC uses FFmpeg's H.264 decoder and that doesn't do multithreaded decoding for H.264 so having dual CPU (or Hyperthreading) won't help you. You can get a performance boost by turning off the deblocking loop filter: Set...

There is a problem for using Cygwin as a compilation environment for VLC, FFmpeg, x264 etc. with the latest version of packages (at least since 7 oct. 2006). VLC (svn 16959 but also later revisions) compile breaks at: misc/version.c:6: error: missing terminating " character misc/version.c:7: er...

The latest development version automatically tries shoutcast (protocol) if icecast fails (there is only support for streaming MP3 to shoutcast). Nightly builds as of 20060817 should have this option. The socket error in this case was caused by a mismatch in the protocol.

Shoutcast uses a different protocol than Icecast. Could you test and see if the following works with a nightly/development build (which should have protocol selection, icy for shoutcast servers and http for icecast which is default). :sout=#transcode{acodec=mp3,ab=128,channels=2}:std{access=shout{mp...

Yes transcoding in the nightly has some issues at the moment, try using this option in the commandline and please report back if this fixes it:

--no-stats

You need to specify a vbv-maxrate instead of quants. See my comment in "CBR mode in x264" post: viewtopic.php?t=21961

Leave out the qp, qp-min and qp-max values because those indeed will take precedence over specifiying a max bitrate, it takes whatever bitrate it needs to maintain quality. If you want something resembling CBR you can specify bitrate like this: vcodec=h264,venc=x264{vbv-maxrate=800,etc.},vb=800,etc....