Re: [FFmpeg-devel] [PATCH] avformat/hls: use av_strlcopy instead of strncpy
Leo Izen 于2023年10月26日周四 11:14写道：
>
> Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
> strncpy.
>
> Signed-off-by: Leo Izen
> ---
> libavformat/hls.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index f5f549b24d..076f92ecfb 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -543,7 +543,7 @@ static struct rendition *new_rendition(HLSContext *c,
> struct rendition_info *inf
> int langlen = strlen(rend->language);
> if (langlen < sizeof(rend->language) - 3) {
> rend->language[langlen] = ',';
> -strncpy(rend->language + langlen + 1, info->assoc_language,
> +av_strlcpy(rend->language + langlen + 1, info->assoc_language,
> sizeof(rend->language) - langlen - 2);
> }
> }
> --
> 2.42.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
LGTM
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hls: use av_strlcopy instead of strncpy
Avoids a -Wstringop-truncation warning by using av_strlcopy instead of
strncpy.
Signed-off-by: Leo Izen
---
libavformat/hls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f5f549b24d..076f92ecfb 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -543,7 +543,7 @@ static struct rendition *new_rendition(HLSContext *c,
struct rendition_info *inf
int langlen = strlen(rend->language);
if (langlen < sizeof(rend->language) - 3) {
rend->language[langlen] = ',';
-strncpy(rend->language + langlen + 1, info->assoc_language,
+av_strlcpy(rend->language + langlen + 1, info->assoc_language,
sizeof(rend->language) - langlen - 2);
}
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] vulkan: return VK_NOT_READY when no queries are available
Fixes a validation issue.
The issue is that the function gets called before we've sumitted a frame
for decoding to that context. However, we cannot run queries before
they've been reset, which happens at submission time.
As we'd need to otherwise run a command queue at init-time, just check
if submissions have happened.
Patch attached.
>From 833a1c249f5e41305fe8ea68f5e2453a5505817d Mon Sep 17 00:00:00 2001
From: Lynne
Date: Wed, 25 Oct 2023 22:58:20 +
Subject: [PATCH] vulkan: return VK_NOT_READY when no queries are available
Fixes a validation issue.
The issue is that the function gets called before we've sumitted a frame
for decoding to that context. However, we cannot run queries before
they've been reset, which happens at submission time.
As we'd need to otherwise run a command queue at init-time, just check
if submissions have happened.
---
libavutil/vulkan.c | 5 +
libavutil/vulkan.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index dec8ccad64..5674ec2943 100644
--- a/libavutil/vulkan.c
+++ b/libavutil/vulkan.c
@@ -456,6 +456,9 @@ VkResult ff_vk_exec_get_query(FFVulkanContext *s, FFVkExecContext *e,
int64_t res = 0;
VkQueryResultFlags qf = 0;
+if (!e->has_query)
+return VK_NOT_READY;
+
qf |= pool->query_64bit ?
VK_QUERY_RESULT_64_BIT : 0x0;
qf |= pool->query_statuses ?
@@ -779,6 +782,8 @@ int ff_vk_exec_submit(FFVulkanContext *s, FFVkExecContext *e)
}
}
+e->has_query = 1;
+
return 0;
}
diff --git a/libavutil/vulkan.h b/libavutil/vulkan.h
index 25c5ad4b74..3069dd27c2 100644
--- a/libavutil/vulkan.h
+++ b/libavutil/vulkan.h
@@ -168,6 +168,7 @@ typedef struct FFVkExecContext {
void *query_data;
int query_idx;
+int has_query;
/* Buffer dependencies */
AVBufferRef **buf_deps;
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Mon, Oct 23, 2023 at 05:56:48PM -0700, Vittorio Giovara wrote: > On Sat, Oct 21, 2023 at 4:20 PM Michael Niedermayer > wrote: > > > On Fri, Oct 20, 2023 at 07:13:00PM -0400, Ronald S. Bultje wrote: > > > Hi, > > > > > > On Fri, Oct 20, 2023 at 12:14 PM Vittorio Giovara < > > > vittorio.giov...@gmail.com> wrote: > > > > > > > tbh while it's great that this functionality exists *somewhere* in > > ffmpeg, > > > > this is really something that should belong to the scaler filter > > (whichever > > > > implementation) > > > > > > > > > > I agree. The reason this was done separately was to be able to have it at > > > all. I considered doing it in sws and realized I probably wouldn't finish > > > it. This was a path of less resistance. > > > > sws supports cascaded_context, with that a sws can just spawn multiple > > sws to implement a path. > > so if a sws can do just colorspace1->colorspace2 and one can scale > > colorspace2 you can quite easily make it support > > colorspace1 scaling into colorspace2 for example > > > > so anything should be quite add-able into sws that you have an > > implementation for > > > > Nothing is quite easily add-able to sws, If you have any difficulty with sws, please ask me, iam here to help > or developers would have done so > instead of writing 4 different scaling libraries People create new libraries, new platforms and new applications all the time for a wide range of reasons other that "Nothing is quite easily add-able" thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cbs_av1: Reject thirty-two zero bits in uvlc code
On Sun, Oct 22, 2023 at 07:35:52PM +0100, Mark Thompson wrote: > The spec allows at least thirty-two zero bits followed by a one to mean > 2^32-1, with no constraint on the number of zeroes. The libaom > reference decoder does not match this, instead reading thirty-two zeroes > but not the following one to mean 2^32-1. These two interpretations are > incompatible and other implementations may follow one or the other. > Therefore reject thirty-two zeroes because the intended behaviour is not > clear. > --- > libaom, dav1d and SVT-AV1 all have the same nonstandard behaviour of stopping > at thirty-two zeroes and not reading the one. gav1 just rejects thirty-two > zeroes. I would suggest to contact the authors of the spec to bring this discrepancy to their attention, unless this is already known and unless this sequence is declared invalid by some other part of the spec (which would make the discrepancy only occur in invalid sequences) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mlp*: improvements
On Wed, Oct 25, 2023 at 9:03 PM Tomas Härdin wrote:
> On Wed, 2023-10-25 at 21:00 +0200, Paul B Mahol wrote:
> > On Wed, Oct 25, 2023 at 8:39 PM Tomas Härdin wrote:
> >
> > >
> > > > if (c) {
> > > > e[0] = 1 << 14;
> > > > e[1] = 0 << 14;
> > > > e[2] = v[1];
> > > > e[3] = v[0];
> > > > } else {
> > > > e[0] = v[0];
> > > > e[1] = v[1];
> > > > e[2] = 0 << 14;
> > > > e[3] = 1 << 14;
> > > > }
> > > >
> > > > if (invert2x2(e, d)) {
> > > > sum = UINT64_MAX;
> > > > goto next;
> > > > }
> > > >
> > >
> > > You can make use of the properties of e to simplify calculating the
> > > inverse. The determinant is always v[0]<<14, so you can just do if
> > > (!v[0]) continue; and skip the determinant check altogether.
> > >
> >
> > Even for real 2x2 matrix case? (Once one of rows is not 1, 0) ?
> > May added such cases later.
>
> You can just work the math out on paper. Inverse of
>
> 1 0
> v[1] v[0]
>
> is
>
> 1 0
> -v[1]/v[0] 1/v[0]
>
> not accounting for shifts.
>
But I want to add real 2x2 matrix with no 0 cell, with:
a, b
c, d
later. (even though gains are small, as encoded files use it rarely)
>
> Also RE: my other comments, you are right. I didn't take into account
> that MLP is lossless and that there may be off-by-one errors.
>
> And as I said on IRC you can formulate this as a least squares problem,
> then solve it using a linear system solve. This patch seems finds a
> solution that minimizes L1 rather than L2 though. Not sure what the
> implications of that are compressionwise. What happens if you replace
> FFABS() with a square for scoring?
>
It reduces size usually by less then 0.002 %
Linear system solver gives vectors to create equations for both channels at
same time?
>
> /Tomas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] vulkan_decode: fix another validation issue
Oct 25, 2023, 01:43 by d...@lynne.ee: > Surprising no one, the insane usage rule has a catch. > > Only happens in the layered_dpb path, which was poorly tested. > > Fixes: > "[AVHWDeviceContext @ 0x557f4b87dc00] Validation Error: [ > VUID-VkImageMemoryBarrier2-srcQueueFamilyIndex-07122 ] Object 0: handle = > 0xaf316ce, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xfe471484 | > vkCmdPipelineBarrier2(): pDependencyInfo->pImageMemoryBarriers[0].oldLayout > (VK_IMAGE_LAYOUT_VIDEO_DECODE_DPB_KHR) is not compatible with VkImage > 0xaf316ce[] usage flags 0x405. The Vulkan spec states: If > srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership > transfer or oldLayout and newLayout define an image layout transition, and > oldLayout or newLayout is VK_IMAGE_LAYOUT_VIDEO_DECODE_DPB_KHR then image > must have been created with VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR > (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkImageMemoryBarrier2-srcQueueFamilyIndex-07122) > " > > Patch attached. > Pushed along the coded_width/height patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: introduce AVStreamGroup
On 10/25/2023 4:25 PM, Tomas Härdin wrote:
+enum AVStreamGroupParamsType {
+ AV_STREAM_GROUP_PARAMS_NONE,
Maybe AV_STREAM_GROUP_PARAMS_NUM on the end?
For what purpose? Usually, when we add those values they are not part of
the API and exist for some internal iteration.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Am 25.10.23 um 19:39 schrieb Rémi Denis-Courmont: Hi, Le 25 octobre 2023 18:52:31 GMT+03:00, Thilo Borgmann via ffmpeg-devel a écrit : Am 25.10.23 um 16:23 schrieb Thilo Borgmann via ffmpeg-devel: Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont: Hi, I am not on the GA, but there are probably people with my locale on the GA. And it seems that the voting system hits a Perl syntax error if your browser locale is set to French. Can you send me a screenshot? Thanks. That appears to be a perl bug, Not going to touch that on the server atm. So sorry, switch to english or use another device for now. That seems to makes no difference (Firefox on Android). The language setting seem to only change the GUI, not whatever the Perl CGI uses (Accept-Language header?). Objectively, it really does not matter insofar as we are dealing solely with non-GA members such as I. But if I were to play devil's advocate, you may be serving on a plate a pretext for some future dissatisfied voters to call the voting process invalid later, or worse, maybe even allege xenophobic discrimination (this does *not* represent my opinion and is *not* meant to constitute an actual serious accusation). Either way it might be a problem in the particular context of this project, especially in light of the abundance of formality from Anton's original post. Not that I'd have a solution. Feel free to ignore. Not a perl "bug" but per-se but something changed about validity of my(my..., my...) constructs. There is a patch for the CIVS source which is two years old [1]. That perl "update" seems to have happened after our last vote (where this issue was non-existant afaict) and today. I'll try to find some time tomorrow to adapt the source on the server and let you know to retest your vote. Should effect french, hungarian and italian. -Thilo [1] https://github.com/andrewcmyers/civs/commit/9578227a1b37c87437bfbf545e0595aa371cf621 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Hi Anton first let me say, this looks much better setup than the previous attempt by jb On Tue, Oct 24, 2023 at 11:15:19PM +0200, Anton Khirnov wrote: > Hi all, > as discussed at the dev meeting at VDD, we need to have a series of > votes, the first of which concerns defining when is the GA voter list to > be updated. > > As the previous attempt to vote on this was hampered by email delivery > issues, and also criticized due to inadequate advance announcement, the > vote was closed and we are going to try again. > > This time, to avoid any confusion, let me clearly state that this is a > declaration of intent to initiate a GA vote next Monday (2023-10-30), > unless there are substantial objections. > > The vote question will be: >How do we update the list of active members of the general assembly? > > Proposed possibilities so far are: > * twice a year (1st Jan & 1st July) > (suggested at VDD) > * before each vote > (suggested at VDD) > * never (keep the 2020 version) > (suggested at VDD) > * keep everyone who had vote rights but add active developers each jan/july > (suggested by Michael on the ML) > > Feel welcome to propose additional possibilities until Friday > 2023-10-27. > > Other constructive comments also welcome. First i suggest s#jan/july#1st Jan & 1st July# Second i suggest to pick a time too, like 0:00 UTC Third, for future votes i suggest to lengthen the period of proposing of additional possibilities. Here we all maybe have seen this already but. If this was new than 2-3 days really is too short. That period needs to include discussion and thinking for a person who might be working 8 hour a day on something unrelated to FFmpeg. There may be more but thats what comes to my mind ATM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat: introduce AVStreamGroup
>
> +enum AVStreamGroupParamsType {
> + AV_STREAM_GROUP_PARAMS_NONE,
Maybe AV_STREAM_GROUP_PARAMS_NUM on the end?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
> On Oct 25, 2023, at 10:39 AM, Rémi Denis-Courmont wrote: > > Objectively, it really does not matter insofar as we are dealing solely with > non-GA members such as I. But if I were to play devil's advocate, you may be > serving on a plate a pretext for some future dissatisfied voters to call the > voting process invalid later, or worse, maybe even allege xenophobic > discrimination (this does *not* represent my opinion and is *not* meant to > constitute an actual serious accusation). Either way it might be a problem in > the particular context of this project, especially in light of the abundance > of formality from Anton's original post. I don't think the intent is to leave this broken. This first test is intended to confirm the email deliverability though so perhaps we can focus on that for now. Then we can circle back on fixing the server side voting software to deal with different locales. - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/jpeg2000dec: Check image offset
On Thu, 2023-10-05 at 00:59 +0200, Michael Niedermayer wrote:
> Fixes: left shift of negative value -538967841
> Fixes: 62447/clusterfuzz-testcase-minimized-
> ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6427134337613824
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/jpeg2000dec.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index eda959e558d..691cfbd8915 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -238,6 +238,11 @@ static int get_siz(Jpeg2000DecoderContext *s)
> return AVERROR_INVALIDDATA;
> }
>
> + if (s->image_offset_x >= s->width || s->image_offset_y >= s-
> >height) {
> + av_log(s->avctx, AV_LOG_ERROR, "image offsets outside
> image");
> + return AVERROR_INVALIDDATA;
> + }
Probably OK
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mlp*: improvements
On Wed, 2023-10-25 at 21:00 +0200, Paul B Mahol wrote:
> On Wed, Oct 25, 2023 at 8:39 PM Tomas Härdin wrote:
>
> >
> > > if (c) {
> > > e[0] = 1 << 14;
> > > e[1] = 0 << 14;
> > > e[2] = v[1];
> > > e[3] = v[0];
> > > } else {
> > > e[0] = v[0];
> > > e[1] = v[1];
> > > e[2] = 0 << 14;
> > > e[3] = 1 << 14;
> > > }
> > >
> > > if (invert2x2(e, d)) {
> > > sum = UINT64_MAX;
> > > goto next;
> > > }
> > >
> >
> > You can make use of the properties of e to simplify calculating the
> > inverse. The determinant is always v[0]<<14, so you can just do if
> > (!v[0]) continue; and skip the determinant check altogether.
> >
>
> Even for real 2x2 matrix case? (Once one of rows is not 1, 0) ?
> May added such cases later.
You can just work the math out on paper. Inverse of
1 0
v[1] v[0]
is
1 0
-v[1]/v[0] 1/v[0]
not accounting for shifts.
Also RE: my other comments, you are right. I didn't take into account
that MLP is lossless and that there may be off-by-one errors.
And as I said on IRC you can formulate this as a least squares problem,
then solve it using a linear system solve. This patch seems finds a
solution that minimizes L1 rather than L2 though. Not sure what the
implications of that are compressionwise. What happens if you replace
FFABS() with a square for scoring?
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mlp*: improvements
On Wed, Oct 25, 2023 at 8:39 PM Tomas Härdin wrote:
>
> > if (c) {
> > e[0] = 1 << 14;
> > e[1] = 0 << 14;
> > e[2] = v[1];
> > e[3] = v[0];
> > } else {
> > e[0] = v[0];
> > e[1] = v[1];
> > e[2] = 0 << 14;
> > e[3] = 1 << 14;
> > }
> >
> > if (invert2x2(e, d)) {
> > sum = UINT64_MAX;
> > goto next;
> > }
> >
>
> You can make use of the properties of e to simplify calculating the
> inverse. The determinant is always v[0]<<14, so you can just do if
> (!v[0]) continue; and skip the determinant check altogether.
>
Even for real 2x2 matrix case? (Once one of rows is not 1, 0) ?
May added such cases later.
>
> > if (d[i] != av_clip_intp2(d[i], 15)) {
>
> d[i] < INT16_MIN || d[i] > INT16_MAX is more clear and probably faster
>
> > +lt = ((lm * e[0]) >> 14) + ((rm * e[1]) >> 14);
> > +rt = ((lm * e[2]) >> 14) + ((rm * e[3]) >> 14);
>
> Result is implementation-defined. Use division by (1<<14). Also add
> then divide. The intermediate result is 49 bits so fits easily in 64
> bits.
>
> You could also simplify this calculation by again making use of the
> properties of e.
>
> > if (c)
> > v += FFABS(rt);
> > else
> > v += FFABS(lt);
> > sum += v;
> > if (sum > best_sum)
> > goto next;
>
> Seems like this reduces to solving a linear program.
>
> > if lt * d[0]) >> 14) + ((rt * d[1]) >> 14))
> > != lm) {
> > sum = UINT64_MAX;
> > goto next;
> > }
> >
> > if lt * d[2]) >> 14) + ((rt * d[3]) >> 14))
> > != rm) {
> > sum = UINT64_MAX;
> > goto next;
> > }
>
> Looks like a massive hack. I'd prefer to formally verify that the
> arithmetic works out. Also again you can make use of the properties of
> e, or inv(e) as it were.
>
> /Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mlp*: improvements
On Wed, Oct 25, 2023 at 8:39 PM Tomas Härdin wrote:
>
> > if (c) {
> > e[0] = 1 << 14;
> > e[1] = 0 << 14;
> > e[2] = v[1];
> > e[3] = v[0];
> > } else {
> > e[0] = v[0];
> > e[1] = v[1];
> > e[2] = 0 << 14;
> > e[3] = 1 << 14;
> > }
> >
> > if (invert2x2(e, d)) {
> > sum = UINT64_MAX;
> > goto next;
> > }
> >
>
> You can make use of the properties of e to simplify calculating the
> inverse. The determinant is always v[0]<<14, so you can just do if
> (!v[0]) continue; and skip the determinant check altogether.
>
> > if (d[i] != av_clip_intp2(d[i], 15)) {
>
> d[i] < INT16_MIN || d[i] > INT16_MAX is more clear and probably faster
>
> > +lt = ((lm * e[0]) >> 14) + ((rm * e[1]) >> 14);
> > +rt = ((lm * e[2]) >> 14) + ((rm * e[3]) >> 14);
>
> Result is implementation-defined. Use division by (1<<14). Also add
> then divide. The intermediate result is 49 bits so fits easily in 64
> bits.
>
Division by (1<<14) will give incorrect results. been there done that,
you can check all your "reviews" validity by testing patches and that
results is bitexact, otherwise I'm just wasting time here.
Additions are done before not later, again check your comments validity
before commenting more. Thanks.
> You could also simplify this calculation by again making use of the
> properties of e.
>
> > if (c)
> > v += FFABS(rt);
> > else
> > v += FFABS(lt);
> > sum += v;
> > if (sum > best_sum)
> > goto next;
>
> Seems like this reduces to solving a linear program.
>
> > if lt * d[0]) >> 14) + ((rt * d[1]) >> 14))
> > != lm) {
> > sum = UINT64_MAX;
> > goto next;
> > }
> >
> > if lt * d[2]) >> 14) + ((rt * d[3]) >> 14))
> > != rm) {
> > sum = UINT64_MAX;
> > goto next;
> > }
>
> Looks like a massive hack. I'd prefer to formally verify that the
> arithmetic works out. Also again you can make use of the properties of
> e, or inv(e) as it were.
>
Arithmetic may not always work out.
>
> /Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mlp*: improvements
> if (c) {
> e[0] = 1 << 14;
> e[1] = 0 << 14;
> e[2] = v[1];
> e[3] = v[0];
> } else {
> e[0] = v[0];
> e[1] = v[1];
> e[2] = 0 << 14;
> e[3] = 1 << 14;
> }
>
> if (invert2x2(e, d)) {
> sum = UINT64_MAX;
> goto next;
> }
>
You can make use of the properties of e to simplify calculating the
inverse. The determinant is always v[0]<<14, so you can just do if
(!v[0]) continue; and skip the determinant check altogether.
> if (d[i] != av_clip_intp2(d[i], 15)) {
d[i] < INT16_MIN || d[i] > INT16_MAX is more clear and probably faster
> +lt = ((lm * e[0]) >> 14) + ((rm * e[1]) >> 14);
> +rt = ((lm * e[2]) >> 14) + ((rm * e[3]) >> 14);
Result is implementation-defined. Use division by (1<<14). Also add
then divide. The intermediate result is 49 bits so fits easily in 64
bits.
You could also simplify this calculation by again making use of the
properties of e.
> if (c)
> v += FFABS(rt);
> else
> v += FFABS(lt);
> sum += v;
> if (sum > best_sum)
> goto next;
Seems like this reduces to solving a linear program.
> if lt * d[0]) >> 14) + ((rt * d[1]) >> 14))
> != lm) {
> sum = UINT64_MAX;
> goto next;
> }
>
> if lt * d[2]) >> 14) + ((rt * d[3]) >> 14))
> != rm) {
> sum = UINT64_MAX;
> goto next;
> }
Looks like a massive hack. I'd prefer to formally verify that the
arithmetic works out. Also again you can make use of the properties of
e, or inv(e) as it were.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Hi, Le 25 octobre 2023 18:52:31 GMT+03:00, Thilo Borgmann via ffmpeg-devel a écrit : >Am 25.10.23 um 16:23 schrieb Thilo Borgmann via ffmpeg-devel: >> Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont: >>> Hi, >>> >>> I am not on the GA, but there are probably people with my locale on the GA. >>> And it seems that the voting system hits a Perl syntax error if your >>> browser locale is set to French. >> >> Can you send me a screenshot? > >Thanks. That appears to be a perl bug, Not going to touch that on the server >atm. > >So sorry, switch to english or use another device for now. That seems to makes no difference (Firefox on Android). The language setting seem to only change the GUI, not whatever the Perl CGI uses (Accept-Language header?). Objectively, it really does not matter insofar as we are dealing solely with non-GA members such as I. But if I were to play devil's advocate, you may be serving on a plate a pretext for some future dissatisfied voters to call the voting process invalid later, or worse, maybe even allege xenophobic discrimination (this does *not* represent my opinion and is *not* meant to constitute an actual serious accusation). Either way it might be a problem in the particular context of this project, especially in light of the abundance of formality from Anton's original post. Not that I'd have a solution. Feel free to ignore. >Thanks, >Thilo >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >To unsubscribe, visit link above, or email >ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Received. > On Oct 25, 2023, at 07:22, Rémi Denis-Courmont wrote: > > Hi, > > I am not on the GA, but there are probably people with my locale on the GA. > And it seems that the voting system hits a Perl syntax error if your browser > locale is set to French. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Am 25.10.23 um 16:23 schrieb Thilo Borgmann via ffmpeg-devel: Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont: Hi, I am not on the GA, but there are probably people with my locale on the GA. And it seems that the voting system hits a Perl syntax error if your browser locale is set to French. Can you send me a screenshot? Thanks. That appears to be a perl bug, Not going to touch that on the server atm. So sorry, switch to english or use another device for now. Thanks, Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/vidstab: add option for file format specification
On 2023-10-22 05:26 pm, Gyan Doshi wrote:
The vidstab library added support in Nov 2020 for writing/reading
the transforms data in binary in addition to ASCII. The library default
was changed to binary format but no changes were made to the AVfilters
resulting in data file for writing or reading being always opened as text.
This effectively broke the filters.
Option added to vidstabdetect to specify file format and open files in
both filters with the correct attributes.
Plan to push tomorrow barring objections.
Regards,
Gyan
---
doc/filters.texi | 13 +
libavfilter/vf_vidstabdetect.c| 15 ++-
libavfilter/vf_vidstabtransform.c | 2 +-
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index f5032ddf74..cc5d0d3f12 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -24618,6 +24618,19 @@ If set to 0, it is disabled. The frames are counted
starting from 1.
Show fields and transforms in the resulting frames. It accepts an
integer in the range 0-2. Default value is 0, which disables any
visualization.
+
+@item fileformat
+Format for the transforms data file to be written.
+Acceptable values are
+
+@table @samp
+@item ascii
+Human-readable plain text
+
+@item binary
+Binary format, roughly 40% smaller than @code{ascii}. (@emph{default})
+@end table
+
@end table
@subsection Examples
diff --git a/libavfilter/vf_vidstabdetect.c b/libavfilter/vf_vidstabdetect.c
index a2c6d89503..aa050afab9 100644
--- a/libavfilter/vf_vidstabdetect.c
+++ b/libavfilter/vf_vidstabdetect.c
@@ -40,6 +40,7 @@ typedef struct StabData {
VSMotionDetectConfig conf;
char *result;
+int fileformat;
FILE *f;
} StabData;
@@ -58,6 +59,11 @@ static const AVOption vidstabdetect_options[] = {
{"show","0: draw nothing; 1,2: show fields and transforms",
OFFSETC(show), AV_OPT_TYPE_INT,{.i64 = 0}, 0, 2, FLAGS},
{"tripod", "virtual tripod mode (if >0): motion is compared to a
reference"
" reference frame (frame # is the value)",
OFFSETC(virtualTripod), AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, FLAGS},
+#ifdef LIBVIDSTAB_FILE_FORMAT_VERSION
+{ "fileformat", "transforms data file format", OFFSET(fileformat),
AV_OPT_TYPE_INT, {.i64 = BINARY_SERIALIZATION_MODE}, ASCII_SERIALIZATION_MODE, BINARY_SERIALIZATION_MODE,
FLAGS, "file_format"},
+{ "ascii","ASCII text", 0, AV_OPT_TYPE_CONST, {.i64 =
ASCII_SERIALIZATION_MODE }, 0, 0, FLAGS, "file_format"},
+{ "binary", "binary", 0, AV_OPT_TYPE_CONST, {.i64 =
BINARY_SERIALIZATION_MODE}, 0, 0, FLAGS, "file_format"},
+#endif
{NULL}
};
@@ -94,6 +100,13 @@ static int config_input(AVFilterLink *inlink)
VSFrameInfo fi;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
int is_planar = desc->flags & AV_PIX_FMT_FLAG_PLANAR;
+const char *file_mode = "w";
+
+#ifdef LIBVIDSTAB_FILE_FORMAT_VERSION
+md->serializationMode = s->fileformat;
+if (s->fileformat == BINARY_SERIALIZATION_MODE)
+file_mode = "wb";
+#endif
vsFrameInfoInit(&fi, inlink->w, inlink->h,
ff_av2vs_pixfmt(ctx, inlink->format));
@@ -129,7 +142,7 @@ static int config_input(AVFilterLink *inlink)
av_log(ctx, AV_LOG_INFO, " show = %d\n", s->conf.show);
av_log(ctx, AV_LOG_INFO, "result = %s\n", s->result);
-s->f = avpriv_fopen_utf8(s->result, "w");
+s->f = avpriv_fopen_utf8(s->result, file_mode);
if (s->f == NULL) {
av_log(ctx, AV_LOG_ERROR, "cannot open transform file %s\n",
s->result);
return AVERROR(EINVAL);
diff --git a/libavfilter/vf_vidstabtransform.c
b/libavfilter/vf_vidstabtransform.c
index 8a66a463b4..f49d302b80 100644
--- a/libavfilter/vf_vidstabtransform.c
+++ b/libavfilter/vf_vidstabtransform.c
@@ -193,7 +193,7 @@ static int config_input(AVFilterLink *inlink)
av_log(ctx, AV_LOG_INFO, "zoomspeed = %g\n", tc->conf.zoomSpeed);
av_log(ctx, AV_LOG_INFO, "interpol = %s\n",
getInterpolationTypeName(tc->conf.interpolType));
-f = avpriv_fopen_utf8(tc->input, "r");
+f = avpriv_fopen_utf8(tc->input, "rb");
if (!f) {
int ret = AVERROR(errno);
av_log(ctx, AV_LOG_ERROR, "cannot open input file %s\n", tc->input);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Am 25.10.23 um 16:22 schrieb Rémi Denis-Courmont: Hi, I am not on the GA, but there are probably people with my locale on the GA. And it seems that the voting system hits a Perl syntax error if your browser locale is set to French. Can you send me a screenshot? -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Hi, I am not on the GA, but there are probably people with my locale on the GA. And it seems that the voting system hits a Perl syntax error if your browser locale is set to French. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 39/42] avcodec/hevcdec: Move collocated_ref to HEVCContext
Quoting Andreas Rheinhardt (2023-09-19 21:57:31) > Only the collocated_ref of the current frame (i.e. HEVCContext.ref) > is ever used*, so move it to HEVCContext directly after ref. > > *: This goes so far that collocated_ref was not even synced across > threads in case of frame-threading. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/hevc_mvs.c | 2 +- > libavcodec/hevc_refs.c | 5 ++--- > libavcodec/hevcdec.c | 6 +++--- > libavcodec/hevcdec.h | 2 +- > 4 files changed, 7 insertions(+), 8 deletions(-) Ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 38/42] avcodec/codec_internal: Remove FF_CODEC_CAP_ALLOCATE_PROGRESS
Quoting Andreas Rheinhardt (2023-09-19 21:57:30) > Before commit f025b8e110b36c1cdb4fb56c4cd57aeca1767b5b, > every frame-threaded decoder used ThreadFrames, even when > they did not have any inter-frame dependencies at all. > In order to distinguish those decoders that need the AVBuffer > for progress communication from those that do not (to avoid > the allocation for the latter), the former decoders were marked > with the FF_CODEC_CAP_ALLOCATE_PROGRESS internal codec cap. > > Yet distinguishing these two can be done in a more natural way: > Don't use ThreadFrames when not needed and split ff_thread_get_buffer() > into a core function that calls the user's get_buffer2 callback > and a wrapper around it that also allocates the progress AVBuffer. > This has been done in 02220b88fc38ef9dd4f2d519f5d3e4151258b60c > and since that commit the ALLOCATE_PROGRESS cap was nearly redundant. > > The only exception was WebP and VP8. WebP can contain VP8 > and uses the VP8 decoder directly (i.e. they share the same > AVCodecContext). Both decoders are frame-threaded and VP8 > has inter-frame dependencies (in general, not in valid WebP) > and therefore the ALLOCATE_PROGRESS cap. In order to avoid > allocating progress in case of a frame-threaded WebP decoder > the cap and the check for the cap has been kept in place. > > Yet now the VP8 decoder has been switched to use ProgressFrames > and therefore there is just no reason any more for this check > and the cap. This commit therefore removes both. > > Also change the value of FF_CODEC_CAP_USES_PROGRESSFRAMES > to leave no gaps. > > Signed-off-by: Andreas Rheinhardt > --- > doc/multithreading.txt | 8 > libavcodec/codec_internal.h | 7 +-- > libavcodec/ffv1dec.c| 3 +-- > libavcodec/h264dec.c| 2 +- > libavcodec/hevcdec.c| 2 +- > libavcodec/mpeg4videodec.c | 3 +-- > libavcodec/pngdec.c | 3 +-- > libavcodec/pthread_frame.c | 12 +--- > libavcodec/rv30.c | 1 - > libavcodec/rv40.c | 1 - > libavcodec/tests/avcodec.c | 7 +-- > 11 files changed, 16 insertions(+), 33 deletions(-) LGTM -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 37/42] avcodec/vp8: Convert to ProgressFrame API
Quoting Andreas Rheinhardt (2023-09-19 21:57:29) > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/vp8.c | 90 +++ > libavcodec/vp8.h | 5 +-- > libavcodec/webp.c | 3 +- > 3 files changed, 33 insertions(+), 65 deletions(-) Looks ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 35/42] avcodec/threadprogress: Add new API for frame-threaded progress
Quoting Andreas Rheinhardt (2023-09-19 21:57:27) > The API is very similar by the ProgressFrame API, with the exception > that it no longer has an included AVFrame. Instead one can wait > on anything via a ThreadProgress. One just has to ensure that > the lifetime of the object containing the ThreadProgress is long > enough (the corresponding problem for ProgressFrames is solved > by allocating the progress and giving each thread a reference > to it). This will typically be solved by putting a ThreadProgress > in a refcounted structure that is shared between threads. > It will be put to the test in the following commits. > > An alternative to the check for whether the owner exists > (meaning "do we use frame-threading?") would be to initialize > the progress to INT_MAX in case frame threading is not in use. > This would probably be preferable on arches where atomic reads > are cheap (like x86), but are there ones where it is not? > > One could also (guarded by e.g. an ASSERT_LEVEL check) actually > track the progress for non-framethreading, too, in order to > track errors even in single-threaded mode. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/pthread_frame.c | 50 + > libavcodec/threadprogress.h | 37 +++ > 2 files changed, 87 insertions(+) > create mode 100644 libavcodec/threadprogress.h Again, I'd prefer to do without owner. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming GA vote
Hi, Am 24.10.23 um 23:15 schrieb Anton Khirnov: Hi all, as discussed at the dev meeting at VDD, we need to have a series of votes, the first of which concerns defining when is the GA voter list to be updated. As the previous attempt to vote on this was hampered by email delivery issues, and also criticized due to inadequate advance announcement, the vote was closed and we are going to try again. This time, to avoid any confusion, let me clearly state that this is a declaration of intent to initiate a GA vote next Monday (2023-10-30), unless there are substantial objections. The vote question will be: How do we update the list of active members of the general assembly? Proposed possibilities so far are: * twice a year (1st Jan & 1st July) (suggested at VDD) * before each vote (suggested at VDD) * never (keep the 2020 version) (suggested at VDD) * keep everyone who had vote rights but add active developers each jan/july (suggested by Michael on the ML) Feel welcome to propose additional possibilities until Friday 2023-10-27. Other constructive comments also welcome. To test the voting beforehand this time, I created a test vote with a fake-GA member list. All of the following people should have received a corresponding mail. If you are part of this list, but did not receive an email, check your spam folder for the sender: ffmpeg.vot...@mail.de. Please comment if you didn't get the mail. The list is as follows: andreas.rheinha...@gmail.com andriy.gel...@gmail.com an...@khirnov.net barryjz...@tencent.com ceffm...@gmail.com c...@passwd.hu dcni...@gmail.com derek.buitenh...@gmail.com d...@lynne.ee devin.heitmuel...@ltnglobal.com epira...@gmail.com ffm...@gyani.pro geo...@nsup.org g...@haasn.dev haihao.xi...@intel.com jamr...@gmail.com jan.ekst...@24i.com j...@itanimul.li jianhua...@intel.com lance.lmw...@gmail.com leo.i...@gmail.com linjie.justin...@gmail.com liuq...@kuaishou.com mar...@martin.st mich...@niedermayer.cc nuomi2...@gmail.com one...@gmail.com p...@palemieux.com phil...@overt.org pr...@xvid.org rco...@rcombs.me r...@remlab.net shubhanshu@gmail.com softwo...@hotmail.com stefa...@gmail.com s...@jkqxz.net thilo.borgm...@mail.de t...@rothenpieler.org u...@pkh.me vittorio.giov...@gmail.com wenbin.c...@intel.com yejun@intel.com z...@zanevaniperen.com zhiliz...@tencent.com -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/demux: use producer timestamp as wallclock when available
When use_wallclock_as_timestamps option is enabled the demux rely on
the time of the system even when a producer wallclock is available.
If a Producer Reference Timestamp is available use it instead of the
system timestamp.
Signed-off-by: Clément Péron
---
libavformat/demux.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 6decb08698..94a622e0cc 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -635,8 +635,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
force_codec_ids(s, st);
/* TODO: audio: time filter; video: frame reordering (pts != dts) */
-if (s->use_wallclock_as_timestamps)
-pkt->dts = pkt->pts = av_rescale_q(av_gettime(), AV_TIME_BASE_Q,
st->time_base);
+if (s->use_wallclock_as_timestamps) {
+AVProducerReferenceTime *prft;
+size_t side_data_size;
+
+// User Producer Reference time as wallclock when available
+prft = (AVProducerReferenceTime *)av_packet_get_side_data(pkt,
AV_PKT_DATA_PRFT, &side_data_size);
+if (prft && side_data_size == sizeof(AVProducerReferenceTime) &&
prft->flags == 24)
+pkt->dts = pkt->pts = av_rescale_q(prft->wallclock,
AV_TIME_BASE_Q, st->time_base);
+else
+pkt->dts = pkt->pts = av_rescale_q(av_gettime(),
AV_TIME_BASE_Q, st->time_base);
+}
if (!pktl && sti->request_probe <= 0)
return 0;
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/mlp*: improvements
Set attached.
From 0e211362a11f58b8cac49b3740c1949b0468541c Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 25 Oct 2023 12:43:13 +0200
Subject: [PATCH 3/4] avcodec/mlpdec: support for truehd with channels not
representable with 5bit field in second stream
Fixes decoding for 4.0/4.1 layouts.
Signed-off-by: Paul B Mahol
---
libavcodec/mlpdec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
index 11b5d2fe98..f1524b95a6 100644
--- a/libavcodec/mlpdec.c
+++ b/libavcodec/mlpdec.c
@@ -452,7 +452,10 @@ static int read_major_sync(MLPDecodeContext *m, GetBitContext *gb)
else
m->substream[2].mask = mh.channel_layout_thd_stream1;
if (m->avctx->ch_layout.nb_channels > 2)
-m->substream[mh.num_substreams > 1].mask = mh.channel_layout_thd_stream1;
+if (mh.num_substreams > 2)
+m->substream[1].mask = mh.channel_layout_thd_stream1;
+else
+m->substream[mh.num_substreams > 1].mask = mh.channel_layout_thd_stream2;
}
m->needs_reordering = mh.channel_arrangement >= 18 && mh.channel_arrangement <= 20;
--
2.42.0
From f5257ca9ed821e9fb3dd9edc3487da4d06ba47a3 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 25 Oct 2023 09:58:24 +0200
Subject: [PATCH 1/4] avcodec/mlpenc: replace naive rematrix with brute-force
search
Signed-off-by: Paul B Mahol
---
libavcodec/mlpenc.c | 183 +++-
1 file changed, 129 insertions(+), 54 deletions(-)
diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
index 6b801605db..27ef5f2c82 100644
--- a/libavcodec/mlpenc.c
+++ b/libavcodec/mlpenc.c
@@ -136,7 +136,8 @@ typedef struct MLPEncodeContext {
int min_restart_interval; ///< Min interval of access units in between two major frames.
int cur_restart_interval;
int lpc_coeff_precision;
-int rematrix_precision;
+int rematrix_search_step;
+int rematrix_search_limit;
int lpc_type;
int lpc_passes;
int prediction_order;
@@ -1399,79 +1400,150 @@ static void determine_filters(MLPEncodeContext *ctx, MLPSubstream *s)
set_filter(ctx, s, ch, 0);
}
+static int invert2x2(const int32_t *s, int32_t *d)
+{
+int64_t det;
+
+d[0] = +s[3];
+d[1] = -s[1];
+d[2] = -s[2];
+d[3] = +s[0];
+
+det = (int64_t)s[0] * d[0] + (int64_t)s[1] * d[2];
+if (det == 0LL)
+return -1;
+
+d[0] = (d[0] * (1LL << 28)) / det;
+d[1] = (d[1] * (1LL << 28)) / det;
+d[2] = (d[2] * (1LL << 28)) / det;
+d[3] = (d[3] * (1LL << 28)) / det;
+
+return 0;
+}
+
static int estimate_coeff(MLPEncodeContext *ctx, MLPSubstream *s,
- MatrixParams *mp,
- int ch0, int ch1)
+ MatrixParams *mp, int ch0, int ch1)
{
-int32_t maxl = INT32_MIN, maxr = INT32_MIN, minl = INT32_MAX, minr = INT32_MAX;
-int64_t summ = 0, sums = 0, suml = 0, sumr = 0, enl = 0, enr = 0;
-const int shift = 14 - ctx->rematrix_precision;
-int32_t cf0, cf1, e[4], d[4], ml, mr;
-int i, count = 0;
+const int search_limit = 1 << ctx->rematrix_search_limit;
+const int search_step = 1 << ctx->rematrix_search_step;
+int32_t best[4], d[4], e[4], count = 0, chan = -1;
+uint64_t best_sum = UINT64_MAX;
+int32_t v[2], inc;
-for (int j = 0; j <= ctx->cur_restart_interval; j++) {
-DecodingParams *dp = &s->b[j].decoding_params;
-const int32_t *ch[2];
+v[0] = 0;
+v[1] = 0;
-ch[0] = dp->sample_buffer[ch0];
-ch[1] = dp->sample_buffer[ch1];
+inc = search_step;
-for (int i = 0; i < dp->blocksize; i++) {
-int32_t lm = ch[0][i], rm = ch[1][i];
+while (1) {
+for (int c = 0; c < 2; c++) {
+uint64_t sum = 0;
+
+if (c) {
+e[0] = 1 << 14;
+e[1] = 0 << 14;
+e[2] = v[1];
+e[3] = v[0];
+} else {
+e[0] = v[0];
+e[1] = v[1];
+e[2] = 0 << 14;
+e[3] = 1 << 14;
+}
-enl += FFABS(lm);
-enr += FFABS(rm);
+if (invert2x2(e, d)) {
+sum = UINT64_MAX;
+goto next;
+}
-summ += FFABS(lm + rm);
-sums += FFABS(lm - rm);
+for (int i = 0; i < 4; i++) {
+if (d[i] != av_clip_intp2(d[i], 15)) {
+sum = UINT64_MAX;
+goto next;
+}
+}
-suml += lm;
-sumr += rm;
+for (int j = 0; j <= ctx->cur_restart_interval; j++) {
+DecodingParams *dp = &s->b[j].decoding_params;
+const int32_t *ch[2];
-maxl
