From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 1EF2440C03 for ; Sat, 5 Feb 2022 09:00:20 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3823968B362; Sat, 5 Feb 2022 11:00:18 +0200 (EET) Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D53C068B302 for ; Sat, 5 Feb 2022 11:00:11 +0200 (EET) Received: by mail-qt1-f178.google.com with SMTP id e16so7786771qtq.6 for ; Sat, 05 Feb 2022 01:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=nxkq+tFW3ylKA2GEwEh3SCNkVXIWekSE6peRk9Il//Y=; b=qZXnjVbsh5ol6Ir1DS78B9arDaUnFx7r7o/69uc3/TrwYQTAxP6z74kd6CWiZ3Vm72 j/26TgWIpHKe5BdRS1xqB6+dO9bX6zOwy/U+n4cXDMZET2Aeqx8xQYrcnHjME9WJHpEV nl3Yzf8n11jEZOYeotT02AeBIuf1c7PSp4qHZpus40n1hTTIHUfEcQszbIhh6/21Ocyi +avCiJwHtAh0dXRMOrDAXzTr7GD+PbCDXzv9PVwhBYv2dPbSRJNeuhsoGuFz8magCPX4 N3QoCPVH8GNA3MiJ7khsuwE8N7QSM0wG/cZwNbJo9PLnDi40ACszA3Sn+icxPe2U5L7a xPJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=nxkq+tFW3ylKA2GEwEh3SCNkVXIWekSE6peRk9Il//Y=; b=Ei3kObTz2IysvLeDUo5171eT68k9fp0t1dcsGsKenzsaSTq+QLK+OiCsWQSf6gGcEU QPY9cZuY4qC2tPtXVlna51sDQlXv4yhnVddCmlOdM1fsDWutb/14u1Se8AVnT4vcQjA7 XYgARJaJlJrrELOFn3J1ntdnU3uYcp9YmwHx9DkATlyrlFrubvdxhtRy/ixb+G9M6VUZ unl/yYxLTG+rIaGsHTTRPxKflCi9+FWZyeLtLulOeKNeWrK0Drm38NDuCJeuh6c5yklZ Hi00DSd7mkunn54qdaJGF9ByChiIjAhCVmU1EIvkbo9y+xICkmF3DbLAkhJyf0Srni5s JO0A== X-Gm-Message-State: AOAM530aeoSEnnz52iJmm38/3zKGhN6Q71mlk69gBUUu4dGWlTuBt3BB TW6McItGkMebvNoAz4FS8EzGrH2pShEmVg== X-Google-Smtp-Source: ABdhPJyLjTQEHceAtB81tBH7Ck/0MSzJGV9BeRgv8XaJSwKq2Eg4Yvjc8R8pNQ4+iTLyEDQfsM1wkA== X-Received: by 2002:ac8:48c8:: with SMTP id l8mr1970013qtr.434.1644051609899; Sat, 05 Feb 2022 01:00:09 -0800 (PST) Received: from [192.168.1.64] ([151.200.235.219]) by smtp.gmail.com with ESMTPSA id q22sm2754221qtw.52.2022.02.05.01.00.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Feb 2022 01:00:09 -0800 (PST) Message-ID: <8b9ee3e8-3862-b052-9183-ff3f6e6839df@gmail.com> Date: Sat, 5 Feb 2022 04:00:08 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220201212056.29712-1-scott.the.elm@gmail.com> <20220203184450.5491-1-scott.the.elm@gmail.com> <20220203184450.5491-9-scott.the.elm@gmail.com> From: Scott Theisen In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v2 08/13] avpriv_find_start_code(): add parameter for ignoring history X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 2/5/22 01:10, Andreas Rheinhardt wrote: > 1. This patch is absolutely unacceptable: It breaks ABI. > 2. I am surprised that there is apparently only one user that actually > wants this feature of state being an input parameter, namely > (ff_)mpeg1_find_frame_end(). This means that this loop done before the > new check should actually be made by this caller alone, obviating the > need to change the signature. > 3. Given that no user of this in libavformat wants this feature, > changing it is IMO acceptable from an ABI-point of view. I'll look into it. > 4. There might be some slight changes introduced by this though: > Consider 00 00 01 00 00 01 xy. If the initial state is -1, a call to > avpriv_find_start_code() will treat the initial four bytes as start code > and return a pointer to the byte preceding the second 0x01. If the user > does not reset the start code between calls to avpriv_find_start_code(), > the second call will combine the last zero byte of the start code with > the rest to form another start code that partially overlaps with the > earlier one. This is (probably) invalid data (definitely for H.262, > H.264 and HEVC). With input buffer 00 00 01 00 00 01 xy ... The code in master will (incorrectly) find a second start code at offset 7. It would need to check if (*start_code == 0x100) and invalidate it. -Scott _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".