From: Jan Ekström
Splits the currently handled subtitle at random access point
packets that can be configured to follow a specific output stream.
This way the subtitle - which is known to be shown at this time
can be split and passed to muxer before its full duration is
yet known.
Signed-off-by
From: Jan Ekström
This enables us to later call this when generating additional
subtitles for splitting purposes.
Signed-off-by: Jan Ekström
---
fftools/ffmpeg.c | 50
1 file changed, 29 insertions(+), 21 deletions(-)
diff --git a/fftools/ffmpe
From: Jan Ekström
Signed-off-by: Jan Ekström
---
tests/fate/ffmpeg.mak | 11 +
tests/ref/fate/ffmpeg-fix_sub_duration | 31 ++
2 files changed, 42 insertions(+)
create mode 100644 tests/ref/fate/ffmpeg-fix_sub_duration
diff --git a/tests/fate/f
> On Dec 21, 2021, at 1:45 AM, Lynne wrote:
>
>
> Thanks for testing, V2 attached, just changes require_cpp to check_cpp,
> since autodetecting is not a hard-require unlike enabling libraries.
> diff --git a/configure b/configure
> index d8b07c8e00..3be4de61e0 100755
> --- a/configure
> +++
On Mon, Dec 20, 2021 at 7:53 PM Aman Karmani wrote:
>
>
> On Mon, Dec 20, 2021 at 5:48 PM Christopher Degawa
> wrote:
>
>>
>>
>> On Mon, Dec 20, 2021 at 7:21 PM Aman Karmani wrote:
>>
>>>
>>>
>>> On Mon, Dec 20, 2021 at 5:03 PM Helmut K. C. Tessarek <
>>> tessa...@evermeet.cx> wrote:
>>>
-
On 2021-12-21 03:06 am, Michael Niedermayer wrote:
On Mon, Dec 20, 2021 at 10:21:53PM +0100, Michael Niedermayer wrote:
On Tue, Dec 21, 2021 at 02:31:33AM +0530, Gyan Doshi wrote:
On 2021-12-21 02:24 am, Andreas Rheinhardt wrote:
Gyan Doshi:
On 2021-12-21 02:18 am, Andreas Rheinhardt wrote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2021-12-20 20:39, Ridley Combs wrote:
> Try this (replacing all previous patches):
> https://gist.github.com/2b1ea91330a748740d608680b0f8abd2
This worked splendidly. All good with this patch.
If you want to test the binary on 10.9 or 10.10, her
On Mon, Dec 20, 2021 at 5:48 PM Christopher Degawa
wrote:
>
>
> On Mon, Dec 20, 2021 at 7:21 PM Aman Karmani wrote:
>
>>
>>
>> On Mon, Dec 20, 2021 at 5:03 PM Helmut K. C. Tessarek <
>> tessa...@evermeet.cx> wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> On 2021-12-20
On Mon, Dec 20, 2021 at 07:27:30PM +0100, Andreas Rheinhardt wrote:
> Currently, user data unregistered SEIs found in input are
> forwarded as side-data to encoders; for the libx26[45] encoders
> these are included in the reencoded output (even including x264 SEIs
> in H.265 and vice versa).
> This
On Mon, Dec 20, 2021 at 7:21 PM Aman Karmani wrote:
>
>
> On Mon, Dec 20, 2021 at 5:03 PM Helmut K. C. Tessarek <
> tessa...@evermeet.cx> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 2021-12-20 19:11, Christopher Degawa wrote:
>> > So I've exported "LIBRARY_PATH" to
>>
On Mon, Dec 20, 2021 at 07:22:56PM +0100, Andreas Rheinhardt wrote:
> The check here is meant to check for whether avcintra-class option
> (default value -1) has been set; yet it checks for the x264_param_t
> value where 0 is the default value (treated as "no avcintra-mode"
> by x264). This meant t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2021-12-20 20:20, Aman Karmani wrote:
> Once we figure out why some computers are using the wrong metal binary,
> then we can fix it and commit the fix to master as well.
With the 2 patches from Ridley and your configure patch I run into the
f
On Mon, Dec 20, 2021 at 7:29 PM Ridley Combs wrote:
> The main thing that confuses me here is that this file does build for me
> when I use the iOS version of the metal compiler (tbh I didn't even know
> there was a difference between them).
>
> What Xcode and macOS version are you on?
>
system
On Mon, Dec 20, 2021 at 7:25 PM Aman Karmani wrote:
> On Mon, Dec 20, 2021 at 5:19 PM Christopher Degawa
> wrote:
>
> > On Mon, Dec 20, 2021 at 6:55 PM Aman Karmani wrote:
> >
> > > On Mon, Dec 20, 2021 at 4:52 PM Helmut K. C. Tessarek <
> > > tessa...@evermeet.cx>
> > > wrote:
> > >
> > > > --
On Mon, Dec 20, 2021 at 5:19 PM Christopher Degawa
wrote:
> On Mon, Dec 20, 2021 at 6:55 PM Aman Karmani wrote:
>
> > On Mon, Dec 20, 2021 at 4:52 PM Helmut K. C. Tessarek <
> > tessa...@evermeet.cx>
> > wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > >
> > >
> > >
> >
On Mon, Dec 20, 2021 at 5:03 PM Helmut K. C. Tessarek
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2021-12-20 19:11, Christopher Degawa wrote:
> > So I've exported "LIBRARY_PATH" to
>
> I'm sorry to say, this is a workaround but hardly a solution.
>
No one said this is the s
On Mon, Dec 20, 2021 at 6:55 PM Aman Karmani wrote:
> On Mon, Dec 20, 2021 at 4:52 PM Helmut K. C. Tessarek <
> tessa...@evermeet.cx>
> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> >
> >
> > On 2021-12-20 19:38, Aman Karmani wrote:
> > > Could you share the output of `xc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2021-12-20 19:11, Christopher Degawa wrote:
> So I've exported "LIBRARY_PATH" to
I'm sorry to say, this is a workaround but hardly a solution.
Before these 2 commits all worked perfectly. Now it doesn't. Tweaking the
build env is not a solution.
On Mon, Dec 20, 2021 at 4:52 PM Helmut K. C. Tessarek
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
>
>
> On 2021-12-20 19:38, Aman Karmani wrote:
> > Could you share the output of `xcrun metal -v`
>
> $ xcrun metal -v
> Apple LLVM version 902.9 (metalfe-902.9.61)
> Target: air64-a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2021-12-20 19:50, Aman Karmani wrote:
> Somehow yours is defaulting to the iOS binary. Do you have some
> environment variable set that could be causing this?
Even though this question was addressed to Christopher, my output also shows
ios. And I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2021-12-20 19:38, Aman Karmani wrote:
> Could you share the output of `xcrun metal -v`
$ xcrun metal -v
Apple LLVM version 902.9 (metalfe-902.9.61)
Target: air64-apple-darwin18.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Conte
On Mon, Dec 20, 2021 at 4:43 PM Christopher Degawa
wrote:
> On Mon, Dec 20, 2021 at 6:39 PM Aman Karmani wrote:
>
> >
> > Could you share the output of `xcrun metal -v`
> >
> >
> xcrun metal -v
> Apple LLVM version 31001.43 (metalfe-31001.43)
> Target: air64-apple-darwin19.6.0
> Thread model: po
On Mon, Dec 20, 2021 at 6:39 PM Aman Karmani wrote:
>
> Could you share the output of `xcrun metal -v`
>
>
xcrun metal -v
Apple LLVM version 31001.43 (metalfe-31001.43)
Target: air64-apple-darwin19.6.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDe
On Mon, Dec 20, 2021 at 4:12 PM Christopher Degawa
wrote:
> On Mon, Dec 20, 2021 at 3:31 PM Helmut K. C. Tessarek <
> tessa...@evermeet.cx>
> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Hello,
> >
> > The following 2 commits break the build with a deployment target of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2021-12-20 19:06, Ridley Combs wrote:
> Try with this as well:
> https://gist.github.com/499380d8ea03a86fc89eb48803ff7b2e
Getting closer...
CC libavfilter/generate_wave_table.o
CC libavfilter/graphdump.o
CC libavfilter/graphparser
On Mon, Dec 20, 2021 at 3:31 PM Helmut K. C. Tessarek
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hello,
>
> The following 2 commits break the build with a deployment target of 10.9 on
> macOS.
>
> I agree that 10.9 is quite old, but the rest of the code worked perfectly
> fine
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Thanks for the rwply.
On 2021-12-20 18:25, Ridley Combs wrote:
> Could you try with this patch and let me know if it works for you then?
> https://gist.github.com/7362df8a689c41b9174ac50fdeda3e43
I've applied your patch and get the following now:
On Mon, Dec 20, 2021 at 06:45:43PM +0100, Lynne wrote:
> 20 Dec 2021, 17:59 by mich...@niedermayer.cc:
>
> > On Mon, Dec 20, 2021 at 11:15:08AM +0100, Lynne wrote:
> >
> >> Recently, Metal support was merged, which is autodetected
> >> by default. Metal doesn't even have a hwcontext and it's not
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Monday, December 20, 2021 11:35 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Politics
>
>
>
> > -Original Message-
> > From: ffmpeg-devel
> > mailto:ffm
> -Original Message-
> From: ffmpeg-devel On Behalf Of Michael
> Niedermayer
> Sent: Monday, December 20, 2021 3:50 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Politics
>
> On Sun, Dec 19, 2021 at 06:31:38PM +, Soft Works wrote:
> >
> >
> > >
On Mon, Dec 20, 2021 at 10:21:53PM +0100, Michael Niedermayer wrote:
> On Tue, Dec 21, 2021 at 02:31:33AM +0530, Gyan Doshi wrote:
> >
> >
> > On 2021-12-21 02:24 am, Andreas Rheinhardt wrote:
> > > Gyan Doshi:
> > > >
> > > > On 2021-12-21 02:18 am, Andreas Rheinhardt wrote:
> > > > > Gyan Dosh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
The following 2 commits break the build with a deployment target of 10.9 on
macOS.
I agree that 10.9 is quite old, but the rest of the code worked perfectly
fine, so were those 2 commits really necessary?
* 4ac869ca2a | 2021-12-18 11:57:31
On Tue, Dec 21, 2021 at 02:31:33AM +0530, Gyan Doshi wrote:
>
>
> On 2021-12-21 02:24 am, Andreas Rheinhardt wrote:
> > Gyan Doshi:
> > >
> > > On 2021-12-21 02:18 am, Andreas Rheinhardt wrote:
> > > > Gyan Doshi:
> > > > > Avoids overreading the box and ingesting absurd values into stts_data
>
On 2021-12-21 02:24 am, Andreas Rheinhardt wrote:
Gyan Doshi:
On 2021-12-21 02:18 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Avoids overreading the box and ingesting absurd values into stts_data
---
libavformat/mov.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/m
Gyan Doshi:
>
>
> On 2021-12-21 02:18 am, Andreas Rheinhardt wrote:
>> Gyan Doshi:
>>> Avoids overreading the box and ingesting absurd values into stts_data
>>> ---
>>> libavformat/mov.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>
On 2021-12-21 02:18 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Avoids overreading the box and ingesting absurd values into stts_data
---
libavformat/mov.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..5a7209837f 100644
--- a
Gyan Doshi:
> Avoids overreading the box and ingesting absurd values into stts_data
> ---
> libavformat/mov.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 2aed6e80ef..5a7209837f 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov
Avoids overreading the box and ingesting absurd values into stts_data
---
libavformat/mov.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..5a7209837f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2935,6 +2935,11 @@ stat
Gyan Doshi:
>
>
> On 2021-12-21 01:27 am, Andreas Rheinhardt wrote:
>> Gyan Doshi:
>>> Avoids overreading the box and ingesting absurd values into stts_data
>>> ---
>>>
>>> Fixes prolonged demuxing for fuzzer-generated files in the loop added in
>>> patch for max_stts_delta
>>>
>>> libavformat/
On 2021-12-21 01:27 am, Andreas Rheinhardt wrote:
Gyan Doshi:
Avoids overreading the box and ingesting absurd values into stts_data
---
Fixes prolonged demuxing for fuzzer-generated files in the loop added in
patch for max_stts_delta
libavformat/mov.c | 5 +
1 file changed, 5 inserti
20 Dec 2021, 20:48 by p...@sandflow.com:
> On Mon, Dec 20, 2021 at 11:19 AM Lynne wrote:
>
>>
>> 20 Dec 2021, 19:57 by p...@sandflow.com:
>>
>> > From: Pierre-Anthony Lemieux
>> >
>> > Signed-off-by: Pierre-Anthony Lemieux
>> > ---
>> >
>> > Notes:
>> > The IMF demuxer accepts as input an IMF
On Mon, Dec 20, 2021 at 1:09 AM Zhao Zhili wrote:
> ---
> ffbuild/common.mak | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/ffbuild/common.mak b/ffbuild/common.mak
> index e79b509425..c13148f476 100644
> --- a/ffbuild/common.mak
> +++ b/ffbuild/common.mak
> @@ -11
Gyan Doshi:
> Avoids overreading the box and ingesting absurd values into stts_data
> ---
>
> Fixes prolonged demuxing for fuzzer-generated files in the loop added in
> patch for max_stts_delta
>
> libavformat/mov.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/mov.c
Avoids overreading the box and ingesting absurd values into stts_data
---
Fixes prolonged demuxing for fuzzer-generated files in the loop added in
patch for max_stts_delta
libavformat/mov.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6
On Mon, Dec 20, 2021 at 11:19 AM Lynne wrote:
>
> 20 Dec 2021, 19:57 by p...@sandflow.com:
>
> > From: Pierre-Anthony Lemieux
> >
> > Signed-off-by: Pierre-Anthony Lemieux
> > ---
> >
> > Notes:
> > The IMF demuxer accepts as input an IMF CPL. The assets referenced by the
> > CPL can be
> > c
Zhao Zhili:
> ---
> libavutil/display.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavutil/display.h b/libavutil/display.h
> index 515adad795..d87bf68425 100644
> --- a/libavutil/display.h
> +++ b/libavutil/display.h
> @@ -88,7 +88,7 @@
> double av_display_rotatio
20 Dec 2021, 19:57 by p...@sandflow.com:
> From: Pierre-Anthony Lemieux
>
> Signed-off-by: Pierre-Anthony Lemieux
> ---
>
> Notes:
> The IMF demuxer accepts as input an IMF CPL. The assets referenced by the
> CPL can be
> contained in multiple deliveries, each defined by an ASSETMAP file:
>
> And then generate the appropriate reference file.
Done at v13 of the patchset.
I have also (separately) requested to samples-requ...@ffmpeg.org the
addition of an IMF sample -- in addition to the tests at
libavformat/tests/imf.c.
On Mon, Dec 20, 2021 at 7:06 AM Anton Khirnov wrote:
>
> As fa
From: Pierre-Anthony Lemieux
Signed-off-by: Pierre-Anthony Lemieux
---
Notes:
Tests for the IMF demuxer.
libavformat/Makefile | 1 +
libavformat/tests/imf.c| 525 +
tests/fate/libavformat.mak | 4 +
tests/ref/fate/imf | 54
4
From: Pierre-Anthony Lemieux
Signed-off-by: Pierre-Anthony Lemieux
---
Notes:
The IMF demuxer accepts as input an IMF CPL. The assets referenced by the
CPL can be
contained in multiple deliveries, each defined by an ASSETMAP file:
ffmpeg -assetmaps ,,... -i
If -asset
Signed-off-by: Michael Niedermayer
---
libavcodec/ass.c | 36 ++--
libavcodec/ass.h | 7 +++
2 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/libavcodec/ass.c b/libavcodec/ass.c
index 725e4d42ba1..a1e560d7ff6 100644
--- a/libavcodec/ass.c
+++ b/
On Mon, Dec 20, 2021 at 02:01:05PM +0530, Gyan Doshi wrote:
> Very high stts sample deltas may occasionally be intended but usually
> they are written in error or used to store a negative value for dts correction
> when treated as signed 32-bit integers.
>
> This option lets the user set an upper
Currently, user data unregistered SEIs found in input are
forwarded as side-data to encoders; for the libx26[45] encoders
these are included in the reencoded output (even including x264 SEIs
in H.265 and vice versa).
This makes tools like mediainfo display the wrong (old) encoding
parameters and ba
The check here is meant to check for whether avcintra-class option
(default value -1) has been set; yet it checks for the x264_param_t
value where 0 is the default value (treated as "no avcintra-mode"
by x264). This meant that in-band extradata has been added unnecessarily
when using global headers
20 Dec 2021, 17:59 by mich...@niedermayer.cc:
> On Mon, Dec 20, 2021 at 11:15:08AM +0100, Lynne wrote:
>
>> Recently, Metal support was merged, which is autodetected
>> by default. Metal doesn't even have a hwcontext and it's not
>> a hwaccel, nor would it likely ever be one as Apple won't drop
>>
From: Jan Ekström
Signed-off-by: Jan Ekström
---
tests/fate/ffmpeg.mak | 8 ++
tests/ref/fate/ffmpeg-fix_sub_duration | 40 ++
2 files changed, 48 insertions(+)
create mode 100644 tests/ref/fate/ffmpeg-fix_sub_duration
diff --git a/tests/fate/ffmp
On Mon, Dec 20, 2021 at 11:15:08AM +0100, Lynne wrote:
> Recently, Metal support was merged, which is autodetected
> by default. Metal doesn't even have a hwcontext and it's not
> a hwaccel, nor would it likely ever be one as Apple won't drop
> videotoolbox.
>
> To keep it fair, autodetect Vulkan,
On Mon, Dec 20, 2021 at 01:39:47AM +0100, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/ass.c | 33 +++--
> > libavcodec/ass.h | 7 +++
> > 2 files changed, 34 insertions(+), 6 deletions(-)
> >
> >
I am not sure the direction from which you approuch this is going to
increase the chances this patch has.
Me neither.
But I can barely talk about ffmpeg internals: they're huge, and I know
the little bits I'm familiar with, having some experience with filters.
So, whatever argument I may have
On Sun, Dec 19, 2021 at 09:00:27PM -0300, James Almer wrote:
>
>
> On 12/19/2021 8:56 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/ass.c | 33 +++--
> > libavcodec/ass.h | 7 +++
> > 2 files changed, 34 insertio
From: Niklas Haas
And expose the parsed values as frame side data. Update FATE results to
match.
It's worth documenting that this relies on the dovi configuration record
being present on the first AVPacket fed to the decoder, which in
practice is the case if if the API user has called something
From: Niklas Haas
To avoid the ref for this growing to a very large size when attaching
the parsed RPU side data. Since this sample does not have any dynamic
metadata, two frames will serve just as well as 100.
Signed-off-by: Niklas Haas
---
tests/fate/hevc.mak| 2 +-
tests/ref/fate/
From: Niklas Haas
Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.
Contains some annoying machinery to persist these values in between
frames, which is needed in theory even
From: Jan Ekström
Co-authored-by: Niklas Haas
---
fftools/ffprobe.c | 173 +-
1 file changed, 170 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 0711e02922..75263cd3a9 100644
--- a/fftools/ffprobe.c
+++ b/fftoo
From: Niklas Haas
Signed-off-by: Niklas Haas
---
libavfilter/vf_showinfo.c | 108 ++
1 file changed, 108 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 62c7833247..eb6684558a 100644
--- a/libavfilter/vf_showinfo.c
+++
From: Niklas Haas
Signed-off-by: Niklas Haas
---
doc/APIchanges| 3 +
libavutil/dovi_meta.c | 12
libavutil/dovi_meta.h | 143 ++
libavutil/frame.c | 1 +
libavutil/frame.h | 9 ++-
libavutil/version.h | 2 +-
6 files chang
20 Dec 2021, 15:59 by alankelly-at-google@ffmpeg.org:
> This flag is set on Haswell and earlier and all AMD cpus.
> ---
> Sets this flag on Zen 3 and earlier.
> libavutil/cpu.h | 1 +
> libavutil/x86/cpu.c | 14 +-
> 2 files changed, 14 insertions(+), 1 deletion(-)
>
> diff
On Mon, Dec 20, 2021 at 11:06:44AM -0300, Daniel Cantarín wrote:
>
> >
> > consider a subtitle track
> > consider 2 video tracks for US 3/1001 fps and EU 25 fps
> >
> > the 6th frame in the US track is at 0.2002 sec, the 5th in the EU track
> > at 0.2sec
> >
> >
> > if these differ and yo
As far as I can tell, the test is not actually run as a part of make
fate. You need something like:
diff --git a/tests/fate/libavformat.mak b/tests/fate/libavformat.mak
index d1e81284ed..59ff0ebc8d 100644
--- a/tests/fate/libavformat.mak
+++ b/tests/fate/libavformat.mak
@@ -22,6 +22,10 @@ FATE_LIB
Andreas Rheinhardt:
> libavcodec currently exports four avpriv symbols that deal with
> PixelFormatTags: avpriv_get_raw_pix_fmt_tags, avpriv_find_pix_fmt,
> avpriv_pix_fmt_bps_avi and avpriv_pix_fmt_bps_mov. The latter two are
> lists of PixelFormatTags, the former returns such a list and the secon
On Mon, Dec 20, 2021 at 3:53 PM James Almer wrote:
>
>
> On 12/20/2021 11:47 AM, Lynne wrote:
> > 20 Dec 2021, 15:43 by alankelly-at-google@ffmpeg.org:
> >
> >> This flag is set on Haswell and earlier and all AMD cpus.
> >> ---
> >> Removes unnecessary indentation, clarifies comment and onl
This flag is set on Haswell and earlier and all AMD cpus.
---
Sets this flag on Zen 3 and earlier.
libavutil/cpu.h | 1 +
libavutil/x86/cpu.c | 14 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavutil/cpu.h b/libavutil/cpu.h
index ae443eccad..ce9bf14bf7 100
Quoting Niklas Haas (2021-12-20 15:47:45)
> So, the reason I made this an avctx is because I'm anticipating the need
> to check `avctx->err_recognition` if the CRC32 check ever gets
> implemented. In theory we could also do some profile-based verification
> in AV_EF_BITSTREAM / AV_EF_EXPLODE, to ch
On 12/20/2021 11:47 AM, Lynne wrote:
20 Dec 2021, 15:43 by alankelly-at-google@ffmpeg.org:
This flag is set on Haswell and earlier and all AMD cpus.
---
Removes unnecessary indentation, clarifies comment and only sets flag on AMD
cpus with AVX2.
libavutil/cpu.h | 1 +
libavut
On Sun, Dec 19, 2021 at 06:31:38PM +, Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Soft Works
> > Sent: Sunday, December 19, 2021 7:23 PM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] Politics
> >
> >
> >
>
On Mon, 20 Dec 2021 11:13:15 +0100 Anton Khirnov wrote:
> nit: FF_ARRAY_ELEMS(s->vdr_ref) is considered better
Done.
> Would not calling ff_dovi_ctx_unref() be safer here?
Good point, changed.
> This is only used for logging (as it should be), so you can make this
> void *logctx and drop the a
20 Dec 2021, 15:43 by alankelly-at-google@ffmpeg.org:
> This flag is set on Haswell and earlier and all AMD cpus.
> ---
> Removes unnecessary indentation, clarifies comment and only sets flag on AMD
> cpus with AVX2.
> libavutil/cpu.h | 1 +
> libavutil/x86/cpu.c | 14 +-
>
This is instead of EXTERNAL_AVX2_FAST so that the avx2 hscale functions
are only used where they are faster.
---
Whoops! Corrects check so that this flag is only enabled where fast
avx2 and fast gathers are available.
libswscale/utils.c| 2 +-
libswscale/x86/swscale.c | 2 +-
tests/chec
This flag is set on Haswell and earlier and all AMD cpus.
---
Removes unnecessary indentation, clarifies comment and only sets flag on AMD
cpus with AVX2.
libavutil/cpu.h | 1 +
libavutil/x86/cpu.c | 14 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavutil
Quoting Michael Niedermayer (2021-12-20 11:50:21)
> On Mon, Dec 20, 2021 at 10:51:56AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2021-12-17 22:51:55)
> > > Fixes: OOM
> >
> > This is very non-obvious and could use more explanation.
>
> I guess its obvious to me as ive seen this
On 12/20/2021 10:57 AM, Alan Kelly wrote:
This is instead of EXTERNAL_AVX2_FAST so that the avx2 hscale functions
are only used where they are faster.
---
libswscale/utils.c| 2 +-
libswscale/x86/swscale.c | 2 +-
tests/checkasm/sw_scale.c | 2 +-
3 files changed, 3 insertions(+)
On 12/20/2021 10:56 AM, Alan Kelly wrote:
This flag is set on Haswell and earlier and all AMD cpus.
---
As discussed on IRC last week.
libavutil/cpu.h | 57 +++--
libavutil/x86/cpu.c | 13 ++-
2 files changed, 41 insertions(+), 29 delet
consider a subtitle track
consider 2 video tracks for US 3/1001 fps and EU 25 fps
the 6th frame in the US track is at 0.2002 sec, the 5th in the EU
track at 0.2sec
if these differ and you want a subtitle to either stop displaying after
the
earlier or begin displaying after the earl
This is instead of EXTERNAL_AVX2_FAST so that the avx2 hscale functions
are only used where they are faster.
---
libswscale/utils.c| 2 +-
libswscale/x86/swscale.c | 2 +-
tests/checkasm/sw_scale.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libswscale/utils.c b
This flag is set on Haswell and earlier and all AMD cpus.
---
As discussed on IRC last week.
libavutil/cpu.h | 57 +++--
libavutil/x86/cpu.c | 13 ++-
2 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/libavutil/cpu.h b/libavutil/c
The more the focus is moving to "a single frame" doesn't matter,
the more will that conversation create the impression that my patchset
would be lacking precision.
This is a possibility, indeed.
Yet, the less one answers, the more it also looks like the issue is dead
and/or some argument was
From: Niklas Haas
And expose the parsed values as frame side data. Update FATE results to
match.
It's worth documenting that this relies on the dovi configuration record
being present on the first AVPacket fed to the decoder, which in
practice is the case if if the API user has called something
From: Niklas Haas
To avoid the ref for this growing to a very large size when attaching
the parsed RPU side data. Since this sample does not have any dynamic
metadata, two frames will serve just as well as 100.
Signed-off-by: Niklas Haas
---
tests/fate/hevc.mak| 2 +-
tests/ref/fate/
From: Niklas Haas
Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.
Contains some annoying machinery to persist these values in between
frames, which is needed in theory even
From: Jan Ekström
Co-authored-by: Niklas Haas
---
fftools/ffprobe.c | 173 +-
1 file changed, 170 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 0711e02922..75263cd3a9 100644
--- a/fftools/ffprobe.c
+++ b/fftoo
From: Niklas Haas
Signed-off-by: Niklas Haas
---
libavfilter/vf_showinfo.c | 108 ++
1 file changed, 108 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 62c7833247..8a7efc15b7 100644
--- a/libavfilter/vf_showinfo.c
+++
From: Niklas Haas
Signed-off-by: Niklas Haas
---
doc/APIchanges| 3 +
libavutil/dovi_meta.c | 12
libavutil/dovi_meta.h | 132 ++
libavutil/frame.c | 1 +
libavutil/frame.h | 9 ++-
libavutil/version.h | 2 +-
6 files chang
On Mon, Dec 20, 2021 at 11:15 AM Lynne wrote:
>
> Recently, Metal support was merged, which is autodetected
> by default. Metal doesn't even have a hwcontext and it's not
> a hwaccel, nor would it likely ever be one as Apple won't drop
> videotoolbox.
>
> To keep it fair, autodetect Vulkan, which
Op ma 20 dec. 2021 om 09:12 schreef Martijn van Beurden :
> +if (avctx->bits_per_raw_sample == 0)
> +avctx->bits_per_raw_sample = 32;
This part is wrong. bits_per_raw_sample should not be 0. I assumed
that 0 meant 'no different from sample format', but I see now that it
On Mon, Dec 20, 2021 at 10:51:56AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-12-17 22:51:55)
> > Fixes: OOM
>
> This is very non-obvious and could use more explanation.
I guess its obvious to me as ive seen this bug more than once
the problem is that directly setting width/h
Quoting Lynne (2021-12-20 11:15:08)
> Recently, Metal support was merged, which is autodetected
> by default. Metal doesn't even have a hwcontext and it's not
> a hwaccel, nor would it likely ever be one as Apple won't drop
> videotoolbox.
>
> To keep it fair, autodetect Vulkan, which is a hwconte
> 2021年12月20日 下午5:09，Zhao Zhili 写道：
>
> ---
> Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Makefile b/Makefile
> index 5b20658b52..df5fb8be15 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -14,6 +14,7 @@ vpath %.texi $(SRC_PATH)
> vpath %.cu $(SRC_PATH)
> vpath %.ptx $(SR
Recently, Metal support was merged, which is autodetected
by default. Metal doesn't even have a hwcontext and it's not
a hwaccel, nor would it likely ever be one as Apple won't drop
videotoolbox.
To keep it fair, autodetect Vulkan, which is a hwcontext,
and for which there is an unmerged hwaccel p
Quoting Niklas Haas (2021-12-12 12:55:44)
> +void ff_dovi_ctx_unref(DOVIContext *s)
> +{
> +for (int i = 0; i < DOVI_MAX_DM_ID; i++)
nit: FF_ARRAY_ELEMS(s->vdr_ref) is considered better
> +av_buffer_unref(&s->vdr_ref[i]);
> +
> +/* Preserve the user-provided fields explicitly, res
Quoting Niklas Haas (2021-12-12 12:55:41)
> From: Niklas Haas
>
> Signed-off-by: Niklas Haas
> ---
> doc/APIchanges| 3 +
> libavutil/dovi_meta.c | 12
> libavutil/dovi_meta.h | 132 ++
> libavutil/frame.c | 1 +
> libavutil/frame.h
1 - 100 of 111 matches
Mail list logo
