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).

Hi, Sorry for asking this problem. I know there is a lot example and tutorial about how to stream SDP to darwin, but I know cannot make it run. I am using VLC version 0.9.9 initialially, then tried 1.0.1, 1.0.2, and i read some ppl said there is problem with new version, so i even downgrade to 0.8....

Usually just too slow cpu/pc compared to encoding settings.

Did you also reverted those preference-changes you made earlier?

Hi, Could you try encoding with littlebit saner (imo) values and see if it makes a difference, for example: venc=x264{keyint=15,vbv-maxrate=160,vbv-bufsize=160} As now you define vbv-maxrate/buffsize something totally different what you tell you want the bitrate to be. Also playing with qcomp is not...

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).

Could you also try same with nightly trunk build?

[ Here is a new comparison: http://multimedialab.elis.ugent.be/users/dvdeurse/x264_vlc_comparison.jpg . The versions that I used: * x264 rev 1259 ( http://mirror01.x264.nl/x264/revision1259/x264.exe ) * VLC branch-20090914-0005 ( http://nightlies.videolan.org/build/win32/branch-20090914-0005/vlc-1....

please send unified diff against git master about that change to vlc-devel if you think it fixes your problem

You could try nightly-builds with more current libx264, it should be faster.

I've spent a lot of time reading the wiki about command line options. Add this below to your stream: --sout-ffmpeg-qmin=10 --sout-ffmpeg-rc-buffer-size=20000 --sout-ffmpeg-qmax=30 --sout-ffmpeg-qscale=1 --sout-ffmpeg-luma-elim-threshold=-4 --sout-ffmpeg-chroma-elim- threshold=7 I've using it in my ...

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...

No wonder it's choppy with those bitrates. Try something like this: "#transcode{vcodec=h264,venc=x264{no-cabac,level=12,vbv-maxrate=384,vbv-bufsize=1000,keyint=75,ref=3,bframes=0},width=320,height=240,acodec=mp4a,ab=128,vb=384}:rtp{sdp=file:///usr/local/movies/t.sdp,mp4a-latm}"

As mentioned on other thread, add --sout-x264-aud (or venc=x264{aud}) option on transcode-chain to get Access unit delimiters. For video part, vlc/x264 doesn't by default generate baseline profile or correct level (not sure what profile/level iphone supports, but baseline should work level 1.2 or so...

Keyint tell how many frames there are between keyframes, and on stremaing, it should be 1-2s to get reasonable fast start on viewing.

That should go on the client side right? Where would the venc=x264{keyinit=30} in my string? Something like this? :sout=#transcode{vcodec=h264,vb=100,fps=30,scale=0.5,acodec=mp3,ab=96,channels=2,samplerate=44100,venc=x264{keyint=30}}:std{access=udp,mux=ts,dst=mywebsite.com:8777} yes, like that. Als...

when streaming, you should try adding lower keyint value to x264, eg that should help on that flash syncing issue on wait also.

I can't seem to find an aq-mode setting. Are you really talking about Direct MV prediction mode?

No, AQ-mode,

Vlc did use old default on x264 aq-mode, but it should be fixed on next release (and next nightly build),
thou it doesn't really explain why it showed up only on windows side, and quality issue ain't on linux side.

Also because of that, I'm not at all sure if that was really the problem.

Ah, nice if you have been able to pinpoint something to affect on your issue. Could you try to either use aq-strenght or aq-mode (only one of them at the time) to see if only changing one of them helps.

You didn't get any different log-messages on windows? Also could you try with threads=1 in windows to see if it has any effect on quality (no thread, threads) and with psnr option on x264.

Did you do compile in linux against contrib-tree and it's x264, or did you have some external x264 (and if so, what version).

As on vlc <-> x264 it doesn't check if encoder is windows or linux, so in that sens there shouldn't be difference because of that.

Only difference there that I spot, is that vlc has different limit on sar-values than x264. Could you dump small amount of that ts-stream and upload it somewhere for me to test out?

Could you try nightly build master (trunk) builds on windows too. Currently vlc doesn't touch the qp if user hasn't requested qp-mode.

could you post also full output of -vvv on that transcode-case.