[Mesa-dev] [st/omx/dec/h264] Handing negative POC

Namburu, Chandu-babu chandu at amd.com
Wed Nov 30 06:53:04 UTC 2016


Hi Ilia,

Thank you for the comments. Please find my response inline.

Regards,
Chandu
-----Original Message-----
From: ibmirkin at gmail.com [mailto:ibmirkin at gmail.com] On Behalf Of Ilia Mirkin
Sent: Tuesday, November 29, 2016 3:15 AM
To: Emil Velikov <emil.l.velikov at gmail.com>
Cc: Christian König <deathsimple at vodafone.de>; mesa-dev at lists.freedesktop.org; Namburu, Chandu-babu <chandu at amd.com>
Subject: Re: [Mesa-dev] [st/omx/dec/h264] Handing negative POC

On Mon, Nov 28, 2016 at 4:38 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hi all,
>
> On 24 November 2016 at 10:22, Christian König <deathsimple at vodafone.de> wrote:
>> Hi,
>>
>> patch is Reviewed-by: Christian König <christian.koenig at amd.com>.
>>
> Shouldn't we also change the h264.pic_order_cnt_[lm]sb also to signed ?
>
> How about field_order_cnt and field_order_cnt_list ?
> We seems to be having an odd mix of signed and unsigned for the latter two.

I had a similar question re using vl_rbsp_u, which returns unsigned.
However I think the situation here is that these are unsigned values, but math performed on them can generate negative numbers. I haven't looked super-carefully though.
[NCB] value returned from the bit -stream NAL is signed value. Negative POC is valid H264 concept to represent the frames that need to displayed prior to IDR frame. 
I will share the implementation of the vl_rbsp_s routine value shortly for review along with the changes of Emil's review comments.

>
> Thanks
> Emil
> P.S. Chandu-babu, please send future patches inline [1].
> [1] http://mesa3d.org/devinfo.html#submitting
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


More information about the mesa-dev mailing list