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 CE1FC44A80 for ; Tue, 6 Dec 2022 14:39:38 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 72D4B68BD26; Tue, 6 Dec 2022 16:39:35 +0200 (EET) Received: from btbn.de (btbn.de [136.243.74.85]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7B6C668BC68 for ; Tue, 6 Dec 2022 16:39:29 +0200 (EET) Received: from [authenticated] by btbn.de (Postfix) with ESMTPSA id 0F7F53AB612 for ; Tue, 6 Dec 2022 15:39:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1670337569; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/zqIz5LnI4lrAlfPxB4xAhx7PTwjVXovl/+rYrz+eA8=; b=muMeu8GvTDgQndp+s3/WDaV8pv2UDjk2BJehUxPx4JvVvPBM+Bfbj/PjVdejAnBfZhvknd MhEu9nkLE6mYi1KhpDsaE9Pck2aAjVGtQNDoS6TvOE6aQBKaXuYV5B/XfJIijTe2kRXCI6 em4ZKIt/0kTLgchrKc0tYICgfEs1oKA44s73Zb412G/Ecqufu3OdEOvZcHcvws8IiGo3p0 Zoa6YknTecaJtBaR32l/tL2kFYF86/NkILjl+Z8F63/cvSfuZ9JZ0jTWUpjjwJPjOAMSAV M1bJS2j7dJ88VZdAU840QyaiPULGEsyqAgxdYg8zu6vtE38MmfcuOEF2vKYgSw== Message-ID: Date: Tue, 6 Dec 2022 15:39:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Content-Language: en-US, de-DE To: ffmpeg-devel@ffmpeg.org References: <20221205133938.505-1-timo@rothenpieler.org> <167033742725.26119.15040760416331150943@lain.khirnov.net> From: Timo Rothenpieler In-Reply-To: <167033742725.26119.15040760416331150943@lain.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders 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 06/12/2022 15:37, Anton Khirnov wrote: > Quoting Timo Rothenpieler (2022-12-05 14:39:37) >> This is fairly basic and makes a lot of assumptions, but it works >> for the most simple cases. >> >> For one, it only ever fetches exactly one packet per call to receive_frame. >> Right now it's impossible for there to ever be more than one, but the API >> allows for more, which might need handled in the future. >> >> It also basically translates the new API back to the old, since that's how >> the frame threading code operates. Which feels backwards in regards to >> the new API, but it was the path with least resistance in implementing this. > > If it only supports one packet to one frame, then it goes against the > whole point of using the receive_frame API. Otherwise the entirety of pthread_frame.c would need rewritten from scratch. It has that assumption coded into it. It also raises question as to how it'd distribute those packets accross threads. Does it just try to read packets until it either runs out of ready threads or encounters EAGAIN? Or does it read until EAGAIN and then passes all those to the same threads? _______________________________________________ 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".