7oby
3rd February 2009, 14:17
[EDIT:] Codec issue during playback.
I'm actually using x264 already for a longer time and I'm not a noob, however today I feel this way:
I fired up MeGUI using the current and default
x264 r1093 - Skystrife's patched build
Unless my input width is a multiple of 8 the resulting H.264 video is entirely black.
I did some testing and these were the constraints regarding width and height:
width % 8 = 0
height % 2 = 0
I expected width % 4 = height % 2 = 0 since my input was in YV12 (4:2:0) colorspace. Searching the forum told me x264 should be fine with width % 4 = 0:
http://forum.doom9.org/showthread.php?t=101195
Here's the x264 command I've been using:
x264.exe --crf 21 --level 4.1 --ref 4 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --deblock
-1:-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 50000 --vbv-maxrate 50000 --me umh
--threads auto --thread-input --sar 31828:22375 --progress --no-psnr --no-ssim --output output.mp4 input.avs
Don't worry about the crazy "--sar". I also tried without.
I'm also aware that compression suffers when not using width % 16 = 0. However I prefer keeping the original width and height and just through some extra bitrate at it. Extending the image by a black border also isn't appealing to me: I don't like black borders during playback and also don't want black borders being compressed.
The ouput of x264 where it produced a black video stream looks fine to me:
avis [info]: 716x436 @ 25.00 fps (235603 frames)
x264 [warning]: width or height not divisible by 16 (716x436), compression will suffer.
x264 [info]: using SAR=31828/22375
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:2092 Avg QP:17.89 size: 25521
x264 [info]: slice P:85328 Avg QP:20.65 size: 9501
x264 [info]: slice B:148183 Avg QP:22.99 size: 2912
x264 [info]: consecutive B-frames: 2.2% 18.8% 62.7% 16.3%
x264 [info]: mb I I16..4: 6.3% 81.9% 11.8%
x264 [info]: mb P I16..4: 0.6% 6.1% 1.0% P16..4: 46.8% 19.8% 14.5% 0.0% 0.0% skip:11.3%
x264 [info]: mb B I16..4: 0.1% 0.5% 0.1% B16..8: 46.3% 1.6% 2.2% direct: 4.0% skip:45.1% L0:37.5% L1:52.8% BI: 9.8%
x264 [info]: 8x8 transform intra:79.7% inter:71.8%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: ref P L0 72.0% 13.6% 9.3% 5.2%
x264 [info]: ref B L0 84.9% 9.1% 6.0%
x264 [info]: kb/s:1099.8
encoded 235603 frames, 8.87 fps, 1099.90 kb/s
Is there really a width % 8 = 0 restriction? Or is this a result of some x264 parameters such as the --partitions or --8x8dct argument?
I'm actually using x264 already for a longer time and I'm not a noob, however today I feel this way:
I fired up MeGUI using the current and default
x264 r1093 - Skystrife's patched build
Unless my input width is a multiple of 8 the resulting H.264 video is entirely black.
I did some testing and these were the constraints regarding width and height:
width % 8 = 0
height % 2 = 0
I expected width % 4 = height % 2 = 0 since my input was in YV12 (4:2:0) colorspace. Searching the forum told me x264 should be fine with width % 4 = 0:
http://forum.doom9.org/showthread.php?t=101195
Here's the x264 command I've been using:
x264.exe --crf 21 --level 4.1 --ref 4 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --deblock
-1:-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 50000 --vbv-maxrate 50000 --me umh
--threads auto --thread-input --sar 31828:22375 --progress --no-psnr --no-ssim --output output.mp4 input.avs
Don't worry about the crazy "--sar". I also tried without.
I'm also aware that compression suffers when not using width % 16 = 0. However I prefer keeping the original width and height and just through some extra bitrate at it. Extending the image by a black border also isn't appealing to me: I don't like black borders during playback and also don't want black borders being compressed.
The ouput of x264 where it produced a black video stream looks fine to me:
avis [info]: 716x436 @ 25.00 fps (235603 frames)
x264 [warning]: width or height not divisible by 16 (716x436), compression will suffer.
x264 [info]: using SAR=31828/22375
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 1 (scale 25)
x264 [info]: slice I:2092 Avg QP:17.89 size: 25521
x264 [info]: slice P:85328 Avg QP:20.65 size: 9501
x264 [info]: slice B:148183 Avg QP:22.99 size: 2912
x264 [info]: consecutive B-frames: 2.2% 18.8% 62.7% 16.3%
x264 [info]: mb I I16..4: 6.3% 81.9% 11.8%
x264 [info]: mb P I16..4: 0.6% 6.1% 1.0% P16..4: 46.8% 19.8% 14.5% 0.0% 0.0% skip:11.3%
x264 [info]: mb B I16..4: 0.1% 0.5% 0.1% B16..8: 46.3% 1.6% 2.2% direct: 4.0% skip:45.1% L0:37.5% L1:52.8% BI: 9.8%
x264 [info]: 8x8 transform intra:79.7% inter:71.8%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: ref P L0 72.0% 13.6% 9.3% 5.2%
x264 [info]: ref B L0 84.9% 9.1% 6.0%
x264 [info]: kb/s:1099.8
encoded 235603 frames, 8.87 fps, 1099.90 kb/s
Is there really a width % 8 = 0 restriction? Or is this a result of some x264 parameters such as the --partitions or --8x8dct argument?