Re: [FFmpeg-devel] [PATCH 1/2] avutil/executor: Allowing thread_count be zero

[Anton Khirnov]

Quoting Zhao Zhili (2024-06-17 07:19:26)
> From: Zhao Zhili 
> 
> When thread_count be zero, it will be run on current thread like
> !HAVE_THREADS.

Other APIs treat zero to mean "auto".

-- 
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 7/9] MAINTAINERS: Update the entries for the release maintainer for FFmpeg

[Anton Khirnov]

Quoting Michael Niedermayer (2024-06-17 01:08:29)
> Ive been told that someone at the BCN video tech meetup claimed to be the
> "release maintainer for FFmpeg".
> 
> If you have any doubt who maintains releases, just do something like the 
> following and look at the output:
> VER=5.1
> echo commiters ; git shortlog  --group=committer -s  n$VER..release/$VER -n ;\
> echo authors   ; git shortlog-s  n$VER..release/$VER -n

Passive aggressive gossip does not belong in a commit message.

-- 
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 1/2] avutil/executor: Allowing thread_count be zero

[Paul B Mahol]

On Mon, Jun 17, 2024 at 9:05 AM Anton Khirnov  wrote:

> Quoting Zhao Zhili (2024-06-17 07:19:26)
> > From: Zhao Zhili 
> >
> > When thread_count be zero, it will be run on current thread like
> > !HAVE_THREADS.
>
> Other APIs treat zero to mean "auto".
>

Agreed, this approach for 0 to mean do it on same thread is questionable at
best.
And no real reasoning for such approach was given as explanation in this
patch.


>
> --
> 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".
>
___
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] lavc/vvc: Invalidate PPSs which refer to a changed SPS

[Anton Khirnov]

Quoting Mark Thompson (2024-06-16 17:26:26)
> Is there some requirement in H.266 that in a single stream the PPS precedes 
> the SPS?
> 
> Currently we effectively require that for a single stream because we use the 
> SPS to enforce constraints on the PPS in both H.265 and H.266, but I'm not 
> seeing a hard dependency and it looks like it will currently work on later 
> stream starts as long as the parameters don't change too much.
> 
> In H.264 there is an explicit dependency because you need chroma_format_idc 
> to parse scaling lists, but again this will usually work because it's 
> unlikely to change inline.

IIRC the spec requirement is about PPS activation, not order in the
bytestream. Our decoder does impose constraints on the order, and I
don't recall it ever causing problems, but it does not follow from the
spec.

-- 
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] [BROKEN] apad causes infinite hang

[Anton Khirnov]

Quoting Paul B Mahol (2024-06-14 14:19:13)
> Just try with:
> 
> ffmpeg -f lavfi -i sine=d=30 -af apad -f null -
> 
> Pressing 'q' will not stop it at all, because current ffmpeg code will try
> to flush all frames, but because pad filter never receives EOF from next
> filter in chain (sink) it will happily produce frame forever.
> 
> Tried to fix ffmpeg.c related code but quickly realized rewrite just made
> it 10 times worse to debug this.
> 
> Most clean solution is adding av_buffersink_close()

I think it would be cleaner to have an API for closing a _source_ (or
any filter that can produce unbounded amounts of output with no new
input).

-- 
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 7/9] MAINTAINERS: Update the entries for the release maintainer for FFmpeg

[Paul B Mahol]

On Mon, Jun 17, 2024 at 1:09 AM Michael Niedermayer 
wrote:

> Ive been told that someone at the BCN video tech meetup claimed to be the
> "release maintainer for FFmpeg".
>
>
That is nothing, I see many claims in many such videos and on many
platforms that they are developer/maintainer of FFmpeg while in fact they
develop/maintain only their closed source business.

Do not tell lies, or half lies, it does not help you on long run.


> If you have any doubt who maintains releases, just do something like the
> following and look at the output:
> VER=5.1
> echo commiters ; git shortlog  --group=committer -s  n$VER..release/$VER
> -n ;\
> echo authors   ; git shortlog-s  n$VER..release/$VER -n
>
> Signed-off-by: Michael Niedermayer 
> ---
>  MAINTAINERS | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 41a98744adf..a82fa58c69f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -536,10 +536,12 @@ wm4
>  Releases
>  
>
> +7.0 Michael Niedermayer
> +6.1 Michael Niedermayer
> +5.1 Michael Niedermayer
> +4.4 Michael Niedermayer
> +3.4 Michael Niedermayer
>  2.8 Michael Niedermayer
> -2.7 Michael Niedermayer
> -2.6 Michael Niedermayer
> -2.5 Michael Niedermayer
>
>  If you want to maintain an older release, please contact us
>
> --
> 2.45.2
>
> ___
> 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 6/6] aacdec_usac, aacsbr: implement SBR support for USAC

[Anton Khirnov]

No tests?

-- 
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] [BROKEN] apad causes infinite hang

[Paul B Mahol]

On Mon, Jun 17, 2024 at 9:24 AM Anton Khirnov  wrote:

> Quoting Paul B Mahol (2024-06-14 14:19:13)
> > Just try with:
> >
> > ffmpeg -f lavfi -i sine=d=30 -af apad -f null -
> >
> > Pressing 'q' will not stop it at all, because current ffmpeg code will
> try
> > to flush all frames, but because pad filter never receives EOF from next
> > filter in chain (sink) it will happily produce frame forever.
> >
> > Tried to fix ffmpeg.c related code but quickly realized rewrite just made
> > it 10 times worse to debug this.
> >
> > Most clean solution is adding av_buffersink_close()
>
> I think it would be cleaner to have an API for closing a _source_ (or
> any filter that can produce unbounded amounts of output with no new
> input).
>

What do you mean by closing a _source_ ?

av_buffersrc_close() already exist.

This bug is fixed in Librempeg.

Adding a call to close random filter is certainly possible, but such
approach is very
frowned upon in multi-threaded environments.

And once you close all buffersinks the EOF will and must propagate backward
to all not-closed filters and their in/out pads.

If there is better internal API for filters, feel free to present it to
wider audience.


>
> --
> 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".
>
___
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 8/9] avcodec/smcenc: width < 4 is unsupported

[Paul B Mahol]

On Mon, Jun 17, 2024 at 1:09 AM Michael Niedermayer 
wrote:

> Fixes: out of array read
> Fixes:
> 68939/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMC_fuzzer-587804104884224
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/smcenc.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/smcenc.c b/libavcodec/smcenc.c
> index 789aef4f770..d70cce900ec 100644
> --- a/libavcodec/smcenc.c
> +++ b/libavcodec/smcenc.c
> @@ -537,6 +537,9 @@ static int smc_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
>  uint8_t *pal;
>  int ret;
>
> +if (avctx->width < 4)
> +return AVERROR_PATCHWELCOME;
> +
>

I just enabled address sanitizer for smc encoder and i do not get any
errors.
Where is log of where overread happens?



>  ret = ff_alloc_packet(avctx, pkt, 8LL * avctx->height * avctx->width);
>  if (ret < 0)
>  return ret;
> --
> 2.45.2
>
> ___
> 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 1/2] avutil/executor: Allowing thread_count be zero

[Zhao Zhili]

> On Jun 17, 2024, at 15:05, Anton Khirnov  wrote:
> 
> Quoting Zhao Zhili (2024-06-17 07:19:26)
>> From: Zhao Zhili 
>> 
>> When thread_count be zero, it will be run on current thread like
>> !HAVE_THREADS.
> 
> Other APIs treat zero to mean "auto".

executor don’t detect cpu cores by itself. It’s more low level than libavcodec.

Zero thread is zero thread, literally. If we use thread_count one to mean
run on current thread, how to create a single thread then?

What’s the API do you suggest? Some negative value?

> 
> -- 
> 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".

___
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 v1] lavc/hevcdec: Put slice address checking after hwaccel decode slice

[Anton Khirnov]

Quoting fei.w.wang-at-intel@ffmpeg.org (2024-06-14 10:18:19)
> From: Fei Wang 
> 
> Slice address tab only been updated in software decode slice data.
> 
> Fixes hwaccel decoding after d725c737fe2a19091b481d4d115fd939e0a674b2.
> 
> Signed-off-by: Fei Wang 
> ---
>  libavcodec/hevc/hevcdec.c | 18 +-
>  1 file changed, 9 insertions(+), 9 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 1/2] avutil/executor: Allowing thread_count be zero

[Hendrik Leppkes]

On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili  wrote:
>
>
>
> > On Jun 17, 2024, at 15:05, Anton Khirnov  wrote:
> >
> > Quoting Zhao Zhili (2024-06-17 07:19:26)
> >> From: Zhao Zhili 
> >>
> >> When thread_count be zero, it will be run on current thread like
> >> !HAVE_THREADS.
> >
> > Other APIs treat zero to mean "auto".
>
> executor don’t detect cpu cores by itself. It’s more low level than 
> libavcodec.
>
> Zero thread is zero thread, literally. If we use thread_count one to mean
> run on current thread, how to create a single thread then?

Whats the point of creating a single thread? Does the main thread ever
do something else in the meantime, or does it just wait for the job
anyway?

- Hendrik
___
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/2] avutil/executor: Allowing thread_count be zero

[Zhao Zhili]

> On Jun 17, 2024, at 16:45, Hendrik Leppkes  wrote:
> 
> On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili  wrote:
>> 
>> 
>> 
>>> On Jun 17, 2024, at 15:05, Anton Khirnov  wrote:
>>> 
>>> Quoting Zhao Zhili (2024-06-17 07:19:26)
 From: Zhao Zhili 
 
 When thread_count be zero, it will be run on current thread like
 !HAVE_THREADS.
>>> 
>>> Other APIs treat zero to mean "auto".
>> 
>> executor don’t detect cpu cores by itself. It’s more low level than 
>> libavcodec.
>> 
>> Zero thread is zero thread, literally. If we use thread_count one to mean
>> run on current thread, how to create a single thread then?
> 
> Whats the point of creating a single thread? Does the main thread ever
> do something else in the meantime, or does it just wait for the job
> anyway?

Executor as a basic infrastructure should support such usage. The caller
don’t need to wait for the job to finish.

> 
> - Hendrik
> ___
> 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 v2] movenc: Add an option for hiding fragments at the end

[Martin Storsjö]

On Sat, 15 Jun 2024, Gyan Doshi wrote:


On 2024-06-15 03:54 am, Dennis Sädtler via ffmpeg-devel wrote:

On 2024-06-14 13:23, Gyan Doshi wrote:


On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:

On 14/06/2024 12:44, Martin Storsjö wrote:

On Fri, 14 Jun 2024, Gyan Doshi wrote:


On 2024-06-14 02:18 am, Martin Storsjö wrote:

On Thu, 13 Jun 2024, Gyan Doshi wrote:


On 2024-06-13 06:20 pm, Martin Storsjö wrote:


I'd otherwise want to push this, but I'm not entirely satisfied 
with the option name quite yet. I'm pondering if we should call 
it "hybrid_fragmented" - any opinions, Dennis or Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.


Those are good suggestions as well - but I think I prefer 
"hybrid_fragmented" still.


In theory, I guess one could implement resilient writing in a 
number of different ways, whereas the hybrid 
fragmented/non-fragmented only is one.


So with a couple other voices agreeing with the name 
"hybrid_fragmented", I'll post a new patch with the option in 
that form - hopefully you don't object to it.


The term hybrid is not applicable here. The fragmented state is 
transient during writing and contingent in the finished artifact 
depending on how the writing process concluded.
Hybrid implies both modes available e.g.. a hybrid vehicle can use 
both types of energy sources. The artifact here will be one _or_ 
the other.


Sure, the file itself is either or, but the process of writing will 
have utilized both. TBH, I don't see it as such a black-or-white 
thing.


What do the others who have chimed in on the thread think, compared 
to calling it "recoverable" or "resilient_mode"?


I don't have a super strong opinion on it, but out of the options 
provided, I'd prefer the hybrid_ one, since there's a good chance 
it'll become an established term now that OBS presents it quite 
publicly visible.


The OBS dev intends to change the term:

"Come up with a better name than "Hybrid MP4" that hopefully won't 
confuse users"


https://github.com/obsproject/obs-studio/pull/10608#issuecomment-2095222024 



Regards,
Gyan


Now that it's merged and in the hands of users I don't have any 
intention of changing the name any more.
We had some chats about about it, but nobody suggested anything that 
people agreed was better, so it stuck.


While "resilient" certainly fits, it could equally apply to regular 
fragmented MP4 (e.g. vMix uses that terminology for fMP4 if I'm not 
mistaken).
The important attribute with this approach is that it's resilient 
*and* compatible, and I'm still not sure how to get that across in 
name alone.


How about `failsafe`?


I don't see how that differs from "resilient", as a regular fragmented 
file also is failsafe (or resilient) in the same way - while the special 
thing here is that it's both fragmented and not.


// Martin
___
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/57] avcodec/mpegutils: Don't output wrong mb skip values

[Andreas Rheinhardt]

Michael Niedermayer:
> On Wed, Jun 12, 2024 at 03:48:33PM +0200, Andreas Rheinhardt wrote:
>> The earlier code had two problems:
>> 1. For reference frames that are not directly output (happens unless
>> low_delay is set), the mb skip values referred to the next reference
>> frame to be decoded.
>> 2. For non-reference frames, every macroblock was always considered
>> skipped.
>> This makes the output (worse than) useless; that no one ever
>> complained about this shows that this feature is not really used.
>> It is therefore removed.
> 
> I used it for statistical purposes long ago, seeing how much blocks where
> skiped and for that a +-1 frame difference is inconsequantal. Also
> i understood that B frame are handled differently, its an internal
> bitstream related number after all

Does "long ago" mean that you agree that it is unused and can be removed?

- Andreas

___
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] avutil/macos_kperf: Fix assert which makes kperf failed to run

[Martin Storsjö]

On Wed, 12 Jun 2024, Zhao Zhili wrote:


From: Zhao Zhili 

On m1, kpc_get_counter_count(KPC_MASK) return 8. The exact value
doesn't matter in our case.


This is somewhat unexpected, I had expected that this API was originally 
tested on an m1. I guess it might depend on what OS version you're using 
as well?



---
libavutil/macos_kperf.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/libavutil/macos_kperf.c b/libavutil/macos_kperf.c
index a0bc845fd3..906b276a34 100644
--- a/libavutil/macos_kperf.c
+++ b/libavutil/macos_kperf.c
@@ -67,14 +67,15 @@ KPERF_LIST
#define KPC_CLASS_POWER_MASK(1 << 2)
#define KPC_CLASS_RAWPMU_MASK   (1 << 3)

-#define COUNTERS_COUNT 10
+#define KPC_MAX_COUNTERS 32
#define CONFIG_COUNT 8
#define KPC_MASK (KPC_CLASS_CONFIGURABLE_MASK | KPC_CLASS_FIXED_MASK)

static void kperf_init(void)
{
-uint64_t config[COUNTERS_COUNT] = {0};
+uint64_t config[CONFIG_COUNT] = {0};


Hmm, this changes the array from 10 to 8 elements. While the change looks 
reasonable based on the variable names, I just wanted to doublecheck that 
we have some clues that this is right?



void *kperf = NULL;
+uint32_t n;

av_assert0(kperf = 
dlopen("/System/Library/PrivateFrameworks/kperf.framework/Versions/A/kperf", 
RTLD_LAZY));

@@ -82,8 +83,10 @@ static void kperf_init(void)
KPERF_LIST
#undef F

-av_assert0(kpc_get_counter_count(KPC_MASK) == COUNTERS_COUNT);
-av_assert0(kpc_get_config_count(KPC_MASK) == CONFIG_COUNT);
+n = kpc_get_counter_count(KPC_MASK);
+av_assert0(n <= KPC_MAX_COUNTERS);
+n = kpc_get_config_count(KPC_MASK);
+av_assert0(n <= CONFIG_COUNT);


I guess this is the actual functional change here, I think this seems 
right.


I CC's Josh on this change too, in case he has something to add here, but 
it looks mostly reasonable to me.


// Martin

___
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/2] avutil/timer: define macos kperf as AV_READ_TIME

[Martin Storsjö]

On Wed, 12 Jun 2024, Zhao Zhili wrote:


From: Zhao Zhili 

Firstly, make ff_kperf_cycles as an implementation of AV_READ_TIME
avoids code duplication.

Secondly, fix compilation error since 6a18c0bc87e when macos-kperf
is enabled. mach_time.h is included only when CONFIG_MACOS_KPERF
is 0. The error happened due to define mach_absolute_time as
AV_READ_TIME but missing include mach_time.h. Define macos kperf
as AV_READ_TIME fixed the issue.


Can you elaborate on what your actual goal is here? We have relatively 
little use of AV_READ_TIME (mostly START/STOP_TIMER), while most 
benchmarking these days is done via checkasm. Do you have a real case 
where you want to do benchmarking with this api, outside of checkasm?


Or do you just want to fix the compilation error? In that case I guess 
it's possible to fix differently by adding the missing includes.


By doing this change, we'd be adding one call to ff_thread_once to every 
single invocation of the timers - which seems suboptimal (even if it 
probably is quite quick). We don't use Linux perf for AV_READ_TIME either, 
we only use it in checkasm. So I'd prefer not to do this change, 
especially unless you have a concrete case where you actively desire to 
use START/STOP_TIMER benchmarking with macOS kperf?


// Martin

___
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 0/3] avfilter/af_volumedetect.c: Add 32bit float audio support

[Yigithan Yigit]

This patchset adds 32bit float audio support to the volumedetect filter and 
fixes issue #9613.
This work is part of my GSoC 2024 Qualification Task.
I would greatly appreciate your review of this patcset.

Thanks for your time and consideration.

Yigithan Yigit (3):
  avfilter/af_volumedetect.c: Move logdb function
  avfilter/af_volumedetect.c: Add 32bit float audio support
  avfilter/af_volumedetect.c: reindent after last commit

 libavfilter/af_volumedetect.c | 221 +-
 1 file changed, 164 insertions(+), 57 deletions(-)

--
2.44.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 1/3] avfilter/af_volumedetect.c: Move logdb function

[Yigithan Yigit]

---
 libavfilter/af_volumedetect.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index 8b001d1cf2..327801a7f9 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -24,6 +24,8 @@
 #include "avfilter.h"
 #include "internal.h"
 
+#define MAX_DB 91
+
 typedef struct VolDetectContext {
 /**
  * Number of samples at each PCM value.
@@ -33,6 +35,14 @@ typedef struct VolDetectContext {
 uint64_t histogram[0x10001];
 } VolDetectContext;
 
+static inline double logdb(uint64_t v)
+{
+double d = v / (double)(0x8000 * 0x8000);
+if (!v)
+return MAX_DB;
+return -log10(d) * 10;
+}
+
 static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
 {
 AVFilterContext *ctx = inlink->dst;
@@ -56,16 +66,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*samples)
 return ff_filter_frame(inlink->dst->outputs[0], samples);
 }
 
-#define MAX_DB 91
-
-static inline double logdb(uint64_t v)
-{
-double d = v / (double)(0x8000 * 0x8000);
-if (!v)
-return MAX_DB;
-return -log10(d) * 10;
-}
-
 static void print_stats(AVFilterContext *ctx)
 {
 VolDetectContext *vd = ctx->priv;
-- 
2.44.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 2/3] avfilter/af_volumedetect.c: Add 32bit float audio support

[Yigithan Yigit]

---
 libavfilter/af_volumedetect.c | 159 --
 1 file changed, 133 insertions(+), 26 deletions(-)

diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index 327801a7f9..dbbcd037a5 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -20,27 +20,51 @@
 
 #include "libavutil/channel_layout.h"
 #include "libavutil/avassert.h"
+#include "libavutil/mem.h"
 #include "audio.h"
 #include "avfilter.h"
 #include "internal.h"
 
+#define MAX_DB_FLT 1024
 #define MAX_DB 91
+#define HISTOGRAM_SIZE 0x1
+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
 
 typedef struct VolDetectContext {
-/**
- * Number of samples at each PCM value.
- * histogram[0x8000 + i] is the number of samples at value i.
- * The extra element is there for symmetry.
- */
-uint64_t histogram[0x10001];
+uint64_t* histogram; ///< for integer number of samples at each PCM value, 
for float number of samples at each dB
+uint64_t nb_samples; ///< number of samples
+double sum2; ///< sum of the squares of the samples
+double max;  ///< maximum sample value
+int is_float;///< true if the input is in floating point
 } VolDetectContext;
 
-static inline double logdb(uint64_t v)
+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
 {
-double d = v / (double)(0x8000 * 0x8000);
-if (!v)
-return MAX_DB;
-return -log10(d) * 10;
+if (sample_fmt == AV_SAMPLE_FMT_FLT) {
+if (!v)
+return MAX_DB_FLT;
+return -log10(v) * 10;
+} else {
+double d = v / (double)(0x8000 * 0x8000);
+if (!v)
+return MAX_DB;
+return -log10(d) * 10;
+}
+}
+
+static void update_float_stats(VolDetectContext *vd, float *audio_data)
+{
+double sample;
+int idx;
+if(!isnormal(*audio_data))
+return;
+sample = fabsf(*audio_data);
+if (sample > vd->max)
+vd->max = sample;
+vd->sum2 += sample * sample;
+idx = lrintf(floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT))) + 
MAX_DB_FLT;
+vd->histogram[idx]++;
+vd->nb_samples++;
 }
 
 static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
@@ -51,18 +75,41 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*samples)
 int nb_channels = samples->ch_layout.nb_channels;
 int nb_planes   = nb_channels;
 int plane, i;
-int16_t *pcm;
+int planar = 0;
 
-if (!av_sample_fmt_is_planar(samples->format)) {
-nb_samples *= nb_channels;
+planar = av_sample_fmt_is_planar(samples->format);
+if (!planar)
 nb_planes = 1;
+if (vd->is_float) {
+float *audio_data;
+for (plane = 0; plane < nb_planes; plane++) {
+audio_data = (float *)samples->extended_data[plane];
+for (i = 0; i < nb_samples; i++) {
+if (planar) {
+update_float_stats(vd, &audio_data[i]);
+} else {
+for (int j = 0; j < nb_channels; j++)
+update_float_stats(vd, &audio_data[i * nb_channels + 
j]);
+}
+}
+}
+} else {
+int16_t *pcm;
+for (plane = 0; plane < nb_planes; plane++) {
+pcm = (int16_t *)samples->extended_data[plane];
+for (i = 0; i < nb_samples; i++) {
+if (planar) {
+vd->histogram[pcm[i] + 0x8000]++;
+vd->nb_samples++;
+} else {
+for (int j = 0; j < nb_channels; j++) {
+vd->histogram[pcm[i * nb_channels + j] + 0x8000]++;
+vd->nb_samples++;
+}
+}
+}
+}
 }
-for (plane = 0; plane < nb_planes; plane++) {
-pcm = (int16_t *)samples->extended_data[plane];
-for (i = 0; i < nb_samples; i++)
-vd->histogram[pcm[i] + 0x8000]++;
-}
-
 return ff_filter_frame(inlink->dst->outputs[0], samples);
 }
 
@@ -73,6 +120,20 @@ static void print_stats(AVFilterContext *ctx)
 uint64_t nb_samples = 0, power = 0, nb_samples_shift = 0, sum = 0;
 uint64_t histdb[MAX_DB + 1] = { 0 };
 
+if (!vd->nb_samples)
+return;
+if (vd->is_float) {
+av_log(ctx, AV_LOG_INFO, "n_samples: %" PRId64 "\n", vd->nb_samples);
+av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb(vd->sum2 / 
vd->nb_samples, AV_SAMPLE_FMT_FLT));
+av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", -2.0*logdb(vd->max, 
AV_SAMPLE_FMT_FLT));
+for (i = 0; i < HISTOGRAM_SIZE_FLT && !vd->histogram[i]; i++);
+for (; i >= 0 && sum < vd->nb_samples / 1000; i++) {
+if (!vd->histogram[i])
+continue;
+av_log(ctx, AV_LOG_INFO, "histogram_%ddb: %" PRId64 "\n", 
MAX_DB_FLT - i, vd->histogram[i]);
+sum += vd->histogram[i];
+}
+} else {
 for (i 

[FFmpeg-devel] [PATCH 3/3] avfilter/af_volumedetect.c: reindent after last commit

[Yigithan Yigit]

---
 libavfilter/af_volumedetect.c | 68 +--
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
index dbbcd037a5..b78b073c09 100644
--- a/libavfilter/af_volumedetect.c
+++ b/libavfilter/af_volumedetect.c
@@ -134,40 +134,40 @@ static void print_stats(AVFilterContext *ctx)
 sum += vd->histogram[i];
 }
 } else {
-for (i = 0; i < 0x1; i++)
-nb_samples += vd->histogram[i];
-av_log(ctx, AV_LOG_INFO, "n_samples: %"PRId64"\n", nb_samples);
-if (!nb_samples)
-return;
-
-/* If nb_samples > 1<<34, there is a risk of overflow in the
-   multiplication or the sum: shift all histogram values to avoid that.
-   The total number of samples must be recomputed to avoid rounding
-   errors. */
-shift = av_log2(nb_samples >> 33);
-for (i = 0; i < 0x1; i++) {
-nb_samples_shift += vd->histogram[i] >> shift;
-power += (i - 0x8000) * (i - 0x8000) * (vd->histogram[i] >> shift);
-}
-if (!nb_samples_shift)
-return;
-power = (power + nb_samples_shift / 2) / nb_samples_shift;
-av_assert0(power <= 0x8000 * 0x8000);
-av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", -logdb((double)power, 
AV_SAMPLE_FMT_S16));
-
-max_volume = 0x8000;
-while (max_volume > 0 && !vd->histogram[0x8000 + max_volume] &&
- !vd->histogram[0x8000 - max_volume])
-max_volume--;
-av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", 
-logdb((double)(max_volume * max_volume), AV_SAMPLE_FMT_S16));
-
-for (i = 0; i < 0x1; i++)
-histdb[(int)logdb((double)(i - 0x8000) * (i - 0x8000), 
AV_SAMPLE_FMT_S16)] += vd->histogram[i];
-for (i = 0; i <= MAX_DB && !histdb[i]; i++);
-for (; i <= MAX_DB && sum < nb_samples / 1000; i++) {
-av_log(ctx, AV_LOG_INFO, "histogram_%ddb: %"PRId64"\n", -i, histdb[i]);
-sum += histdb[i];
-}
+for (i = 0; i < 0x1; i++)
+nb_samples += vd->histogram[i];
+av_log(ctx, AV_LOG_INFO, "n_samples: %"PRId64"\n", nb_samples);
+if (!nb_samples)
+return;
+
+/* If nb_samples > 1<<34, there is a risk of overflow in the
+multiplication or the sum: shift all histogram values to avoid that.
+The total number of samples must be recomputed to avoid rounding
+errors. */
+shift = av_log2(nb_samples >> 33);
+for (i = 0; i < 0x1; i++) {
+nb_samples_shift += vd->histogram[i] >> shift;
+power += (i - 0x8000) * (i - 0x8000) * (vd->histogram[i] >> shift);
+}
+if (!nb_samples_shift)
+return;
+power = (power + nb_samples_shift / 2) / nb_samples_shift;
+av_assert0(power <= 0x8000 * 0x8000);
+av_log(ctx, AV_LOG_INFO, "mean_volume: %.1f dB\n", 
-logdb((double)power, AV_SAMPLE_FMT_S16));
+
+max_volume = 0x8000;
+while (max_volume > 0 && !vd->histogram[0x8000 + max_volume] &&
+!vd->histogram[0x8000 - max_volume])
+max_volume--;
+av_log(ctx, AV_LOG_INFO, "max_volume: %.1f dB\n", 
-logdb((double)(max_volume * max_volume), AV_SAMPLE_FMT_S16));
+
+for (i = 0; i < 0x1; i++)
+histdb[(int)logdb((double)(i - 0x8000) * (i - 0x8000), 
AV_SAMPLE_FMT_S16)] += vd->histogram[i];
+for (i = 0; i <= MAX_DB && !histdb[i]; i++);
+for (; i <= MAX_DB && sum < nb_samples / 1000; i++) {
+av_log(ctx, AV_LOG_INFO, "histogram_%ddb: %"PRId64"\n", -i, 
histdb[i]);
+sum += histdb[i];
+}
 }
 }
 
-- 
2.44.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".

Re: [FFmpeg-devel] [PATCH 1/2] avutil/timer: define macos kperf as AV_READ_TIME

[Martin Storsjö]

On Mon, 17 Jun 2024, Martin Storsjö wrote:


On Wed, 12 Jun 2024, Zhao Zhili wrote:


From: Zhao Zhili 

Firstly, make ff_kperf_cycles as an implementation of AV_READ_TIME
avoids code duplication.

Secondly, fix compilation error since 6a18c0bc87e when macos-kperf
is enabled. mach_time.h is included only when CONFIG_MACOS_KPERF
is 0. The error happened due to define mach_absolute_time as
AV_READ_TIME but missing include mach_time.h. Define macos kperf
as AV_READ_TIME fixed the issue.


Can you elaborate on what your actual goal is here? We have relatively little 
use of AV_READ_TIME (mostly START/STOP_TIMER), while most benchmarking these 
days is done via checkasm. Do you have a real case where you want to do 
benchmarking with this api, outside of checkasm?


Or do you just want to fix the compilation error? In that case I guess it's 
possible to fix differently by adding the missing includes.


Btw, in this case, the compilation error also went away when I pushed the 
patch that made it use inline assembly with cntvct_el0 on macOS too.


But as long as we do have the common AV_READ_TIME fallback to 
mach_absolute_time, we definitely should include the right header for that 
case anyway.


// Martin
___
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] avutil/macos_kperf: Fix assert which makes kperf failed to run

[J. Dekker]

On Mon, Jun 17, 2024, at 13:10, Martin Storsjö wrote:
> On Wed, 12 Jun 2024, Zhao Zhili wrote:
>
>> From: Zhao Zhili 
>>
>> On m1, kpc_get_counter_count(KPC_MASK) return 8. The exact value
>> doesn't matter in our case.
>
> This is somewhat unexpected, I had expected that this API was originally 
> tested on an m1. I guess it might depend on what OS version you're using 
> as well?
>
>> ---
>> libavutil/macos_kperf.c | 15 +--
>> 1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavutil/macos_kperf.c b/libavutil/macos_kperf.c
>> index a0bc845fd3..906b276a34 100644
>> --- a/libavutil/macos_kperf.c
>> +++ b/libavutil/macos_kperf.c
>> @@ -67,14 +67,15 @@ KPERF_LIST
>> #define KPC_CLASS_POWER_MASK(1 << 2)
>> #define KPC_CLASS_RAWPMU_MASK   (1 << 3)
>>
>> -#define COUNTERS_COUNT 10
>> +#define KPC_MAX_COUNTERS 32
>> #define CONFIG_COUNT 8
>> #define KPC_MASK (KPC_CLASS_CONFIGURABLE_MASK | KPC_CLASS_FIXED_MASK)
>>
>> static void kperf_init(void)
>> {
>> -uint64_t config[COUNTERS_COUNT] = {0};
>> +uint64_t config[CONFIG_COUNT] = {0};
>
> Hmm, this changes the array from 10 to 8 elements. While the change looks 
> reasonable based on the variable names, I just wanted to doublecheck that 
> we have some clues that this is right?
>
>> void *kperf = NULL;
>> +uint32_t n;
>>
>> av_assert0(kperf = 
>> dlopen("/System/Library/PrivateFrameworks/kperf.framework/Versions/A/kperf", 
>> RTLD_LAZY));
>>
>> @@ -82,8 +83,10 @@ static void kperf_init(void)
>> KPERF_LIST
>> #undef F
>>
>> -av_assert0(kpc_get_counter_count(KPC_MASK) == COUNTERS_COUNT);
>> -av_assert0(kpc_get_config_count(KPC_MASK) == CONFIG_COUNT);
>> +n = kpc_get_counter_count(KPC_MASK);
>> +av_assert0(n <= KPC_MAX_COUNTERS);
>> +n = kpc_get_config_count(KPC_MASK);
>> +av_assert0(n <= CONFIG_COUNT);
>
> I guess this is the actual functional change here, I think this seems 
> right.
>
> I CC's Josh on this change too, in case he has something to add here, but 
> it looks mostly reasonable to me.

It’s a private kernel API there are no guarantees about it working at any 
point. I just know that it used to work. If it needs changes to work currently 
and this fixes it for you then that’s fine, you should probably also port this 
change to dav1d. I’m personally unable to test this as I am just running Linux 
on my M1 machine now.

-- 
jd
___
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/2] avutil/timer: define macos kperf as AV_READ_TIME

[Zhao Zhili]

> On Jun 17, 2024, at 19:15, Martin Storsjö  wrote:
> 
> On Wed, 12 Jun 2024, Zhao Zhili wrote:
> 
>> From: Zhao Zhili 
>> 
>> Firstly, make ff_kperf_cycles as an implementation of AV_READ_TIME
>> avoids code duplication.
>> 
>> Secondly, fix compilation error since 6a18c0bc87e when macos-kperf
>> is enabled. mach_time.h is included only when CONFIG_MACOS_KPERF
>> is 0. The error happened due to define mach_absolute_time as
>> AV_READ_TIME but missing include mach_time.h. Define macos kperf
>> as AV_READ_TIME fixed the issue.
> 
> Can you elaborate on what your actual goal is here? We have relatively little 
> use of AV_READ_TIME (mostly START/STOP_TIMER), while most benchmarking these 
> days is done via checkasm. Do you have a real case where you want to do 
> benchmarking with this api, outside of checkasm?
> 
> Or do you just want to fix the compilation error? In that case I guess it's 
> possible to fix differently by adding the missing includes.
> 
> By doing this change, we'd be adding one call to ff_thread_once to every 
> single invocation of the timers - which seems suboptimal (even if it probably 
> is quite quick). We don't use Linux perf for AV_READ_TIME either, we only use 
> it in checkasm. So I'd prefer not to do this change, especially unless you 
> have a concrete case where you actively desire to use START/STOP_TIMER 
> benchmarking with macOS kperf?

I’m trying to fix the missing include header file first. Then I saw 
ff_kperf_init() is called each time by START_TIMER, which can be simplified by 
merge ff_kperf_init into ff_kperf_cycles.

#define START_TIMER \
uint64_t tperf; \
ff_kperf_init();\
tperf = ff_kperf_cycles();

Now I think I have chose the wrong example. checkasm bench_init_kperf is the 
right one.

We can remove the ff_thread_once in ff_kperf_init, and let caller make 
guarantee to only call it once. But kperf is only for test, so not urgent to do 
such change.

Will add missing include in v2.

> 
> // Martin
> 
> ___
> 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 1/2] avutil/timer: define macos kperf as AV_READ_TIME

[Martin Storsjö]

On Mon, 17 Jun 2024, Zhao Zhili wrote:





On Jun 17, 2024, at 19:15, Martin Storsjö  wrote:

On Wed, 12 Jun 2024, Zhao Zhili wrote:


From: Zhao Zhili 

Firstly, make ff_kperf_cycles as an implementation of AV_READ_TIME
avoids code duplication.

Secondly, fix compilation error since 6a18c0bc87e when macos-kperf
is enabled. mach_time.h is included only when CONFIG_MACOS_KPERF
is 0. The error happened due to define mach_absolute_time as
AV_READ_TIME but missing include mach_time.h. Define macos kperf
as AV_READ_TIME fixed the issue.


Can you elaborate on what your actual goal is here? We have relatively little 
use of AV_READ_TIME (mostly START/STOP_TIMER), while most benchmarking these 
days is done via checkasm. Do you have a real case where you want to do 
benchmarking with this api, outside of checkasm?

Or do you just want to fix the compilation error? In that case I guess it's 
possible to fix differently by adding the missing includes.

By doing this change, we'd be adding one call to ff_thread_once to every single 
invocation of the timers - which seems suboptimal (even if it probably is quite 
quick). We don't use Linux perf for AV_READ_TIME either, we only use it in 
checkasm. So I'd prefer not to do this change, especially unless you have a 
concrete case where you actively desire to use START/STOP_TIMER benchmarking 
with macOS kperf?


I’m trying to fix the missing include header file first. Then I saw 
ff_kperf_init() is called each time by START_TIMER, which can be 
simplified by merge ff_kperf_init into ff_kperf_cycles.


#define START_TIMER \
   uint64_t tperf; \
   ff_kperf_init();\
   tperf = ff_kperf_cycles();

Now I think I have chose the wrong example. checkasm bench_init_kperf is 
the right one.


Oh, right, I had entirely missed that we already do this - so both Linux 
perf and macOS kperf are used for START/STOP_TIMER, they're just not used 
for AV_READ_TIME so far. I see...


We can remove the ff_thread_once in ff_kperf_init, and let caller make 
guarantee to only call it once. But kperf is only for test, so not 
urgent to do such change.


In any case, I much rather have ff_thread_once in an _init function, than 
in every single timer invocation. Not sure if it's worth trying to get rid 
of the ff_thread_once from there.


// Martin
___
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] avutil/macos_kperf: Fix assert which makes kperf failed to run

[Zhao Zhili]

> On Jun 17, 2024, at 19:10, Martin Storsjö  wrote:
> 
> On Wed, 12 Jun 2024, Zhao Zhili wrote:
> 
>> From: Zhao Zhili 
>> 
>> On m1, kpc_get_counter_count(KPC_MASK) return 8. The exact value
>> doesn't matter in our case.
> 
> This is somewhat unexpected, I had expected that this API was originally 
> tested on an m1. I guess it might depend on what OS version you're using as 
> well?

On arm64 [1]

#define KPC_ARM64_FIXED_COUNT(2)
#define KPC_ARM64_CONFIGURABLE_COUNT (CORE_NCTRS - KPC_ARM64_FIXED_COUNT)

#define KPC_MAX_COUNTERS (KPC_ARM64_FIXED_COUNT + KPC_ARM64_CONFIGURABLE_COUNT 
+ 1)

On x86_64:
#define KPC_MAX_COUNTERS 32

[1] 
https://github.com/apple/darwin-xnu/blob/2ff845c2e033bd0ff64b5b6aa6063a1f8f65aa32/osfmk/arm64/machine_kpc.h#L36

> 
>> ---
>> libavutil/macos_kperf.c | 15 +--
>> 1 file changed, 9 insertions(+), 6 deletions(-)
>> 
>> diff --git a/libavutil/macos_kperf.c b/libavutil/macos_kperf.c
>> index a0bc845fd3..906b276a34 100644
>> --- a/libavutil/macos_kperf.c
>> +++ b/libavutil/macos_kperf.c
>> @@ -67,14 +67,15 @@ KPERF_LIST
>> #define KPC_CLASS_POWER_MASK(1 << 2)
>> #define KPC_CLASS_RAWPMU_MASK   (1 << 3)
>> 
>> -#define COUNTERS_COUNT 10
>> +#define KPC_MAX_COUNTERS 32
>> #define CONFIG_COUNT 8
>> #define KPC_MASK (KPC_CLASS_CONFIGURABLE_MASK | KPC_CLASS_FIXED_MASK)
>> 
>> static void kperf_init(void)
>> {
>> -uint64_t config[COUNTERS_COUNT] = {0};
>> +uint64_t config[CONFIG_COUNT] = {0};
> 
> Hmm, this changes the array from 10 to 8 elements. While the change looks 
> reasonable based on the variable names, I just wanted to doublecheck that we 
> have some clues that this is right?

The change is base on the check

av_assert0(kpc_get_config_count(KPC_MASK) == CONFIG_COUNT

> 
>>void *kperf = NULL;
>> +uint32_t n;
>> 
>>av_assert0(kperf = 
>> dlopen("/System/Library/PrivateFrameworks/kperf.framework/Versions/A/kperf", 
>> RTLD_LAZY));
>> 
>> @@ -82,8 +83,10 @@ static void kperf_init(void)
>>KPERF_LIST
>> #undef F
>> 
>> -av_assert0(kpc_get_counter_count(KPC_MASK) == COUNTERS_COUNT);
>> -av_assert0(kpc_get_config_count(KPC_MASK) == CONFIG_COUNT);
>> +n = kpc_get_counter_count(KPC_MASK);
>> +av_assert0(n <= KPC_MAX_COUNTERS);
>> +n = kpc_get_config_count(KPC_MASK);
>> +av_assert0(n <= CONFIG_COUNT);
> 
> I guess this is the actual functional change here, I think this seems right.
> 
> I CC's Josh on this change too, in case he has something to add here, but it 
> looks mostly reasonable to me.

> 
> // Martin
> 
> ___
> 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 v2] movenc: Add an option for hiding fragments at the end

[Gyan Doshi via ffmpeg-devel]

On 2024-06-17 04:08 pm, Martin Storsjö wrote:

On Sat, 15 Jun 2024, Gyan Doshi wrote:


On 2024-06-15 03:54 am, Dennis Sädtler via ffmpeg-devel wrote:

On 2024-06-14 13:23, Gyan Doshi wrote:


On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:

On 14/06/2024 12:44, Martin Storsjö wrote:

On Fri, 14 Jun 2024, Gyan Doshi wrote:


On 2024-06-14 02:18 am, Martin Storsjö wrote:

On Thu, 13 Jun 2024, Gyan Doshi wrote:


On 2024-06-13 06:20 pm, Martin Storsjö wrote:


I'd otherwise want to push this, but I'm not entirely 
satisfied with the option name quite yet. I'm pondering if we 
should call it "hybrid_fragmented" - any opinions, Dennis or 
Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.


Those are good suggestions as well - but I think I prefer 
"hybrid_fragmented" still.


In theory, I guess one could implement resilient writing in a 
number of different ways, whereas the hybrid 
fragmented/non-fragmented only is one.


So with a couple other voices agreeing with the name 
"hybrid_fragmented", I'll post a new patch with the option in 
that form - hopefully you don't object to it.


The term hybrid is not applicable here. The fragmented state is 
transient during writing and contingent in the finished artifact 
depending on how the writing process concluded.
Hybrid implies both modes available e.g.. a hybrid vehicle can 
use both types of energy sources. The artifact here will be one 
_or_ the other.


Sure, the file itself is either or, but the process of writing 
will have utilized both. TBH, I don't see it as such a 
black-or-white thing.


What do the others who have chimed in on the thread think, 
compared to calling it "recoverable" or "resilient_mode"?


I don't have a super strong opinion on it, but out of the options 
provided, I'd prefer the hybrid_ one, since there's a good chance 
it'll become an established term now that OBS presents it quite 
publicly visible.


The OBS dev intends to change the term:

"Come up with a better name than "Hybrid MP4" that hopefully won't 
confuse users"


https://github.com/obsproject/obs-studio/pull/10608#issuecomment-2095222024 




Regards,
Gyan


Now that it's merged and in the hands of users I don't have any 
intention of changing the name any more.
We had some chats about about it, but nobody suggested anything that 
people agreed was better, so it stuck.


While "resilient" certainly fits, it could equally apply to regular 
fragmented MP4 (e.g. vMix uses that terminology for fMP4 if I'm not 
mistaken).
The important attribute with this approach is that it's resilient 
*and* compatible, and I'm still not sure how to get that across in 
name alone.


How about `failsafe`?


I don't see how that differs from "resilient", as a regular fragmented 
file also is failsafe (or resilient) in the same way - while the 
special thing here is that it's both fragmented and not.


The expert user already knows to save a fragmented file if they want 
resilience. This option saves them a remux step if the original writing 
ends gracefully.
For all other users,  the value proposition _is_ the resilience.  If the 
muxing ends normally, they just have a normal file. If it ends 
prematurely, they just want to be able to convert to a regular seekable 
MP4. The fact that it is saved in fragmented or any other mode is 
irrelevant - an academic detail at best.


Ultimately, as long as the doc is clear about what the use of this 
option is, and what to do next if the muxing does abort, it should not 
matter too much what the option is called. But just like the faststart 
flag name identifies the purpose instead of being called something like 
moov_in_front, hopefully so will the name here.


Regards,
Gyan

___
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 6/6] swscale/yuv2rgb/x86: remove mmx/mmxext yuv2rgb functions

[Ramiro Polla]

On Mon, Jun 17, 2024 at 1:16 AM James Almer  wrote:
> On 6/16/2024 7:28 PM, Ramiro Polla wrote:
> > These functions are either slower or barely faster than the C LUT
> > yuv2rgb code.
> > ---
> >   libswscale/x86/yuv2rgb.c  | 51 -
> >   libswscale/x86/yuv2rgb_template.c |  4 --
> >   libswscale/x86/yuv_2_rgb.asm  | 93 +--
> >   3 files changed, 3 insertions(+), 145 deletions(-)
> >
> > diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
> > index 6754062245..41dfa80f33 100644
> > --- a/libswscale/x86/yuv2rgb.c
> > +++ b/libswscale/x86/yuv2rgb.c
> > @@ -41,25 +41,8 @@
> >
> >   #define DITHER1XBPP // only for MMX
>
> Shouldn't this be removed too?

I think this #define can already be removed from everywhere. It seems
to be unconditionally set in swscale_internal.h (I haven't tracked
down since when this is the case).

> > -//MMX versions
> > -#if HAVE_MMX
> > -#undef RENAME
> > -#define COMPILE_TEMPLATE_MMX
> > -#define RENAME(a) a ## _mmx
> > -#include "yuv2rgb_template.c"
> > -#undef COMPILE_TEMPLATE_MMX
> > -#endif /* HAVE_MMX */
> > -
> > -// MMXEXT versions
> > -#undef RENAME
> > -#define COMPILE_TEMPLATE_MMXEXT
> > -#define RENAME(a) a ## _mmxext
> > -#include "yuv2rgb_template.c"
> > -#undef COMPILE_TEMPLATE_MMXEXT
> > -
> >   //SSSE3 versions
> >   #undef RENAME
> > -#define COMPILE_TEMPLATE_SSSE3
> >   #define RENAME(a) a ## _ssse3
> >   #include "yuv2rgb_template.c"
>
> You could write a seventh patch that moves the template stuff back to
> this file, now that SSSE3 is the only version. See commit 8b62fb231a78.

Will do in the next version of this patchset.
___
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/5] avutil/spherical: Add more spherical types

[Derek Buitenhuis]

On 6/14/2024 2:03 PM, Derek Buitenhuis wrote:
> I think setting it to 0 (AV_STEREO3D_2D) is correct rather than this (and is 
> already
> done), and I don't think we need to reorder.
> 
> I had discussed this with Vittorio and it was decided that it was good to 
> disambiguate
> between 2D (not stereoscopic) and coded rectangular.

Please disregard this, my brain got two enums mixed up. You're right, and I 
have made
this change locally.

- Derek
___
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] lavc/vvc: Invalidate PPSs which refer to a changed SPS

[Nuo Mi]

On Sun, Jun 16, 2024 at 11:26 PM Mark Thompson  wrote:

> On 15/06/2024 17:37, Frank Plowman wrote:
> > n 15/06/2024 13:24, Nuo Mi wrote:
> >> On Sat, Jun 15, 2024 at 2:35 PM Christophe Gisquet <
> >> christophe.gisq...@gmail.com> wrote:
> >>
> >>> Le ven. 14 juin 2024, 11:39, Frank Plowman  a
> >>> écrit :
> >>>
>  When the SPS associated with a particular SPS ID changes, invalidate
> all
>  the PPSs which use that SPS ID.  Fixes crashes with illegal
> bitstreams.
>  This is done in the CBS, rather than in libavcodec/vvc/ps.c like the
> SPS
>  ID reuse validation, as parts of the CBS parsing process for PPSs
>  depend on the SPS being referred to.
> 
> >>>
> >>> I am uncertain about this. I have no definite knowledge nor proof, but
> I
> >>> would have thought these are persistent, IE it's legal to update some
> of
> >>> them, their validity depending on something else.
> >>>
> >>
> >>> Wondering if the tested streams are thus conformant.
> >>>
> >>> But I don't know the actual rule. Maybe finding an EOB/EOS NUT?
> Related to
> >>> some particular shape of a clean random access point, that would
> require
> >>> retransmitting VPS/SPS/PPS/APS/... ?
> >>>
> >>> Asking Benjamin Bross might be a better option here.
> >>>
> >> Hi Chris,
> >> spec said sps should not change in a CVS.  Frank has some patches to
> fix a
> >> similar issue.
> >>
> https://github.com/FFmpeg/FFmpeg/commit/2d79ae3f8a3306d24afe43ba505693a8dbefd21b
> >>
> >>
> >> Hi Frank,
> >> Did it crash before your error hand code in ps.c?
> >> Could you send me the clip?
> >>
> >> Thank you
> >>
> >
> > Hi both,
> >
> > Thank you for your reviews.
> >
> > An example of a crashing bitstream which is fixed by this patch is ID
> > 295 available here: https://github.com/ffvvc/tests/pull/43.  The
> > relevant part of the bitstream is a sequence of NAL units
> >
> > AU (decode_order=5)
> > 18. SPS
> > sps_seq_parameter_set_id = 0
> > sps_ctb_log2_size_y = 5
> > 19. PPS
> > pps_pic_parameter_set_id = 0
> > pps_seq_parameter_set_id = 0
> > 20. IDR_N_LP
> > ph_pic_order_cnt_lsb = 0
> > NoOutputBeforeRecoveryFlag = 1
> > ph_pic_parameter_set_id = 0
> >
> > AU (decode_order=6)
> > 21. AUD
> > 22. VPS
> > 23. SPS
> > sps_seq_parameter_set_id = 0
> > sps_ctb_log2_size_y = 7
> > 24. PREFIX_APS
> > 25. IDR_N_LP
> > ph_pic_order_cnt_lsb = 0
> > NoOutputBeforeRecoveryFlag = 1
> > ph_pic_parameter_set_id = 0
> >
> > The layout of SPSs alone is legal (not covered by the checks introduced
> > in 2d79ae3f8a3306d24afe43ba505693a8dbefd21b) as the second AU is a CLVSS
> > AU.  As a result, the bitstream crashes both before and after
> > 2d79ae3f8a3306d24afe43ba505693a8dbefd21b.  What this patch does is
> > produce an error when the VCL NAL unit in the second AU (25.) tries to
> > use PPS ID 0, as the SPS NAL unit that PPS was defined with reference to
> > (18.) is no longer available.
> >
> > Christophe, is my interpretation of your point correct when I say you
> > are suggesting that the above sequence may be legal, so long as the PPS
> > still satisfies the new bounds etc. derived from the second SPS?  I did
> > consider this, and I think it may be possible to implement by delaying
> > CBS element validation and inference until libavcodec/vvc/ps.c.
> > However, there are no bitstreams in the conformance suite which contain
> > such a structure and this is different to how the native HEVC decoder
> > behaves (see libavcodec/hevc/ps.c:72).
>
> Is there some requirement in H.266 that in a single stream the PPS
> precedes the SPS?
>
No, the spec only states that when decoding the picture header, we need the
corresponding PPS and SPS.
If we strictly follow the spec, we should delay the PPS-derived process
when decoding the picture header, but it may be very complex.

7.4.3.4 Sequence parameter set RBSP semantics
An SPS RBSP shall be available to the decoding process, by inclusion in at
least one AU with TemporalId equal to 0 or
provided through external means, prior to it being referenced by either of
the following:
– a PH NAL unit having a ph_pic_parameter_set_id that refers to a PPS with
pps_seq_parameter_set_id equal to the
value of sps_seq_parameter_set_id in the SPS RBSP,
– a coded slice NAL unit having sh_picture_header_in_slice_header_flag
equal to 1 with a ph_pic_parameter_set_id
that refers to a PPS with pps_seq_parameter_set_id equal to the value of
sps_seq_parameter_set_id in the SPS RBSP

>
> Currently we effectively require that for a single stream because we use
> the SPS to enforce constraints on the PPS in both H.265 and H.266, but I'm
> not seeing a hard dependency and it looks like it will currently work on
> later stream starts as long as the parameters don't change too much.
>
> In H.264 there is an explicit dependency because you need
> chroma_format_idc to parse scaling lists, but again this will usually work
> because it's unlikely to change inline.
>
> If that is not required the

[FFmpeg-devel] [PATCH v2 0/5] Vision Pro Spatial Data

[Derek Buitenhuis]

* All comments applied from previous review.
* Renamed rectangular to more industry standard rectilinear.

Derek Buitenhuis (5):
  avutil/spherical: Add more spherical types
  avutil/stereo3d: Fill out stereo info provided by Vision Pro files
  fftools/ffprobe: Print more Stereo 3D info from side data
  avformat/mov: Add support for exporting Video Extension Usage info
  avformat/mov: Add support for reading and exporting horizontal field
of view

 fftools/ffprobe.c|   8 +
 libavformat/mov.c| 308 +++
 libavutil/spherical.c|   5 +
 libavutil/spherical.h|  16 +
 libavutil/stereo3d.c |  52 
 libavutil/stereo3d.h |  78 +
 libavutil/version.h  |   2 +-
 tests/ref/fate/matroska-spherical-mono   |   2 +
 tests/ref/fate/matroska-spherical-mono-remux |   4 +
 tests/ref/fate/matroska-stereo_mode  |   8 +
 tests/ref/fate/matroska-vp8-alpha-remux  |   2 +
 tests/ref/fate/mov-spherical-mono|   2 +
 12 files changed, 486 insertions(+), 1 deletion(-)

-- 
2.43.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 v2 1/5] avutil/spherical: Add more spherical types

[Derek Buitenhuis]

These originate from the Apple Vision Pro, and are documented here:

https://developer.apple.com/documentation/coremedia/cmprojectiontype

Signed-off-by: Derek Buitenhuis 
---
 libavutil/spherical.c |  5 +
 libavutil/spherical.h | 16 
 libavutil/version.h   |  2 +-
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/libavutil/spherical.c b/libavutil/spherical.c
index 800d3459a5..64ade1d0ec 100644
--- a/libavutil/spherical.c
+++ b/libavutil/spherical.c
@@ -29,6 +29,8 @@ AVSphericalMapping *av_spherical_alloc(size_t *size)
 if (!spherical)
 return NULL;
 
+spherical->projection = AV_SPHERICAL_RECTILINEAR;
+
 if (size)
 *size = sizeof(*spherical);
 
@@ -57,6 +59,9 @@ static const char *const spherical_projection_names[] = {
 [AV_SPHERICAL_EQUIRECTANGULAR]  = "equirectangular",
 [AV_SPHERICAL_CUBEMAP]  = "cubemap",
 [AV_SPHERICAL_EQUIRECTANGULAR_TILE] = "tiled equirectangular",
+[AV_SPHERICAL_HALF_EQUIRECTANGULAR] = "half equirectangular",
+[AV_SPHERICAL_RECTILINEAR]  = "rectilinear",
+[AV_SPHERICAL_FISHEYE]  = "fisheye",
 };
 
 const char *av_spherical_projection_name(enum AVSphericalProjection projection)
diff --git a/libavutil/spherical.h b/libavutil/spherical.h
index 828ac836da..2e90f7752d 100644
--- a/libavutil/spherical.h
+++ b/libavutil/spherical.h
@@ -66,6 +66,22 @@ enum AVSphericalProjection {
  * the position of the current video in a larger surface.
  */
 AV_SPHERICAL_EQUIRECTANGULAR_TILE,
+
+/**
+ * Video frame displays as a 180 degree equirectangular projection.
+ */
+AV_SPHERICAL_HALF_EQUIRECTANGULAR,
+
+/**
+ * Video frame displays on a flat, rectangular 2D surface.
+ */
+AV_SPHERICAL_RECTILINEAR,
+
+/**
+ * Fisheye projection (Apple).
+ * See: 
https://developer.apple.com/documentation/coremedia/cmprojectiontype/fisheye
+ */
+AV_SPHERICAL_FISHEYE,
 };
 
 /**
diff --git a/libavutil/version.h b/libavutil/version.h
index 2756f2aa03..7df546ee22 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  59
-#define LIBAVUTIL_VERSION_MINOR  22
+#define LIBAVUTIL_VERSION_MINOR  23
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.43.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 v2 2/5] avutil/stereo3d: Fill out stereo info provided by Vision Pro files

[Derek Buitenhuis]

Based on what is in the files themselves, and what the API provides
to users.

URLs:
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
  * 
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview

Signed-off-by: Derek Buitenhuis 
---
 libavutil/stereo3d.c | 52 +
 libavutil/stereo3d.h | 78 
 libavutil/version.h  |  2 +-
 3 files changed, 131 insertions(+), 1 deletion(-)

diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 9c29ab01b5..a40a9439bb 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -55,6 +55,18 @@ static const char * const stereo3d_type_names[] = {
 [AV_STEREO3D_COLUMNS] = "interleaved columns",
 };
 
+static const char * const stereo3d_view_names[] = {
+[AV_STEREO3D_VIEW_PACKED] = "packed",
+[AV_STEREO3D_VIEW_LEFT]   = "left",
+[AV_STEREO3D_VIEW_RIGHT]  = "right",
+};
+
+static const char * const stereo3d_primary_eye_names[] = {
+[AV_PRIMARY_EYE_NONE]  = "none",
+[AV_PRIMARY_EYE_LEFT]  = "left",
+[AV_PRIMARY_EYE_RIGHT] = "right",
+};
+
 const char *av_stereo3d_type_name(unsigned int type)
 {
 if (type >= FF_ARRAY_ELEMS(stereo3d_type_names))
@@ -74,3 +86,43 @@ int av_stereo3d_from_name(const char *name)
 
 return -1;
 }
+
+const char *av_stereo3d_view_name(unsigned int view)
+{
+if (view >= FF_ARRAY_ELEMS(stereo3d_view_names))
+return "unknown";
+
+return stereo3d_view_names[view];
+}
+
+int av_stereo3d_view_from_name(const char *name)
+{
+int i;
+
+for (i = 0; i < FF_ARRAY_ELEMS(stereo3d_view_names); i++) {
+if (av_strstart(name, stereo3d_view_names[i], NULL))
+return i;
+}
+
+return -1;
+}
+
+const char *av_stereo3d_primary_eye_name(unsigned int eye)
+{
+if (eye >= FF_ARRAY_ELEMS(stereo3d_primary_eye_names))
+return "unknown";
+
+return stereo3d_primary_eye_names[eye];
+}
+
+int av_stereo3d_primary_eye_from_name(const char *name)
+{
+int i;
+
+for (i = 0; i < FF_ARRAY_ELEMS(stereo3d_primary_eye_names); i++) {
+if (av_strstart(name, stereo3d_primary_eye_names[i], NULL))
+return i;
+}
+
+return -1;
+}
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 3aab959b79..d35e46e670 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -158,6 +158,26 @@ enum AVStereo3DView {
 AV_STEREO3D_VIEW_RIGHT,
 };
 
+/**
+ * List of possible primary eyes.
+ */
+enum AVStereo3DPrimaryEye {
+/**
+ * Neither eye.
+ */
+AV_PRIMARY_EYE_NONE,
+
+/**
+ * Left eye.
+ */
+AV_PRIMARY_EYE_LEFT,
+
+/**
+ * Right eye
+ */
+AV_PRIMARY_EYE_RIGHT,
+};
+
 /**
  * Inverted views, Right/Bottom represents the left view.
  */
@@ -185,6 +205,28 @@ typedef struct AVStereo3D {
  * Determines which views are packed.
  */
 enum AVStereo3DView view;
+
+/**
+ * Which eye is the primary eye when rendering in 2D.
+ */
+enum AVStereo3DPrimaryEye primary_eye;
+
+/**
+ * The distance between the centres of the lenses of the camera system,
+ * in micrometers. Zero if unset.
+ */
+uint32_t baseline;
+
+/**
+ * Relative shift of the left and right images, which changes the zero 
parallax plane.
+ * Range -1 to 1, mapped to -1.0 to 1.0. Zero if unset.
+ */
+int32_t horizontal_disparity_adjustment;
+
+/**
+ * Horizontal field of view in thousanths of a degree. Zero if unset.
+ */
+uint32_t horizontal_field_of_view;
 } AVStereo3D;
 
 /**
@@ -222,6 +264,42 @@ const char *av_stereo3d_type_name(unsigned int type);
  */
 int av_stereo3d_from_name(const char *name);
 
+/**
+ * Provide a human-readable name of a given stereo3d view.
+ *
+ * @param type The input stereo3d view value.
+ *
+ * @return The name of the stereo3d view value, or "unknown".
+ */
+const char *av_stereo3d_view_name(unsigned int view);
+
+/**
+ * Get the AVStereo3DView form a human-readable name.
+ *
+ * @param name The input string.
+ *
+ * @return The AVStereo3DView value, or -1 if not found.
+ */
+int av_stereo3d_view_from_name(const char *name);
+
+/**
+ * Provide a human-readable name of a given stereo3d primary eye.
+ *
+ * @param type The input stereo3d primary eye value.
+ *
+ * @return The name of the stereo3d primary eye value, or "unknown".
+ */
+const char *av_stereo3d_primary_eye_name(unsigned int eye);
+
+/**
+ * Get the AVStereo3DPrimaryEye form a human-readable name.
+ *
+ * @param name The input string.
+ *
+ * @return The AVStereo3DPrimaryEye value, or -1 if not found.
+ */
+int av_stereo3d_primary_eye_from_name(const char *name);
+
 /**
  * @}
  */
diff

[FFmpeg-devel] [PATCH v2 3/5] fftools/ffprobe: Print more Stereo 3D info from side data

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis 
---
 fftools/ffprobe.c| 8 
 tests/ref/fate/matroska-spherical-mono   | 2 ++
 tests/ref/fate/matroska-spherical-mono-remux | 4 
 tests/ref/fate/matroska-stereo_mode  | 8 
 tests/ref/fate/matroska-vp8-alpha-remux  | 2 ++
 tests/ref/fate/mov-spherical-mono| 2 ++
 6 files changed, 26 insertions(+)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 2d38e5dfdc..082cec8a64 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2544,6 +2544,14 @@ static void print_pkt_side_data(WriterContext *w,
 const AVStereo3D *stereo = (AVStereo3D *)sd->data;
 print_str("type", av_stereo3d_type_name(stereo->type));
 print_int("inverted", !!(stereo->flags & AV_STEREO3D_FLAG_INVERT));
+print_str("view", av_stereo3d_view_name(stereo->view));
+print_str("primary_eye", 
av_stereo3d_primary_eye_name(stereo->primary_eye));
+if (stereo->baseline)
+print_int("baseline", stereo->baseline);
+if (stereo->horizontal_disparity_adjustment)
+print_int("horizontal_disparity_adjustment", 
stereo->horizontal_disparity_adjustment);
+if (stereo->horizontal_field_of_view)
+print_int("horizontal_field_of_view", 
stereo->horizontal_field_of_view);
 } else if (sd->type == AV_PKT_DATA_SPHERICAL) {
 const AVSphericalMapping *spherical = (AVSphericalMapping 
*)sd->data;
 print_str("projection", 
av_spherical_projection_name(spherical->projection));
diff --git a/tests/ref/fate/matroska-spherical-mono 
b/tests/ref/fate/matroska-spherical-mono
index bd57d94514..08b94e455b 100644
--- a/tests/ref/fate/matroska-spherical-mono
+++ b/tests/ref/fate/matroska-spherical-mono
@@ -3,6 +3,8 @@
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [SIDE_DATA]
 side_data_type=Spherical Mapping
diff --git a/tests/ref/fate/matroska-spherical-mono-remux 
b/tests/ref/fate/matroska-spherical-mono-remux
index 6fcda14822..0ca77c8074 100644
--- a/tests/ref/fate/matroska-spherical-mono-remux
+++ b/tests/ref/fate/matroska-spherical-mono-remux
@@ -27,6 +27,8 @@ DISPOSITION:forced=1
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [SIDE_DATA]
 side_data_type=Spherical Mapping
@@ -51,6 +53,8 @@ DISPOSITION:forced=0
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [SIDE_DATA]
 side_data_type=Spherical Mapping
diff --git a/tests/ref/fate/matroska-stereo_mode 
b/tests/ref/fate/matroska-stereo_mode
index 739b789fea..13bce13cb8 100644
--- a/tests/ref/fate/matroska-stereo_mode
+++ b/tests/ref/fate/matroska-stereo_mode
@@ -132,6 +132,8 @@ TAG:DURATION=00:00:10.0
 side_data_type=Stereo 3D
 type=side by side
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
 [STREAM]
@@ -147,6 +149,8 @@ TAG:DURATION=00:00:10.0
 side_data_type=Stereo 3D
 type=top and bottom
 inverted=1
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
 [STREAM]
@@ -160,6 +164,8 @@ TAG:DURATION=00:00:10.0
 side_data_type=Stereo 3D
 type=interleaved lines
 inverted=1
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
 [STREAM]
@@ -174,6 +180,8 @@ TAG:DURATION=00:00:10.0
 side_data_type=Stereo 3D
 type=interleaved columns
 inverted=1
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
 [STREAM]
diff --git a/tests/ref/fate/matroska-vp8-alpha-remux 
b/tests/ref/fate/matroska-vp8-alpha-remux
index f6c24dead6..e54304cafd 100644
--- a/tests/ref/fate/matroska-vp8-alpha-remux
+++ b/tests/ref/fate/matroska-vp8-alpha-remux
@@ -35,5 +35,7 @@ DISPOSITION:still_image=0
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
diff --git a/tests/ref/fate/mov-spherical-mono 
b/tests/ref/fate/mov-spherical-mono
index bd57d94514..08b94e455b 100644
--- a/tests/ref/fate/mov-spherical-mono
+++ b/tests/ref/fate/mov-spherical-mono
@@ -3,6 +3,8 @@
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [SIDE_DATA]
 side_data_type=Spherical Mapping
-- 
2.43.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 v2 4/5] avformat/mov: Add support for exporting Video Extension Usage info

[Derek Buitenhuis]

This box is provided by files created by the Apple Vision Pro, as well
as the iPhone 15+ when capture for Vision Pro is enabled.

The boxes are a mix of things documented by Apple in some PDFs, their
API docs, and reverse engineering. Ideally we will have a real spec
one day.

Links:
  * 
https://developer.apple.com/av-foundation/Stereo-Video-ISOBMFF-Extensions.pdf
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye

Signed-off-by: Derek Buitenhuis 
---
 libavformat/mov.c | 279 ++
 1 file changed, 279 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9016cd5ad0..a7ca0b5a3c 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6477,6 +6477,284 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return 0;
 }
 
+static int mov_read_vexu_proj(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+int size;
+uint32_t tag;
+enum AVSphericalProjection projection;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+if (atom.size != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size for proj box: %"PRIu64"\n", 
atom.size);
+return AVERROR_INVALIDDATA;
+}
+
+size = avio_rb32(pb);
+if (size != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size for prji box: %d\n", size);
+return AVERROR_INVALIDDATA;
+}
+
+tag = avio_rl32(pb);
+if (tag != MKTAG('p','r','j','i')) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid child box of proj box: 0x%08X\n", 
tag);
+return AVERROR_INVALIDDATA;
+}
+
+avio_skip(pb, 1); // version
+avio_skip(pb, 3); // flags
+
+tag = avio_rl32(pb);
+switch (tag) {
+case MKTAG('r','e','c','t'):
+projection = AV_SPHERICAL_RECTANGULAR;
+break;
+case MKTAG('e','q','u','i'):
+projection = AV_SPHERICAL_EQUIRECTANGULAR;
+break;
+case MKTAG('h','e','q','u'):
+projection = AV_SPHERICAL_HALF_EQUIRECTANGULAR;
+break;
+case MKTAG('f','i','s','h'):
+projection = AV_SPHERICAL_FISHEYE;
+break;
+default:
+av_log(c->fc, AV_LOG_ERROR, "Invalid projection type in prji box: 
0x%08X\n", tag);
+return AVERROR_INVALIDDATA;
+}
+
+sc->spherical = av_spherical_alloc(&sc->spherical_size);
+if (!sc->spherical)
+return AVERROR(ENOMEM);
+
+sc->spherical->projection = projection;
+
+return 0;
+}
+
+static int mov_read_eyes(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+int size, flags = 0;
+int64_t remaining;
+uint32_t tag, baseline = 0;
+enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
+enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
+int32_t horizontal_disparity_adjustment = 0;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+remaining = atom.size;
+while (remaining > 0) {
+size = avio_rb32(pb);
+if (size < 8 || size > remaining ) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid child size in eyes box\n");
+return AVERROR_INVALIDDATA;
+}
+
+tag = avio_rl32(pb);
+switch (tag) {
+case MKTAG('s','t','r','i'): {
+int has_right, has_left;
+uint8_t tmp;
+if (size != 13) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size of stri box: %d\n", 
size);
+return AVERROR_INVALIDDATA;
+}
+avio_skip(pb, 1); // version
+avio_skip(pb, 3); // flags
+
+tmp = avio_r8(pb);
+
+// eye_views_reversed
+if (tmp & 8) {
+flags |= AV_STEREO3D_FLAG_INVERT;
+}
+// has_additional_views
+if (tmp & 4) {
+// skip...
+}
+
+has_right = tmp & 2; // has_right_eye_view
+has_left = tmp & 1; // has_left_eye_view
+
+if (has_left && has_right)
+view = AV_STEREO3D_VIEW_PACKED;
+else if (has_left)
+view = AV_STEREO3D_VIEW_LEFT;
+else if (has_right)
+view = AV_STEREO3D_VIEW_RIGHT;
+break;
+}
+case MKTAG('h','e','r','o'): {
+int tmp;
+if (size != 13) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size of hero box: %d\n", 
size);
+return AVERROR_INVALIDDATA;
+}
+avio_skip(pb, 1); // version
+avio_skip(pb, 3); // flags
+

[FFmpeg-devel] [PATCH v2 5/5] avformat/mov: Add support for reading and exporting horizontal field of view

[Derek Buitenhuis]

These boxes are created by the Apple Vision Pro and the iPhone 15+ when
capture for the Vision Pro is enabled.

Based off of the swift API:
  * 
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview

Signed-off-by: Derek Buitenhuis 
---
 libavformat/mov.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index a7ca0b5a3c..391b11a4e1 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6755,6 +6755,34 @@ static int mov_read_vexu(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return 0;
 }
 
+static int mov_read_hfov(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+if (atom.size != 4) {
+ av_log(c->fc, AV_LOG_ERROR, "Invalid size of hfov box: %"PRIu64"\n", 
atom.size);
+ return AVERROR_INVALIDDATA;
+}
+
+
+if (!sc->stereo3d) {
+sc->stereo3d = av_stereo3d_alloc();
+if (!sc->stereo3d)
+return AVERROR(ENOMEM);
+}
+
+sc->stereo3d->horizontal_field_of_view = avio_rb32(pb);
+
+return 0;
+}
+
 static int mov_parse_uuid_spherical(MOVStreamContext *sc, AVIOContext *pb, 
size_t len)
 {
 int ret = 0;
@@ -8874,6 +8902,7 @@ static const MOVParseTableEntry mov_default_parse_table[] 
= {
 { MKTAG('s','t','3','d'), mov_read_st3d }, /* stereoscopic 3D video box */
 { MKTAG('s','v','3','d'), mov_read_sv3d }, /* spherical video box */
 { MKTAG('v','e','x','u'), mov_read_vexu }, /* video extension usage */
+{ MKTAG('h','f','o','v'), mov_read_hfov },
 { MKTAG('d','O','p','s'), mov_read_dops },
 { MKTAG('d','m','l','p'), mov_read_dmlp },
 { MKTAG('S','m','D','m'), mov_read_smdm },
-- 
2.43.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 v3 4/5] avformat/mov: Add support for exporting Video Extension Usage info

[Derek Buitenhuis]

This box is provided by files created by the Apple Vision Pro, as well
as the iPhone 15+ when capture for Vision Pro is enabled.

The boxes are a mix of things documented by Apple in some PDFs, their
API docs, and reverse engineering. Ideally we will have a real spec
one day.

Links:
  * 
https://developer.apple.com/av-foundation/Stereo-Video-ISOBMFF-Extensions.pdf
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye

Signed-off-by: Derek Buitenhuis 
---
Only difference from v2 is s/RECTANGULAR/RECTILINEAR/.
---
 libavformat/mov.c | 279 ++
 1 file changed, 279 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9016cd5ad0..0f8d7e83b2 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6477,6 +6477,284 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return 0;
 }
 
+static int mov_read_vexu_proj(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+int size;
+uint32_t tag;
+enum AVSphericalProjection projection;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+if (atom.size != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size for proj box: %"PRIu64"\n", 
atom.size);
+return AVERROR_INVALIDDATA;
+}
+
+size = avio_rb32(pb);
+if (size != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size for prji box: %d\n", size);
+return AVERROR_INVALIDDATA;
+}
+
+tag = avio_rl32(pb);
+if (tag != MKTAG('p','r','j','i')) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid child box of proj box: 0x%08X\n", 
tag);
+return AVERROR_INVALIDDATA;
+}
+
+avio_skip(pb, 1); // version
+avio_skip(pb, 3); // flags
+
+tag = avio_rl32(pb);
+switch (tag) {
+case MKTAG('r','e','c','t'):
+projection = AV_SPHERICAL_RECTILINEAR;
+break;
+case MKTAG('e','q','u','i'):
+projection = AV_SPHERICAL_EQUIRECTANGULAR;
+break;
+case MKTAG('h','e','q','u'):
+projection = AV_SPHERICAL_HALF_EQUIRECTANGULAR;
+break;
+case MKTAG('f','i','s','h'):
+projection = AV_SPHERICAL_FISHEYE;
+break;
+default:
+av_log(c->fc, AV_LOG_ERROR, "Invalid projection type in prji box: 
0x%08X\n", tag);
+return AVERROR_INVALIDDATA;
+}
+
+sc->spherical = av_spherical_alloc(&sc->spherical_size);
+if (!sc->spherical)
+return AVERROR(ENOMEM);
+
+sc->spherical->projection = projection;
+
+return 0;
+}
+
+static int mov_read_eyes(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+int size, flags = 0;
+int64_t remaining;
+uint32_t tag, baseline = 0;
+enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
+enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
+int32_t horizontal_disparity_adjustment = 0;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+remaining = atom.size;
+while (remaining > 0) {
+size = avio_rb32(pb);
+if (size < 8 || size > remaining ) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid child size in eyes box\n");
+return AVERROR_INVALIDDATA;
+}
+
+tag = avio_rl32(pb);
+switch (tag) {
+case MKTAG('s','t','r','i'): {
+int has_right, has_left;
+uint8_t tmp;
+if (size != 13) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size of stri box: %d\n", 
size);
+return AVERROR_INVALIDDATA;
+}
+avio_skip(pb, 1); // version
+avio_skip(pb, 3); // flags
+
+tmp = avio_r8(pb);
+
+// eye_views_reversed
+if (tmp & 8) {
+flags |= AV_STEREO3D_FLAG_INVERT;
+}
+// has_additional_views
+if (tmp & 4) {
+// skip...
+}
+
+has_right = tmp & 2; // has_right_eye_view
+has_left = tmp & 1; // has_left_eye_view
+
+if (has_left && has_right)
+view = AV_STEREO3D_VIEW_PACKED;
+else if (has_left)
+view = AV_STEREO3D_VIEW_LEFT;
+else if (has_right)
+view = AV_STEREO3D_VIEW_RIGHT;
+break;
+}
+case MKTAG('h','e','r','o'): {
+int tmp;
+if (size != 13) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size of hero box: %d\n", 
size);
+return AVERROR_INVALIDDATA;
+}
+avio_skip(pb

Re: [FFmpeg-devel] [PATCH v2 4/5] avformat/mov: Add support for exporting Video Extension Usage info

[Derek Buitenhuis]

On 6/17/2024 2:41 PM, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavformat/mov.c | 279 ++
>  1 file changed, 279 insertions(+)

Replaced by v3.

- Derek
___
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 1/2] avformat/evc: remove useless struct field

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/evc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/evc.c b/libavformat/evc.c
index 0b72a6441e..928ae1ff65 100644
--- a/libavformat/evc.c
+++ b/libavformat/evc.c
@@ -60,7 +60,6 @@ typedef struct EVCDecoderConfigurationRecord {
 uint8_t  bit_depth_chroma_minus8;   // 3 bits
 uint16_t pic_width_in_luma_samples; // 16 bits
 uint16_t pic_height_in_luma_samples;// 16 bits
-uint8_t  reserved;  // 6 bits '00'b
 uint8_t  lengthSizeMinusOne;// 2 bits
 uint8_t  num_of_arrays; // 8 bits
 EVCNALUnitArray arrays[NB_ARRAYS];
-- 
2.45.2

___
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 2/2] avformat/evc: fix writing reserved bits

[James Almer]

They are all zeroes, no ones.

Signed-off-by: James Almer 
---
 libavformat/evc.c   | 4 ++--
 tests/ref/lavf-fate/evc.mp4 | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/evc.c b/libavformat/evc.c
index 928ae1ff65..ff350aad21 100644
--- a/libavformat/evc.c
+++ b/libavformat/evc.c
@@ -257,10 +257,10 @@ static int evcc_write(AVIOContext *pb, 
EVCDecoderConfigurationRecord *evcc)
 avio_wb16(pb, evcc->pic_height_in_luma_samples);
 
 /*
- * bit(6) reserved = '11'b;
+ * unsigned int(6) reserved = '00'b;
  * unsigned int(2) chromaFormat;
  */
-avio_w8(pb, evcc->lengthSizeMinusOne | 0xfc);
+avio_w8(pb, evcc->lengthSizeMinusOne);
 
 /* unsigned int(8) numOfArrays; */
 avio_w8(pb, evcc->num_of_arrays);
diff --git a/tests/ref/lavf-fate/evc.mp4 b/tests/ref/lavf-fate/evc.mp4
index 4b410b84f3..6ef7af4ddc 100644
--- a/tests/ref/lavf-fate/evc.mp4
+++ b/tests/ref/lavf-fate/evc.mp4
@@ -1,3 +1,3 @@
-885fb330b20632b88ef9d7fb03dfa2e9 *tests/data/lavf-fate/lavf.evc.mp4
+bebb66fc3e13ece081d1aa96802e3c1f *tests/data/lavf-fate/lavf.evc.mp4
 37386 tests/data/lavf-fate/lavf.evc.mp4
 tests/data/lavf-fate/lavf.evc.mp4 CRC=0x48063f85
-- 
2.45.2

___
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] fate/lavf-container: add a hevc in ISOBMFF remux test

[James Almer]

Signed-off-by: James Almer 
---
 tests/fate/lavf-container.mak | 2 ++
 tests/ref/lavf-fate/hevc.mp4  | 3 +++
 2 files changed, 5 insertions(+)
 create mode 100644 tests/ref/lavf-fate/hevc.mp4

diff --git a/tests/fate/lavf-container.mak b/tests/fate/lavf-container.mak
index d84117c50f..56490c3369 100644
--- a/tests/fate/lavf-container.mak
+++ b/tests/fate/lavf-container.mak
@@ -74,6 +74,7 @@ FATE_LAVF_CONTAINER_FATE-$(call ALLYES, IVF_DEMUXER 
AV1_DECODER AV1_PARSER MOV_M
 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, IVF_DEMUXER AV1_DECODER AV1_PARSER 
MATROSKA_MUXER) += av1.mkv
 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, EVC_DEMUXER EVC_PARSER MOV_MUXER)  
+= evc.mp4
 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, H264_DEMUXER H264_PARSER MOV_MUXER)
+= h264.mp4
+FATE_LAVF_CONTAINER_FATE-$(call ALLYES, HEVC_DEMUXER HEVC_PARSER MOV_MUXER)
+= hevc.mp4
 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, VVC_DEMUXER VVC_PARSER MOV_MUXER)  
+= vvc.mp4
 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MATROSKA_DEMUXER   OGG_MUXER)  
+= vp3.ogg
 FATE_LAVF_CONTAINER_FATE-$(call ALLYES, MATROSKA_DEMUXER   OGV_MUXER)  
+= vp8.ogg
@@ -92,6 +93,7 @@ fate-lavf-fate-av1.mp4: CMD = lavf_container_fate 
"av1-test-vectors/av1-1-b8-05-
 fate-lavf-fate-av1.mkv: CMD = lavf_container_fate 
"av1-test-vectors/av1-1-b8-05-mv.ivf" "-c:v av1" "-c:v copy"
 fate-lavf-fate-evc.mp4: CMD = lavf_container_fate "evc/akiyo_cif.evc" "" "-c:v 
copy"
 fate-lavf-fate-h264.mp4: CMD = lavf_container_fate "h264/intra_refresh.h264" 
"" "-c:v copy"
+fate-lavf-fate-hevc.mp4: CMD = lavf_container_fate 
"hevc-conformance/HRD_A_Fujitsu_2.bit" "" "-c:v copy"
 fate-lavf-fate-vvc.mp4: CMD = lavf_container_fate 
"vvc-conformance/VPS_A_3.bit" "" "-c:v copy"
 fate-lavf-fate-vp3.ogg: CMD = lavf_container_fate "vp3/coeff_level64.mkv" 
"-idct auto"
 fate-lavf-fate-vp8.ogg: CMD = lavf_container_fate "vp8/RRSF49-short.webm" "" 
"-acodec copy"
diff --git a/tests/ref/lavf-fate/hevc.mp4 b/tests/ref/lavf-fate/hevc.mp4
new file mode 100644
index 00..aea5ae8979
--- /dev/null
+++ b/tests/ref/lavf-fate/hevc.mp4
@@ -0,0 +1,3 @@
+37b3a3e84df2350380b05b2af4dc97f5 *tests/data/lavf-fate/lavf.hevc.mp4
+151340 tests/data/lavf-fate/lavf.hevc.mp4
+tests/data/lavf-fate/lavf.hevc.mp4 CRC=0xc0a771de
-- 
2.45.2

___
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/3] avfilter/af_volumedetect.c: Add 32bit float audio support

[Rémi Denis-Courmont]

Le 17 juin 2024 13:18:11 GMT+02:00, Yigithan Yigit 
 a écrit :
>---
> libavfilter/af_volumedetect.c | 159 --
> 1 file changed, 133 insertions(+), 26 deletions(-)
>
>diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
>index 327801a7f9..dbbcd037a5 100644
>--- a/libavfilter/af_volumedetect.c
>+++ b/libavfilter/af_volumedetect.c
>@@ -20,27 +20,51 @@
> 
> #include "libavutil/channel_layout.h"
> #include "libavutil/avassert.h"
>+#include "libavutil/mem.h"
> #include "audio.h"
> #include "avfilter.h"
> #include "internal.h"
> 
>+#define MAX_DB_FLT 1024
> #define MAX_DB 91
>+#define HISTOGRAM_SIZE 0x1
>+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
> 
> typedef struct VolDetectContext {
>-/**
>- * Number of samples at each PCM value.
>- * histogram[0x8000 + i] is the number of samples at value i.
>- * The extra element is there for symmetry.
>- */
>-uint64_t histogram[0x10001];
>+uint64_t* histogram; ///< for integer number of samples at each PCM 
>value, for float number of samples at each dB
>+uint64_t nb_samples; ///< number of samples
>+double sum2; ///< sum of the squares of the samples
>+double max;  ///< maximum sample value
>+int is_float;///< true if the input is in floating point
> } VolDetectContext;
> 
>-static inline double logdb(uint64_t v)
>+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
> {
>-double d = v / (double)(0x8000 * 0x8000);
>-if (!v)
>-return MAX_DB;
>-return -log10(d) * 10;
>+if (sample_fmt == AV_SAMPLE_FMT_FLT) {
>+if (!v)
>+return MAX_DB_FLT;
>+return -log10(v) * 10;
>+} else {
>+double d = v / (double)(0x8000 * 0x8000);
>+if (!v)
>+return MAX_DB;
>+return -log10(d) * 10;
>+}
>+}
>+
>+static void update_float_stats(VolDetectContext *vd, float *audio_data)
>+{
>+double sample;
>+int idx;
>+if(!isnormal(*audio_data))
>+return;

Do we really need to classify floats here? That's probably going to hurt perfs 
badly, and makes an otherwise very vectorisable function not so easily vectored.

>+sample = fabsf(*audio_data);
>+if (sample > vd->max)
>+vd->max = sample;
>+vd->sum2 += sample * sample;
>+idx = lrintf(floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT))) + 
>MAX_DB_FLT;

You're recomputing the same value again, and you seem to be rounding twice in a 
row?

>+vd->histogram[idx]++;
>+vd->nb_samples++;
> }
> 
> static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
>@@ -51,18 +75,41 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
>*samples)
> int nb_channels = samples->ch_layout.nb_channels;
> int nb_planes   = nb_channels;
> int plane, i;
>-int16_t *pcm;
>+int planar = 0;
> 
>-if (!av_sample_fmt_is_planar(samples->format)) {
>-nb_samples *= nb_channels;
>+planar = av_sample_fmt_is_planar(samples->format);
>+if (!planar)
> nb_planes = 1;
>+if (vd->is_float) {
>+float *audio_data;
>+for (plane = 0; plane < nb_planes; plane++) {
>+audio_data = (float *)samples->extended_data[plane];
>+for (i = 0; i < nb_samples; i++) {
>+if (planar) {
>+update_float_stats(vd, &audio_data[i]);
>+} else {
>+for (int j = 0; j < nb_channels; j++)
>+update_float_stats(vd, &audio_data[i * nb_channels + 
>j]);
>+}
>+}
>+}
>+} else {
>+int16_t *pcm;
>+for (plane = 0; plane < nb_planes; plane++) {
>+pcm = (int16_t *)samples->extended_data[plane];
>+for (i = 0; i < nb_samples; i++) {
>+if (planar) {
>+vd->histogram[pcm[i] + 0x8000]++;
>+vd->nb_samples++;
>+} else {
>+for (int j = 0; j < nb_channels; j++) {
>+vd->histogram[pcm[i * nb_channels + j] + 0x8000]++;
>+vd->nb_samples++;
>+}
>+}
>+}
>+}

Can't we pick the correct implementation (planar/packed and float/int) once and 
for all whilst configuring the filter?

> }
>-for (plane = 0; plane < nb_planes; plane++) {
>-pcm = (int16_t *)samples->extended_data[plane];
>-for (i = 0; i < nb_samples; i++)
>-vd->histogram[pcm[i] + 0x8000]++;
>-}
>-
> return ff_filter_frame(inlink->dst->outputs[0], samples);
> }
> 
>@@ -73,6 +120,20 @@ static void print_stats(AVFilterContext *ctx)
> uint64_t nb_samples = 0, power = 0, nb_samples_shift = 0, sum = 0;
> uint64_t histdb[MAX_DB + 1] = { 0 };
> 
>+if (!vd->nb_samples)
>+return;
>+if (vd->is_float) {
>+av_log(ctx, AV_LOG_INFO, "n_samples: %" PRId64 "\n", vd->nb_samples);
>+av_log(ctx, AV

Re: [FFmpeg-devel] [PATCH v2 2/5] avutil/stereo3d: Fill out stereo info provided by Vision Pro files

[James Almer]

On 6/17/2024 10:41 AM, Derek Buitenhuis wrote:

Based on what is in the files themselves, and what the API provides
to users.

URLs:
   * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye
   * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
   * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
   * 
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview

Signed-off-by: Derek Buitenhuis 
---
  libavutil/stereo3d.c | 52 +
  libavutil/stereo3d.h | 78 
  libavutil/version.h  |  2 +-
  3 files changed, 131 insertions(+), 1 deletion(-)

diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 9c29ab01b5..a40a9439bb 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -55,6 +55,18 @@ static const char * const stereo3d_type_names[] = {
  [AV_STEREO3D_COLUMNS] = "interleaved columns",
  };
  
+static const char * const stereo3d_view_names[] = {

+[AV_STEREO3D_VIEW_PACKED] = "packed",
+[AV_STEREO3D_VIEW_LEFT]   = "left",
+[AV_STEREO3D_VIEW_RIGHT]  = "right",
+};
+
+static const char * const stereo3d_primary_eye_names[] = {
+[AV_PRIMARY_EYE_NONE]  = "none",
+[AV_PRIMARY_EYE_LEFT]  = "left",
+[AV_PRIMARY_EYE_RIGHT] = "right",
+};
+
  const char *av_stereo3d_type_name(unsigned int type)
  {
  if (type >= FF_ARRAY_ELEMS(stereo3d_type_names))
@@ -74,3 +86,43 @@ int av_stereo3d_from_name(const char *name)
  
  return -1;

  }
+
+const char *av_stereo3d_view_name(unsigned int view)
+{
+if (view >= FF_ARRAY_ELEMS(stereo3d_view_names))
+return "unknown";
+
+return stereo3d_view_names[view];
+}
+
+int av_stereo3d_view_from_name(const char *name)
+{
+int i;
+
+for (i = 0; i < FF_ARRAY_ELEMS(stereo3d_view_names); i++) {
+if (av_strstart(name, stereo3d_view_names[i], NULL))
+return i;
+}
+
+return -1;
+}
+
+const char *av_stereo3d_primary_eye_name(unsigned int eye)
+{
+if (eye >= FF_ARRAY_ELEMS(stereo3d_primary_eye_names))
+return "unknown";
+
+return stereo3d_primary_eye_names[eye];
+}
+
+int av_stereo3d_primary_eye_from_name(const char *name)
+{
+int i;
+
+for (i = 0; i < FF_ARRAY_ELEMS(stereo3d_primary_eye_names); i++) {
+if (av_strstart(name, stereo3d_primary_eye_names[i], NULL))
+return i;
+}
+
+return -1;
+}
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 3aab959b79..d35e46e670 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -158,6 +158,26 @@ enum AVStereo3DView {
  AV_STEREO3D_VIEW_RIGHT,
  };
  
+/**

+ * List of possible primary eyes.
+ */
+enum AVStereo3DPrimaryEye {
+/**
+ * Neither eye.
+ */
+AV_PRIMARY_EYE_NONE,
+
+/**
+ * Left eye.
+ */
+AV_PRIMARY_EYE_LEFT,
+
+/**
+ * Right eye
+ */
+AV_PRIMARY_EYE_RIGHT,
+};
+
  /**
   * Inverted views, Right/Bottom represents the left view.
   */
@@ -185,6 +205,28 @@ typedef struct AVStereo3D {
   * Determines which views are packed.
   */
  enum AVStereo3DView view;
+
+/**
+ * Which eye is the primary eye when rendering in 2D.
+ */
+enum AVStereo3DPrimaryEye primary_eye;
+
+/**
+ * The distance between the centres of the lenses of the camera system,
+ * in micrometers. Zero if unset.
+ */
+uint32_t baseline;
+
+/**
+ * Relative shift of the left and right images, which changes the zero 
parallax plane.
+ * Range -1 to 1, mapped to -1.0 to 1.0. Zero if unset.


Maybe this should be an AVRational then.


+ */
+int32_t horizontal_disparity_adjustment;
+
+/**
+ * Horizontal field of view in thousanths of a degree. Zero if unset.
+ */
+uint32_t horizontal_field_of_view;
  } AVStereo3D;
  
  /**

@@ -222,6 +264,42 @@ const char *av_stereo3d_type_name(unsigned int type);
   */
  int av_stereo3d_from_name(const char *name);
  
+/**

+ * Provide a human-readable name of a given stereo3d view.
+ *
+ * @param type The input stereo3d view value.
+ *
+ * @return The name of the stereo3d view value, or "unknown".
+ */
+const char *av_stereo3d_view_name(unsigned int view);
+
+/**
+ * Get the AVStereo3DView form a human-readable name.
+ *
+ * @param name The input string.
+ *
+ * @return The AVStereo3DView value, or -1 if not found.
+ */
+int av_stereo3d_view_from_name(const char *name);
+
+/**
+ * Provide a human-readable name of a given stereo3d primary eye.
+ *
+ * @param type The input stereo3d primary eye value.
+ *
+ * @return The name of the stereo3d primary eye value, or "unknown".
+ */
+const char *av_stereo3d_primary_eye_name(unsigned int eye);
+
+/**
+ * Get the AVStereo3DPrimaryEye form a human-readable name.
+ *
+ * @param name The input string.
+ *
+ * @return The AVS

[FFmpeg-devel] [PATCH v2 1/2] avutil/timer: Fix missing header for mach_absolute_time

[Zhao Zhili]

From: Zhao Zhili 

mach/mach_time.h was included only when CONFIG_MACOS_KPERF wasn't
been defined.

Signed-off-by: Zhao Zhili 
---
 libavutil/timer.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavutil/timer.h b/libavutil/timer.h
index 6bd6a0c645..9fe6aa1385 100644
--- a/libavutil/timer.h
+++ b/libavutil/timer.h
@@ -44,7 +44,9 @@
 
 #if CONFIG_MACOS_KPERF
 #include "macos_kperf.h"
-#elif HAVE_MACH_ABSOLUTE_TIME
+#endif
+
+#if HAVE_MACH_ABSOLUTE_TIME
 #include 
 #elif HAVE_CLOCK_GETTIME
 #include 
-- 
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 v2 2/2] avutil/macos_kperf: Fix assert which makes kperf failed to run

[Zhao Zhili]

From: Zhao Zhili 

On m1, kpc_get_counter_count(KPC_MASK) return 8 in my test. The
exact value doesn't matter in our case, as long as we have a
sufficiently large array

Signed-off-by: Zhao Zhili 
---
 libavutil/macos_kperf.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavutil/macos_kperf.c b/libavutil/macos_kperf.c
index 9fb047..b2c1d164ac 100644
--- a/libavutil/macos_kperf.c
+++ b/libavutil/macos_kperf.c
@@ -67,14 +67,15 @@ KPERF_LIST
 #define KPC_CLASS_POWER_MASK(1 << 2)
 #define KPC_CLASS_RAWPMU_MASK   (1 << 3)
 
-#define COUNTERS_COUNT 10
+#define KPC_MAX_COUNTERS 32
 #define CONFIG_COUNT 8
 #define KPC_MASK (KPC_CLASS_CONFIGURABLE_MASK | KPC_CLASS_FIXED_MASK)
 
 static void kperf_init(void)
 {
-uint64_t config[COUNTERS_COUNT] = {0};
+uint64_t config[CONFIG_COUNT] = {0};
 void *kperf = NULL;
+uint32_t n;
 
 av_assert0(kperf = 
dlopen("/System/Library/PrivateFrameworks/kperf.framework/Versions/A/kperf", 
RTLD_LAZY));
 
@@ -82,8 +83,10 @@ static void kperf_init(void)
 KPERF_LIST
 #undef F
 
-av_assert0(kpc_get_counter_count(KPC_MASK) == COUNTERS_COUNT);
-av_assert0(kpc_get_config_count(KPC_MASK) == CONFIG_COUNT);
+n = kpc_get_counter_count(KPC_MASK);
+av_assert0(n <= KPC_MAX_COUNTERS);
+n = kpc_get_config_count(KPC_MASK);
+av_assert0(n <= CONFIG_COUNT);
 
 config[0] = CPMU_CORE_CYCLE | CFGWORD_EL0A64EN_MASK;
 // config[3] = CPMU_INST_BRANCH | CFGWORD_EL0A64EN_MASK;
@@ -104,8 +107,9 @@ void ff_kperf_init(void)
 
 uint64_t ff_kperf_cycles(void)
 {
-uint64_t counters[COUNTERS_COUNT];
-if (kpc_get_thread_counters(0, COUNTERS_COUNT, counters)) {
+uint64_t counters[KPC_MAX_COUNTERS];
+
+if (kpc_get_thread_counters(0, KPC_MAX_COUNTERS, counters)) {
 return -1;
 }
 
-- 
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".

Re: [FFmpeg-devel] [PATCH v2 2/5] avutil/stereo3d: Fill out stereo info provided by Vision Pro files

[Derek Buitenhuis]

On 6/17/2024 5:53 PM, James Almer wrote:
> Maybe this should be an AVRational then.

While that is probably 'more correct', it does mean that in 100% places
this could be used, it'll have to be converted back to the -1 to 1
range. Is there a simple way to do that with an AVRational that doesn't
involve a round trip to a double or float (i.e. lossy)?

- Derek
___
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 6/9] avcodec/libvpxenc: Cleanup on error

[James Zern via ffmpeg-devel]

On Sun, Jun 16, 2024 at 4:09 PM Michael Niedermayer
 wrote:
>
> This or fifo needs to be freed on errors explicitly
> I have not verified that its always safe to call vpx_free() this needs to be 
> checked before applying this
>

It should be safe to call into libvpx whether the encoder init
succeeded or not; av_freep() is most of the rest of the code.

> Fixes: memleak
> Fixes: 
> 68937/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVPX_VP8_fuzzer-4830831016214528
>
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/libvpxenc.c | 2 ++
>  1 file changed, 2 insertions(+)
>

lgtm.
___
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/3] avfilter/af_volumedetect.c: Add 32bit float audio support

[Paul B Mahol]

On Mon, Jun 17, 2024 at 4:52 PM Rémi Denis-Courmont  wrote:

>
>
> Le 17 juin 2024 13:18:11 GMT+02:00, Yigithan Yigit <
> yigithanyigitde...@gmail.com> a écrit :
> >---
> > libavfilter/af_volumedetect.c | 159 --
> > 1 file changed, 133 insertions(+), 26 deletions(-)
> >
> >diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
> >index 327801a7f9..dbbcd037a5 100644
> >--- a/libavfilter/af_volumedetect.c
> >+++ b/libavfilter/af_volumedetect.c
> >@@ -20,27 +20,51 @@
> >
> > #include "libavutil/channel_layout.h"
> > #include "libavutil/avassert.h"
> >+#include "libavutil/mem.h"
> > #include "audio.h"
> > #include "avfilter.h"
> > #include "internal.h"
> >
> >+#define MAX_DB_FLT 1024
> > #define MAX_DB 91
> >+#define HISTOGRAM_SIZE 0x1
> >+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
> >
> > typedef struct VolDetectContext {
> >-/**
> >- * Number of samples at each PCM value.
> >- * histogram[0x8000 + i] is the number of samples at value i.
> >- * The extra element is there for symmetry.
> >- */
> >-uint64_t histogram[0x10001];
> >+uint64_t* histogram; ///< for integer number of samples at each PCM
> value, for float number of samples at each dB
> >+uint64_t nb_samples; ///< number of samples
> >+double sum2; ///< sum of the squares of the samples
> >+double max;  ///< maximum sample value
> >+int is_float;///< true if the input is in floating point
> > } VolDetectContext;
> >
> >-static inline double logdb(uint64_t v)
> >+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
> > {
> >-double d = v / (double)(0x8000 * 0x8000);
> >-if (!v)
> >-return MAX_DB;
> >-return -log10(d) * 10;
> >+if (sample_fmt == AV_SAMPLE_FMT_FLT) {
> >+if (!v)
> >+return MAX_DB_FLT;
> >+return -log10(v) * 10;
> >+} else {
> >+double d = v / (double)(0x8000 * 0x8000);
> >+if (!v)
> >+return MAX_DB;
> >+return -log10(d) * 10;
> >+}
> >+}
> >+
> >+static void update_float_stats(VolDetectContext *vd, float *audio_data)
> >+{
> >+double sample;
> >+int idx;
> >+if(!isnormal(*audio_data))
> >+return;
>
> Do we really need to classify floats here? That's probably going to hurt
> perfs badly, and makes an otherwise very vectorisable function not so
> easily vectored.
>

This is fast, it should translate to checking few bits of memory.


>
> >+sample = fabsf(*audio_data);
> >+if (sample > vd->max)
> >+vd->max = sample;
> >+vd->sum2 += sample * sample;
> >+idx = lrintf(floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT))) +
> MAX_DB_FLT;
>
> You're recomputing the same value again, and you seem to be rounding twice
> in a row?
>
> >+vd->histogram[idx]++;
> >+vd->nb_samples++;
> > }
> >
> > static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
> >@@ -51,18 +75,41 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *samples)
> > int nb_channels = samples->ch_layout.nb_channels;
> > int nb_planes   = nb_channels;
> > int plane, i;
> >-int16_t *pcm;
> >+int planar = 0;
> >
> >-if (!av_sample_fmt_is_planar(samples->format)) {
> >-nb_samples *= nb_channels;
> >+planar = av_sample_fmt_is_planar(samples->format);
> >+if (!planar)
> > nb_planes = 1;
> >+if (vd->is_float) {
> >+float *audio_data;
> >+for (plane = 0; plane < nb_planes; plane++) {
> >+audio_data = (float *)samples->extended_data[plane];
> >+for (i = 0; i < nb_samples; i++) {
> >+if (planar) {
> >+update_float_stats(vd, &audio_data[i]);
> >+} else {
> >+for (int j = 0; j < nb_channels; j++)
> >+update_float_stats(vd, &audio_data[i *
> nb_channels + j]);
> >+}
> >+}
> >+}
> >+} else {
> >+int16_t *pcm;
> >+for (plane = 0; plane < nb_planes; plane++) {
> >+pcm = (int16_t *)samples->extended_data[plane];
> >+for (i = 0; i < nb_samples; i++) {
> >+if (planar) {
> >+vd->histogram[pcm[i] + 0x8000]++;
> >+vd->nb_samples++;
> >+} else {
> >+for (int j = 0; j < nb_channels; j++) {
> >+vd->histogram[pcm[i * nb_channels + j] +
> 0x8000]++;
> >+vd->nb_samples++;
> >+}
> >+}
> >+}
> >+}
>
> Can't we pick the correct implementation (planar/packed and float/int)
> once and for all whilst configuring the filter?
>
> > }
> >-for (plane = 0; plane < nb_planes; plane++) {
> >-pcm = (int16_t *)samples->extended_data[plane];
> >-for (i = 0; i < nb_samples; i++)
> >-vd->histogram[pcm[i] + 0x8000]++;
> >-}
> >-
> > retur

Re: [FFmpeg-devel] [BROKEN] apad causes infinite hang

[Nicolas George]

Paul B Mahol (12024-06-17):
> And once you close all buffersinks the EOF will and must propagate backward
> to all not-closed filters and their in/out pads.

Your analysis here is right, obviously. Closing a source for this bug
makes no sense.

Regards,

-- 
  Nicolas George
___
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 2/5] avutil/stereo3d: Fill out stereo info provided by Vision Pro files

[James Almer]

On 6/17/2024 2:07 PM, Derek Buitenhuis wrote:

On 6/17/2024 5:53 PM, James Almer wrote:

Maybe this should be an AVRational then.


While that is probably 'more correct', it does mean that in 100% places
this could be used, it'll have to be converted back to the -1 to 1
range. Is there a simple way to do that with an AVRational that doesn't
involve a round trip to a double or float (i.e. lossy)?


No, it's av_d2q(), av_q2d(), and av_rescale() as needed. Same as we do 
for Mastering Display and Ambient Viewing Environment Metadata.
The reason to use AVRational is that in this specific spec the values 
have a denominator of 1, but in others it doesn't need to, allowing 
for more precise values (Matroska would store it as a double, in fact).


So we shouldn't define our API for one specific implementation but 
rather in a generic way that should accommodate to any potential 
implementation. I think we already did the former with a Google 
implementation (x.y fixed point values), and i want to avoid doing it again.




- Derek
___
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] [RFC] 5 year plan & Inovation

[Michael Niedermayer]

On Tue, Apr 30, 2024 at 07:42:53PM +0200, Michael Niedermayer wrote:
> On Mon, Apr 22, 2024 at 01:32:27PM +0200, Lynne wrote:
> > Apr 22, 2024, 13:07 by stefa...@gmail.com:
> > 
> > > On date Sunday 2024-04-21 22:12:56 -0300, James Almer wrote:
> > >
> > >> On 4/17/2024 10:58 AM, Michael Niedermayer wrote:
> > >>
> > > [...]
> > >
> > >> A full rewrite of ffserver, using only public API, and with modern 
> > >> streaming
> > >> in mind. It would give a lot of code in lavf some use.
> > >>
> > >
> > > If this is going to happen, my advice is to use "ffstream" to stick to
> > > the ffVERB convention (with the exeption of ffmpeg, which might still
> > > be converted to ffconvert with some proper aliasing) and to avoid
> > > association with the old incompatible tool .
> > >
> > 
> > That's basically what txproto is, only that it also does transcoding
> > and filtering. It can accept incoming streams and output them to
> > multiple destinations via remux or transcode. It was built as an
> > ffmpeg.c with a scriptable interface and with dynamic switching.
> > It doesn't do this out of the box, it's something you have to script,
> > but that was largely the case that ffserver had.
> > 
> > What is missing is something that ffserver had, which was that
> > it was able to express exactly what lavf had in its context on both
> > the sender and receiver, for which it needed private APIs.
> > AVTransport can largely fill that niche.
> 
> hmm
> how would we (assert(people agreeing)) go from what you describe
> to a (very easy to use) ffserver "2.0" in something on the ffmpeg.org 
> download page
> ?

also if you look at google trends, even today more people search for ffserver
than txproto. In fact at every point in time more people searched for ffserver
than txproto.

https://trends.google.com/trends/explore?date=all&q=txproto,ffserver

So even though ffserver is dead, removed and unmaintained, it has more
users

And this comes back to what i said many times. We should use the name
FFmpeg, our domain and NOT push every bit of new inovation out into
sub projects.

We should put a newly developed ffserver into the main ffmpeg git.
We should put wasm build support into the main ffmpeg git.
We should turn ffplay into a fully competetive player.
...



thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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] [RFC] 5 year plan & Inovation

[Nicolas George]

Michael Niedermayer (12024-06-17):
> also if you look at google trends, even today more people search for ffserver
> than txproto. In fact at every point in time more people searched for ffserver
> than txproto.
> 
> https://trends.google.com/trends/explore?date=all&q=txproto,ffserver
> 
> So even though ffserver is dead, removed and unmaintained, it has more
> users
> 
> And this comes back to what i said many times. We should use the name
> FFmpeg, our domain and NOT push every bit of new inovation out into
> sub projects.
> 
> We should put a newly developed ffserver into the main ffmpeg git.
> We should put wasm build support into the main ffmpeg git.
> We should turn ffplay into a fully competetive player.
> ...

Hear! Hear! 

I would add, as general guiding principles:

We should provide both low- and high-level APIs. Ideally, the fftools
should be just user interface around the high-level APIs provided by the
libraries.

Regards,

-- 
  Nicolas George
___
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 6/6] aacdec_usac, aacsbr: implement SBR support for USAC

[Lynne via ffmpeg-devel]

On 17/06/2024 09:35, Anton Khirnov wrote:

No tests?


Tests for this particular part are tricky. We still have the SBR issue 
where we add a single sample of delay to the output, which the reference 
samples and their decodings do not. Adding a test would mean modifying 
the samples in a way where we would not be able to use them after fixing 
this (in addition to all the other regular AAC samples with SBR we have 
that would become irrelevant).


My plan is to fix this after this patch, as its a troublesome topic.


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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 2/5] avutil/stereo3d: Fill out stereo info provided by Vision Pro files

[Derek Buitenhuis]

On 6/17/2024 7:09 PM, James Almer wrote:
> No, it's av_d2q(), av_q2d(), and av_rescale() as needed. Same as we do 
> for Mastering Display and Ambient Viewing Environment Metadata.
> The reason to use AVRational is that in this specific spec the values 
> have a denominator of 1, but in others it doesn't need to, allowing 
> for more precise values (Matroska would store it as a double, in fact).

This is unfortunate. Possibly we should add some util func for this case,
as it's a case I know I've personally hit more than once (with bugs caused
by lossy roundtrip) in my own code - I ended up manually using num/den in
the end.

> So we shouldn't define our API for one specific implementation but 
> rather in a generic way that should accommodate to any potential 
> implementation. I think we already did the former with a Google 
> implementation (x.y fixed point values), and i want to avoid doing it again.

Will send a v3 set using AVRational, then.

- Derek
___
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 6/6] aacdec_usac, aacsbr: implement SBR support for USAC

[Lynne via ffmpeg-devel]

On 17/06/2024 21:01, Lynne wrote:

On 17/06/2024 09:35, Anton Khirnov wrote:

No tests?


Tests for this particular part are tricky. We still have the SBR issue 
where we add a single sample of delay to the output, which the reference 
samples and their decodings do not. Adding a test would mean modifying 
the samples in a way where we would not be able to use them after fixing 
this (in addition to all the other regular AAC samples with SBR we have 
that would become irrelevant).


My plan is to fix this after this patch, as its a troublesome topic.


Additionally, we also don't correctly take into account encoder SBR 
delay signalled via MP4.


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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".

[FFmpeg-devel] [PATCH v3 0/5] Vision Pro Spatial Data

[Derek Buitenhuis]

Changes since v2:
* horizontal display adjustment is now a rational

Derek Buitenhuis (5):
  avutil/spherical: Add more spherical types
  avutil/stereo3d: Fill out stereo info provided by Vision Pro files
  fftools/ffprobe: Print more Stereo 3D info from side data
  avformat/mov: Add support for exporting Video Extension Usage info
  avformat/mov: Add support for reading and exporting horizontal field
of view

 fftools/ffprobe.c|   8 +
 libavformat/mov.c| 312 +++
 libavutil/spherical.c|   5 +
 libavutil/spherical.h|  16 +
 libavutil/stereo3d.c |  52 
 libavutil/stereo3d.h |  78 +
 libavutil/version.h  |   2 +-
 tests/ref/fate/matroska-spherical-mono   |   2 +
 tests/ref/fate/matroska-spherical-mono-remux |   4 +
 tests/ref/fate/matroska-stereo_mode  |   8 +
 tests/ref/fate/matroska-vp8-alpha-remux  |   2 +
 tests/ref/fate/mov-spherical-mono|   2 +
 12 files changed, 490 insertions(+), 1 deletion(-)

-- 
2.43.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 v3 1/5] avutil/spherical: Add more spherical types

[Derek Buitenhuis]

These originate from the Apple Vision Pro, and are documented here:

https://developer.apple.com/documentation/coremedia/cmprojectiontype

Signed-off-by: Derek Buitenhuis 
---
 libavutil/spherical.c |  5 +
 libavutil/spherical.h | 16 
 libavutil/version.h   |  2 +-
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/libavutil/spherical.c b/libavutil/spherical.c
index 800d3459a5..64ade1d0ec 100644
--- a/libavutil/spherical.c
+++ b/libavutil/spherical.c
@@ -29,6 +29,8 @@ AVSphericalMapping *av_spherical_alloc(size_t *size)
 if (!spherical)
 return NULL;
 
+spherical->projection = AV_SPHERICAL_RECTILINEAR;
+
 if (size)
 *size = sizeof(*spherical);
 
@@ -57,6 +59,9 @@ static const char *const spherical_projection_names[] = {
 [AV_SPHERICAL_EQUIRECTANGULAR]  = "equirectangular",
 [AV_SPHERICAL_CUBEMAP]  = "cubemap",
 [AV_SPHERICAL_EQUIRECTANGULAR_TILE] = "tiled equirectangular",
+[AV_SPHERICAL_HALF_EQUIRECTANGULAR] = "half equirectangular",
+[AV_SPHERICAL_RECTILINEAR]  = "rectilinear",
+[AV_SPHERICAL_FISHEYE]  = "fisheye",
 };
 
 const char *av_spherical_projection_name(enum AVSphericalProjection projection)
diff --git a/libavutil/spherical.h b/libavutil/spherical.h
index 828ac836da..2e90f7752d 100644
--- a/libavutil/spherical.h
+++ b/libavutil/spherical.h
@@ -66,6 +66,22 @@ enum AVSphericalProjection {
  * the position of the current video in a larger surface.
  */
 AV_SPHERICAL_EQUIRECTANGULAR_TILE,
+
+/**
+ * Video frame displays as a 180 degree equirectangular projection.
+ */
+AV_SPHERICAL_HALF_EQUIRECTANGULAR,
+
+/**
+ * Video frame displays on a flat, rectangular 2D surface.
+ */
+AV_SPHERICAL_RECTILINEAR,
+
+/**
+ * Fisheye projection (Apple).
+ * See: 
https://developer.apple.com/documentation/coremedia/cmprojectiontype/fisheye
+ */
+AV_SPHERICAL_FISHEYE,
 };
 
 /**
diff --git a/libavutil/version.h b/libavutil/version.h
index 2756f2aa03..7df546ee22 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  59
-#define LIBAVUTIL_VERSION_MINOR  22
+#define LIBAVUTIL_VERSION_MINOR  23
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
2.43.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 v3 2/5] avutil/stereo3d: Fill out stereo info provided by Vision Pro files

[Derek Buitenhuis]

Based on what is in the files themselves, and what the API provides
to users.

URLs:
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
  * 
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview

Signed-off-by: Derek Buitenhuis 
---
 libavutil/stereo3d.c | 52 +
 libavutil/stereo3d.h | 78 
 libavutil/version.h  |  2 +-
 3 files changed, 131 insertions(+), 1 deletion(-)

diff --git a/libavutil/stereo3d.c b/libavutil/stereo3d.c
index 9c29ab01b5..a40a9439bb 100644
--- a/libavutil/stereo3d.c
+++ b/libavutil/stereo3d.c
@@ -55,6 +55,18 @@ static const char * const stereo3d_type_names[] = {
 [AV_STEREO3D_COLUMNS] = "interleaved columns",
 };
 
+static const char * const stereo3d_view_names[] = {
+[AV_STEREO3D_VIEW_PACKED] = "packed",
+[AV_STEREO3D_VIEW_LEFT]   = "left",
+[AV_STEREO3D_VIEW_RIGHT]  = "right",
+};
+
+static const char * const stereo3d_primary_eye_names[] = {
+[AV_PRIMARY_EYE_NONE]  = "none",
+[AV_PRIMARY_EYE_LEFT]  = "left",
+[AV_PRIMARY_EYE_RIGHT] = "right",
+};
+
 const char *av_stereo3d_type_name(unsigned int type)
 {
 if (type >= FF_ARRAY_ELEMS(stereo3d_type_names))
@@ -74,3 +86,43 @@ int av_stereo3d_from_name(const char *name)
 
 return -1;
 }
+
+const char *av_stereo3d_view_name(unsigned int view)
+{
+if (view >= FF_ARRAY_ELEMS(stereo3d_view_names))
+return "unknown";
+
+return stereo3d_view_names[view];
+}
+
+int av_stereo3d_view_from_name(const char *name)
+{
+int i;
+
+for (i = 0; i < FF_ARRAY_ELEMS(stereo3d_view_names); i++) {
+if (av_strstart(name, stereo3d_view_names[i], NULL))
+return i;
+}
+
+return -1;
+}
+
+const char *av_stereo3d_primary_eye_name(unsigned int eye)
+{
+if (eye >= FF_ARRAY_ELEMS(stereo3d_primary_eye_names))
+return "unknown";
+
+return stereo3d_primary_eye_names[eye];
+}
+
+int av_stereo3d_primary_eye_from_name(const char *name)
+{
+int i;
+
+for (i = 0; i < FF_ARRAY_ELEMS(stereo3d_primary_eye_names); i++) {
+if (av_strstart(name, stereo3d_primary_eye_names[i], NULL))
+return i;
+}
+
+return -1;
+}
diff --git a/libavutil/stereo3d.h b/libavutil/stereo3d.h
index 3aab959b79..00a5c3900e 100644
--- a/libavutil/stereo3d.h
+++ b/libavutil/stereo3d.h
@@ -158,6 +158,26 @@ enum AVStereo3DView {
 AV_STEREO3D_VIEW_RIGHT,
 };
 
+/**
+ * List of possible primary eyes.
+ */
+enum AVStereo3DPrimaryEye {
+/**
+ * Neither eye.
+ */
+AV_PRIMARY_EYE_NONE,
+
+/**
+ * Left eye.
+ */
+AV_PRIMARY_EYE_LEFT,
+
+/**
+ * Right eye
+ */
+AV_PRIMARY_EYE_RIGHT,
+};
+
 /**
  * Inverted views, Right/Bottom represents the left view.
  */
@@ -185,6 +205,28 @@ typedef struct AVStereo3D {
  * Determines which views are packed.
  */
 enum AVStereo3DView view;
+
+/**
+ * Which eye is the primary eye when rendering in 2D.
+ */
+enum AVStereo3DPrimaryEye primary_eye;
+
+/**
+ * The distance between the centres of the lenses of the camera system,
+ * in micrometers. Zero if unset.
+ */
+uint32_t baseline;
+
+/**
+ * Relative shift of the left and right images, which changes the zero 
parallax plane.
+ * Range is -1.0 to 1.0. Zero if unset.
+ */
+AVRational horizontal_disparity_adjustment;
+
+/**
+ * Horizontal field of view in thousanths of a degree. Zero if unset.
+ */
+uint32_t horizontal_field_of_view;
 } AVStereo3D;
 
 /**
@@ -222,6 +264,42 @@ const char *av_stereo3d_type_name(unsigned int type);
  */
 int av_stereo3d_from_name(const char *name);
 
+/**
+ * Provide a human-readable name of a given stereo3d view.
+ *
+ * @param type The input stereo3d view value.
+ *
+ * @return The name of the stereo3d view value, or "unknown".
+ */
+const char *av_stereo3d_view_name(unsigned int view);
+
+/**
+ * Get the AVStereo3DView form a human-readable name.
+ *
+ * @param name The input string.
+ *
+ * @return The AVStereo3DView value, or -1 if not found.
+ */
+int av_stereo3d_view_from_name(const char *name);
+
+/**
+ * Provide a human-readable name of a given stereo3d primary eye.
+ *
+ * @param type The input stereo3d primary eye value.
+ *
+ * @return The name of the stereo3d primary eye value, or "unknown".
+ */
+const char *av_stereo3d_primary_eye_name(unsigned int eye);
+
+/**
+ * Get the AVStereo3DPrimaryEye form a human-readable name.
+ *
+ * @param name The input string.
+ *
+ * @return The AVStereo3DPrimaryEye value, or -1 if not found.
+ */
+int av_stereo3d_primary_eye_from_name(const char *name);
+
 /**
  * @}
  */
diff --git a/libavutil/ve

[FFmpeg-devel] [PATCH v3 3/5] fftools/ffprobe: Print more Stereo 3D info from side data

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis 
---
 fftools/ffprobe.c| 8 
 tests/ref/fate/matroska-spherical-mono   | 2 ++
 tests/ref/fate/matroska-spherical-mono-remux | 4 
 tests/ref/fate/matroska-stereo_mode  | 8 
 tests/ref/fate/matroska-vp8-alpha-remux  | 2 ++
 tests/ref/fate/mov-spherical-mono| 2 ++
 6 files changed, 26 insertions(+)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 2d38e5dfdc..a814cb5ade 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2544,6 +2544,14 @@ static void print_pkt_side_data(WriterContext *w,
 const AVStereo3D *stereo = (AVStereo3D *)sd->data;
 print_str("type", av_stereo3d_type_name(stereo->type));
 print_int("inverted", !!(stereo->flags & AV_STEREO3D_FLAG_INVERT));
+print_str("view", av_stereo3d_view_name(stereo->view));
+print_str("primary_eye", 
av_stereo3d_primary_eye_name(stereo->primary_eye));
+if (stereo->baseline)
+print_int("baseline", stereo->baseline);
+if (stereo->horizontal_disparity_adjustment.num && 
stereo->horizontal_disparity_adjustment.den)
+print_q("horizontal_disparity_adjustment", 
stereo->horizontal_disparity_adjustment, '/');
+if (stereo->horizontal_field_of_view)
+print_int("horizontal_field_of_view", 
stereo->horizontal_field_of_view);
 } else if (sd->type == AV_PKT_DATA_SPHERICAL) {
 const AVSphericalMapping *spherical = (AVSphericalMapping 
*)sd->data;
 print_str("projection", 
av_spherical_projection_name(spherical->projection));
diff --git a/tests/ref/fate/matroska-spherical-mono 
b/tests/ref/fate/matroska-spherical-mono
index bd57d94514..08b94e455b 100644
--- a/tests/ref/fate/matroska-spherical-mono
+++ b/tests/ref/fate/matroska-spherical-mono
@@ -3,6 +3,8 @@
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [SIDE_DATA]
 side_data_type=Spherical Mapping
diff --git a/tests/ref/fate/matroska-spherical-mono-remux 
b/tests/ref/fate/matroska-spherical-mono-remux
index 6fcda14822..0ca77c8074 100644
--- a/tests/ref/fate/matroska-spherical-mono-remux
+++ b/tests/ref/fate/matroska-spherical-mono-remux
@@ -27,6 +27,8 @@ DISPOSITION:forced=1
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [SIDE_DATA]
 side_data_type=Spherical Mapping
@@ -51,6 +53,8 @@ DISPOSITION:forced=0
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [SIDE_DATA]
 side_data_type=Spherical Mapping
diff --git a/tests/ref/fate/matroska-stereo_mode 
b/tests/ref/fate/matroska-stereo_mode
index 739b789fea..13bce13cb8 100644
--- a/tests/ref/fate/matroska-stereo_mode
+++ b/tests/ref/fate/matroska-stereo_mode
@@ -132,6 +132,8 @@ TAG:DURATION=00:00:10.0
 side_data_type=Stereo 3D
 type=side by side
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
 [STREAM]
@@ -147,6 +149,8 @@ TAG:DURATION=00:00:10.0
 side_data_type=Stereo 3D
 type=top and bottom
 inverted=1
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
 [STREAM]
@@ -160,6 +164,8 @@ TAG:DURATION=00:00:10.0
 side_data_type=Stereo 3D
 type=interleaved lines
 inverted=1
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
 [STREAM]
@@ -174,6 +180,8 @@ TAG:DURATION=00:00:10.0
 side_data_type=Stereo 3D
 type=interleaved columns
 inverted=1
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
 [STREAM]
diff --git a/tests/ref/fate/matroska-vp8-alpha-remux 
b/tests/ref/fate/matroska-vp8-alpha-remux
index f6c24dead6..e54304cafd 100644
--- a/tests/ref/fate/matroska-vp8-alpha-remux
+++ b/tests/ref/fate/matroska-vp8-alpha-remux
@@ -35,5 +35,7 @@ DISPOSITION:still_image=0
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [/STREAM]
diff --git a/tests/ref/fate/mov-spherical-mono 
b/tests/ref/fate/mov-spherical-mono
index bd57d94514..08b94e455b 100644
--- a/tests/ref/fate/mov-spherical-mono
+++ b/tests/ref/fate/mov-spherical-mono
@@ -3,6 +3,8 @@
 side_data_type=Stereo 3D
 type=2D
 inverted=0
+view=packed
+primary_eye=none
 [/SIDE_DATA]
 [SIDE_DATA]
 side_data_type=Spherical Mapping
-- 
2.43.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 v3 4/5] avformat/mov: Add support for exporting Video Extension Usage info

[Derek Buitenhuis]

This box is provided by files created by the Apple Vision Pro, as well
as the iPhone 15+ when capture for Vision Pro is enabled.

The boxes are a mix of things documented by Apple in some PDFs, their
API docs, and reverse engineering. Ideally we will have a real spec
one day.

Links:
  * 
https://developer.apple.com/av-foundation/Stereo-Video-ISOBMFF-Extensions.pdf
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
  * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye

Signed-off-by: Derek Buitenhuis 
---
 libavformat/mov.c | 283 ++
 1 file changed, 283 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9016cd5ad0..5724b4ef93 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6477,6 +6477,288 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return 0;
 }
 
+static int mov_read_vexu_proj(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+int size;
+uint32_t tag;
+enum AVSphericalProjection projection;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+if (atom.size != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size for proj box: %"PRIu64"\n", 
atom.size);
+return AVERROR_INVALIDDATA;
+}
+
+size = avio_rb32(pb);
+if (size != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size for prji box: %d\n", size);
+return AVERROR_INVALIDDATA;
+}
+
+tag = avio_rl32(pb);
+if (tag != MKTAG('p','r','j','i')) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid child box of proj box: 0x%08X\n", 
tag);
+return AVERROR_INVALIDDATA;
+}
+
+avio_skip(pb, 1); // version
+avio_skip(pb, 3); // flags
+
+tag = avio_rl32(pb);
+switch (tag) {
+case MKTAG('r','e','c','t'):
+projection = AV_SPHERICAL_RECTILINEAR;
+break;
+case MKTAG('e','q','u','i'):
+projection = AV_SPHERICAL_EQUIRECTANGULAR;
+break;
+case MKTAG('h','e','q','u'):
+projection = AV_SPHERICAL_HALF_EQUIRECTANGULAR;
+break;
+case MKTAG('f','i','s','h'):
+projection = AV_SPHERICAL_FISHEYE;
+break;
+default:
+av_log(c->fc, AV_LOG_ERROR, "Invalid projection type in prji box: 
0x%08X\n", tag);
+return AVERROR_INVALIDDATA;
+}
+
+sc->spherical = av_spherical_alloc(&sc->spherical_size);
+if (!sc->spherical)
+return AVERROR(ENOMEM);
+
+sc->spherical->projection = projection;
+
+return 0;
+}
+
+static int mov_read_eyes(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+int size, flags = 0;
+int64_t remaining;
+uint32_t tag, baseline = 0;
+enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
+enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
+AVRational horizontal_disparity_adjustment = { 0, 0 };
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+remaining = atom.size;
+while (remaining > 0) {
+size = avio_rb32(pb);
+if (size < 8 || size > remaining ) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid child size in eyes box\n");
+return AVERROR_INVALIDDATA;
+}
+
+tag = avio_rl32(pb);
+switch (tag) {
+case MKTAG('s','t','r','i'): {
+int has_right, has_left;
+uint8_t tmp;
+if (size != 13) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size of stri box: %d\n", 
size);
+return AVERROR_INVALIDDATA;
+}
+avio_skip(pb, 1); // version
+avio_skip(pb, 3); // flags
+
+tmp = avio_r8(pb);
+
+// eye_views_reversed
+if (tmp & 8) {
+flags |= AV_STEREO3D_FLAG_INVERT;
+}
+// has_additional_views
+if (tmp & 4) {
+// skip...
+}
+
+has_right = tmp & 2; // has_right_eye_view
+has_left = tmp & 1; // has_left_eye_view
+
+if (has_left && has_right)
+view = AV_STEREO3D_VIEW_PACKED;
+else if (has_left)
+view = AV_STEREO3D_VIEW_LEFT;
+else if (has_right)
+view = AV_STEREO3D_VIEW_RIGHT;
+break;
+}
+case MKTAG('h','e','r','o'): {
+int tmp;
+if (size != 13) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size of hero box: %d\n", 
size);
+return AVERROR_INVALIDDATA;
+}
+avio_skip(pb, 1); // version
+avio_skip(pb, 3); /

[FFmpeg-devel] [PATCH v3 5/5] avformat/mov: Add support for reading and exporting horizontal field of view

[Derek Buitenhuis]

These boxes are created by the Apple Vision Pro and the iPhone 15+ when
capture for the Vision Pro is enabled.

Based off of the swift API:
  * 
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview

Signed-off-by: Derek Buitenhuis 
---
 libavformat/mov.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 5724b4ef93..367af8478b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6759,6 +6759,34 @@ static int mov_read_vexu(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return 0;
 }
 
+static int mov_read_hfov(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+if (atom.size != 4) {
+ av_log(c->fc, AV_LOG_ERROR, "Invalid size of hfov box: %"PRIu64"\n", 
atom.size);
+ return AVERROR_INVALIDDATA;
+}
+
+
+if (!sc->stereo3d) {
+sc->stereo3d = av_stereo3d_alloc();
+if (!sc->stereo3d)
+return AVERROR(ENOMEM);
+}
+
+sc->stereo3d->horizontal_field_of_view = avio_rb32(pb);
+
+return 0;
+}
+
 static int mov_parse_uuid_spherical(MOVStreamContext *sc, AVIOContext *pb, 
size_t len)
 {
 int ret = 0;
@@ -8878,6 +8906,7 @@ static const MOVParseTableEntry mov_default_parse_table[] 
= {
 { MKTAG('s','t','3','d'), mov_read_st3d }, /* stereoscopic 3D video box */
 { MKTAG('s','v','3','d'), mov_read_sv3d }, /* spherical video box */
 { MKTAG('v','e','x','u'), mov_read_vexu }, /* video extension usage */
+{ MKTAG('h','f','o','v'), mov_read_hfov },
 { MKTAG('d','O','p','s'), mov_read_dops },
 { MKTAG('d','m','l','p'), mov_read_dmlp },
 { MKTAG('S','m','D','m'), mov_read_smdm },
-- 
2.43.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".

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Vittorio Giovara]

On Mon, Jun 17, 2024 at 8:34 PM Michael Niedermayer 
wrote:

> On Tue, Apr 30, 2024 at 07:42:53PM +0200, Michael Niedermayer wrote:
> > On Mon, Apr 22, 2024 at 01:32:27PM +0200, Lynne wrote:
> > > Apr 22, 2024, 13:07 by stefa...@gmail.com:
> > >
> > > > On date Sunday 2024-04-21 22:12:56 -0300, James Almer wrote:
> > > >
> > > >> On 4/17/2024 10:58 AM, Michael Niedermayer wrote:
> > > >>
> > > > [...]
> > > >
> > > >> A full rewrite of ffserver, using only public API, and with modern
> streaming
> > > >> in mind. It would give a lot of code in lavf some use.
> > > >>
> > > >
> > > > If this is going to happen, my advice is to use "ffstream" to stick
> to
> > > > the ffVERB convention (with the exeption of ffmpeg, which might still
> > > > be converted to ffconvert with some proper aliasing) and to avoid
> > > > association with the old incompatible tool .
> > > >
> > >
> > > That's basically what txproto is, only that it also does transcoding
> > > and filtering. It can accept incoming streams and output them to
> > > multiple destinations via remux or transcode. It was built as an
> > > ffmpeg.c with a scriptable interface and with dynamic switching.
> > > It doesn't do this out of the box, it's something you have to script,
> > > but that was largely the case that ffserver had.
> > >
> > > What is missing is something that ffserver had, which was that
> > > it was able to express exactly what lavf had in its context on both
> > > the sender and receiver, for which it needed private APIs.
> > > AVTransport can largely fill that niche.
> >
> > hmm
> > how would we (assert(people agreeing)) go from what you describe
> > to a (very easy to use) ffserver "2.0" in something on the ffmpeg.org
> download page
> > ?
>
> also if you look at google trends, even today more people search for
> ffserver
> than txproto. In fact at every point in time more people searched for
> ffserver
> than txproto.
>
> https://trends.google.com/trends/explore?date=all&q=txproto,ffserver
>
> So even though ffserver is dead, removed and unmaintained, it has more
> users
>

https://trends.google.it/trends/explore?date=now%201-d&q=ffmpeg,vlc&hl=it
By that reasoning we should stop working on ffmpeg and move off to working
on VLC

or mpv
https://trends.google.it/trends/explore?date=now%201-d&q=ffmpeg,mpv&hl=it


> And this comes back to what i said many times. We should use the name
> FFmpeg, our domain and NOT push every bit of new inovation out into
> sub projects.
>

https://trends.google.it/trends/explore?date=now%201-d&q=ffmpeg,gpac&hl=it
so you agree that we shouldn't have had gpac at the ffmpeg booth?


> We should put a newly developed ffserver into the main ffmpeg git.
> We should put wasm build support into the main ffmpeg git.
> We should turn ffplay into a fully competetive player.
>

We should move to a patch review system with a modern UI, like
github/gitea/gitlab, everything else is secondary
-- 
Vittorio
___
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] [RFC] 5 year plan & Inovation

[Vittorio Giovara]

On Mon, Jun 17, 2024 at 9:01 PM Nicolas George  wrote:

> Michael Niedermayer (12024-06-17):
> > also if you look at google trends, even today more people search for
> ffserver
> > than txproto. In fact at every point in time more people searched for
> ffserver
> > than txproto.
> >
> > https://trends.google.com/trends/explore?date=all&q=txproto,ffserver
> >
> > So even though ffserver is dead, removed and unmaintained, it has more
> > users
> >
> > And this comes back to what i said many times. We should use the name
> > FFmpeg, our domain and NOT push every bit of new inovation out into
> > sub projects.
> >
> > We should put a newly developed ffserver into the main ffmpeg git.
> > We should put wasm build support into the main ffmpeg git.
> > We should turn ffplay into a fully competetive player.
> > ...
>
> Hear! Hear!
>
> I would add, as general guiding principles:
>
> We should provide both low- and high-level APIs. Ideally, the fftools
> should be just user interface around the high-level APIs provided by the
> libraries.


Patches welcome? Not that it means anything, but you had exactly 2 lines on
ffserver before it got removed, so I wonder who exactly you think should be
maintaining all that cruft code (honest question, if you have a real plan
for solving this ageless problem I think many people on the ML would be
interested)
-- 
Vittorio
___
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 v3 2/5] avutil/stereo3d: Fill out stereo info provided by Vision Pro files

[James Almer]

On 6/17/2024 4:20 PM, Derek Buitenhuis wrote:

Based on what is in the files themselves, and what the API provides
to users.

URLs:
   * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye
   * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
   * 
https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
   * 
https://developer.apple.com/documentation/coremedia/kcmformatdescriptionextension_horizontalfieldofview

Signed-off-by: Derek Buitenhuis 
---
  libavutil/stereo3d.c | 52 +
  libavutil/stereo3d.h | 78 
  libavutil/version.h  |  2 +-
  3 files changed, 131 insertions(+), 1 deletion(-)


Missing APIChanges entry (no need to resend, you can just amend before 
pushing).

___
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 2/2] avutil/macos_kperf: Fix assert which makes kperf failed to run

[Martin Storsjö]

On Tue, 18 Jun 2024, Zhao Zhili wrote:


From: Zhao Zhili 

On m1, kpc_get_counter_count(KPC_MASK) return 8 in my test. The
exact value doesn't matter in our case, as long as we have a
sufficiently large array

Signed-off-by: Zhao Zhili 
---
libavutil/macos_kperf.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)


Both these patche LGTM, thanks!

// Martin

___
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 v3 4/5] avformat/mov: Add support for exporting Video Extension Usage info

[James Almer]

On 6/17/2024 4:20 PM, Derek Buitenhuis wrote:

This box is provided by files created by the Apple Vision Pro, as well
as the iPhone 15+ when capture for Vision Pro is enabled.

The boxes are a mix of things documented by Apple in some PDFs, their
API docs, and reverse engineering. Ideally we will have a real spec
one day.

Links:
   
*https://developer.apple.com/av-foundation/Stereo-Video-ISOBMFF-Extensions.pdf
   
*https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_horizontaldisparityadjustment
   
*https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_stereocamerabaseline
   
*https://developer.apple.com/documentation/videotoolbox/kvtcompressionpropertykey_heroeye

Signed-off-by: Derek Buitenhuis
---
  libavformat/mov.c | 283 ++
  1 file changed, 283 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9016cd5ad0..5724b4ef93 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6477,6 +6477,288 @@ static int mov_read_sv3d(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
  return 0;
  }
  
+static int mov_read_vexu_proj(MOVContext *c, AVIOContext *pb, MOVAtom atom)

+{
+AVStream *st;
+MOVStreamContext *sc;
+int size;
+uint32_t tag;
+enum AVSphericalProjection projection;
+
+if (c->fc->nb_streams < 1)
+return 0;
+
+st = c->fc->streams[c->fc->nb_streams - 1];
+sc = st->priv_data;
+
+if (atom.size != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size for proj box: %"PRIu64"\n", 
atom.size);
+return AVERROR_INVALIDDATA;
+}
+
+size = avio_rb32(pb);
+if (size != 16) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid size for prji box: %d\n", size);
+return AVERROR_INVALIDDATA;
+}
+
+tag = avio_rl32(pb);
+if (tag != MKTAG('p','r','j','i')) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid child box of proj box: 0x%08X\n", 
tag);
+return AVERROR_INVALIDDATA;
+}
+
+avio_skip(pb, 1); // version
+avio_skip(pb, 3); // flags
+
+tag = avio_rl32(pb);
+switch (tag) {
+case MKTAG('r','e','c','t'):
+projection = AV_SPHERICAL_RECTILINEAR;
+break;
+case MKTAG('e','q','u','i'):
+projection = AV_SPHERICAL_EQUIRECTANGULAR;
+break;
+case MKTAG('h','e','q','u'):
+projection = AV_SPHERICAL_HALF_EQUIRECTANGULAR;
+break;
+case MKTAG('f','i','s','h'):
+projection = AV_SPHERICAL_FISHEYE;
+break;
+default:
+av_log(c->fc, AV_LOG_ERROR, "Invalid projection type in prji box: 
0x%08X\n", tag);
+return AVERROR_INVALIDDATA;
+}
+
+sc->spherical = av_spherical_alloc(&sc->spherical_size);
+if (!sc->spherical)
+return AVERROR(ENOMEM);
+
+sc->spherical->projection = projection;
+
+return 0;
+}
+
+static int mov_read_eyes(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+AVStream *st;
+MOVStreamContext *sc;
+int size, flags = 0;
+int64_t remaining;
+uint32_t tag, baseline = 0;
+enum AVStereo3DView view = AV_STEREO3D_VIEW_PACKED;
+enum AVStereo3DPrimaryEye primary_eye = AV_PRIMARY_EYE_NONE;
+AVRational horizontal_disparity_adjustment = { 0, 0 };


nit: { 0, 1 }.

Should be ok either way.
___
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 1/2] avutil/timestamp: introduce av_ts_make_time_string2 for better precision

[Hendrik Leppkes]

On Sat, Mar 23, 2024 at 12:14 PM Marton Balint  wrote:
> +char *av_ts_make_time_string2(char *buf, int64_t ts, AVRational tb)
> +{
> +if (ts == AV_NOPTS_VALUE) {
> +snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
> +} else {
> +double val = av_q2d(tb) * ts;
> +double log = floor(log10(fabs(val)));

This causes a floating point exception on some systems (div by zero)
if val ends up zero. Can we introduce a check to avoid the FPE?
log10(0) seems to be implementation defined, and may raise a FPE,
which we should avoid.

- Hendrik
___
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 v3 2/5] avutil/stereo3d: Fill out stereo info provided by Vision Pro files

[Derek Buitenhuis]

On 6/17/2024 9:03 PM, James Almer wrote:
> Missing APIChanges entry (no need to resend, you can just amend before 
> pushing).

Done locally for this and previous commit.

- Derek
___
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 v3 4/5] avformat/mov: Add support for exporting Video Extension Usage info

[Derek Buitenhuis]

On 6/17/2024 9:07 PM, James Almer wrote:
> nit: { 0, 1 }.

If we set it to 0, 1 here, should it be set to that in the alloc function too?
It'll be 0, 0 at alloc time due to use of av_mallocz.

- Derek
___
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] avutil/timestamp: avoid possible FPE when 0 is passed to av_ts_make_time_string2()

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavutil/timestamp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
index 2a3e3012a4..6c231a517d 100644
--- a/libavutil/timestamp.c
+++ b/libavutil/timestamp.c
@@ -24,7 +24,7 @@ char *av_ts_make_time_string2(char *buf, int64_t ts, 
AVRational tb)
 snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
 } else {
 double val = av_q2d(tb) * ts;
-double log = floor(log10(fabs(val)));
+double log = (fpclassify(val) == FP_ZERO ? -INFINITY : 
floor(log10(fabs(val;
 int precision = (isfinite(log) && log < 0) ? -log + 5 : 6;
 int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f", precision, 
val);
 last = FFMIN(last, AV_TS_MAX_STRING_SIZE - 1) - 1;
-- 
2.35.3

___
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 v3 4/5] avformat/mov: Add support for exporting Video Extension Usage info

[James Almer]

On 6/17/2024 5:27 PM, Derek Buitenhuis wrote:

On 6/17/2024 9:07 PM, James Almer wrote:

nit: { 0, 1 }.


If we set it to 0, 1 here, should it be set to that in the alloc function too?
It'll be 0, 0 at alloc time due to use of av_mallocz.


Personally I'd say yes, but other similar lavu APIs (Mastering, Ambient 
Viewing) don't seem to bother with it, so maybe just leave it as 0 
unless someone else has a strong opinion about it.

___
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 v3 4/5] avformat/mov: Add support for exporting Video Extension Usage info

[Derek Buitenhuis]

On 6/17/2024 9:33 PM, James Almer wrote:
> Personally I'd say yes, but other similar lavu APIs (Mastering, Ambient 
> Viewing) don't seem to bother with it, so maybe just leave it as 0 
> unless someone else has a strong opinion about it.

I'll leave it for consistency then.

- Derek
___
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] [RFC] 5 year plan & Inovation

[Rémi Denis-Courmont]

Le 17 juin 2024 20:34:39 GMT+02:00, Michael Niedermayer 
 a écrit :
>also if you look at google trends, even today more people search for ffserver
>than txproto. In fact at every point in time more people searched for ffserver
>than txproto.

Nobody looks at txproto since it's (AFAIK) a one-person experimental project 
that almost no one knows about. I don't think that metric has any relevance 
whatsoever, TBH.


>
>So even though ffserver is dead, removed and unmaintained, it has more
>users

It's easy to have more users than one. I'm sure even VLS that has been 
unmaintained for 20 years, give or take, has more users than txproto, by that 
questionable metric.

>
>And this comes back to what i said many times. We should use the name
>FFmpeg, our domain and NOT push every bit of new inovation out into
>sub projects.

It proves no such thing. And that goes against all common sense. Using FFmpeg 
branding and website is one thing; if the community agrees to it, why not. But 
tying different projects into a single git tree is just plain dumb.

Git is not designed to handle more than one release timeline for one thing, and 
you will need separate release timelines if you take up separate projects.

Also people have been complaining about excess traffic on ffmpeg-devel, which 
indicates that we should break stuff down into smaller projects (if it were 
practical - I don't think it is in this particular case), rather than let the 
scope creep.

>We should put a newly developed ffserver into the main ffmpeg git.

Well, if you have funding for developing and maintaining it, I don't think 
people will object much. Because it's not that big of a stretch from what 
FFmpeg is, and no stretch at all from what it was.

>We should put wasm build support into the main ffmpeg git.

Sure, if it can pass code reviews absolutely. WASM should be treated as just 
another ISA.

>We should turn ffplay into a fully competetive player.

No. First there is no such thing as "a fully competitive player". You would 
need at least one mobile player, one smart TV and STB player and one desktop 
player, on top of the existing crude CLI player. And that's if you manage 
Android and iOS, mac and Windows, together. Otherwise it's even more players.

Then you would need each of them to have features that FFmpeg doesn't have as a 
back-end, notably media library management.

That's a lot of work, mostly GUI work. No offence but you and most other devs 
here don't strike me as GUI devs. VLC is pretty much dead now for 
under-estimating how hard it was to rewrite the desktop UI. How will you find 
and keep motivated the developers for all that UI work? They are not going to 
manifest spontaneously, even less so in a community with a deservedly horrible 
reputation as FFmpeg's.

Unless you just won the Euromillion or something like that, this is not going 
to happen. No ifs or buts about it.
___
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] [RFC] 5 year plan & Inovation

[Andrew Sayers]

On Mon, Jun 17, 2024 at 09:29:57PM +0200, Vittorio Giovara wrote:
> On Mon, Jun 17, 2024 at 9:01 PM Nicolas George  wrote:
> 
> > Michael Niedermayer (12024-06-17):
> > > also if you look at google trends, even today more people search for
> > ffserver
> > > than txproto. In fact at every point in time more people searched for
> > ffserver
> > > than txproto.
> > >
> > > https://trends.google.com/trends/explore?date=all&q=txproto,ffserver
> > >
> > > So even though ffserver is dead, removed and unmaintained, it has more
> > > users
> > >
> > > And this comes back to what i said many times. We should use the name
> > > FFmpeg, our domain and NOT push every bit of new inovation out into
> > > sub projects.
> > >
> > > We should put a newly developed ffserver into the main ffmpeg git.
> > > We should put wasm build support into the main ffmpeg git.
> > > We should turn ffplay into a fully competetive player.
> > > ...
> >
> > Hear! Hear!
> >
> > I would add, as general guiding principles:
> >
> > We should provide both low- and high-level APIs. Ideally, the fftools
> > should be just user interface around the high-level APIs provided by the
> > libraries.
> 
> 
> Patches welcome? Not that it means anything, but you had exactly 2 lines on
> ffserver before it got removed, so I wonder who exactly you think should be
> maintaining all that cruft code (honest question, if you have a real plan
> for solving this ageless problem I think many people on the ML would be
> interested)

This isn't a hard problem to solve, just a boring one:

If you want more contributions, you need more contributors.
If you want more contributors, you need to make it easy to get started.
If you want to make it easy to get started, focus on the tedious things
that trip newbies up, not the interesting problems you'd like them to have.

You talked elsewhere about moving to a modern UI.  That's a fine long-term goal,
but how about starting simple - instead of waiting for patches to go stale
and making people beg, apply patches 48 hours after the thread goes quiet,
then revert them if someone asks for more time to review.
___
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 7/9] MAINTAINERS: Update the entries for the release maintainer for FFmpeg

[Michael Niedermayer]

On Mon, Jun 17, 2024 at 09:07:23AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-06-17 01:08:29)
> > Ive been told that someone at the BCN video tech meetup claimed to be the
> > "release maintainer for FFmpeg".
> > 
> > If you have any doubt who maintains releases, just do something like the 
> > following and look at the output:
> > VER=5.1
> > echo commiters ; git shortlog  --group=committer -s  n$VER..release/$VER -n 
> > ;\
> > echo authors   ; git shortlog-s  n$VER..release/$VER -n
> 
> Passive aggressive gossip does not belong in a commit message.

we generally explain in a commit message the "why" and "what" and so on.
There was no intention of any aggression.

But how would you word it instead ?

The example git commands simply show the authors and commiters on the release 
branch
since the first release on it. I think its reasonable to provide these as 
reference

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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 8/9] avcodec/smcenc: width < 4 is unsupported

[Michael Niedermayer]

On Mon, Jun 17, 2024 at 09:50:18AM +0200, Paul B Mahol wrote:
> On Mon, Jun 17, 2024 at 1:09 AM Michael Niedermayer 
> wrote:
> 
> > Fixes: out of array read
> > Fixes:
> > 68939/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMC_fuzzer-587804104884224
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by
> > :
> > Michael Niedermayer 
> > ---
> >  libavcodec/smcenc.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/smcenc.c b/libavcodec/smcenc.c
> > index 789aef4f770..d70cce900ec 100644
> > --- a/libavcodec/smcenc.c
> > +++ b/libavcodec/smcenc.c
> > @@ -537,6 +537,9 @@ static int smc_encode_frame(AVCodecContext *avctx,
> > AVPacket *pkt,
> >  uint8_t *pal;
> >  int ret;
> >
> > +if (avctx->width < 4)
> > +return AVERROR_PATCHWELCOME;
> > +
> >
> 
> I just enabled address sanitizer for smc encoder and i do not get any
> errors.
> Where is log of where overread happens?

log is below:

+Release Build 
Stacktrace+
Command: /mnt/scratch0/clusterfuzz/resources/platform/linux/unshare -c -n 
/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds-i386_ffmpeg_bbf927d7e4cde0b71897048111a2d684e48dfab7/revisions/ffmpeg_AV_CODEC_ID_SMC_fuzzer
 -rss_limit_mb=2560 -timeout=60 -runs=100 
/mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-0e842ae89cdd58a7ef107605832b8beb5821004e
Time ran: 0.04435396194458008
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 267861690
INFO: Loaded 1 modules   (65950 inline 8-bit counters): 65950 [0x8b8e570, 
0x8b9e70e),
INFO: Loaded 1 PC tables (65950 PCs): 65950 [0x8a2d0d0,0x8aaddc0),
/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds-i386_ffmpeg_bbf927d7e4cde0b71897048111a2d684e48dfab7/revisions/ffmpeg_AV_CODEC_ID_SMC_fuzzer:
 Running 1 inputs 100 time(s) each.
Running: 
/mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-0e842ae89cdd58a7ef107605832b8beb5821004e
=
==23375==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf76af7fe at 
pc 0x08141703 bp 0xffb541a8 sp 0xffb53d80
READ of size 1 at 0xf76af7fe thread T0
SCARINESS: 12 (1-byte-read-heap-buffer-overflow)
#0 0x8141702 in MemcmpInterceptorCommon(void*, int (*)(void const*, void 
const*, unsigned int), void const*, void const*, unsigned int) 
/src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:860:7
#1 0x8141c31 in memcmp 
/src/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:892:10
#2 0x822ccab in smc_encode_stream /src/ffmpeg/libavcodec/smcenc.c:193:30
#3 0x822ccab in smc_encode_frame /src/ffmpeg/libavcodec/smcenc.c:560:5
#4 0x820f5cc in ff_encode_encode_cb /src/ffmpeg/libavcodec/encode.c:254:11
#5 0x82114db in encode_simple_internal 
/src/ffmpeg/libavcodec/encode.c:340:15
#6 0x82114db in encode_simple_receive_packet 
/src/ffmpeg/libavcodec/encode.c:354:15
#7 0x82114db in encode_receive_packet_internal 
/src/ffmpeg/libavcodec/encode.c:388:15
#8 0x821082f in avcodec_send_frame /src/ffmpeg/libavcodec/encode.c:531:15
#9 0x81ef067 in encode /src/ffmpeg/tools/target_enc_fuzzer.c:56:11
#10 0x81ef067 in LLVMFuzzerTestOneInput 
/src/ffmpeg/tools/target_enc_fuzzer.c:186:15
#11 0x80aefce in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#12 0x8099f2e in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:324:6
#13 0x809fb30 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char 
const*, unsigned int)) 
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:860:9
#14 0x80c9717 in main 
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#15 0xf7c6aed4 in __libc_start_main
#16 0x8091075 in _start
0xf76af7fe is located 2 bytes to the left of 264320-byte region 
[0xf76af800,0xf76f0080)
allocated by thread T0 here:
#0 0x81ab67a in posix_memalign 
/src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3
#1 0x884f02f in av_malloc /src/ffmpeg/libavutil/mem.c:107:9
#2 0x880036a in av_buffer_alloc /src/ffmpeg/libavutil/buffer.c:82:12
#3 0x8821c97 in get_video_buffer /src/ffmpeg/libavutil/frame.c:215:21
#4 0x8821c97 in av_frame_get_buffer /src/ffmpeg/libavutil/frame.c:294:16
#5 0x81eed9f in LLVMFuzzerTestOneInput 
/src/ffmpeg/tools/target_enc_fuzzer.c:171:15
#6 0x80aefce in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned int) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#7 0x8099f2e in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
int) /src/llvm-project/compiler-rt/lib/fuzz

Re: [FFmpeg-devel] [PATCH 4/9] avformat/iamf_parse: Layer, thou shalt not be 0

[James Almer]

On 6/16/2024 8:08 PM, Michael Niedermayer wrote:

Fixes: out of array access
Fixes: 
68302/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4665793796177920

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
  libavformat/iamf_parse.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
index 5c2ff6862a7..12c2b9533a8 100644
--- a/libavformat/iamf_parse.c
+++ b/libavformat/iamf_parse.c
@@ -330,7 +330,7 @@ static int scalable_channel_layout_config(void *s, 
AVIOContext *pb,
  nb_layers = avio_r8(pb) >> 5; // get_bits(&gb, 3);
  // skip_bits(&gb, 5); //reserved
  
-if (nb_layers > 6)

+if (nb_layers > 6 || nb_layers == 0)
  return AVERROR_INVALIDDATA;
  
  audio_element->layers = av_calloc(nb_layers, sizeof(*audio_element->layers));


LGMT, but please change the commit message.
___
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 3/9] avformat/iamf_parse: Try to use less space after the array

[James Almer]

On 6/16/2024 8:08 PM, Michael Niedermayer wrote:

Fixes: out of array access
Fixes: 
68584/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6256656668229632

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
  libavformat/iamf_parse.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
index 312090b247c..5c2ff6862a7 100644
--- a/libavformat/iamf_parse.c
+++ b/libavformat/iamf_parse.c
@@ -355,6 +355,9 @@ static int scalable_channel_layout_config(void *s, 
AVIOContext *pb,
  substream_count = avio_r8(pb);
  coupled_substream_count = avio_r8(pb);
  
+if (substream_count + k > audio_element->nb_substreams)

+return AVERROR_INVALIDDATA;
+
  audio_element->layers[i].substream_count = substream_count;
  audio_element->layers[i].coupled_substream_count = 
coupled_substream_count;
  if (output_gain_is_present_flag) {


LGTM, and ditto, change the commit message.
___
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 5/9] avformat/mov: Check extend and base offset

[James Almer]

On 6/16/2024 8:08 PM, Michael Niedermayer wrote:

Fixes: signed integer overflow: 2314885530818453536 + 9151314442816847872 
cannot be represented in type 'long'
Fixes: 
68359/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6571950311800832

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
  libavformat/mov.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9016cd5ad08..46cbce98040 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8131,7 +8131,9 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
  }
  for (int j = 0; j < extent_count; j++) {
  if (rb_size(pb, &extent_offset, offset_size) < 0 ||
-rb_size(pb, &extent_length, length_size) < 0)
+rb_size(pb, &extent_length, length_size) < 0 ||
+base_offset < 0 || extent_offset < 0 ||
+base_offset + (uint64_t)extent_offset > INT64_MAX)


You can do the negative value check directly in rb_size() instead. And 
I'd prefer the other check to be (base_offset > INT64_MAX - extent_offset).



  return AVERROR_INVALIDDATA;
  if (offset_type == 1)
  c->heif_item[i].is_idat_relative = 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".

[FFmpeg-devel] [PATCH] avformat/iamf_parse: add missing padding to AAC extradata

[James Almer]

Fixes: out of array access
Fixes: 
68863/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-4833546039525376

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer 
---
 libavformat/iamf_parse.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/iamf_parse.c b/libavformat/iamf_parse.c
index 312090b247..ff1b6cc75b 100644
--- a/libavformat/iamf_parse.c
+++ b/libavformat/iamf_parse.c
@@ -92,13 +92,16 @@ static int aac_decoder_config(IAMFCodecConfig *codec_config,
 if (left <= 0)
 return AVERROR_INVALIDDATA;
 
-codec_config->extradata = av_malloc(left);
+// We pad extradata here because avpriv_mpeg4audio_get_config2() needs it.
+codec_config->extradata = av_malloc(left + AV_INPUT_BUFFER_PADDING_SIZE);
 if (!codec_config->extradata)
 return AVERROR(ENOMEM);
 
 codec_config->extradata_size = avio_read(pb, codec_config->extradata, 
left);
 if (codec_config->extradata_size < left)
 return AVERROR_INVALIDDATA;
+memset(codec_config->extradata + codec_config->extradata_size, 0,
+   AV_INPUT_BUFFER_PADDING_SIZE);
 
 ret = avpriv_mpeg4audio_get_config2(&cfg, codec_config->extradata,
 codec_config->extradata_size, 1, 
logctx);
-- 
2.45.2

___
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 6/6] lavf/tls_mbedtls: add workaround for TLSv1.3 vs. verify=0

[Anton Khirnov]

Quoting sfan5 (2024-06-11 18:17:00)
> Am 11.06.24 um 17:02 schrieb Anton Khirnov:
> > Quoting Sfan5 (2024-05-17 10:34:50)
> >> As of mbedTLS 3.6.0 TLSv1.3 is enabled by default and certificate
> >> verification
> >> is now mandatory. Our default configuration does not do verification, so
> >> downgrade to 1.2 in these situations to avoid breaking it.
> >>
> >> ref: https://github.com/Mbed-TLS/mbedtls/issues/7075
> >> Signed-off-by: sfan5 
> >> ---
> > Would it not be simpler to simply set authmode to
> > MBEDTLS_SSL_VERIFY_OPTIONAL unconditionally, then just disregard the
> > verification result?
> >
> That's the thing and it's exactly as stupid as it sounds: When using 
> TLSv1.3 it will ignore the MBEDTLS_SSL_VERIFY mode entirely.
> 
> If the verification doesn't pass the handshake fails and you don't get 
> an usable connection. I'm hoping the mbedTLS devs realize at some point 
> how nonviable this is and fix it but as of right now this is the only 
> way to not have ffmpeg "randomly" (depending on if the server speaks 
> TLSv1.3) fail with mbedTLS 3.6.0.

uh...that sure is...special

Patch pushed then.

-- 
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 2/3] avfilter/af_volumedetect.c: Add 32bit float audio support

[Rémi Denis-Courmont]

Le 17 juin 2024 19:52:10 GMT+02:00, Paul B Mahol  a écrit :
>On Mon, Jun 17, 2024 at 4:52 PM Rémi Denis-Courmont  wrote:
>
>>
>>
>> Le 17 juin 2024 13:18:11 GMT+02:00, Yigithan Yigit <
>> yigithanyigitde...@gmail.com> a écrit :
>> >---
>> > libavfilter/af_volumedetect.c | 159 --
>> > 1 file changed, 133 insertions(+), 26 deletions(-)
>> >
>> >diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
>> >index 327801a7f9..dbbcd037a5 100644
>> >--- a/libavfilter/af_volumedetect.c
>> >+++ b/libavfilter/af_volumedetect.c
>> >@@ -20,27 +20,51 @@
>> >
>> > #include "libavutil/channel_layout.h"
>> > #include "libavutil/avassert.h"
>> >+#include "libavutil/mem.h"
>> > #include "audio.h"
>> > #include "avfilter.h"
>> > #include "internal.h"
>> >
>> >+#define MAX_DB_FLT 1024
>> > #define MAX_DB 91
>> >+#define HISTOGRAM_SIZE 0x1
>> >+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
>> >
>> > typedef struct VolDetectContext {
>> >-/**
>> >- * Number of samples at each PCM value.
>> >- * histogram[0x8000 + i] is the number of samples at value i.
>> >- * The extra element is there for symmetry.
>> >- */
>> >-uint64_t histogram[0x10001];
>> >+uint64_t* histogram; ///< for integer number of samples at each PCM
>> value, for float number of samples at each dB
>> >+uint64_t nb_samples; ///< number of samples
>> >+double sum2; ///< sum of the squares of the samples
>> >+double max;  ///< maximum sample value
>> >+int is_float;///< true if the input is in floating point
>> > } VolDetectContext;
>> >
>> >-static inline double logdb(uint64_t v)
>> >+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
>> > {
>> >-double d = v / (double)(0x8000 * 0x8000);
>> >-if (!v)
>> >-return MAX_DB;
>> >-return -log10(d) * 10;
>> >+if (sample_fmt == AV_SAMPLE_FMT_FLT) {
>> >+if (!v)
>> >+return MAX_DB_FLT;
>> >+return -log10(v) * 10;
>> >+} else {
>> >+double d = v / (double)(0x8000 * 0x8000);
>> >+if (!v)
>> >+return MAX_DB;
>> >+return -log10(d) * 10;
>> >+}
>> >+}
>> >+
>> >+static void update_float_stats(VolDetectContext *vd, float *audio_data)
>> >+{
>> >+double sample;
>> >+int idx;
>> >+if(!isnormal(*audio_data))
>> >+return;
>>
>> Do we really need to classify floats here? That's probably going to hurt
>> perfs badly, and makes an otherwise very vectorisable function not so
>> easily vectored.
>>
>
>This is fast, it should translate to checking few bits of memory.

Sure but the branch is what irks me here, not the classification per se. And I 
don't get why it's needed here, where most of the code base seems to assume 
that floats are always numeric. It's also not clear why subnormals are 
disallowed here.

IMO all that needs justification in the commit message which I find lacking. Or 
if it's unjustified then it shouldn't be there.

>> >+sample = fabsf(*audio_data);
>> >+if (sample > vd->max)
>> >+vd->max = sample;
>> >+vd->sum2 += sample * sample;
>> >+idx = lrintf(floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT))) +
>> MAX_DB_FLT;
>>
>> You're recomputing the same value again, and you seem to be rounding twice
>> in a row?
___
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".