As far as I can tell the value can never go outside
the int16_t type.
And especially the cost of the initialization is
reduced quite a bit by making it smaller.
Overall decoding speedup not measurable though.
Signed-off-by: Reimar Döffinger <reimar.doeffin...@gmx.de>
---
libavcodec/h264_mb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 7feae57..dd406c7 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_mb.c
@@ -49,7 +49,7 @@ static inline int get_lowest_part_list_y(H264Context *h,
H264Picture *pic, int n
return FFMAX(0, bottom);
}
-static inline void get_lowest_part_y(H264Context *h, int refs[2][48], int n,
+static inline void get_lowest_part_y(H264Context *h, int16_t refs[2][48], int
n,
int height, int y_offset, int list0,
int list1, int *nrefs)
{
@@ -96,7 +96,7 @@ static void await_references(H264Context *h)
{
const int mb_xy = h->mb_xy;
const int mb_type = h->cur_pic.mb_type[mb_xy];
- int refs[2][48];
+ int16_t refs[2][48];
int nrefs[2] = { 0 };
int ref, list;
--
2.1.3
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
