From patchwork Mon Jul 29 19:56:57 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Rheinhardt X-Patchwork-Id: 14130 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 B7D25448F4F for ; Mon, 29 Jul 2019 23:08:59 +0300 (EEST) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 939EF68A737; Mon, 29 Jul 2019 23:08:59 +0300 (EEST) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E045A680687 for ; Mon, 29 Jul 2019 23:08:53 +0300 (EEST) Received: by mail-wr1-f54.google.com with SMTP id n9so38121460wrr.4 for ; Mon, 29 Jul 2019 13:08:53 -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=REXdezDSxueGT7hGrh9RjdlUNO5UNiaSyXFQlkCEkBY=; b=Gco8m7uFQmnLgOB1z06fet/fkoteOJ8T707peHMOF5WNE+mAgh3HmDtj6rPcj2PezE cv2bfdaxJNEckWy/2VqPoRMARGB9QXK6xH+XBIwub5GqinezgWzozFWk72Sq04hVi3y1 9e0y2dFTJQATYRCP6tZ44buVKQ3Tn75peZY90rBAPQWHGDszaMexkjAbg1/MQZVrRSNl ZqL0hafm1sKjKdJfl04u+uWcQ4MpmT0CisxIE0JtsVNyLDAcSDcknXb5XDA8pyZHXhcB YuQo2PBw4PsjardQmhcvudQE/HTqvvKQgYFNH93cuc4O16whfodf1WhiQAcv5PnmU/E8 jqQg== 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=REXdezDSxueGT7hGrh9RjdlUNO5UNiaSyXFQlkCEkBY=; b=mYHYDxEXrvo8TeJnN3tDdhGqLcj7xE21UErLLNNuEqd+GEz0mN3Ne36uxfk9pbuYqk z9hDPO8d99RSdWxn56sbNxFeR2VD0jM9+vbHm0hUcN9N7aG1LC2/2pW9f3CD19sCy7iJ KEiDOEsCl+kU5d8smC8a5Gpfbw7C6KOhm2geR2NkgKlqX2sxL3prMEzv5yT1HXznd/NM fMEmDFqOJZ9JMN9XBC29clYA6e2fOtlyAgxBci3a/InU+e4v7icIP9w6+esGXyaGCdHg j7XRO7fjDJAap1wUE0RCq0/vpqYo6qI6cDnzRYiyWbnUcTqq976venWEhxb1PA4LT6vN Pp5w== X-Gm-Message-State: APjAAAUkfJbh7jMJp3DoVeR+D8N9Y/g1T3f8tH0iUBn6qGRDQQib527w n0vN2jmPP3FtfZrTFk5mdX/hj4H7 X-Google-Smtp-Source: APXvYqzZLyx40vQfjLqhnL0fBu1/EjONMvTCpCxg7XM2SUdKPorARWeVRAFiAxY41HgwEf5U/NEn3g== X-Received: by 2002:a5d:438e:: with SMTP id i14mr118505760wrq.122.1564430620680; Mon, 29 Jul 2019 13:03:40 -0700 (PDT) Received: from localhost.localdomain (ipbcc08b8f.dynamic.kabel-deutschland.de. [188.192.139.143]) by smtp.gmail.com with ESMTPSA id t24sm56602211wmj.14.2019.07.29.13.03.39 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 29 Jul 2019 13:03:40 -0700 (PDT) From: Andreas Rheinhardt To: ffmpeg-devel@ffmpeg.org Date: Mon, 29 Jul 2019 21:56:57 +0200 Message-Id: <20190729195658.56078-6-andreas.rheinhardt@gmail.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190729195658.56078-1-andreas.rheinhardt@gmail.com> References: <20190729195658.56078-1-andreas.rheinhardt@gmail.com> MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 6/7] cbs_mpeg2: Remove zero byte stuffing 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" Remove superfluous trailing zeros from slices. Because MPEG-2 slices can end with zero bits a safe number of trailing zero bits is always kept. More explicitly, 6 + max{f_code[i][1] - 1, i = 0,1, f_code[i][1] != 0xf} is an upper bound for the number of possible trailing zeros that are part of the slice. Here f_code[i][1] is the relevant value of the picture coding extension the slice belongs to and the maximum of the empty set is zero. It is this number of trailing zero bits that is actually kept. That this is really an upper bound can be seen as follows: a) Every slice actually ends with a macroblock. b) If the last macroblock of a slice ends with a block(i) structure with pattern_code[i] != 0, then the slice ends with an "End of block" VLC code (namely the "End of block" code of the last block with pattern_code[i] != 0). These codes are 10 and 0110, so that in this case there is exactly one trailing zero bit. c) Otherwise, all pattern_code[i] are zero. In this case, if macroblock_pattern is set for the last macroblock of the slice, then by the definition of pattern_code[i] in 6.3.17.4 cbp (derived according to table B.9) must be zero and also the coded_block_pattern_1/2 (if existing) must consist of zeros alone. The value zero for cbp is coded by 0000 0000 1 so that the maximum number of trailing zeros in this case is the length of coded_block_pattern_1/2 which have a length of two resp. six bits. So six trailing zero bits at most. d) Otherwise, if the slice actually ends with the marker bit of the last macroblock, then there are certainly no trailing zero bits at all. e) Otherwise, if the slice ends with a motion_vectors(s) structure (with s = 0 or 1 -- it doesn't matter which one), then it ends with a motion_vector(r,s) (r, s = 0, 1 -- it doesn't matter) structure. This structure ends with motion_code[r][s][1] (always existing) potentially followed by motion_residual[r][s][1] and dmvector[1]. If dmvector[1] exists, and contains a bit different from 0, there is at most one trailing zero bit; if dmvector[1] consists of zeros alone, its length is one according to B.11. motion_residual[r][s][1] (if it exists) has a length of f_code[s][1] - 1 bits and can consist of zero bits alone. Given that the value 0xf for f_code indicates that there is no motion vector of the mentioned type, the length of motion_residual[r][s][1] is bounded by max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf}. The motion_code[r][s][1] can end with at most five zero bits (see B.10) and always contains a bit set to one, so that in this case there are at most 5 + max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf} + 1 zero trailing bits. f) Otherwise, if the last macroblock of the slice ends with a quantiser_scale_code, then there are at most four trailing zero bits, because quantiser_scale_code has a length of five bits and must not attain the value zero. g) Otherwise, the last macroblock ends with the macroblock_modes syntax structure. The potentially existing dct_type at the end might be a zero bit; the frame/field_motion_type isn't present here, because otherwise we would have a motion_vectors(i) (i = 0 or 1 or both) syntax structure, so that e) (or b)-d)) would have applied. spatial_temporal_weight_code might entirely consist of two zero bits. The macroblock_type VLC code always contains a 1 bit and ends with two zero bits at most (see B.2-B.8 for this), so we have maximally 2+2+1 trailing zero bits. The fate test cbs-mpeg2-sony-ct3 had to be adapted because the input file contains trailing zeros that were stripped away; the filesize is reduced from 135 KB to 117 KB. Of course, decoding the smaller output still produces the same frames. Most of these savings happen in between slices rather than after the last slice: The chomp bitstream filter can only reduce the filesize by 50 bytes. Signed-off-by: Andreas Rheinhardt --- The fate test result for cbs-mpeg2-sony-ct3 had to be modified compared to the last patch because the sample ends with a sequence_end_code that is preceded by several zero bytes. The earlier code thought that the slice ended at the end of the packet (i.e. at the end of the sequence_end_code) and therefore did not strip any of these zero bytes between the last slice and the sequence_start_code away. The now code does this. libavcodec/cbs_mpeg2.c | 30 ++++++++++++++++++++++++++++-- tests/ref/fate/cbs-mpeg2-sony-ct3 | 2 +- 2 files changed, 29 insertions(+), 3 deletions(-) diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c index 596e9677b7..559793dc98 100644 --- a/libavcodec/cbs_mpeg2.c +++ b/libavcodec/cbs_mpeg2.c @@ -170,7 +170,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext *ctx, CodedBitstreamUnitType unit_type; uint32_t start_code = -1; size_t unit_size; - int err, i, final = 0; + int err, i, final = 0, max_trailing_bits = 15; start = avpriv_find_start_code(frag->data, frag->data + frag->data_size, &start_code); @@ -199,7 +199,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext *ctx, // the end of fragment->data). if (start_code >> 8 == 0x01) { // Unit runs from start to the beginning of the start code - // pointed to by end (including any padding zeroes). + // pointed to by end (preliminarily including any padding zeroes). unit_size = (end - 4) - start; } else { // We didn't find a start code, so this is the final unit. @@ -207,6 +207,32 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext *ctx, final = 1; } + if (unit_type == MPEG2_START_EXTENSION && unit_size >= 4 && + start[1] >> 4 == MPEG2_EXTENSION_PICTURE_CODING) { + // The values f_code[0][1], f_code[1][1] are used to derive + // an upper bound for the number of trailing zero bits. + // 6 + max{f_code[i][1] - 1, i = 0,1, f_code[i][1] != 0xf} is + // an upper bound. An f_code value of 0xf means that there is + // no motion vector of the respective type. f_code values 10..14 + // are reserved and 0 is forbidden. In these cases, no attempt + // to strip trailing zeroes is made. +#define BOUND(f_code) \ + ((f_code) == 0xf ? 0 : (f_code) >= 10 || !(f_code) ? 9 : (f_code) - 1) + max_trailing_bits = 6 + FFMAX(BOUND(start[2] >> 4), + BOUND(start[3] >> 4)); + } + + if (MPEG2_START_IS_SLICE(unit_type) && max_trailing_bits < 15) { + const uint8_t *tmp = start + unit_size - 1; + + while (tmp > start && *tmp == 0) + tmp--; + av_assert0(*tmp); + + unit_size = FFMIN(unit_size, tmp + 1 - start + max_trailing_bits / 8 + + (ff_ctz(*tmp) < max_trailing_bits % 8)); + } + err = ff_cbs_insert_unit_data(ctx, frag, i, unit_type, (uint8_t*)start, unit_size, frag->data_ref); if (err < 0) diff --git a/tests/ref/fate/cbs-mpeg2-sony-ct3 b/tests/ref/fate/cbs-mpeg2-sony-ct3 index b5b4b12f07..df7af1af31 100644 --- a/tests/ref/fate/cbs-mpeg2-sony-ct3 +++ b/tests/ref/fate/cbs-mpeg2-sony-ct3 @@ -1 +1 @@ -b1e15a09cfffbad801810af0928736ab +9d55aa8bf36ee193b637001b5ef7e2ab