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 38EDC44A20 for ; Tue, 6 Dec 2022 11:21:24 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7D58468BD1D; Tue, 6 Dec 2022 13:21:21 +0200 (EET) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E156668BCA6 for ; Tue, 6 Dec 2022 13:21:15 +0200 (EET) Received: by mail-oi1-f180.google.com with SMTP id h132so16539821oif.2 for ; Tue, 06 Dec 2022 03:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=jiX91N+NE1l8TKGrI9qs4+igZ5sDLRlyA83QfJkfJDU=; b=VOXyu+Nt0uQA75pzVQQLH42fLLBrtpt9kF8nUdciOVio0khlrMMva4f+G+49iCjMb/ MyQvkSOLdOu2tVDKkU4NmcO3ft4YM/P2V7SfDC1wiiNtP/tZw7k3saiz4bwMaUUQKx5n oMvSCPkfd4LtdoE9Iv7Kro8qUtIyw3fEHzv/I+hEt7YXzG6L0f+fUr8g78vbn6MALDvv Jvppfh5lWyR9cp0pdrA+5ivggxl5WzN0YcO00fXdxukjlKGq/xbYX6HzqKhD7bZBFr1z HMa2/emkTnbm2+F4pBQQXEeu5llpvhmOYCqHJwVhqzXwQ1N8r88tvlEopjDS6GBsd1Y0 r7MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jiX91N+NE1l8TKGrI9qs4+igZ5sDLRlyA83QfJkfJDU=; b=dR0pqyJxTGWT5WkGH6jpds4QJ5v0hJW5nfdzd0BSZqh7fpdYPBWFlD8s1qEimfwevD c42FmOwbc8Ak/hjBeJ30gWvhjTesKEJEhjmfIvsowpI02+IlpxtFqZYNwr/Yhh+24eD2 sopNTSk+fUcYBDOufeX3d51N5aop+sQqUB2abPPzIn9E0iCjGmkHgZlHd92mwmVBAta7 QWzajVYIgunodSHv9iQM5LheNE4u1ggaDERySCemtgzoXgg10r3pw/YL1+yLqTzm/SRh MAZROCPsAAzQyTiMcA6I2fzKn7FM99nF7B4XfhTvTw8yI/rbmxhGhObgp7hEFfWczleB +WTw== X-Gm-Message-State: ANoB5pnYdbTije3fih71nZ/QBsbMgIyeQwjSlv/f8VkPWVjyvt5CCvJw gB8i8kgrVD6wdaJqGo8ZAtoe3m23Fk8= X-Google-Smtp-Source: AA0mqf79YJU5giCkbPQgSNTDVacFWl4qgQo+eDDz7MOLnnIzJyf3+x+uwjEC6tfZx2VSpY5Zr8WKSQ== X-Received: by 2002:a05:6808:14cd:b0:35b:ea4f:7141 with SMTP id f13-20020a05680814cd00b0035bea4f7141mr10374615oiw.266.1670325673986; Tue, 06 Dec 2022 03:21:13 -0800 (PST) Received: from [192.168.0.11] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id m6-20020a056870a40600b0012d939eb0bfsm10522087oal.34.2022.12.06.03.21.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Dec 2022 03:21:13 -0800 (PST) Message-ID: <28be1785-a2f0-a1a1-db86-17321fa3786d@gmail.com> Date: Tue, 6 Dec 2022 08:21:11 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 To: ffmpeg-devel@ffmpeg.org References: <20221204215227.4186-1-jamrial@gmail.com> <20221204215227.4186-5-jamrial@gmail.com> Content-Language: en-US From: James Almer In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 5/5] avcodec/mpeg4videodec: duplicate the last decoded frame when the last coded frame was skipped 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 12/6/2022 6:17 AM, Andreas Rheinhardt wrote: > James Almer: >> This ensures the video stream duration is not lost after decoding. >> >> Signed-off-by: James Almer >> --- >> libavcodec/h263dec.c | 13 +++++++++++++ >> libavcodec/mpegvideo.h | 1 + >> 2 files changed, 14 insertions(+) >> >> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c >> index ac7a8521e5..0a2d7487a8 100644 >> --- a/libavcodec/h263dec.c >> +++ b/libavcodec/h263dec.c >> @@ -430,6 +430,18 @@ int ff_h263_decode_frame(AVCodecContext *avctx, AVFrame *pict, >> return ret; >> s->next_picture_ptr = NULL; >> >> + *got_frame = 1; >> + } else if (s->skipped_last_frame && s->current_picture_ptr) { >> + /* Output the last picture we decoded again if the stream ended with >> + * an NVOP */ >> + if ((ret = av_frame_ref(pict, s->current_picture_ptr->f)) < 0) >> + return ret; >> + /* Copy props from the last input packet. Otherwise, props from the last >> + * returned picture would be reused */ >> + if ((ret = ff_decode_frame_props(avctx, pict)) < 0) >> + return ret; >> + s->current_picture_ptr = NULL; >> + >> *got_frame = 1; >> } >> >> @@ -500,6 +512,7 @@ retry: >> s->extradata_parsed = 1; >> } >> ret = ff_mpeg4_decode_picture_header(avctx->priv_data, &s->gb, 0, 0); >> + s->skipped_last_frame = (ret == FRAME_SKIPPED); >> } else if (CONFIG_H263I_DECODER && s->codec_id == AV_CODEC_ID_H263I) { >> ret = ff_intel_h263_decode_picture_header(s); >> } else if (CONFIG_FLV_DECODER && s->h263_flv) { >> diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h >> index 6440b906b1..42275953b9 100644 >> --- a/libavcodec/mpegvideo.h >> +++ b/libavcodec/mpegvideo.h >> @@ -175,6 +175,7 @@ typedef struct MpegEncContext { >> Picture *last_picture_ptr; ///< pointer to the previous picture. >> Picture *next_picture_ptr; ///< pointer to the next picture (for bidir pred) >> Picture *current_picture_ptr; ///< pointer to the current picture >> + int skipped_last_frame; >> int last_dc[3]; ///< last DC values for MPEG-1 >> int16_t *dc_val_base; >> int16_t *dc_val[3]; ///< used for MPEG-4 DC prediction, all 3 arrays must be continuous > > Can you give an example where this matters? And what does the spec say > about this? Is "output the last frame again" really the appropriate > response upon encountering a NVOP? > The reference decoder returns a frame for every packet, nvop or otherwise. If nvop, it will be the last decoded frame. Doing that here was rejected some years ago as it would make the decoder unconditionally cfr, and that's undesired. Say you have a video stream that's 6 minutes and 30 seconds long, where the last thirty seconds worth of packets are NVOPs. The decoder will consume them and generate nothing, as expected, but then at EOF the last returned frame was that with a pts at the 6 minutes mark, resulting in the decoded stream being 6 minutes, and as such stream length information is lost. By returning the last frame again at the end with the last input packet's pts, you will get the correct stream length with no difference in video output while remaining vfr. _______________________________________________ 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".