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 DADAF48226 for ; Tue, 14 May 2024 19:39:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 96ED068D72A; Tue, 14 May 2024 22:39:48 +0300 (EEST) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 6234968D5C9 for ; Tue, 14 May 2024 22:39:42 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id 96F0AEA6CE for ; Tue, 14 May 2024 21:39:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTbE0qS6Gd0D for ; Tue, 14 May 2024 21:39:39 +0200 (CEST) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id 36468EA61F for ; Tue, 14 May 2024 21:39:39 +0200 (CEST) Date: Tue, 14 May 2024 21:39:39 +0200 (CEST) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <6c4c27be-ac9b-4351-be6a-b3dc347843f1@nativewaves.com> Message-ID: <3be8ccc0-119b-a2a1-15b8-a6c999687d11@passwd.hu> References: <1c80d825-5046-4108-87b4-ae5f5f1a9ac8@nativewaves.com> <9e94a07b-21ac-50ad-1572-ac9327974b97@passwd.hu> <6c4c27be-ac9b-4351-be6a-b3dc347843f1@nativewaves.com> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH v2 1/1] libavdevice/decklink: extend available actions on signal loss 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 Tue, 14 May 2024, Michael Riedl wrote: >> >>> Deprecate the option 'draw_bars' in favor of the new option 'signal_loss_action', >>> which controls the behavior when the input signal is not available >>> (including the behavior previously available through draw_bars). >>> The default behavior remains unchanged to be backwards compatible. >>> The new option is more flexible for extending now and in the future. >>> >>> The new value 'repeat' repeats the last video frame. >>> This is useful for very short dropouts and was not available before. >> >> As far as I see, you are overriding frameBytes for a repeated frame, that seems wrong. pkt.data (frameBytes) must be associated with the videoFrame which is passed to av_buffer_create() later on. >> >> Every AVFrame returned by the decklink device has an AVBuffer set up which >> keeps a reference to the original DeckLink frame. This allows the use of the DeckLink frame's raw buffer directly. But you cannot use the raw buffer of another DeckLink frame for which the AVBuffer of the AVFrame does not keep a reference. > > Thank you for your feedback! > > I took another look at the code and revisited the DeckLink documentation > to ensure my understanding was correct. It seems that frameBytes is a > pointer to the buffer of an IDeckLinkVideoFrame, and it remains valid as > long as the videoFrame is not released. That is just it. You are releasing the repeated frame as soon as a valid frame comes in. The AVPacket data you previously returned will still point to the now released frameBytes. As I wrote above, the decklink frame corresponding to the returned frameBytes must be released in the destructor of the AVPacket buffer. Regards, Marton _______________________________________________ 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".