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 98CF049A6B for ; Thu, 28 Mar 2024 00:57:07 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3DDCE68D582; Thu, 28 Mar 2024 02:57:04 +0200 (EET) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 704B268D540 for ; Thu, 28 Mar 2024 02:56:58 +0200 (EET) Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-41545616455so179045e9.0 for ; Wed, 27 Mar 2024 17:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711587417; x=1712192217; darn=ffmpeg.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=H432swFSVonDunf0N9Hh2abjtxCsa1ocqBgTC2cWWV4=; b=AjAjaDYhcYnq7gVzt+z5CBAKGu+FLYtJMyrmkHIVfA6H8zm87B1Do9M5/h8J1gBF2m /4LZ6448/kT9X7KVgAMn/8wH65GTdJqmDYN1Szw+GZwWyd2DHHkwTHfJStR0GelFPLhf 6nERPPHWvT9rrAXGBkDz1nDCvTb7dV8jpq/u2Wd5UsVDa3wE6tyxlu2ZjVq4U3wk18Vu hrSFjjNfwUJOWl9YRGq4w09Ed+nwsrqIS717tPopo+JHIm/De7n+rJWzSzBKb4qEsVv+ cMcj1Ie7B8E5pLqYEVSrg5veFvHOFqIBQEzeM0p6dRIEe0O5YcA9bsBNFBeXh8UtAUXX u4PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711587417; x=1712192217; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=H432swFSVonDunf0N9Hh2abjtxCsa1ocqBgTC2cWWV4=; b=dN2KXY5Lq05qfwJYDV569RAyS0pH5v7cp/8CvM2N8+A2cCrJucXPYoZwUhRpL8LGpj wDNhgqJ4ZafBQskVfyxUQIMD15RNDUZQSytdF4ns6If3nb16bqFcM4C6SrQBqeq0Fjjv gv2e4Ay5z5ugr2MxhxfNwZ+098UezCZ5NL7o55WyICaTvkdIhVbNCoN++ZCv4Q1Xsjjk d7v9i6g6vY17INW+6FayMlmaFEzCEzP7Ss4rqqrGflemLGzZEgXT+NHNB9fCb+m2pkSl hJCurY+ASAxkTSCQ1uCdWbf7n6ydKI8Uy0bKSJa6cUYtCpKjyryPJbOW6t542YNRljq1 tr6A== X-Gm-Message-State: AOJu0YxpDSKI9ODeIlnk6XtFr809P7F2j16fnDVvKEtQAY1qhPpak9Zp H2ia0vstz/tLUS/ZwEnCJ4mrde7OF8cWnAqcRfGylzw8ARV0TL+I5AEM1YZq X-Google-Smtp-Source: AGHT+IHvjxjHuQhJbL5MSU0kS16syYJu5gEiHgG4X1o07Hh/tU6hQ1gPa8aMt72YWGMadINaIuITdQ== X-Received: by 2002:a05:600c:1d22:b0:414:9104:3696 with SMTP id l34-20020a05600c1d2200b0041491043696mr578612wms.31.1711587417052; Wed, 27 Mar 2024 17:56:57 -0700 (PDT) Received: from localhost.localdomain (dynamic-078-055-195-187.78.55.pool.telefonica.de. [78.55.195.187]) by smtp.gmail.com with ESMTPSA id m28-20020a056000181c00b00341d186a2dbsm325529wrh.14.2024.03.27.17.56.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 17:56:56 -0700 (PDT) From: arch1t3cht To: ffmpeg-devel@ffmpeg.org Date: Thu, 28 Mar 2024 02:56:36 +0100 Message-ID: <20240328015639.1425494-1-arch1t3cht@gmail.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 Subject: [FFmpeg-devel] [PATCH 0/3] avcodec/h264dec: Fix dropped frames when draining 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 Cc: arch1t3cht 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: Fix one or more frames being dropped when starting decoding at a SEI recovery point that is very close to the end of the stream (specifically, which is less than 2 * has_b_frames frames before the end of the stream in decoding order). One case of this was reported in ticket #10936. Tested for regressions using FATE. If necessary I can also try to add a test for the previously broken behavior. There's now a bit of code duplication between h264_select_output_frame and send_next_delayed_frame (or, rather, there was already some code duplication and this patch adds a bit more). But this probably cannot be avoided without a larger refactor to, say, also call h264_select_output_frame in send_next_delayed_frame instead of manually selecting a frame, which I don't feel confident enough to do myself. arch1t3cht (3): avcodec/h264dec: Properly mark frames as recovered when draining avcodec/h264dec: Handle non-recovered frames when draining avcodec/h264dec: Reindent after the previous commit libavcodec/h264dec.c | 44 ++++++++++++++++++++++++++------------------ 1 file changed, 26 insertions(+), 18 deletions(-) -- 2.44.0 _______________________________________________ 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".