Problem: Transcoding VC1 > x264

[CruNcher]

ahh yeah sorry for dualcore it endsup the same tough hehe both 3 ofcourse it's not the same ;)

[lithiumus]

http://forum.doom9.org/showthread.php?t=134656
also trying to lower X264 automatic threading wich i think does core+1 to the actuall cores --threads = cores seemed to help avoiding this issue with VBV (ofcourse with a small slowdown but better then turning threading of completely)

@lithiums
i know you workaround that problem yourself but just for fun could you try to set threading i guess @ least for the 1st pass to the same amount of cores you have (manualy) and see if you still get those borked frames with the same vbv settings ? (also try once for both passes)

Thanks Cruncher, I'll give that a try. I wouldn't conclude that the workaround works 100% as I'll need to ensure that my HD-DVD to Blu-ray conversion will actually play properly on my BD Player and PS3. It's possible that the "lack" of VBV buffer may have other adverse effects...

[lithiumus]

So put 3 under threads? Not 2 for Core2Duo?

[CruNcher]

for dualcore 2 then --threads 2 :)

[qyqgpower]

this VBV issue would only take place when encoding the whole clip. if you encode the problem part separately, the issue may not be reproduced.
I've encountered same problem, and fixed the broken parts by reencode them separately.

[lithiumus]

this VBV issue would only take place when encoding the whole clip. if you encode the problem part separately, the issue may not be reproduced.
I've encountered same problem, and fixed the broken parts by reencode them separately.

Maybe a fluke, but regardless of how the clips I posted are encoded i.e. split up or the entire clip, the issue is reproduced. Which I guess makes it a good candidate for debugging purposes.

The entire trailer is 1.5 mins and I split it up to 5 second clips. Unless you are talking about isolating a 10-20 frame sequence that is less than a second, what use is that? Maybe if I just encoded those 5 frames in isolation the problem would not happen... but is that useful?

[Dark Shikari]

Maybe a fluke, but regardless of how, the clips I posted are encoded i.e. split up or the entire clip, the issue is reproduced. Which I guess makes it a good candidate for debugging purposes.It is. I've already sent it off to Gabriel, the author of the VBV code, for consideration.

[Dark Shikari]

Now that was a very subtle VBV problem, related to the fact that your frames were duplicates of each other (one frame takes loads of bits, the next takes zero, since its the same as the previous frame). This was confusing the hell out of VBV.

Fixed in latest revision.

[jefrey]

finally i've encoded my movie 3times again an again:D and the error appears allways on the same frame/timestamp.
what can prefere such damned thing?, that are 3 movies where that appears

[Ranguvar]

With r949?

[lithiumus]

Now that was a very subtle VBV problem, related to the fact that your frames were duplicates of each other (one frame takes loads of bits, the next takes zero, since its the same as the previous frame). This was confusing the hell out of VBV.

Fixed in latest revision.

Nice work! I reverified it with the new r949 build and it works a charm! Sounds like this would only affect Anime sources since they do have duplicate frames and most live action won't.

Thanks again!

[jefrey]

no i used the old one, 940 ill test later the new build

[qyqgpower]

It seems that DA have fixed the previous VBV issue in 949, but I still get random blocky pictures with 949 & 951

The bad news is that I couldn't reproduce the issue with same source (at least for re-encoding a few GOPs around the blocky point), so it's hard to tell whether this is a bug of x264 or my fault.

here's a sample, but I wonder if anyone could figure out things from this isolated sample. Anyway, I'm expecting some kind of advice.

http://www.mediafire.com/?hwmmpgc5pfd
command line:
--pass 2 --bitrate 4000 --stats ".stats" --level 4.1 --keyint 240 --min-keyint 24 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 38000 --me tesa --merange 32 --threads auto --thread-input --aq-mode 1 --progress --no-psnr --no-ssim --output "output" "input" --psy-rd 0:0 --sar 1:1

[CruNcher]

@qyqgpower
try this http://forum.doom9.org/showthread.php?p=1173808#post1173808 explained there maybe it helps you have nothing to lose (except some speed) :)