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 41F3644C95 for ; Sat, 14 Jan 2023 15:16:04 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 0152E68B7E9; Sat, 14 Jan 2023 17:16:01 +0200 (EET) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B9AE168B5B0 for ; Sat, 14 Jan 2023 17:15:54 +0200 (EET) Received: by mail-lj1-f182.google.com with SMTP id e13so25464545ljn.0 for ; Sat, 14 Jan 2023 07:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=R+KHAsRDLyZ+5/aQTK1f9FM4cvLxlRNV2Kq45nuvHEc=; b=SyaDWo80CuVNJjkPzCAE79Y9L3DT2Pt82rEuHu+SwPrpSam9wW+znDC/KFKKYOs07v zIopSwsmbKL/lT+wx4zi26QinBD77ghrCKzcWvVoMv1j5nkw5351BosS2rpq30z8BpZ0 VahXdJK3vDII/AlV2yTy3+TzpRKH9MHp0q12i7HyLWa5HEpMHyS412xHWSBPFKoRGuLG YiOLcM2C3h8QUg3lRNTzN7Pq+vJFX0P+yx7KZ6MdMeUDN2dMaqpg5twq3U8AaCD4Zr1K UTAwAbPw0CxgaVI3JD1qKYB5J1xzTwkblLJO3+WtSfJiKVIZujruqNI5NwjxoUUkWBY1 EcaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=R+KHAsRDLyZ+5/aQTK1f9FM4cvLxlRNV2Kq45nuvHEc=; b=5Co8YhCPNgorM51agnLIr39D12G/Y2sb7lnK7eoM2Nha2LYf+TwB8Jkja/ycvW7jSs JUa/ptWDjS0j03fLYQIPNQN0wPfEoMGWFH1QmBA6u/jsuj3FrMWWPO4OVi6eI+s6rElW UpdNzk4Sg+vOvrrpgEJmKQ5C+hSClQ7ApN/ivp8i8/dVgXOG49Ol/ipKC1hEyWs2J1ef UfUIJsdWDQMDK9JCbZdjylaEbMSKE7sCNT+QbdSyVHTmwwIBDSUgqNkzlAJgdj1Z5Dsb WoW6iEpKDZ6gqlBrHaDweMw+jVepI5d49PUra5mKhAK4frX3CsWdixiE3cVhvj1zFyw/ xC7Q== X-Gm-Message-State: AFqh2kpFTzXUhzKzyw1KbtCv+j51fOhwZakw/D9aWelE/X0LEJN26Isr PbZleYWVVXEmKPiS+EUCcREOEusXrGykDHplyvgIhPxYS/U= X-Google-Smtp-Source: AMrXdXuZhtPXL4ioLffhsm6eTzZ9sdgw1XZrOk+RMLLEoBCOH1ccac4SKZ8mRv9RTMcoL53rStGYUe0TdKbU7q5b5SM= X-Received: by 2002:a2e:7c10:0:b0:28b:601e:4507 with SMTP id x16-20020a2e7c10000000b0028b601e4507mr374055ljc.91.1673709353289; Sat, 14 Jan 2023 07:15:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nuo Mi Date: Sat, 14 Jan 2023 23:15:42 +0800 Message-ID: To: FFmpeg development discussions and patches X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: Re: [FFmpeg-devel] Let us review and collebrate on vvc native decoder. 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-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: Hi Ronald, Thank you for the detailed comment. You read code really quickly. On Sat, Jan 14, 2023 at 10:28 PM Ronald S. Bultje wrote: > Hi, > > On Sat, Jan 14, 2023 at 8:32 AM Nuo Mi wrote: > > > On Sat, Jan 14, 2023 at 9:13 PM Nuo Mi wrote: > > > I am happy to send out the first draft of vvc decoder. > > > It's not ready for upstream yet, but it's a good base ground for review > > > and future improvement. > > > > > > It has the following features: > > > * C only > > > + Fast. On a 4 cores laptop, it can get 30~35+ fps for 10bits 1080P. > > > + Support traditional features I, P B frames, 8/10 bits, chroma > 400,420, > > > 422, and 444, > > > + Support VVC new tools like MIP, CCLM, AFFINE, GPM, DMVR, PROF, BDOF, > > > LMCS, ALF > > > - Not support RPR, PCM, IBC, PALETTE, and other minor features yet. > > > > > > Please help review the attached patch and provide your valuable > comment. > > > > The custom threading framework (Executor, Task) - can you elaborate on this > further? If this is meant to be used outside (since it lacks VVC prefix), > it should be properly namespaced (FF, AV). It seems like you're trying to > combine row/col/frame threading from vvc_thread.c. These (frame, col/row) > are fairly common in FFmpeg and there already is existing API for that > (although you can't combine them; ask kurosu who IIRC has a private branch > doing this for hevc :-) ). This probably needs some further discussion > depending on what the rest of the community wants. Right now, this adds VVC > private functionality to enable combination of "slice" (row/col) and > "frame" threading, which other codecs wouldn't have. This is probably not a > desirable end state. > Yes. It can be used by other codecs or even filters too. The task allocation, and the task readiness check delegate to the caller. so It gets more flexible from the caller's or executor's view. When I read the hevc code it was a little surprise to me since it can't combine frame and slice threading. I guess it will impact the fps, but I do not have time to provide it. I will check with kurosu offline, It's better to have a unified solution for hevc and vvc. I can follow him if the api can do frame + slice/CTU multi-thread. > Some functions contain av_assert calls, e.g. chroma_mc_bi or > get_luma_weight. Are these not yet implemented or impossible because of > bitstream coding constraints? If former, please use > avpriv_report_missing_feature() so the user is informed of the incomplete > decoding. If the latter, please add a comment and remove #if 0 code. For > other cases of missing features (e.g. PCM), don't silently return 0, but > use avpriv_report_missing_feature() so the user is informed. > Yes. weight prediction and PCM are missing features, it's listed at https://github.com/ffvvc/FFmpeg/issues. I or some kindly contributor will implement it before we upstream it. Thank you for your suggestion, if we can't fix it before upstream, I will use avpriv_report_missing_feature() > How come vvcdsp has only 8/10 bits/component code but vvcpred has 8/9/10/12 > bits/component code? > I will remove it. > Not a lot of comments other than references to the spec... > Before I send out the patch, it's like walking in a dark tunnel. I try my best to get to another side. Not have so much time to polish things. I will add more comments and do some react to make the code more readable. > Is any of the code (e.g. tools such as sao dsp) shareable with HEVC? This > would reduce the total implementation requirement for arch-specific code. > SAO can be fully reused, most inter predict code can be reused, and some parts of intra-predict and deblocking can be reused.. I will create a full list at the github repo. > > Ronald > _______________________________________________ > 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". > _______________________________________________ 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".