[Libva] calculation of next marker for MPEG-4 streams for hw decode using VA

[anuj mittal]

Hello

I've a MPEG-4 stream that has the code 00 00 within slice data. I see
a slight distortion when I try to decode this using HWAccel VAAPI.
I've found that the slice size being fed to VA is wrong.

001aca0: 60c8 b7d4 d755 6eb6 66a0 c082 fff8 283a  `....Un.f.....(:
001acb0: a7f9 8a7f 8b6d 3c0a 0f2d 9765 b2c6 672a  .....m<..-.e..g*
001acc0: 1703 0000 d626 6159 f0c0 3bb4 402f fea0  .....&aY..;.@/..
001acd0: 875f d29f fb00 0001 b65a 5998 0ca7 864e  ._.......ZY....N
001ace0: 7393 5739 ce4a 5739 cfa5 c9e0 c9c9 9dce  s.W9.JW9........

The code in ff_h263_find_resync_marker (ituh263dec.c) in ffmpeg
libavcodec returns the position in slice where this code appears and
as a result, the slice size being sent to VAAPI is 90B instead of 91E.
Commenting this code would get rid of the error.

My question is:

1. Would this stream comply with the standard? I tried looking in the
standard but didn't find anything related to start code emulation
prevention. Does MPEG-4 standard allow start code to be present in the
slice data?
2. How should I deal with this?

I can see that resync_marker is 0 (resync not enabled) for this stream.

Does it make more sense checking specifically for the length of the
video packet start code based on vop_coding_type, vop_fcode_forward
and vop_fcode_backward parameters?

Thank you

Anuj