Extend parameter buffers to support Hantro G1 H.264

[pH5]

The Hantro G1 hardware H.264 decoder parses slices itself, with some assistance. It requires the parsed num_ref_idx_l[01]_default_active_minus1 and idr_pic_id syntax elements, as well as the size in bits of the dec_ref_pic_marking() syntax element and the total size in bits of the pic_order_cnt_lsb/delta_pic_order_cnt_bottom/delta_pic_order_cnt[0]/delta_pic_order_cnt[1] syntax elements.

These patches extend VAPictureParameterBufferH264 and VASliceParameterBufferH264 to allow supporting Hantro G1 decoders via libva-v4l2-request.

[CameronNemo]

Any word on whether this will be reviewed and/or merged?

[ndufresne]

Any word on whether this will be reviewed and/or merged?

With native support for V4L2 stateless codecs making it into GStreamer, and being present in Chrome with pending patches for ffmpeg, support for Hantro through VA API isn't a priority to me any-more. Our feeling is that VA as a way to regroup vendor under the same API is not longer an Intel priority (up to Intel to correct here). So as long as it fits AMD, I suspect patches like this one will remain ignored forever.

[CameronNemo]

@ndufresne thanks for the update. unfortunately firefox seems to depend on vaapi and cannot use v4l2 codecs directly. are there any non-libva options for firefox video acceleration?

[okias]

@ndufresne thanks for the update. unfortunately firefox seems to depend on vaapi and cannot use v4l2 codecs directly. are there any non-libva options for firefox video acceleration?

sadly, Firefox is in bad shape, so I assume Red Hat guys won't be contributing with another backend.

[ndufresne]

Then feel free to carry on, you'll have to take the V4L2 Request VA driver maintenance though, as it no longer has a maintainer.