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

[Fu, Linjie]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Wednesday, December 26, 2018 09:15
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope with more
> leading_zero_8bits and update FATE
> 
> On Wed, Dec 26, 2018 at 12:42 AM Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> >
> > 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
> >
> 
> Isnt it the parsers job to do just this cutting, or correct badly cut packets?
> 
> - Hendrik

Paser will cache the bit stream in pc->buffer if END_NOT_FOUND in current buf.
I think Michael's concern was some 0 bytes were stored in pc->buffer, and this patch could 
only cope with the 0 bytes in current buf but leave those 0 bytes stored in pc->buffer.

If so,  is it  make sense to find all the leading 0 bytes in pc->buffer and change the index to cut 
correctly after finding the frame end?

---
Thanks,
Linjie