Doom10 Forum: Digital Video Discussion

Lately I started using tc-input for some of my encoding (e.g. Bakemonogatari). There are many scenes that are 10-60 frames apart like a slideshow so I wanted to make x264 rate control to be aware of the VFR (with scenes as low as ~0.1FPS).

And so I realized half of my encoded files are plagued with corrupted frames. I'm aware of a bug with timecode in 1806 but I don't think that is related to this issue.

My encoding setting is:

C:\x264-64\x264-1804-x64.exe --stdin y4m - --crf 13.5 --fullrange "on" --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --keyint 240 --min-keyint 24 --ref 16 --no-fast-pskip --bframes 6 --b-adapt 2 --b-pyramid normal --deblock -2:-2 --subme 10 --trellis 2 --psy-rd 0.6:0.0 --me umh --merange 32 --threads 1 --thread-input --vbv-maxrate 20000 --vbv-bufsize 20000 --qcomp 0.86 --aq-strength 0.18 --no-dct-decimate --psnr --ssim

While avisynth sometimes does spit out some crap frame (< 3% of encodings) but since I've started using x264 with timecode input I get significantly more broken encodes.

I'm reverting back to not giving x264 the timecode file and also removed the vbv limit as a workaround and see if it improves.

I've been trying to run the 64bit version of x264.

C:\x264-64\pipebuf.exe "C:\x264-64\avs2yuv.exe" -raw (input avs) - : "C:\x264-64\x264-1416-x64.exe" (setting) --output (output) --fps=24000/1001 - (resolution) : 4
I am experiencing very odd behavior on 2 out of 4 of my systems, which the avs2yuv process would stall (eats up a whole CPU core) after x264 finished encoding. That prevents me from batch encoding with the 64bit x264.

It works when I have a freshly installed system (All Windows 7). I couldn't pinpoint the programs, or even possibly windows updates that might have causes the problem.

Thank you.