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 1FC5646953 for ; Fri, 28 Jul 2023 07:44:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id D20B968C92F; Fri, 28 Jul 2023 10:44:47 +0300 (EEST) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7AD5E68C68A for ; Fri, 28 Jul 2023 10:44:41 +0300 (EEST) Received: by mail-ed1-f43.google.com with SMTP id 4fb4d7f45d1cf-5217ad95029so2309581a12.2 for ; Fri, 28 Jul 2023 00:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690530280; x=1691135080; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=tGB/gploUXcoIJz7w77RiVx2ZsszQCX0E2kv+yVEw5A=; b=ZxkHl8fi3rgBSjeRrb2jAP0GPo1POuFCiJB0nFPzt6Bhpt3BMFB8N9i2aJGzOFwkrC jdPHWWQRRV7l5orpPbd2EUGvfau7IvZtO8V+ETT2qjlJkUN5sz98Cw19kDqTcHNzAAzk iHbOhR2aGejt8dQ9IyzO9LCOfjY1kGKibcHxgviUqR/9xmmnCntOUnd+VpcxYR1oQvok 6hADZm6OqeM637K4mGG5RqMoA7qJVnc1lMaLm6MH0OQ2217yIsHF81LTfwINi7RA1kBD rZGO7S/xvJ+Uqgla77Xvq/DG1S+ujFj3fNF9ji070s2+0uIRGFGlix8jWROkyl2u2Gl4 WhPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690530280; x=1691135080; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tGB/gploUXcoIJz7w77RiVx2ZsszQCX0E2kv+yVEw5A=; b=MVEtqYWH/wpG0ForBUbDeOrQyhE4yBF7kEOTYCFIOMqSLItk7QbhZt+ogLmwxb34V0 5KqLU80MWgKXG3ezl7D7TZXHwf7aUweAh5fNHc6r1pl7DA9ayAOXzFwhO2YJlbUZ/50K quLMItAsO1X84bpmBdmjtdoJxYxBdT/ZmtNg9Vk7O/X6nv/DuNXDw17wMCZ3l7Pgp5k7 N/d7yDl5wyPL2lY0y5MQv0o9YeVxn6HyWBU99fYgJ5OnP/45J4LBUNXoo4acUqop3IhH 7SaozBRfbblHGJaev2JVHQMHrcJzRpB2Cn6UTXeFDVDXyIzB+JH6hPNNu6WOcC4wxyW/ vlcg== X-Gm-Message-State: ABy/qLYjhaGbl9F2oeAISDvYacjCcY5yR0pHft5J85p+FuD3v3tcznFO R/Fz9/98t6TDy4Zy92a8d2vUMcsapWRwVA== X-Google-Smtp-Source: APBJJlFeCVNFWWW2W1r+Lof1a5vR8WdGrQUX+cseeSLL78wN4u0HZjKLzviHYwRukcei5OLRWI9jBA== X-Received: by 2002:aa7:ce16:0:b0:51e:5251:8f45 with SMTP id d22-20020aa7ce16000000b0051e52518f45mr1222389edv.4.1690530280006; Fri, 28 Jul 2023 00:44:40 -0700 (PDT) Received: from mariano ([82.84.192.32]) by smtp.gmail.com with ESMTPSA id i6-20020aa7dd06000000b0051df5bd1cd8sm1496266edv.65.2023.07.28.00.44.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Jul 2023 00:44:38 -0700 (PDT) Received: by mariano (Postfix, from userid 1000) id AFA42BFB73; Fri, 28 Jul 2023 09:44:37 +0200 (CEST) Date: Fri, 28 Jul 2023 09:44:37 +0200 From: Stefano Sabatini To: FFmpeg development discussions and patches Message-ID: <20230728074437.GC10927@mariano> Mail-Followup-To: FFmpeg development discussions and patches References: <168820043273.21886.17648463695363628461@lain.khirnov.net> <20230709110529.29490-1-anton@khirnov.net> <2ef05e377ecdcb086d2ec00a0c8d810ff962ca77.camel@amazon.it> <20230717221940.GC10400@mariano> <20230723232727.GB10927@mariano> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.13.2 (2019-12-18) Subject: Re: [FFmpeg-devel] [PATCH] lavu: add AVVideoHint API 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On date Wednesday 2023-07-26 10:52:57 +0000, Carotti, Elias wrote: > On Mon, 2023-07-24 at 01:27 +0200, Stefano Sabatini wrote: > > CAUTION: This email originated from outside of the organization. Do > > not click links or open attachments unless you can confirm the sender > > and know the content is safe. > > = > > = > > = > > > = > > > sorry to nitpick, but if we have this information in the single > > > rect > > > should not we use that instead? > > > = > > > Basically I see two options: > > > 1. generic VideoHint, storing single hint type and rects > > > = > > > for example we might have type=3Dchanged, and the rects storing only > > > the > > > changed rects > > > = > > > If we want to extend this then we need to add a new type. The > > > problem > > > might be if we want to store more than one VideoHint in the side > > > data > > > (it it possible to store more than one AVVideoHint, each one with a > > > different type, as side data?). Suppose for example we want to add > > > a > > > new hint type, e.g. ROI, then we can add a new AVHideoHint with > > > type=3Droi - but I don't know if we can have several frame hint side > > > data (each one with different individual types). > > > = > > > 2. generic VideoHint, storing rects each one containing the hint > > > type > > > = > > > for example we might have a list of rects, each one with > > > type=3Dchanged|constant|roi. This would allow one to store different > > > kind of hints in the same AVVideoHint structure, but at the same > > > time > > > would enable inconsistent data (for example we might have changed > > > and > > > unchanged rects in the same list of rects) > > > = > = > I don't think it allowed such inconsistency the way it was made. > Basically, the semantics was that the Hint type could be either > CONSTANT or CHANGED and that was the basis to interpret the rects with > type DAMAGE. = Yes, but then there is no guarantee that you'll have all rects with the same subtype, and you need to iterate and check each one to check the subtype (so you might have mixed constant/changed and unclear behavior to apply in this case). > > > In each case, storing the type in the generic AVVideHint and in > > > each > > > rect might lead to inconsistent states (e.g. you might have generic > > > type=3Ddamage, and have type=3Droi and type=3Dchanged in the rects), = in > > > this > > > case having the type in both the general structure and in each > > > rects > > > seems redundant and leads to possible data inconsistencies. > > > = > > > ... > > > = > > = > > > I would rather go to solution 1, but I'm not sure if having more > > > than > > > one hint in the side data (with different subtypes) is possible and > > > wanted. If this is the case, probably the best solution would be to > > > store more than one AVVideoHint (each one with an individual type > > > and > > > list of rects) in the single side data object. > > = > > Elaborating on this. > > = > > 1. Ideally we might want to extend the av_frame_get_side_data API to > > be able to store more than one entry per side data, by adding a > > unique > > label to the side data, but this requires probably more effort and > > extends the scope even further. > > = > > 2. Alternatively, we might extend the hint API like this: > > = > > AVVideoHint *av_video_hint_create_side_data(AVFrame *frame, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 size_t nb_rect= s); > > = > > AVVideoHint *av_video_hint_extend_side_data(AVFrame *frame, > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 size_t nb_rect= s); > > = > > by marking the continuation on the previous hint (but this would > > complicate deserialization as you need then to iterate to get all the > > side data). > > = > > Or we could make a variadic function like this: > > AVVideoHint *av_video_hint_create_side_data(AVFrame *frame, size_t > > nb_rects, ...); > > = > > Alternatively, we might store in AVVideoHint more than one hint, but > > this somehow conflict with the general design. > > = > > ... > > = > > As a low effort approach, I would keep the initial design of a single > > hint type per side-data (dropping the possibility of having more than > > one hint type in the same side data), which should be fixed > > generically by implementing 1. > = > Agreed. > For clarity I am attaching again the patch with Anton's changes just > rebased on the current master branch. > Anton, is this still ok to be merged? I'm fine with the current patch, the behavior can then be extended by extending side data with multiple-label for the same type. Anton, if you are fine with it I would merge this one (and maybe get included in the next release if we are not too late already). Thanks. _______________________________________________ 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".