x264 development

[ak]

Originally posted by pogo stick
makeAVIS files are causing this error:

Opening video decoder: [vfw] Win32/VfW video codecs
Loading codec DLL: 'C:\Program Files\ffdshow\ffdshow.ax'
Loaded DLL driver C:\Program Files\ffdshow\ffdshow.ax at 10000000
ICDecompressGetFormat failed: Error -2

Probably old ffvfw.dll can do the trick, put it in mplayer codecs dir and edit codecs.conf. And maybe create fake avi with makeavis.exe from ffvfw bundle, not sure if it matters though.

I was trying .ax once and it didn't work for me either, although old ffvfw used to work, IIRC.

[yaz]

Originally posted by pogo stick
... ICDecompressGetFormat failed: Error -2 ... Fake avis are also giving error in VirtualDubMod and can not be decoded.
Opening in DShow and using AviSource() with VDub works.
It's strange. imho

1) its a colorspace misery. try
- destall all ffvfw (a time ago this whole makeavis business was made by ffvfw but now it's merged into ffdshow) and install ffdshow041012 (or newer:-) make sure makeavis is ticked!
- check whether vidc.avis is set in the registry (needed not by mencoder but by any ds player)
- when making fake avis do not(!) force any color ouput format (let mencoder convert it if needed). serve audio only if u got it in the source (mencoder will check it but why to make it risky? :-)
- try playing the fake avi. if everything went right it should play fine in ds (& mencoder will accept it)
if not ... try the 'workaround of the workaround'.
- find and old ffvfw (say, 031113 made me the trick).
- install
- copy ffvfw.dll (from the system dir) and libmplayer.dll (from the install dir) besides(!) mencoder.exe.
- change the codecs.conf's 'dll' item to ffvfw.dll
- uninstall ffvfw (& put back ffdshow)
i made avisynthing for months (until makeavi support was switched back) this way & worked fine.

2) some filters, filter-chains or functions (avis) may cause serving misery. if nothing works from the aboves try building your script filter by filter.

the bests
y

[yaz]

Originally posted by Sagittaire
x264 seem to have a very good potential ... sure! what it produces is really amazing. on some scenes it beats xvid (which is the etalon for me:-) definitely.
Originally posted by Sagittaire
... but visualy high block flicking for high quant encoding ... for playback i suggest vss decoder, as ffdshow makes some artifacting on fine texture and also on wide flat surfaces. maybe, that's what u experienced.
btw, how did u make that psnr tests ? & what is h264 ?

the bests
y

[pogo stick]

Thanks for helping, ak, yaz! :)
It seems like colorspace thing. I was forcing YV12 in makeAVIS. Without forcing it worked. With ffdshow-20041012-sse2 picture was flipped. So I used ffvfw-20031028 (the latest I could find) and it's OK. But there are few things that I don't understand:

Opening video decoder: [vfw] Win32/VfW video codecs
Loading codec DLL: 'codecs\ffvfw.dll'
Loaded DLL driver codecs\ffvfw.dll at 10000000
VDec: vo config request - 704 x 544 (preferred csp: Packed YUY2)
[PP] Using codec's postprocessing, max q = 9.
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
x264 [warning]: rc buffer size 0 too small
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
Selected video codec: [makeavis] vfm:vfw (FFdshow makeavis)

If my source (just cropped and trimmed MPEG2 file) is YV12 then why it shows YUY2? Why it doesn't find matching colorspace, use scale filter and use converter? And what is codec's postprocessing? Also warning about rc buffer is little bit confusing. I didn't change default ratecontrol setting and it's fixed quantizer first pass so as I understand it shouldn't matter. :confused:

[akupenguin]

I don't know why forcing YV12 didn't work, or why YUY2 is preferred.

It needs a "unscaled Planar YV12 -> Planar YV12 special converter" because x264 (or at least the mencoder wrapper for x264) supports I420 but not YV12. The only difference is the order of image planes in memory, so the "scaler" swaps a couple of pointers and all is good.

rc buffer is indeed irrelevant to constant qp mode. I just submitted a patch to remove that warning.

[yaz]

Originally posted by pogo stick
...With ffdshow-20041012-sse2 picture was flipped. So I used ffvfw-20031028 (the latest I could find) and it's OK ...
yep ... joke from ffdshow. sorry, i forgot to mention it. no problem, anyway. just put a flipvertical() at the end of your script & use ffdshow041012. (it's clean, dry & safe :-)
Originally posted by pogo stick
... If my source (just cropped and trimmed MPEG2 file) is YV12 then why ... :confused: so am i. it's spoken exactly the same way whatever input/output combination i've tried. don't bother, it doesn't hurt. it seems as if this mantra would be needed for proper operation of mencoder :-)))

the bests
y

ps celtic_druid kindly provided an update of mencoder. it's worth to try. x264 seems better than ever.

[pogo stick]

OK. Than colorspace changing is not a big problem. But is postprocessing seems strange. Is it how it should be?
Originally posted by yaz
celtic_druid kindly provided an update of mencoder. it's worth to try. x264 seems better than ever.
Great! Is there something new?

[pogo stick]

Originally posted by akupenguin
MEncoder itself doesn't support AVS. MakeAVIS doesn't work because MEncoder doesn't use VfW.
I wrote an AVS decoder program which I cross-compiled and run under Wine, but who knows, it might work under Windows too. AVS2YUV (http://students.washington.edu/lorenm/src/avisynth/avs2yuv/)
After installing Helix YV12 / I420 VFW codecs avs2yuv started to work without problems (no green video). But mencoder with avs2yuv doesn't work:

Reading from stdin...
success: format: 0 data: 0x0 - 0x0
total frames: 896
YUV4MPEG2 file format detected.
YUV4MPEG2 Video stream 0 size: display: 384x208, codec: 384x208
VIDEO: [YV12] 384x208 12bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:12 fourcc:0x32315659 size:384x208 fps:23.98 ftime:=0.0417
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 384 x 208 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
x264 [warning]: rc buffer size 0 too small
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==================================
Writing AVI header...
ODML: vprp aspect is 16384:8874.

Flushing video frames

Writing AVI index...
Fixing AVI header...
ODML: vprp aspect is 16384:8874.

Video stream: -1.#IO kbit/s (-2147483648 bps) size: 0 bytes 0.000 secs 0 frames
x264 [info]: analyse=0(0ms) encode=0(0ms) write=0(0ms) filter=0(0ms)
Output error: wrote only 77546 of 79872 bytes

I just thought that maybe something else is missing in my system.
"Reading from stdin..." in mencoder and "The outfile may be "-", meaning stdout" in avs2yuv.
What is std?

I am sorry that about talking too much about mencoder in x264 thread. But it is very connected now. And I fell much more comfortable encoding in mencoder then in virtualdub.

[ak]

Try adding -rawvideo on:w=<width>:h=<height>:yv12 to cmdline.

Yeah and 'std' means standard, afaik.

[akupenguin]

Originally posted by ak
Try adding -rawvideo on:w=<width>:h=<height>:yv12 to cmdline. That won't work. Or rather, it should display something, but not what you want: avs2yuv outputs yuv4mpeg (yv12 with headers), not raw yv12. Anyway, you can see that mencoder correctly identified the video, the problem is in the pipe.

Output error: wrote only 77546 of 79872 bytes Someone in the Avisynth under Linux (http://forum.doom9.org/showthread.php?s=&threadid=81793) thread had the same problem. I couldn't reproduce it. His workaround was to use fifos, but those don't exist in Windows.

[ak]

Oh boy, and was mixing them all the time. Going to rtfm.

[pogo stick]

Originally posted by ak
Try adding -rawvideo on:w=<width>:h=<height>:yv12 to cmdline.
I don't know what is it, but I really like how it looks!
It's like train of distorted video moving from left to right!
Not really useful, but fun! :)

[ak]

Originally posted by akupenguin
Anyway, you can see that mencoder correctly identified the video, the problem is in the pipe.

Someone in the Avisynth under Linux ("http://forum.doom9.org/showthread.php?s=&threadid=81793) thread had the same problem. I couldn't reproduce it. His workaround waas to use fifos, but those don't exist in Windows.
Yeah, something confuses mencoder in piped avs2yuv output, mpeg2enc as well for that matter. They give this on first frame:
<mencoder>: error reading frame bad header magic
<mpeg2enc>: Error reading frame header (0): codebad header magic!

Ffmpeg's yuv4mpegpipe works with both otoh, so does encoding using fifo.

[movmasty]

Originally posted by snacky
In any case, it's very frustrating - there is really no way to get reasonable quants, OR the bitrate you want, OR the constant quant you want,.... This completely rules out ffdshow for generating watchable x264-encoded clips, and imo it throws a big monkeywrench in the works even if all you want to do is to test some options, since the main determinant of quality/filesize/encoding time/decoding time is always going to be the number of absurdly underquantized macroblocks.
i set a min Q of 4 and ffds kept using 1,2,3....

and i found that gives me half the bitrate i set, so to have 600kb i have to set 1.200kb...

[hellfred]

Originally posted by movmasty
i set a min Q of 4 and ffds kept using 1,2,3....

and i found that gives me half the bitrate i set, so to have 600kb i have to set 1.200kb...
Just get yourself to use mencoder for encoding to x264. It is not that hard to compile it for yourself, and once set up, you can easily compile the very latest x264 and link to it.
Steps involved:
Dl and install mingw and msys packages from www.mingw.org.
(First msys and than mingw into /mingw of msys root directory)
Dl nasm source. Unpack it (e.g. in your MSYS home directory /home/<loginname>) and compile it in MSYS using
"/.configure && make && make install"
Dl and compile x264 source from www.videolan.org using a windows svn client from http://subversion.tigris.org/ and the command line given on the vlc html page.
"cd x264/build/cygwin && make"
Afterwards copy the libx264.a and x264.h to /mingw/lib and /mingw/inclode:
cp bin/libx264.a /mingw/lib ;cd ../..; cp x264.h /mingw/include
You may have to edit the x264.h file to include stdargs.h:
...
#define _X264_H 1
#include <stdarg.h> //<- Add this
#define X264_BUILD 0x000b
...

Now downlad mplayer cvs source from mplayerhq.hu.
Get yourself the daily CVS snapshot source from the download page
Unpack it in MSYS and change into it using
tar xfj MPlayer-current.tar.bz2
cd MPlayer-2004xxyy
where xxyy will be the month and date of the day you have downloaded MPlayer-current.tar.bz2.
./configure
At the end of the summary you can check that x264 is listed under Codecs in the section, which should happen automatically when you copied the x264.h and libx264.a file to the appropriate directoris.
Enabled optional drivers:
Codecs: libavcodec ... x264

Then just type
make && make install
and you are done.
From then on you can use the command lines in the mencoder + x264 thread as a start to experiment with the codec. If you just can't get over using VDubMod for filtering/editing the source, output to some lossless codec from VDubMod and use that as imput for mencoder.
Only drawback of MSYS that i found up to now is that man is missing, so you have to find youself an up to date html man page for learning the x264encopts on the net.

Hellfred

[ak]

Regarding pipes, I remembered there was something similar with another program,
so this one here should work: http://4nykey.nm.ru/tmp/

[akupenguin]

I managed to find a Windows box and reproduced the piping bug: It occurs whenever the frame contains a byte 0x1A. (Ascii name "substitute", treated as EOF by Windows.) However, the stream does not translate \n to \r\n, so it isn't just the normal textmode corruption.
ak's patch ( "setmode(fileno(yuv_out),_O_BINARY);" ) doesn't help. It fixes "avs2yuv foo.avs - > file", but not "avs2yuv foo.avs - | mplayer -". For that matter, it isn't just my program that fails; "cat foo.avi | mplayer -" also dies on Windows.
Still, fwiw, I have updated avs2yuv to use binmode stdout.

... I don't like systems where eof() returns true when you aren't at the end of the file, even in textmode. So until further notice, I will continue running avs2yuv under Wine, because it's better than Windows.

[Leak]

Originally posted by akupenguin
... I don't like systems where eof() returns true when you aren't at the end of the file, even in textmode. So until further notice, I will continue running avs2yuv under Wine, because it's better than Windows.

I have the nagging feeling that all this will suddenly start to work as soon as it's done in a Cygwin bash or zsh, as opposed to CMD.EXE...

np: Poto & Cabengo - Life In San Diego (Poto & Cabengo)

[ak]

Originally posted by akupenguin
ak's patch ( "setmode(fileno(yuv_out),_O_BINARY);" ) doesn't help. It fixes "avs2yuv foo.avs - > file", but not "avs2yuv foo.avs - | mplayer -". For that matter, it isn't just my program that fails; "cat foo.avi | mplayer -" also dies on Windows.
Not much from me, that was pretty much copy'n'paste excersise.

FWIW, now 'avs2yuv foo.avs - | mplayer -' works for me in both wine and windows (using cmd.exe that is).

[hellfred]

Originally posted by ak
Not much from me, that was pretty much copy'n'paste excersise.

FWIW, now 'avs2yuv foo.avs - | mplayer -' works for me in both wine and windows (using cmd.exe that is).
Thank you a lot, ak
If I find some time, I will test it (Win98 Command.com && MSYS rxvt or cmd.exe from ReactOS project). I am looking forward to see if it works.

Hellfred

[hellfred]

No good on Win98
Both using MSYS rxvt console and cmd from ReactOS project, avs2yuv does not work. First is end of dir command in cmd.exe and second is the output of rxvt.
10-31-2004 7:34p <DIR> MPlayer-20041020
11-01-2004 8:44p 6,233 avs2yuv.exe
11-01-2004 8:51p 47 test.avs
34 Files 43,015,199 bytes
20 Dirs 3,249,659,904 bytes free

D:\Stefan\msys\1.0\home\Stefan>avs2yuv.exe test.avs -
Unknown error! Error code: 0xc1

D:\Stefan\msys\1.0\home\Stefan>avs2yuv.exe test.avs - | ..\..\mplayer_x264\bin\m
player.exe -
Unknown error! Error code: 0xc1
File not found -- Error executing CreateProcess()!!


D:\Stefan\msys\1.0\home\Stefan>

D:\Stefan\msys\1.0\opt\mplayer_x264\bin>avs2yuv.exe test.avs - | mplayer.exe -
Unknown error! Error code: 0xc1
MPlayer dev-CVS-041023-16:21-3.3.3 (C) 2000-2004 MPlayer Team

CPU: Intel Pentium III Katmai/Pentium III Xeon Tanner (Family: 6, Stepping: 3)
Detected cache-line size is 32 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE

Reading config file /opt/mplayer_x264/etc/mplayer/mplayer.conf: No such file or
directory
Reading config file D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/config
Reading D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/codecs.conf: Can't open
'D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/codecs.conf': No such file or d
irectory
Reading /opt/mplayer_x264/etc/mplayer/codecs.conf: Can't open '/opt/mplayer_x264
/etc/mplayer/codecs.conf': No such file or directory
Using built-in default codecs.conf.
font: can't open file: D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/font/font
.desc
font: can't open file: /opt/mplayer_x264/share/mplayer/font/font.desc
Using Windows native timing
Can't open input config file D:/STEFAN/MSYS/1.0/OPT/MPLAYER_X264/BIN/mplayer/inp
ut.conf: No such file or directory
Can't open input config file /opt/mplayer_x264/etc/mplayer/input.conf: No such f
ile or directory
Falling back on default (hardcoded) input config

Playing -.
Reading from stdin...


Exiting... (End of file)

D:\Stefan\msys\1.0\opt\mplayer_x264\bin>

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ ls
avs2yuv.exe mplayer out.avi skript.sh test.avi
mencoder.exe mplayer.exe out.avi.bak sub_snow_q255.avi test.avs

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ avs2yuv.exe
sh: ./avs2yuv.exe: Permission denied

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ avs2yuv.exe test.avs
sh: ./avs2yuv.exe: Permission denied

Stefan@J5U7R1 /opt/mplayer_x264/bin
$ avs2yuv.exe test.avs - | ./mplayer -
sh: ./avs2yuv.exe: Permission denied
MPlayer dev-CVS-041023-16:21-3.3.3 (C) 2000-2004 MPlayer Team

CPU: Intel Pentium III Katmai/Pentium III Xeon Tanner (Family: 6, Stepping: 3)
Detected cache-line size is 32 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE

Reading config file /opt/mplayer_x264/etc/mplayer/mplayer.conf: No such file or directory
Reading config file D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/config
Reading D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/codecs.conf: Can't open 'D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/codecs.conf': No such file or directory
Reading /opt/mplayer_x264/etc/mplayer/codecs.conf: Can't open '/opt/mplayer_x264/etc/mplayer/codecs.conf': No such file or directory
Using built-in default codecs.conf.
Font D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/font/font.desc loaded successfully! (206 chars)
Using Windows native timing
Can't open input config file D:/STEFAN/MSYS/1.0/home/Stefan/mplayer/input.conf: No such file or directory
Can't open input config file /opt/mplayer_x264/etc/mplayer/input.conf: No such file or directory
Falling back on default (hardcoded) input config

Playing -.
Reading from stdin...


Exiting... (End of file)

Stefan@J5U7R1 /opt/mplayer_x264/bin
$

"Unknown error! Error code: 0xc1" and "sh: ./avs2yuv.exe: Permission denied"
Any idear what those mean? I will try your avs2yuv on some WinXP SP1 system soon, too.

Hellfred

[akupenguin]

Originally posted by hellfred
11-01-2004 8:44p 6,233 avs2yuv.exe I'm assuming you compiled that? None of my builds nor 4nykey's is that size.

Unknown error! Error code: 0xc1 I have no better idea what that is than you do.

sh: ./avs2yuv.exe: Permission denied That means that I packed the zipfile on Linux, where the exe, being a win32 binary, isn't executable. If unpacked on ntfs by a permission-aware unzip program, it will retain the non-executable status, which sh sees. I changed the zip to fix that, or you can chmod +x it.

[hellfred]

Originally posted by akupenguin
I'm assuming you compiled that? None of my builds nor 4nykey's is that size.

I have no better idea what that is than you do.

That means that I packed the zipfile on Linux, where the exe, being a win32 binary, isn't executable. If unpacked on ntfs by a permission-aware unzip program, it will retain the non-executable status, which sh sees. I changed the zip to fix that, or you can chmod +x it.
I have downladed that binary from 4nykey's side linked by ak. I will redownload it to see if it.

When doubleclicking the avs2auv on Win98, the OS will tell me that this is no win32 binary, and WinXP will tell me something about 16 Bit instructions. Sorry, as my OS is german, so are the messages, that i assume you will not understand therefore. So i did not copy & past them in here.

Msys tells me, that it can be executed:
Stefan@J5U7R1 /opt/mplayer_x264/bin
$ ls -l avs2yuv.exe
-rwxr-xr-x 1 Stefan unknown 6233 Nov 1 20:44 avs2yuv.exe

I will dl the executeable once more from 4nykey's side.

Hellfred

EDIT: Now i get an error message as the dll file AVISYNTH_C.DLL can not be found. I have latest AviSynth 2.5.5 installed and ffdshow 20041012 with all options checked. Where to get that file?

EDIT2: Found it in google and just downloading it.

EDIT3: Now it works, just a error in kernel32.dll at the end of playback.
AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00ad2780 SS=0167 ESP=017afb64 EBP=00ac38c0
ECX=00bd6b20 DS=0167 ESI=6fd30df0 FS=557f
EDX=00ac38c0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00bc0490 6fb169b2 6fd30df0 00ad2780 00bc0490 6fb26e5d 00ad2780 557f0167 00000000 6fac2e38 00ac38c0 bff9ab2b bff7b30e 00000000 00bc0490 00000004

[CruNcher]

akupenguin how far is b-frame decoding in libavcodec for H.264 by now ?
i get damaged output with the newest videolan vlc-0.8.0-win32-20041101
i used Weighted Prediction, B-frames and Cabac in this clip

http://cruncher.mufflastig.com/h264/libavcodec_h264_b-frame-problem.png

[ak]

Originally posted by hellfred
I have downladed that binary from 4nykey's side linked by ak.
These are one person, actually, I just use either of these nicks, when another is taken by someone else.

As for avs2yuv not being win32 binary, probably site's fault. 'Save as' most probably won't work, left click should do.

Regarding crash, no idea, it runs (and exits) smoothly on win2003, haven't tried it on any other machine.

[akupenguin]

Originally posted by CruNcher
akupenguin how far is b-frame decoding in libavcodec for H.264 by now ? Weighted prediction is not supported at all. (That probably caused the discolored blocks, but can't be related to the streaks.) CABAC should pose no problems. The only known issue with B-frames is that they are displayed out of order. But I'm open to any video clips that break decoding, if you want to send it to me.

[hellfred]

Originally posted by ak
These are one person, actually, I just use either of these nicks, when another is taken by someone else.

As for avs2yuv not being win32 binary, probably site's fault. 'Save as' most probably won't work, left click should do.

Regarding crash, no idea, it runs (and exits) smoothly on win2003, haven't tried it on any other machine.
avs2yuv does not work well on WinXP SP1, too. It is even worse. My testing script was just an
AVISource("C:\FUll\path\to\file.avi")
with three different avis containing MPEG4 encodes.
I could always open it in VDubMod easily, and in my DShow Player BSPlayer. But only the smallest (in terms of both resolution and file size) could be streamed to mplayer, giving me a error message ahead of mplayer displaying the video. Video playback started after clicking away the error message.
Is that due to the fact that i did not eleminate the audio track?

Hellfred

[akupenguin]

Originally posted by hellfred
Is that due to the fact that i did not eleminate the audio track?
avs2yuv completely ignores the audio track. that shouldn't be an issue.

[hellfred]

Originally posted by pogo stick
After installing Helix YV12 / I420 VFW codecs avs2yuv started to work without problems (no green video)...
Can you point me to a location where i can find this codec, please? Finding anything on helixcommunity.org is impossible, and google did not help either. Up to now i have tryed xvid and ffdshow for decode, but both are unstable. I know that once one programm that i installed came with it (RealAnime?) but i can not find it no more.
Hellfred

EDIT:
Found it here (http://forum.doom9.org/showthread.php?s=&threadid=56972) in the forum.

[hellfred]

Finally everything is next to working smooth with the latest build of avs2yuv on WinXP and Win98, as long as i only decode 500 frames (-frames 500). The first binary that I have downloaded from ak got truncated somewhere in the download process. Getting another one fixed that.
Then output was unstable on Win98 when decoding using XviD v1.1 alpha build, and failed using ffdshow configured for processing raw videos, but with helix vfw codec finally i get some frames. Although there is still a error message to click away, so that using avs2yuv in batchs/scripts is still impossible, as nobody is there to click away the error message e.g between two passes of a multipass encode or differnt encodes. :(
On WinXP I had to get rid of DivX v5.0.2, as the output was all green, and install Helix vfw codec. But again an error message makes it impossible to do unattained batch encodes. :(

On Win98 i get the error message mainly at the end of decoding:

AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00b85e40 SS=0167 ESP=016efb64 EBP=00ac4dc0
ECX=00bd6ba0 DS=0167 ESI=6fd30df0 FS=52bf
EDX=00ac4dc0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00ac488c 6fae4e52 6fd30df0 00b85e40 00ac488c 6fb26e78 00b85e40 52bf0167 00000000 6fac2e38 00ac4dc0 bff9ab2b bff7b30e 00000000 00ac488c 00000004

No matter if i tage the msys, cygwin or ReactOS cmd.exe console.

Just usingure, build in command.com i get it ahead of mplayer showing the video. Command.com is a little bit faster than the other three consoles.

AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00b85e40 SS=0167 ESP=016efb64 EBP=00ac4dc0
ECX=00bd6ba0 DS=0167 ESI=6fd30df0 FS=4437
EDX=00ac4dc0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00ac488c 6fae4e52 6fd30df0 00b85e40 00ac488c 6fb26e78 00b85e40 44370167 00000000 6fac2e38 00ac4dc0 bff9ab2b bff7b30e 00000000 00ac488c 00000004

Why a restriction of 500 frames? When i start piping, my Windows partition beginns getting filled rapidly, till after some 200MBs there is not enough space left and mplayer suddenly stops the playback. The Prompt reappears in the console in a new line.
I was wrong about the last one. It is like this:
First: I start the command
avs2yuv test.avs - | mplayer.exe -
Then and i hear that a lot of data is written to the harddrive, till c:\ has not a single byte of freee space left. This takes some seconds. Now I get the error message (probably writing to disk failed to to the lack of free space), click it away, and mplayer starts the playback of the frames that where decoded up untill the computer ran out of free space.
That is not what a pipe is supposed to do :mad:

This behavour is confirmed by the output of avs2yuv just ahead of / just after the error message popps up:
D:\Stefan\msys\1.0\opt\mplayer_x264\bin>avs2yuv.exe test.avs - | mplayer.exe -
test.avs
total frames: 10759
Output error: wrote only 213734 of 230400 bytes
The data are being writen to a file named "AJCKACDC" (command.com) or "CMDF001.TMP" (ReactOS cmd.exe) residing in c:\Windows\temp.
Any idea hot to fix this? Is there any information that i can provide for you to understand this bug? Or is there no way to implement something like a "real" pipe in Win9x that handles the information from one process to the other "on the fly"?

Hellfred

EDIT: Cygwin bash is somehow able to pipe the output without writing the data to disk ahead. Looks like the cygwin1.dll takes care of the simulation of the linux/unix kernel/OS quite well, but i have to pay for this with a heavy impact on performance. Like only half the frames are decoded and served per time unit.
And there still remains the problem of an error message at the end of decoding:
[code]AVS2YUV verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 015f:bff7b997.
Register:
EAX=00000000 CS=015f EIP=bff7b997 EFLGS=00000246
EBX=00b85e40 SS=0167 ESP=017afb64 EBP=00ac4dc0
ECX=00bd6ba0 DS=0167 ESI=6fd30df0 FS=4fb7
EDX=00ac4dc0 ES=0167 EDI=00000004 GS=0000
Bytes bei CS:EIP:
ff 76 04 e8 26 89 ff ff 5e c2 04 00 56 8b 74 24
Stapelwerte:
00ac488c 6fae4e52 6fd30df0 00b85e40 00ac488c 6fb26e78 00b85e40 4fb70167 00000000 6fac2e38 00ac4dc0 bff9ab2b bff7b30e 00000000 00ac488c 00000004[\code]

[Leak]

Originally posted by hellfred
Why a restriction of 500 frames? When i start piping, my Windows partition beginns getting filled rapidly, till after some 200MBs there is not enough space left and mplayer suddenly stops the playback. The Prompt reappears in the console in a new line.
I was wrong about the last one. It is like this:
First: I start the command
avs2yuv test.avs - | mplayer.exe -
Then and i hear that a lot of data is written to the harddrive, till c:\ has not a single byte of freee space left. This takes some seconds. Now I get the error message (probably writing to disk failed to to the lack of free space), click it away, and mplayer starts the playback of the frames that where decoded up untill the computer ran out of free space.
That is not what a pipe is supposed to do :mad:

Ah, but that's the way piping was/is implemented in DOS and Win9x/ME command interpreters - writing the output of one program to a temp file and feeding that to the next one in the pipe. You can't do anything about it, other than either upgrading to a newer windows or use a different shell, like Cygwin bash or zsh.

Cygwin bash is somehow able to pipe the output without writing the data to disk ahead. Looks like the cygwin1.dll takes care of the simulation of the linux/unix kernel/OS quite well, but i have to pay for this with a heavy impact on performance. Like only half the frames are decoded and served per time unit.

Of course - after all, both the encoder and decoder are now running at the same time, whereas before the decoder's output was dumped to a file which was read in again afterwards...

[hellfred]

Sorry for highjacking the x264 development thread
I have start a new thread (http://forum.doom9.org/showthread.php?s=&threadid=84852) in the AviSynth usage section of this forum. I wellcome akapenguin, ak and all the others to discuss avs2yuv usage and to help getting it working under win32 there.

Hellfred

[Tommy Carrot]

Apparently the underquantization bug in fixed quantizer mode has been fixed in ffdshow, it works flawlessly in Celtic_druid's latest build.

[celtic_druid]

http://celticdruid.no-ip.com/test/ ff_x264.2004.10.30 ones are the same was in my recent ffdshow builds, but with -march/mtune=Athlon-xp/pentium4. I guess that (ff_x264.dll) is what solved the problem so it should also work with the latest sourceforge builds.

[hellfred]

Here is a small feature request.
Is it possible to add a switch that will disable the output of the video frames? When doing a multi pass encode, the logfile is all what is needed to run the next pass. Discarding the frames can help when one has only limited disc space. This is done by several other codecs / encoders, too, e.g. Xvid and ffdshow.

Hellfrd

[akupenguin]

That feature doesn't belong in x264: it's not codec specific, and doesn't save any encode time (at least not unless I optimize CABAC for the case where we only care how many bits it would output.) Ask ffdshow to extend their discard 1st pass option to all codecs.

[hellfred]

In ffdshow one just has to uncheck "Store frames to AVI", and nothing is written to a file, no matter which codec you have chosen for encoding.
Actually the basic idea was to keep mencoder from writing the first pass to harddisk. On Linux one can use -o /dev/null and on win32 -o NUL: as a workaround. I have learned the later one from Leak after i have asked this question here.
So please spend your time on improving this great codec of yours. And thank you for the great work up to now.

Hellfred

[virus]

Here's what I got in the last days when trying to update or checkout the sources for x264 using SVN. It worked until a week or two ago.

$ svn co svn://svn.videolan.org/x264/trunk x264
svn: Berkeley DB error while opening 'nodes' table for filesystem /var/lib/svn/x264/db:
Cannot allocate memory

Same output for "svn status" or "svn update".
I've tried with some permutations of the above cmdline (x264-trunk and similar, following the hints on videolan.org) but I always get the same error. I've also tried a fresh checkout of the VLC sources from the same server and everything worked perfectly. What happened?

[Sirber]

yep, same here:

sirber@detrinux sirber $ svn co svn://svn.videolan.org/x264/trunk x264
svn: Berkeley DB error while opening 'nodes' table for filesystem /var/lib/svn/x264/db:
Cannot allocate memory

[hellfred]

Don't mind it being broken, as there are only very few modivications to the source code that can be tracked through the development mailing list via this link (http://www.via.ecp.fr/via/ml/x264-devel/).
Siber, don't you have a Athlon64. Have a look at the last mail of oktober (http://www.via.ecp.fr/via/ml/x264-devel/200410/msg00033.html) .

Hellfred

[Sirber]

No

Brand old AMD XP 2000+ :o

[Sagittaire]

Preview: very good test for x264

http://jfl1974.free.fr/Test/Comparatif/PSNRAverage.gif

http://jfl1974.free.fr/Test/Comparatif/PSNROverall.gif

[gotaserena]

I just tested revision 59 on two different encodes. The first went fine (TV capture, noisy), but the DVD backup I was making with bitrate set to double what qp_constant=22 said seg faulted with this error:

x264 [error]: Error: 2pass curve failed to converge
x264_encoder_open failed.

If I reduce the bitrate it encodes fine.

Anybody found some similar behaviour?

[akupenguin]

Try r60. It won't fix the error, but it will provide more information on what happened.

[gotaserena]

I'm recompiling mplayer and will begin encoding soon.

I'm also having these problems with some frames:

http://img120.exs.cx/img120/5152/sample-problem.th.png (http://img120.exs.cx/my.php?loc=img120&image=sample-problem.png)

qp_min=15:qp_max=45:nofullinter:cabac:keyint=250:subq=2
deblock:deblockalpha=2:frameref=5

[akupenguin]

To help with that I would need not just a snapshot, but a source clip and compressed clip that demonstrate the problem (preferable short clips. and the source need not be lossless, as long as it's what you actually gave to mencoder), along with the exact encoder command line.

[gotaserena]

Here's it aku (ankka?)

Source (http://s5.yousendit.com/d.aspx?id=2DD4C707B54AA8FE857CCF0B9A97EF82)

1-pass:
mencoder -mc 0 -noskip -skiplimit 0 -nosound -o /dev/null -vf scale=384:288 -ovc x264 -x264encopts pass=1:qp_constant=22:nofullinter:cabac:keyint=250:subq=2:deblock:deblockalpha=2:frameref=5 -of avi segment-day01.mpg

2-pass:
mencoder -mc 0 -noskip -skiplimit 0 -nosound -o segment-avc.avi -vf scale=384:288 -ovc x264 -x264encopts pass=2:bitrate=1168:qp_min=15:qp_max=45:nofullinter:cabac:keyint=250:subq=2:deblock:deblockalpha=2:frameref=5 -of avi segment-day01.mpg

Result (http://s5.yousendit.com/d.aspx?id=7AF861860CBE9528F8E0FA275357FEC2)

BTW, thanks for the revision. I saw that I foolishly had set qp_min too high to manage the bitrate I wanted. Still it's better to have a reminder than a core dump :D

[akupenguin]

I confirm the error, and notice that all the extraneous black rectangles are Skip macroblocks. Skip simply copies the block from the previous frame, and the motion vectors look reasonable. This leads me to believe that it's a bug in lavc's decoder rather than in x264.
But I'm happy to patch lavc too, so I'll see what I can do.

Sidenote: you'll get improved quality by using "-vf field=0,crop=684:284:12:2,hqdn3d=5,scale=368:288": As long as you're downscaling interlaced content, you keep more detail by dropping one field rather than blending them. And black borders are also bad.
(Your error happens to go away when I add the crop filter. Maybe lavc is erroneously replicating pixels from the edge of the frame?)

p.s.
Here's it aku (ankka?)aku:
悪 【あく】 (n) evil; wickedness;
悪戯 【いたずら(P); あくぎ】 (adj-na,n,vs) tease; prank; trick; practical joke; mischief
(no relation to either the magazine Aku Ankka nor Donald Duck.)

[gotaserena]

Hmm, sorry for not trying to decode the file in windows before complaining here. At least something was learnt. Thanks for all the help and sorry for the bad joke!

[akupenguin]

What codec would you use under windows? ffdshow uses lavc too, so it should have the same bugs. Unless you have a beta of Ateme?
Anyway, you did uncover a bug, and I will try to fix it.