| Message ID | 20181210102354.924-1-linjie.fu@intel.com |
|---|---|
| State | Superseded |
| Headers | show |
> -----Original Message----- > From: Fu, Linjie > Sent: Monday, December 10, 2018 18:24 > To: ffmpeg-devel@ffmpeg.org > Cc: Fu, Linjie <linjie.fu@intel.com> > Subject: [PATCH,v3] lavc/hevc_parser: cope with more leading_zero_8bits > and update FATE > > 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@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; > } > > @@ -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; > } > > static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx, > diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak > index db3ea19340..ab8da53535 100644 > --- a/tests/fate/hevc.mak > +++ b/tests/fate/hevc.mak > @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER > MOV_DEMUXER HEVC_MP4TOANNEXB_BSF MOV_MUXER > fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov > fate-hevc-bsf-mp4toannexb: CMD = md5 -i > $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f > hevc > fate-hevc-bsf-mp4toannexb: CMP = oneline > -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9 > +fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0 > > fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i > $(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -sws_flags > bitexact > FATE_HEVC += fate-hevc-skiploopfilter > -- > 2.17.1 Ping?
> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf > Of Fu, Linjie > Sent: Tuesday, December 18, 2018 08:52 > To: FFmpeg development discussions and patches <ffmpeg- > devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope with more > leading_zero_8bits and update FATE > > > -----Original Message----- > > From: Fu, Linjie > > Sent: Monday, December 10, 2018 18:24 > > To: ffmpeg-devel@ffmpeg.org > > Cc: Fu, Linjie <linjie.fu@intel.com> > > Subject: [PATCH,v3] lavc/hevc_parser: cope with more leading_zero_8bits > > and update FATE > > > > 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@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; > > } > > > > @@ -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; > > } > > > > static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx, > > diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak > > index db3ea19340..ab8da53535 100644 > > --- a/tests/fate/hevc.mak > > +++ b/tests/fate/hevc.mak > > @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER > > MOV_DEMUXER HEVC_MP4TOANNEXB_BSF MOV_MUXER > > fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov > > fate-hevc-bsf-mp4toannexb: CMD = md5 -i > > $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f > > hevc > > fate-hevc-bsf-mp4toannexb: CMP = oneline > > -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9 > > +fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0 > > > > fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i > > $(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit - > sws_flags > > bitexact > > FATE_HEVC += fate-hevc-skiploopfilter > > -- > > 2.17.1 > Ping? Another ping. Any comments on this change in hevc_parser and fate? --- Thanks, Linjie
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@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 [...]
On Wed, Dec 26, 2018 at 12:42 AM Michael Niedermayer <michael@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@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
> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces@ffmpeg.org] On Behalf > Of Hendrik Leppkes > Sent: Wednesday, December 26, 2018 09:15 > To: FFmpeg development discussions and patches <ffmpeg- > devel@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@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@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
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; } @@ -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; } static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx, diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index db3ea19340..ab8da53535 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER MOV_DEMUXER HEVC_MP4TOANNEXB_BSF MOV_MUXER fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov fate-hevc-bsf-mp4toannexb: CMD = md5 -i $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc fate-hevc-bsf-mp4toannexb: CMP = oneline -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9 +fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0 fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i $(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -sws_flags bitexact FATE_HEVC += fate-hevc-skiploopfilter
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@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(-)