[Libva] keep Nalu start code in VASliceDataBufferType data

[Sreerenj]

Hi,


On 31.08.2016 05:31, Randy Li wrote:
>
>
> On 08/31/2016 09:52 AM, Xiang, Haihao wrote:
>> On Tue, 2016-08-30 at 08:59 +0800, Randy Li wrote:
>>> Hi all:
>>>    When I just doing the driver for us chip, we would request the
>>> Nalu
>>> header present in the data to be process. But I found the data be
>>> Rendered to with type VASliceDataBufferType is removed the Nalu start
>>> code. Is there any way to make the client send the data without
>>> remove
>>> the start code ? Thank you.
>>
>> Do you mean the start code prefix 0x000001?  It depends on the codec,
>> VA-API has this requirement for HEVC, but no for AVC.
>>
>> For AVC, I don't think the existing softwares using vaapi send the
>> prefix to driver, you have to workaround it in your driver. but if the
>> application is developed by yourself, you may send the prefix with
>> setting the right slice_data_offset, so other drivers can work well ,
>> with your application.
> I see thank you. I think the Intel could handle the offset. So I think 
> it could be regard as a bug for Gstreamer. I would report the Gstreamer.
>

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.



-- 
Thanks
Sree

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.