[FFmpeg-devel] [PATCH, v2] lavc/hevc_parser: add 4 bytes startcode condition and update FATE
Fu, Linjie
linjie.fu at intel.com
Wed Jan 9 05:18:45 EET 2019
> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Wednesday, January 9, 2019 10:51
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/hevc_parser: add 4 bytes
> startcode condition and update FATE
>
> > -----Original Message-----
> > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> Behalf
> > Of Mark Thompson
> > Sent: Monday, December 10, 2018 01:40
> > To: ffmpeg-devel at ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/hevc_parser: add 4 bytes
> > startcode condition and update FATE
> >
> > On 07/12/2018 11:33, Linjie Fu wrote:
> > > The startcode before VPS,SPS,PPS and the first NALU in an AU is 4 bytes.
> > > Blindly taking the startcode as 3 bytes will leave 0x00 in last packet
> > > and may lead to some warnings in parse_nal_units when s->flags is set to
> > > PARSER_FLAG_COMPLETE_FRAMES.
> > >
> > > Add 4 bytes startcode condition in hevc_find_frame_end.
> > > 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
> > >
> > > libavcodec/hevc_parser.c | 15 ++++++++++-----
> > > tests/fate/hevc.mak | 2 +-
> > > 2 files changed, 11 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> > > index 369d1338d0..aa216e3c8d 100644
> > > --- a/libavcodec/hevc_parser.c
> > > +++ b/libavcodec/hevc_parser.c
> > > @@ -32,6 +32,7 @@
> > > #include "parser.h"
> > >
> > > #define START_CODE 0x000001 ///< start_code_prefix_one_3bytes
> > > +#define START_CODE_4 0x00000001 ///< start_code_4bytes
> >
> > (There is no syntax element called "start_code_4bytes".)
> >
> > >
> > > #define IS_IRAP_NAL(nal) (nal->type >= 16 && nal->type <= 23)
> > > #define IS_IDR_NAL(nal) (nal->type == HEVC_NAL_IDR_W_RADL || nal-
> > >type == HEVC_NAL_IDR_N_LP)
> > > @@ -239,7 +240,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 +268,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 +277,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;
> > > + if (((pc->state64 >> 3 * 8) & 0xFFFFFFFF) == START_CODE_4)
> > > + return i - 6;
> > > + return i - 5;
> > > }
> >
> > Maybe? Special-casing four bytes doesn't make me feel good about this,
> > given that leading_zero_8bits can be included as many times as you like at
> > the beginning of a NAL unit.
> >
> > If there are a large number of zeroes between two frames, which packet
> do
> > you want them to end up in? This changes it from "all at the end of the first
> > frame" to "all except the last one at the end of the first frame", and it's not
> > immediately obvious to me why that would be the right choice. Why not,
> for
> > example, put all of the zeroes into the second frame?
> >
> > >
> >
> > Thanks,
> >
> > - Mark
>
> Hi,
>
> Does h264_find_frame_end() has the same issue if the leading_zero_8bits is
> included for more times?
> It seems to return i - 4 or i - 5 if the startcode is found, and could not cope
> with the more leading_zero_8bits situation?
>
> ---h264_parser.c
> Return i - (state & 5)
> ---
>
> And I'm considering to improve this in hevc_parser according to Michael's
> concern:
>
> 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
>
> ---hevc_parser.c
> found:
> pc->frame_start_found = 0;
> while ((i - 6 >= 0 && !buf[i - 6]) ||
> (i - 6 < 0 && pc->last_index + i - 6 >= 0 && !pc->buffer[pc->last_index + i
> - 6]))
pc->last_index should be pc->index, sorry for the mistake.
> i--;
> return i - 5;
> }
> ---
>
> Thanks,
> Linjie
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
More information about the ffmpeg-devel
mailing list