From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7E99D1B6CE4 for ; Tue, 14 Jan 2025 16:16:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736871414; cv=none; b=G+CWarMFNrs3S6FL9z99FHrRwtCvYBEXNi68CZYCpS+fMBJMQGQDFu3pTmN9KIz0RSzh9e5JQcaE1NVgZJxtrvSNsgOaEzqVhxRcvvFShhGxmH817tbGx53vCsFV3GgRxOjmXa7Pd5OpPNmHheEH6ZIk31cK9T+hn23IdmBiG+E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736871414; c=relaxed/simple; bh=lt7KkUDtg/XGs925Gs0yrNTATid7sSWRB4gtE0t++Ts=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=tZHT479vyx14ZUsDi/4DCYsq1q3tlrj2T5YonBAB62k4XtIIwW8XwSO1TnY9aUrcf+toEZ5lDS3Bsnb4RRfSW40pBPcqAmMlzsJLYu6rrL2wcrmNhJXm5MV2wvXK8Sf2H5fSwN4GmKH+f0obKgownuhw7DGJ8GXucjkZmzS6G64= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=gn0pXtVY; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="gn0pXtVY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1736871409; bh=lt7KkUDtg/XGs925Gs0yrNTATid7sSWRB4gtE0t++Ts=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=gn0pXtVYm+FqJD48Xx/PFhayD5TrvNTk2xy+CGEj+Zd+NMYTRcwABJ9Yx8YXbYjpp Xi4Sd9ZlyC0UxxUxBgw1sooucJrrhpacTzrW4UZz8YEcZ+/cNpC3E9UJ9qhttCVIF/ XBFJhM5yht1Q4KKp3DVScFREV4e0Iz8vUADQzcS+9ugzH/T20ytzZo040KOMYp66B8 BV6M5pyIDVr2J1getl84eEn/7s8Vq3QrFjYiWrycGl3wMycovWRUREiGjaWTIBpgbN gsDhf92a6lc/mFnOR4/+6WKhiNY/5zVNgnYQ1oOSsyJ96aYv+/0p158wSkl0ncSA0Y Q6vj1NpgfuTQQ== Received: from nicolas-tpx395.localdomain (unknown [IPv6:2606:6d00:15:862e::7a9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nicolas) by bali.collaboradmins.com (Postfix) with ESMTPSA id 3748517E0D72; Tue, 14 Jan 2025 17:16:48 +0100 (CET) Message-ID: Subject: Re: Hantro H1 Encoding Upstreaming From: Nicolas Dufresne To: Daniel Almeida , Adam Ford Cc: Fabio Estevam , andrzejtp2010@gmail.com, Frank Li , ming.qian@oss.nxp.com, linux-media , linux-imx@nxmp.com, paulk@sys-base.io, Benjamin Gaignard , Gustavo Padovan Date: Tue, 14 Jan 2025 11:16:47 -0500 In-Reply-To: References: Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.54.2 (3.54.2-1.fc41) Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi everyone, despite Andrzej having left the community, we are not giving up on the encoder work. In 2025, we aim at working more seriously on the V4L2 spec, as just writing driver won't cut it. Each class of codecs needs a general workflow spec similar to what we have already for stateful encoder/decoder and stateless decoder. - https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-decoder.html - https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-encoder.html - https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-stateless-decoder.html It is on top of this, that for each codec we have to add controls (mostly compound) specifics and details that suites stateless accelerators. >From a community stand point, the most important focus is to write and agree on spec and controls. Once we have that, vendors will be able to slowly move away from their custom solution, and compete on actual hardware rather then integration. It is also time to start looking toward the future, since Hantro H1 is very limited and ancient encoder. On same brand, if someone could work on VC8000E shipped on IMX8M Plus, or Rockchip codecs, that will certainly help progress. We can also get inspiration from many other stateless encoding APIs now, notably VA, DXVA and Vulkan Video. Of course, folks likes to know when this will happen, stateless decoders took 5 years from start to the first codec being merged, hopefully we don't beat that record. I personally aim for producing work during the summer, and mostly focus on the spec. Its obvious for me that testing on H1 with a GStreamer implementation is the most productive, though I have strong interest in having an ecosystem of drivers. A second userspace implementation, perhaps ffmpeg ?, could also be useful. If you'd like to take a bite, this is a good thread to discuss forward. Until the summer, I planned to reach to Paul, who made this great presentation [1] at FOSDEM last year and start moving the RFC into using these ideas. One of the biggest discussion is rate control, it is clear to me that modern HW integrated RC offloading, though some HW specific knobs or even firmware offloading, and this is what Paul has been putting some thought into. If decoders have progressed so much in quality in the last few years, it is mostly before we have better ways to test them. It is also needed to start thinking how do we want to test our encoders. The stateful scene is not all green, with a very organic groth and difficult to unify set of encoders. And we have no metric of how good or bad they are either. regards, Nicolas Le lundi 13 janvier 2025 à 18:08 -0300, Daniel Almeida a écrit : > +cc Nicolas > > > Hey Adam, > > > > > > Daniel, > > > > Do you know if anyone will be picking up the H1 encoder? > > > > adam > > > > > > — Daniel > > > > > > > I think my colleague Nicolas is the best person to answer this. > > — Daniel