All of lore.kernel.org
 help / color / mirror / Atom feed
* keep Nalu start code in VASliceDataBufferType data
@ 2016-08-30  0:59 Randy Li
  2016-08-31  1:52 ` [Libva] " Xiang, Haihao
  0 siblings, 1 reply; 3+ messages in thread
From: Randy Li @ 2016-08-30  0:59 UTC (permalink / raw)
  To: libva-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
  Cc: intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW

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.

P.S Thank you for the Intel guys help, I decided not to use the DRM 
framework to implement the interface in kernel after I talked to the 
kernel upstream. But the request API would be used.
-- 
Randy Li
The third produce department

_______________________________________________
Libva mailing list
Libva@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libva

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Libva] keep Nalu start code in VASliceDataBufferType data
  2016-08-30  0:59 keep Nalu start code in VASliceDataBufferType data Randy Li
@ 2016-08-31  1:52 ` Xiang, Haihao
  2016-08-31  2:31   ` Randy Li
  0 siblings, 1 reply; 3+ messages in thread
From: Xiang, Haihao @ 2016-08-31  1:52 UTC (permalink / raw)
  To: randy.li@rock-chips.com, libva@lists.freedesktop.org
  Cc: intel-gfx@lists.freedesktop.org

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.

> 
> P.S Thank you for the Intel guys help, I decided not to use the DRM 
> framework to implement the interface in kernel after I talked to the 
> kernel upstream. But the request API would be used.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Libva] keep Nalu start code in VASliceDataBufferType data
  2016-08-31  1:52 ` [Libva] " Xiang, Haihao
@ 2016-08-31  2:31   ` Randy Li
  0 siblings, 0 replies; 3+ messages in thread
From: Randy Li @ 2016-08-31  2:31 UTC (permalink / raw)
  To: Xiang, Haihao, libva@lists.freedesktop.org
  Cc: intel-gfx@lists.freedesktop.org



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.


-- 
Randy Li
The third produce department

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-08-31  2:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-30  0:59 keep Nalu start code in VASliceDataBufferType data Randy Li
2016-08-31  1:52 ` [Libva] " Xiang, Haihao
2016-08-31  2:31   ` Randy Li

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.