Tested with MediaInfo 0.7.32 and x264 Rev. 1570 (updated in MeGUI 0.3.4.13 dev.):
for /L %r in (1,1,8) do x264.exe --ref %r -o 25p-ref%r.mkv 25p.avs
[--b-pyramid normal]
Reported ReFrame count: 2, 2, 3, 4, 5, 6, 7, 8
for /L %r in (1,1,8) do x264.exe --b-pyramid strict --ref %r -o 25p-ref%r.mkv 25p.avs
Reported ReFrame count: 3, 3, 3, 3, 4, 5, 6, 7
for /L %r in (1,1,8) do x264.exe --b-pyramid none --ref %r -o 25p-ref%r.mkv 25p.avs
Reported ReFrame count: 4, 4, 4, 4, 5, 6, 7, 8
The "minimum cap" is related to reporting the DPB, according to Dark_Shikari from the x264 development team. Reporting 1 reference frame less than requested for a strict b-pyramide, though, seems to have an own reason. It is not certain yet if the mistake is in x264 or MediaInfo.
Sorry - mixed up results:
normal = 4, 4, 4, 4, 5, 6, 7, 8
none = 2, 2, 3, 4, 5, 6, 7, 8
Please provide directly sample, so I could check and be sure we discuss about the same file.
About "ReFrames" field in MediaInfo, I provide the value of "max_num_ref_frames" in seq_parameter_set_data( ) of ISO/IEC 14496-10:
"max_num_ref_frames specifies the maximum number of short-term and long-term reference frames, complementary
reference field pairs, and non-paired reference fields that may be used by the decoding process for inter prediction of
any picture in the sequence. max_num_ref_frames also determines the size of the sliding window operation"
What's wrong with this? Which value do you expect?
"
x264 --b-pyramid normal --ref [1, 2, 3, 4, 5, 6, 7, 8]
ReFrames reported by MediaInfo: [4, 4, 4, 4, 5, 6, 7, 8] = OK, as expected (4 is minimum)
x264 --b-pyramid strict --ref [1, 2, 3, 4, 5, 6, 7, 8]
ReFrames reported by MediaInfo: [3, 3, 3, 3, 4, 5, 6, 7] = 1 ReFrame less than requested (but 3 is minimum: OK)
x264 --b-pyramid none --ref [1, 2, 3, 4, 5, 6, 7, 8]
ReFrames reported by MediaInfo: [2, 2, 3, 4, 5, 6, 7, 8] = OK, as expected
The question is, if MediaInfo reports too few reference frames in the case of strict b-frame pyramide, or if x264 creates too few. But Dark_Shikari was quite certain that x264 is correct ...
All I can say is that I provide the "max_num_ref_frames" field, nothing more... Maybe I am wrong somewhere, I don't know, please upload a file somewhere, I could make a trace of the file.
I see no reason to have an error between "max_num_ref_frames" field and what I display, but I am not sure that "max_num_ref_frames" is OK for B-pyramid frames.
Again, I am not a H.264 expert, I only display the content of a field from the H.264 header, nothing else, I don't know if it is correct or not in the case of pyramid frames. I am ready to change how it is working if you show me what I should change...
Sorry for the delay - the satellite connection was saturated, uploads kept failing...
http://www.ligh.de/tmp/25p-refx.7z
contains 3x8 MKV files with AVC encoded by x264 rev. 1570 + MediaInfo full logs.
I will try to get x264 developers here to help explaining which side might be wrong.
pengvado explained: "1 frame is reserved for reordering, and thus isn't a reference frame even though it is a slot in the DPB." - So you are probably right with your result, reporting the value regarding the DPB size.
So I am fine with closing this report as "not an error".
Tested 25p-ref8-strict.mkv:
0000009D seq_parameter_set (28 bytes)
0000009D Size: 1A (26)
0000009F nal_ref_idc: 3 (3)
0000009F nal_unit_type: 7 (7)
000000A0 profile_idc: 64 (100)
000000A1 constraints (1 bytes)
000000A1 constraint_set0_flag: No
000000A1 constraint_set1_flag: No
000000A1 constraint_set2_flag: No
000000A1 constraint_set3_flag: No
000000A1 reserved_zero_4bits: No
000000A1 reserved_zero_4bits: No
000000A1 reserved_zero_4bits: No
000000A1 reserved_zero_4bits: No
000000A2 level_idc: 15 (21)
000000A3 seq_parameter_set_id: 0 (0)
000000A3 high profile specific (1 bytes)
000000A3 chroma_format_idc: 1 (1) - 4:2:0
000000A3 bit_depth_luma_minus8: 0 (0)
000000A3 bit_depth_Colorimetry_minus8: 0 (0)
000000A3 qpprime_y_zero_transform_bypass_flag: No
000000A3 seq_scaling_matrix_present_flag: No
000000A4 log2_max_frame_num_minus4: 5 (5)
000000A4 pic_order_cnt_type: 0 (0)
000000A5 log2_max_pic_order_cnt_lsb_minus4: 6 (6)
000000A5 max_num_ref_frames: 7 (7)
000000A6 gaps_in_frame_num_value_allowed_flag: No
000000A7 pic_width_in_mbs_minus1: 1F (31)
000000A8 pic_height_in_map_units_minus1: 11 (17)
000000A8 frame_mbs_only_flag: Yes
000000A9 direct_8x8_inference_flag: Yes
000000A9 frame_cropping_flag: No
000000A9 vui_parameters_present_flag (13 bytes)
000000A9 vui_parameters_present_flag: Yes
000000A9 aspect_ratio_info_present_flag: No
000000A9 overscan_info_present_flag: No
000000A9 video_signal_type_present_flag: No
000000A9 chroma_loc_info_present_flag: No
000000A9 timing_info_present_flag (10 bytes)
000000A9 timing_info_present_flag: Yes
000000AA num_units_in_tick: 1 (1)
000000AE time_scale: 32 (50)
000000B2 fixed_frame_rate_flag: Yes
000000B2 nal_hrd_parameters_present_flag: No
000000B2 vcl_hrd_parameters_present_flag: No
000000B2 pic_struct_present_flag: No
000000B2 bitstream_restriction_flag (4 bytes)
000000B2 bitstream_restriction_flag: Yes
000000B2 motion_vectors_over_pic_boundaries_flagYes
000000B2 max_bytes_per_pic_denom: 0 (0)
000000B2 max_bits_per_mb_denom: 0 (0)
000000B3 log2_max_mv_length_horizontal: A (10)
000000B4 log2_max_mv_length_vertical: A (10)
000000B5 num_reorder_frames: 2 (2)
000000B5 max_dec_frame_buffering: 8 (8)
For me, the bug is not from MeidiaInfo, because the max_num_ref_frames field is actualy 7 in the file.
OK.
BTW, is it intersting to have the DPB value?
I am not an expert either... I'd recommend to talk directly about it in #x264 on FreeNode...
For me it is fine to know that there are reasons to report one ReFrame less (reserved for special features).