[x264-devel] Why number of forward reference frames is limited to 2?
dj alek
dj_alek at mail.com
Wed Oct 1 15:03:47 CEST 2014
>> Hi!
>> Does anyone know the reason of hardcoded limit of RefPicList1 size?:
>> - b_ref_reorder[2];
>> - sps->vui.i_num_reorder_frames = param->i_bframe_pyramid ? 2 : param->i_bframe ? 1 : 0;
>> - h->frames.i_max_ref1 = X264_MIN(
>> h->sps->vui.i_num_reorder_frames, h->param.i_frame_reference );
>> - etc
>> Is the increase in size will not improve the encoding quality? I
>> mean, eg, redistribution of parameter i_frame_reference = 10 to
>> num_ref_l0 = 5 & num_ref_l1 = 5 instead of the current num_ref_l0 =
>> 8 & num_ref_l1 = 2 (to use 5 forward + 5 backward frames for
>> reference rather than 2 forward + 8 backward)?
>>
> There is no reason to set RefPicList1 size large because you will have
> at max 2 futures frames when using [one level] B-pyramid so there are
> nothing to put there more than this 2 frames.
Any-level B-pyramid allows B frames to serve as reference, it doesn't limit the number of reference frames (of any type: I, P or B), as I understand.
In x264 implementation you can see B-pyramid usage coexists with more than 2 backward reference frames.
Similarly, more than 2 forward frames can be allowed for schema to become symmetrical.
I mean possibility to use [0..max_num_ref_frames] forward references fair to [0..max_num_ref_frames] backward references for each coded frame.
E.g. with max_num_ref_frames = 8: some frames are coded using 6 backward + 2 forward references, some are coded using 2 backward + 6 forward, some are coded using 1 backward + 1 forward, etc - the most efficient number/direction of references is selected for each frame individually, but using equivalent rights/chances for backward and forward frames to be a reference.
More information about the x264-devel
mailing list