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...@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
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel