On Mon, Dec 20, 2021 at 2:04 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > // store to device_list output
> > if (av_reallocp_array(&(*device_list)->devices,
> > (*device_list)->nb_devices + 1,
> > @@ -412,6 +417,
On Mon, Dec 20, 2021 at 2:27 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > @@ -545,11 +759,40 @@ dshow_cycle_formats(AVFormatContext *avctx, enum
> > dshowDeviceType devtype,
> > } else {
> > av_log(avctx, AV_LOG_INFO, " pixel_format=%s",
> > a
Enables creation of FLAC files with up to 32 bits-per-sample, up from the
previous limit of 24 bit. This is a feature requested for RAWcooked, the
archiving community has a need for storing files with 32-bit integer audio
samples. See https://github.com/MediaArea/RAWcooked/issues/356
Restrictions
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 limit, beyond which the delta is clamped
to 1.
Values greater than th
> 2021年12月18日 下午10:27，Hao Chen 写道：
>
> ./ffmpeg -i ../9_vp8_1080p_30fps_2Mbps.webm -f rawvideo -y /dev/null -an
> before: 210fps
> after : 585fps
> ffmpeg -i ../10_vp9_1080p_30fps_3Mbps.webm -f rawvideo -y /dev/null -an
> before:170fps
> after :294fps
> ./ffmpeg -i 11_wmv3_720p_24fps_7Mbps.wmv
---
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 $(SRC_PATH)
vpath %/fate_config.sh.template $(SRC_PATH)
+vpath
---
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
@@ -113,13 +113,13 @@ $(BIN2CEXE): ffbuild/bin2c_host.o
$(HOSTLD) $
Quoting Lynne (2021-12-17 21:54:14)
> Dec 17, 2021, 3:25 PM by an...@khirnov.net:
>
> > Quoting Pierre-Anthony Lemieux (2021-12-15 21:41:25)
> >
> >> On Wed, Dec 15, 2021 at 12:20 PM Anton Khirnov wrote:
> >> >
> >> > Quoting Pierre-Anthony Lemieux (2021-12-15 01:17:26)
> >> > > >
> >> > > > Now
Quoting Michael Niedermayer (2021-12-17 22:51:55)
> Fixes: OOM
This is very non-obvious and could use more explanation.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscr
Quoting Niklas Haas (2021-12-12 12:55:41)
> +/**
> + * Coefficients of a piece-wise function. The pieces of the function span the
> + * value ranges between two adjacent pivot values.
> + */
> +#define FF_DOVI_MAX_PIECES 8
Why FF_? It's public, no?
--
Anton Khirnov
__
Hi Andreas,
On Mon, Dec 20, 2021 at 1:59 AM Andreas Rheinhardt
wrote:
>
> Diederick Niehorster:
> > diff --git a/libavdevice/avdevice.h b/libavdevice/avdevice.h
> > index 8370bbc7f2..6f24976dcc 100644
> > --- a/libavdevice/avdevice.h
> > +++ b/libavdevice/avdevice.h
> > @@ -457,6 +457,8 @@ void
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
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
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
> 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
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
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
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 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
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
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: 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
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: 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
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
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
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
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
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
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
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(+)
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
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
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
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 +-
>
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
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 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
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
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
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
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
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
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
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
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
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: 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
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: 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
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
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
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 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(-)
> >
> >
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,
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
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
>>
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
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
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
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/
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
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
> 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
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:
>
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
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
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
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
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
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 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
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/
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:
> 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
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:
>
>
> 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: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
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
>
-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 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
> -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:
> >
> >
> > >
> -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
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
>
-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 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
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 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
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: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
-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
-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
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: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 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
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 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 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 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
-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
1 - 100 of 111 matches
Mail list logo
