The VideoLAN Forums

J-B has worked regarding this matter, and if you could test 1.0.3-rc version regarding this matter, it would be great (seems ok for me with quick test, but I don't really use windows or do encoding on windows side at all). I did a quick test (same parameters as discussed here before) and the qualit...

There have been people complaining about windows side quality on x264 before, and we're checking that possible crosscompile bug. But as VLC doesn't have that many windows developers, it takes littlebit time (and as 1.0.2 is coming out soon (Tm), it takes time too).

Any progress on this problem?

Is there anyone that can confirm these problems with the windows version of VLC 1.01?

I did also the test (i.e., same VLC parameters as described above) with the linux version of VLC (1.0.1). Surprisingly, the linux version does not have this problem: http://multimedialab.elis.ugent.be/users/dvdeurse/vlc_101_linux.jpg . Maybe something goes wrong during the cross-compilation to Windo...

Same result (i.e., bad quality) with the nightly trunk build (trunk-20090916-2205): http://multimedialab.elis.ugent.be/user ... _trunk.jpg

Did you use same parameters with vlc also eg #transcode{venc=x264{keyint=32,bframes=0,ref=1,aq-mode=0},vb=500} ? Yes I did: vlc.exe -vvv -Idummy --reset-config dshow:// :dshow-vdev="Osprey-5X0 Video Device 2" :dshow-adev="none" :dshow-size="768x432" :dshow-fps=25 :dsho...

Did you test that x264 stand-alone encode dated same as vlc 1.0.1 release? as x264 has fixed some bugs/got improvements meanwhile. So could you try nightly build trunk and compare it to current x264 stand-alone encoder instead. Here is a new comparison: http://multimedialab.elis.ugent.be/users/dvde...

I don't think that the right aq-mode setting solves this problem. Even after disabling aq-mode, I still get the problem mentioned in this thread. The configuration I've used is as follows: * VLC 1.0.1 and VLC 0.9.8i (both Windows versions) * capture stream from a direct show filter * transcode this ...