Log in

View Full Version : Minor Bug Report


jdobbs
17th July 2009, 23:22
Not sure if this is the correct way to report bugs... forgive me if not. I'm using r1181, but I believe this bug has been here a while -- I saw it in r1179 but didn't catch on.

It seems to be related to the "--threads" option and very small sources (his one is 6 frames). I'm running on a 4 core Phenom processor. When attempting to do a two pass encode with "--threads auto", the second pass fails because the .stats file is not populated with information. If, however, I change the option to "--threads 1", the .stats file is populated and the second pass continues correctly. I noticed the error because the same source in BD Rebuilder would work on a dual core system but failed on the quad.

If I run this command:"E:\BD_Rebuilder\tools\x264.exe" "E:\WORKING2\WORKFILES\VID_00074.AVS" --bitrate 1211 --level 4.1 --sar 32:27 --fps 30000/1001 --vbv-bufsize 14500 --keyint 24 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --vbv-maxrate 17500 --threads auto --thread-input --stats "E:\WORKING2\WORKFILES\VID_00074.AVS.MKV.stats" --pass 1 --output NUL it runs correctly without error but after completion the .stats files looks like this:#options: 720x480 fps=10000000/333667 cabac=1 ref=1 deblock=1:0:0 analyse=0x1:0 me=dia subme=2 psy_rd=0.0:0.0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=6 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=0 b_adapt=1 b_bias=0 direct=1 wpredb=1 keyint=24 keyint_min=1 scenecut=40 rc=cbr bitrate=1211 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 vbv_maxrate=17500 vbv_bufsize=14500 ip_ratio=1.10 pb_ratio=1.10 aq=1:1.00 and the second pass fails.

If however I run the exact same command with "--threads 1", this is the contents of the .stats file:#options: 720x480 fps=10000000/333667 cabac=1 ref=1 deblock=1:0:0 analyse=0x1:0 me=dia subme=2 psy_rd=0.0:0.0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=1 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=0 b_adapt=1 b_bias=0 direct=1 wpredb=1 keyint=24 keyint_min=1 scenecut=40 rc=cbr bitrate=1211 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 vbv_maxrate=17500 vbv_bufsize=14500 ip_ratio=1.10 pb_ratio=1.10 aq=1:1.00
in:0 out:0 type:I q:13.00 tex:248 mv:482 misc:4982 imb:1350 pmb:0 smb:0 d:-;
in:4 out:1 type:P q:12.01 tex:0 mv:0 misc:168 imb:0 pmb:0 smb:1350 d:-;
in:1 out:2 type:b q:12.99 tex:0 mv:0 misc:144 imb:0 pmb:0 smb:1350 d:-;
in:2 out:3 type:b q:12.99 tex:0 mv:0 misc:144 imb:0 pmb:0 smb:1350 d:-;
in:3 out:4 type:b q:12.99 tex:0 mv:0 misc:144 imb:0 pmb:0 smb:1350 d:-;
in:5 out:5 type:P q:11.99 tex:0 mv:0 misc:168 imb:0 pmb:0 smb:1350 d:-; and the second pass completes successfully. I know it's fairly trivial and it's easy enought to reencode 6 frames, but I thought I'd report it.

Dark Shikari
17th July 2009, 23:25
Yes, if the lookahead size is larger than the size of the input video, x264 may fail. This is a problem with the standalone executable, not the library, and has been a known bug for a very long time.

Patches welcome, though the proper way to fix this requires an API modification.

(And for what you mentioned to me via PM that you were doing, there is no reason ever to encode just 6 frames.)

jdobbs
18th July 2009, 03:03
Yes, if the lookahead size is larger than the size of the input video, x264 may fail. This is a problem with the standalone executable, not the library, and has been a known bug for a very long time.

Patches welcome, though the proper way to fix this requires an API modification.

(And for what you mentioned to me via PM that you were doing, there is no reason ever to encode just 6 frames.) Thanks. It's unrelated. This was during a backup encode of a full BD disc, and it bombed when I hit a certain small M2TS file. I thought I'd found a workaround by switching to CRF when it fails on a very small file. But on that one I seem to have gotten a zero length output -- I assume its the same.