GNOME Bugzilla – Bug 770683
Not start code and slice_data_offset for H.264(AVC) VASliceDataBufferType type data
Last modified: 2018-11-03 15:48:20 UTC
The Intel i915 VA-API doesn't require the start code for H.264(AVS) but the HEVC does, it would use the slice_data_offset to omit the start code prefix(0x000001). But some hardware video process do require the start code for AVS. The known device are those ARM chips from rockchips. It would be not strip the start code for AVS to work in all the devices.
(In reply to ayaka from comment #0) > The Intel i915 VA-API doesn't require the start code for H.264(AVS) but the > HEVC does, it would use the slice_data_offset to omit the start code > prefix(0x000001). But some hardware video process do require the start code > for AVS. The known device are those ARM chips from rockchips. > > It would be not strip the start code for AVS to work in all the devices. copy & pasting my reply from mailing list: https://lists.freedesktop.org/archives/libva/2016-September/004340.html It is right that VA spec requires start code prefix, but AFAIK vaapi-intel-driver can work even if middleware doesn't insert start code.. From gstreamer-vaapi side, we are not sending SC for both avc and hevc, and we use a single code path for both stream-formats (avc and avc_bytestream , hevc and hevc_bytestream). We can make it compliant with the spec , but more code change requires for non-bytestream format. I mean, we have to explicitly insert the SC prefix for non-bytestream formats of AVC and HEVC. BTW, H264 is AVC, not AVS :)
OK, you could assign this issue to me, I would like to submit patches in the future time.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/44.