提交 f964c409 编写于 作者: L Lucas Stach 提交者: Mauro Carvalho Chehab

[media] coda: clamp frame sequence counters to 16 bit

This is already done for one side of the comparison with the expectation
that the HW counter rolls over at the 16 bit boundary. This is true when
decoding a h.264 stream, but doesn't hold for at least MJPEG. As we don't
know the exact wrap-around point for this format just clamp the HW counter
to the same 16 bits. This should be enough to detect most of the errors
and saves us from doing different comparisons based on the decoded format.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
上级 adb8963f
......@@ -1902,7 +1902,14 @@ static void coda_finish_decode(struct coda_ctx *ctx)
meta = list_first_entry(&ctx->buffer_meta_list,
struct coda_buffer_meta, list);
list_del(&meta->list);
if (val != (meta->sequence & 0xffff)) {
/*
* Clamp counters to 16 bits for comparison, as the HW
* counter rolls over at this point for h.264. This
* may be different for other formats, but using 16 bits
* should be enough to detect most errors and saves us
* from doing different things based on the format.
*/
if ((val & 0xffff) != (meta->sequence & 0xffff)) {
v4l2_err(&dev->v4l2_dev,
"sequence number mismatch (%d(%d) != %d)\n",
val, ctx->sequence_offset,
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册