From patchwork Thu Jul 9 19:20:18 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Rheinhardt X-Patchwork-Id: 20934 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id 0B3F844B0C4 for ; Thu, 9 Jul 2020 22:20:48 +0300 (EEST) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id EC26268B5F4; Thu, 9 Jul 2020 22:20:47 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 91F6168B5D7 for ; Thu, 9 Jul 2020 22:20:40 +0300 (EEST) Received: by mail-wr1-f67.google.com with SMTP id f7so3577701wrw.1 for ; Thu, 09 Jul 2020 12:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=OndvtoTXzV3yb71OAlr5q2tht6lkO7X0KXR2RR6ScFM=; b=jKkpcWGvXAZZR06d+yGMkKG9wdsP82MU6kz1zAvlJjD0rDaP6UUdJCq5DGm/UaOJCq BOckQ3xT22Aqw+5PsbDpxcfJ8LZ7z5Vm/NgP2wFBY2UjPxmYWX7ZjP7Xms2teWRblUtc +rCbjjz0C2GqOaMwUYNG+VZkucgbF4dSsB943DEsjdnk0hv0Qg4VzXEllDTOIc7J+3OB dGSqFhqMJ0R0n3Z0C8m22LRph3DlZUiDPw8vkV38Wij6gHfGOk5RkqAkfm4YbRZXSG5/ 2EoEeNokP11ZNJxjcSbUNu6t70gu93gEJdGAWEysg2zrEuSM+kQE1fNYjtuC5P7/2T+y mKcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=OndvtoTXzV3yb71OAlr5q2tht6lkO7X0KXR2RR6ScFM=; b=qzHaR6slhJ0czpaNnCmO+QnNvdxK4G5cCICko3FuWztyIhQvPDthxVR+Ld3S9bL6Sh Qf+qWHD8NLA2a+2RoScN5vNjamkV6lBXPcmOrbefeCQNc7O2rDQMujY9KkbvxJqF6Fwn BXqNzt3N7BmnFiYJwqImRwI2eGJK9QSDJBWNgROaV5X9630gbPSOBGHLltUdWavz09zj V+QolukcALcJQxwqRaezROX8W+8oADUy6ScVvaZz7v94OXlsh1PYnt5725/K6KTDbHqB 7PSi0holItQNornfSEpjIDHNqnxvLT3zBswpHcB8VrVkI0u1rkROujrzqFKcDd+xFwD+ mosA== X-Gm-Message-State: AOAM530OpQFBHxQMgMT/ivS8lM1VdrKF4d0kdBt5RsqweIHb6/u6Kwyl E/QyH8WsYZ63OOCJPBWoU0a9K49M X-Google-Smtp-Source: ABdhPJx8Mp6iO8I6HKzhLl2Nns0lhdJ3AtorEyfTRNar31OZan57RjJeq/BHWHw5lKtlhvD9Q97TXA== X-Received: by 2002:a5d:4710:: with SMTP id y16mr67030972wrq.189.1594322439578; Thu, 09 Jul 2020 12:20:39 -0700 (PDT) Received: from sblaptop.fritz.box (ipbcc10296.dynamic.kabel-deutschland.de. [188.193.2.150]) by smtp.gmail.com with ESMTPSA id p25sm5485330wmg.39.2020.07.09.12.20.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2020 12:20:38 -0700 (PDT) From: Andreas Rheinhardt To: ffmpeg-devel@ffmpeg.org Date: Thu, 9 Jul 2020 21:20:18 +0200 Message-Id: <20200709192022.9412-5-andreas.rheinhardt@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200709103542.19909-1-andreas.rheinhardt@gmail.com> References: <20200709103542.19909-1-andreas.rheinhardt@gmail.com> MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 13/17] avformat/avc: Remove trailing zero bytes during annex B->mp4 conversion X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Cc: Andreas Rheinhardt Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" The annex B format of H.264 and HEVC allows there to be trailing zero bytes in byte stream NAL units; this means that there can be trailing zero bytes after the actual NAL units (besides start codes prepended to them). Samples in mp4 contain a sequence of length-prefixed NAL units and not byte stream NAL units; as such, the trailing zero bytes are actually not allowed. Therefore this commit strips them away. Two fate-tests needed to be updated: hevc-bsf-mp4toannexb because the HEVC parser does not properly check for four byte startcodes and instead assigns the leading zero to the end of the preceding packet (it is now stripped away) and lavf-fate-h264.mp4 because of an oddity of ff_h2645_extract_rbsp: It also assigns the first byte of a four-byte startcode to the preceding unit and this meant that the extradata (from the extract extradata bsf) has a trailing zero at the end which is now discarded. Signed-off-by: Andreas Rheinhardt --- libavformat/avc.c | 11 +++++++---- tests/fate/hevc.mak | 2 +- tests/ref/lavf-fate/h264.mp4 | 4 ++-- 3 files changed, 10 insertions(+), 7 deletions(-) diff --git a/libavformat/avc.c b/libavformat/avc.c index 17fcd1e73f..9f375ca992 100644 --- a/libavformat/avc.c +++ b/libavformat/avc.c @@ -92,7 +92,7 @@ const uint8_t *ff_avc_find_startcode(const uint8_t *p, const uint8_t *end){ const uint8_t *ff_avc_parse_nalu(const uint8_t **start, const uint8_t **nal_end, const uint8_t *end) { - const uint8_t *p = *start, *next; + const uint8_t *p = *start, *next, *end_temp; if (!p) return NULL; @@ -108,18 +108,21 @@ search_again: next = avc_find_startcode_internal(p, end); if (next) { - *nal_end = next > p && !next[-1] ? next - 1 : next; + end_temp = next; next += 3; } else { - *nal_end = end; + end_temp = end; } - if (*nal_end == p) { + while (end_temp > p && !end_temp[-1]) + end_temp--; + if (end_temp == p) { if (!next) return NULL; p = next; goto search_again; } *start = next; + *nal_end = end_temp; return p; } diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index 65c5a262e9..bd94cc6cff 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -251,7 +251,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 diff --git a/tests/ref/lavf-fate/h264.mp4 b/tests/ref/lavf-fate/h264.mp4 index bb52f45758..7a84b7a983 100644 --- a/tests/ref/lavf-fate/h264.mp4 +++ b/tests/ref/lavf-fate/h264.mp4 @@ -1,3 +1,3 @@ -6d158b25efe7391c803f6f61c7a80aa0 *tests/data/lavf-fate/lavf.h264.mp4 -547908 tests/data/lavf-fate/lavf.h264.mp4 +aaf8b3d9340ab1fdebced54ada2447d5 *tests/data/lavf-fate/lavf.h264.mp4 +547907 tests/data/lavf-fate/lavf.h264.mp4 tests/data/lavf-fate/lavf.h264.mp4 CRC=0x9da2c999