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 AF7EB40B65 for ; Mon, 7 Mar 2022 21:55:55 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 192DF68A61A; Mon, 7 Mar 2022 23:55:52 +0200 (EET) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 291A568A61A for ; Mon, 7 Mar 2022 23:55:45 +0200 (EET) Received: by mail-yb1-f172.google.com with SMTP id e186so33862986ybc.7 for ; Mon, 07 Mar 2022 13:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kq9+iyfPPUxNWTMn8qUVDFkvC9vuOJJFOln+pNmJtZU=; b=X9il86OwQpvchZ9F8ysfqgniCnK6EgwjbBiteon7Q8/ir/sxBdd9VuDrCg3bUuDpAV IEJhjQsbL2ZKtA8Ii4hm1b3SQxzJ69r6LhSE/CbhOT4/bK2q4a+ZZ2U4cjI6Mtvx6sEy f/6LEOc8egO/1gvfX8ECGTUFrkNkfwk3ABLdTv3GfEhRqfaVWvqpQNyJaAR8RPNyb0cK 0JCXdNtzNSxo5LZcmYfNZKH6anGoWLoVBhJCfl9xdF5KNgiRhx1dlLagHJYH9XE79SqR 2yTw/DZATJJE8LTMBFE0/EpApSW/WzZxkTZrpiLoQWQomonWEvc0d3zYAV92GxUIM/g+ HNDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kq9+iyfPPUxNWTMn8qUVDFkvC9vuOJJFOln+pNmJtZU=; b=y900hu53BfhWVaK8YLR/WzDACF+H02dGzRSqcvI6oOVpxfVOz3mDolMCZcs3HHCLZX bartogJxHIkury8pJC3zoBX/Kb+gfyUEq8HEYTUwIKrwDsxcgz8CDs94S2eL3Xeik6Ld alqcAm7lo32pPMMKX3OKgGfT2+NBdNcD1c35WNXhVJO8XJkM93ATjTPE8JiWyT+F5QfB DzyQpYBw9YeDvwvNWIYqsRnB3UhZKyYX2huOhYq6wsWPR8r0VUvb/Dq7Wh7+4Hj/wh+O u1ORLQV+2/N27qmRBNPZ//H+qXToegQQVVz8yfQlXz8cjynFB779ZA0NKbX5WE3xIFgp qcmA== X-Gm-Message-State: AOAM532KzLCqSQ/BpJjiF1/8O/8HFCnIAcAV4xYhUsgpT35dkjWEykM8 Pa233Sdmu/1XxMeZDiNCGA+vj3m7XsfZCSaLTpSTpHLJ2jw= X-Google-Smtp-Source: ABdhPJxi9mD284hTzCiLB4+IViJ27KcFWu8z6vFvSoLlRM5hzj8Dx4/MU+GuUjaCaMEs5vPQU+3sFLtiuDfxCmY1EdA= X-Received: by 2002:a25:d312:0:b0:629:593d:3f76 with SMTP id e18-20020a25d312000000b00629593d3f76mr3452734ybf.86.1646690142299; Mon, 07 Mar 2022 13:55:42 -0800 (PST) MIME-Version: 1.0 References: <20220306223259.9491-1-jeebjp@gmail.com> <20220307171019.GK2829255@pb2> In-Reply-To: <20220307171019.GK2829255@pb2> From: Hendrik Leppkes Date: Mon, 7 Mar 2022 22:55:28 +0100 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] mlp_parser: fetch a new timestamp when major sync is found 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Mon, Mar 7, 2022 at 6:10 PM Michael Niedermayer wrote: > So why is this considered to be "ok" in audio codecs? > Because we dont visually see that data is lost ? This patch is not trying to argue that its "ok" to drop data, nor does it introduce this behavior. Someone else did that years ago. > > but i dont think we should just build on top of this droping > logic without some argumentation why this droped data can really > not be used ever in any way (it may become harder to fix it the > more is build on top) > There is no question that dropping the data inside a parser is not the appropriate and documented behavior, but it is what it does, and what it has done for ages. Leaving an actual bug because some theoretical better fix might be available is not rather productive, especially when the fix is one short line - unless you actually provide said better fix in a reasonable timeframe. It is not adding the dropping behavior, that already existed afterall, its just fixing the timestamp - in a rather trivial manner, too. If you, or anyone else, wants to change the parsers logic to not drop data, this patch does not hinder that in any way. It immediately fixes the bug that was brought to my attention a while ago, that this case breaks timestamps. Dropping of data in front of a keyframe is another bug, even if they are practically undecodable without some manual hackery, a parser should not do that - but this patch does not even touch on that behavior, other then mentioning it in the message. - Hendrik _______________________________________________ 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".