Re: [FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Wednesday, December 26, 2018 09:15
> To: FFmpeg development discussions and patches de...@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
> 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
> > > ---
> > > [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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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
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
> > ---
> > [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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE
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
> ---
> [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
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Tuesday, December 18, 2018 08:52
> To: FFmpeg development discussions and patches de...@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
> > 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
> > ---
> > [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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
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
> 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
> ---
> [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?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [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
---
[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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
