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 CC318435AA for ; Mon, 17 Oct 2022 08:18:41 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5070568BD08; Mon, 17 Oct 2022 11:18:39 +0300 (EEST) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 51E0068BBDE for ; Mon, 17 Oct 2022 11:18:33 +0300 (EEST) Received: by mail-lj1-f180.google.com with SMTP id bs14so13006873ljb.9 for ; Mon, 17 Oct 2022 01:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=sLFjUzwlz1/m9Tf5Zb3zlW6QmS4ZYTM0cAHhYdGaEg4=; b=FzBZBEucwgHA4HKZGJ1Wi+6x+vSVT0NrdsPujW785MLYnBvNf7auNxR7ln8X2OiaTH SFm7T6NiqWag0Gr6FaWHby9+f3mFGpjUEWtrQSpnbiUBwcGobzUZ/xkfv/gCkCxONYhc nlEZ2FFCaUK/3hvQoZhncU2mCLiAgrfoql4D7nwYsqoKIRDqVZQug4/Xxq5hFKWJCFp+ GR7/4/T35RqKwSwMF40AV4pPJunX2dxM6+pp0ma6aLYYIA812wklXZ1AJHDgLe58M7GG 9FU69anhi9/SgH8YsRKyA6f3kd/ulrK8Tu5sxjdoO7rZ41NCkcHIbCTeR/ZTopBoa/bi PaBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sLFjUzwlz1/m9Tf5Zb3zlW6QmS4ZYTM0cAHhYdGaEg4=; b=AJHv+aznOJO6OBgbnABv9i8hnZgIAS+oz7QJDTG7wcMKwsp/oQ4hNyNhwN8kngavHA DcOBpwufYcbhOrDrEnG3O6a14WyBSsufU3l92XjhN/VUTYJJIvU2jQDXezfFMjGt3qbk F2W5ZbsvSSzReeaxYm4HlzNJnVdkqJgIQpXXAx2LMW+wAfVEcEZb2ZAu6N7IyoGBfpYP YmiM9K4F9dq8RYdb4V/+RH8Lz9Xxl0vBBahufgYIqXRBGyYLckNMm+s4o1bCgWaWZT5y 4OBJgn58QGeBAiXDaKYV3K2CawzAfEGKxqKXOIW+itjPINiR0L8qNwWoCE6wQsO0qH4+ 6XSg== X-Gm-Message-State: ACrzQf0P1/dkQvlrofv9Rlj56vLlp/R0ifcYREDGwELKBKWPrQuGDLg5 2MLbpC8oo2mzF1V5jy+dSOznECKlJwPx6NZUxpXIj9BT X-Google-Smtp-Source: AMsMyM4oDnUL0JCCMrAi+joBOO+7qYKwQg1cF1L14IbQ21RzzCt62XGvPfcOEsBkrIRh/FE+x1idKV+6Regxdd7/q68= X-Received: by 2002:a2e:8688:0:b0:26f:a77c:c022 with SMTP id l8-20020a2e8688000000b0026fa77cc022mr3837501lji.328.1665994712621; Mon, 17 Oct 2022 01:18:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:2a44:0:0:0:0:0 with HTTP; Mon, 17 Oct 2022 01:18:31 -0700 (PDT) In-Reply-To: References: <20220908082505.953-1-jyrkive@nekonyansoft.com> From: Paul B Mahol Date: Mon, 17 Oct 2022 10:18:31 +0200 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] avcodec: Vorbis decode: don't use a flag to determine if frames have been output 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 10/17/22, Hendrik Leppkes wrote: > On Thu, Sep 8, 2022 at 10:26 AM wrote: >> >> From: Jyrki Vesterinen >> >> If a developer using FFmpeg libraries seeks into an earlier position and >> calls >> avcodec_flush_buffers() afterwards as recommended, the Vorbis decoder will >> drop >> the next frame, since buffer flushing clears the first_frame flag. As a >> result, >> the audio samples the calling code receives may be ahead of the requested >> seek >> position, which is unacceptable in some use cases such as playing a >> looping >> sound effect. >> >> This commit removes the first_frame flag entirely and instead uses the >> presentation timestamp to determine if it's the first frame. >> --- >> libavcodec/vorbisdec.c | 5 +---- >> 1 file changed, 1 insertion(+), 4 deletions(-) >> >> diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c >> index 4d03947c49..d4b030d7b9 100644 >> --- a/libavcodec/vorbisdec.c >> +++ b/libavcodec/vorbisdec.c >> @@ -130,7 +130,6 @@ typedef struct vorbis_context_s { >> AVFloatDSPContext *fdsp; >> >> FFTContext mdct[2]; >> - uint8_t first_frame; >> uint32_t version; >> uint8_t audio_channels; >> uint32_t audio_samplerate; >> @@ -1845,8 +1844,7 @@ static int vorbis_decode_frame(AVCodecContext >> *avctx, AVFrame *frame, >> if ((len = vorbis_parse_audio_packet(vc, channel_ptrs)) <= 0) >> return len; >> >> - if (!vc->first_frame) { >> - vc->first_frame = 1; >> + if (frame->pts < 0) { >> *got_frame_ptr = 0; >> av_frame_unref(frame); >> return buf_size; >> @@ -1881,7 +1879,6 @@ static av_cold void >> vorbis_decode_flush(AVCodecContext *avctx) >> sizeof(*vc->saved)); >> } >> vc->previous_window = -1; >> - vc->first_frame = 0; >> } >> >> const FFCodec ff_vorbis_decoder = { >> -- >> 2.37.2.windows.2 >> > > This change seems to be rather fragile and faulty, causing vorbis > decoding to fail in various scenarios for a bunch of downstream > projects. > > - A user may not set pts at all, resulting in all frames being dropped > (pure audio files don't necessarily need timestamps) > - A seek could happen before any frame is ever decoded, resulting in > wrong drops, potentially in the middle of playback if the user seeks > backwards after opening in the middle. > > In general, using timestamps to control decoder behavior is often just > wrong, as timestamps are not reliable, and most importantly, not tied > to the bitstream at all. > > Can we revert this and re-think the approach? Are you saying that previous solution was better than current one? By your own words its ever worse that current state. > > - 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". > _______________________________________________ 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".