On 2019-05-15 12:09, Paul Kocialkowski wrote: > Hi, > > With the Rockchip stateless VPU driver in the works, we now have a > better idea of what the situation is like on platforms other than > Allwinner. This email shares my conclusions about the situation and how > we should update the MPEG-2, H.264 and H.265 controls accordingly. > > [...] > > - Clear split of controls and terminology > > Some codecs have explicit NAL units that are good fits to match as > controls: e.g. slice header, pps, sps. I think we should stick to the > bitstream element names for those. > > For H.264, that would suggest the following changes: > - renaming v4l2_ctrl_h264_decode_param to v4l2_ctrl_h264_slice_header; > - killing v4l2_ctrl_h264_decode_param and having the reference lists > where they belong, which seems to be slice_header; I have two more changes and/or clarifications that is needed for v4l2_ctrl_h264_scaling_matrix, the expected order of scaling_list elements needs to be defined and documented. In cedrus driver the expected order of elements is after the inverse scanning process as been applied. This is in the order the hardware expects and what both ffmpeg use internally and vaapi expects, allows for simple memcpy/sram write in both userspace and driver. The rockchip vpu h264 driver from chromeos was expecting elements in scaling list order and would apply the inverse zig-zag scan in driver. Side note: it would also wrongly apply zig-zag scan instead of field scan on field coded content. I propose a clarification that the scaling lists element order should be after the inverse scanning process as been applied, the order that cedrus, rockchip and vaapi expects. Secondly the order of the six scaling_list_8x8 lists is currently using "ffmpeg order" where Intra Y is in [0] and Inter Y in [3]. Table 7-2 in H.264 specification list them in following order (index 6-11): Intra Y, Inter Y, Intra Cb, Inter Cb, Intra Cr and Inter Cr. The 8x8 Cb/Cr lists should only be needed for 4:4:4 content. Rockchip was expecting Intra/Inter Y to be in [0] and [1], cedrus use list [0] and [3]. VA-API only seem to support Intra/Inter Y, ffmpeg vaapi hwaccel copies [0] and [3] into vaapi [0] and [1]. I propose a clarification that the 8x8 scaling lists use the same order as they are listed in Table 7-2, and that cedrus driver is changed to use 8x8 lists from [0] and [1] instead of [0] and [3]. Regards, Jonas > I'm up for preparing and submitting these control changes and updating > cedrus if they seem agreeable. > > What do you think? > > Cheers, > > Paul
