[FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE

[Michael Niedermayer]

On Mon, Dec 10, 2018 at 06:23:54PM +0800, Linjie Fu wrote:
> Given that leading_zero_8bits can be included many times at the beginning
> of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
> in last frame and may lead to some warnings in parse_nal_units when s->flags
> is set to PARSER_FLAG_COMPLETE_FRAMES.
> 
> Modify to put all of the zeroes between two frames into the second frame.
> Modify the code to print the buf_size like in H264 and reduce the duplication.
> 
> Update the FATE checksum for fate-hevc-bsf-mp4toannexb:
> The ref output has redundant 0x00 at the end of the SUFFIX_SEI:
> { 50 01 84 31 00 19 39 77 d0 7b 3f bd 1e 09 38 9a 79 41
> c0 16 11 da 18 aa 0a db 2b 19 fa 47 3f 0f 67 4a 91 9c a1
> 12 72 67 d6 f0 8f 66 ee 95 f9 e2 b9 ba 23 9a e8 80 00 }
> 
> To verify the output of FATE:
> ffmpeg -i hevc-conformance/WPP_A_ericsson_MAIN10_2.bit -c copy -flags \
>         +bitexact hevc-mp4.mov
> ffmpeg -i hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc hevc.out
> 
> Signed-off-by: Linjie Fu <linjie.fu at intel.com>
> ---
> [v2]: Update FATE checksum.
> [v3]: Cope with more leading_zero_8bits cases.
> 
>  libavcodec/hevc_parser.c | 14 +++++++++-----
>  tests/fate/hevc.mak      |  2 +-
>  2 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> index 369d1338d0..62100ac654 100644
> --- a/libavcodec/hevc_parser.c
> +++ b/libavcodec/hevc_parser.c
> @@ -239,7 +239,7 @@ static int parse_nal_units(AVCodecParserContext *s, const uint8_t *buf,
>          }
>      }
>      /* didn't find a picture! */
> -    av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
> +    av_log(avctx, AV_LOG_ERROR, "missing picture in access unit with size %d\n", buf_size);
>      return -1;

this should ne in a seperate patch


>  }
>  
> @@ -267,8 +267,7 @@ static int hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
>          if ((nut >= HEVC_NAL_VPS && nut <= HEVC_NAL_EOB_NUT) || nut == HEVC_NAL_SEI_PREFIX ||
>              (nut >= 41 && nut <= 44) || (nut >= 48 && nut <= 55)) {
>              if (pc->frame_start_found) {
> -                pc->frame_start_found = 0;
> -                return i - 5;
> +                goto found;
>              }
>          } else if (nut <= HEVC_NAL_RASL_R ||
>                     (nut >= HEVC_NAL_BLA_W_LP && nut <= HEVC_NAL_CRA_NUT)) {
> @@ -277,14 +276,19 @@ static int hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
>                  if (!pc->frame_start_found) {
>                      pc->frame_start_found = 1;
>                  } else { // First slice of next frame found
> -                    pc->frame_start_found = 0;
> -                    return i - 5;
> +                    goto found;
>                  }
>              }
>          }
>      }
>  
>      return END_NOT_FOUND;
> +
> +found:
> +    pc->frame_start_found = 0;
> +    while (i - 6 >= 0 && !buf[i - 6])
> +        i--;
> +    return i - 5;

I think this is incorrect
a parser should produce the same output independant on how the input is cut
into bytsstream parts. But this would behave different depending on if the 
last 0 bytes are still in the current buffer

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20181226/571be963/attachment.sig>