On Sun, Jun 6, 2021 at 6:15 AM Andreas Rheinhardt
wrote:
> Diederick C. Niehorster:
> > See other mails: the bit of documentation in avdevice.h (lines
> > 334--402) suggest the capabilities API is supposed to be used on an
> > unopened device. It would make sense: probe the device for what it can
Check for sys/auxv.h because not all toolchains contain this header.
Fixes https://trac.ffmpeg.org/ticket/9138
Signed-off-by: Bernd Kuhls
---
configure| 2 ++
libavutil/mips/cpu.c | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index
On Sun, 6 Jun 2021, Valerii Zapodovnikov wrote:
I am sorry, what? It converts to 420 always? Wow? But you are right.
Yes, because ffplay uses the default SDL renderer (may it be
opengl/directx or anything else), and ffplay queries the hardware
acccelerated pixel formats supported by that
AVFrame->color_range? But even if I were using full range file (I do not)
that would force BT.601 full range matrix (that is JPEG matrix) and I have
the opposite here, BT.709 is forced.
I suppose the problem can be checked with simple printf
of frame->colorspace with that sample that uses BT.601.
Anton Khirnov:
> Memory ordering constraints other than the default (sequentially
> consistent) can behave in very unintuitive and unexpected ways, and so
> should be avoided unless there is a strong (typically performance)
> reason for using them. This holds especially for memory_order_relaxed,
>
Hi,
Am 05.06.21 um 16:33 schrieb Anton Khirnov:
> Quoting Thilo Borgmann (2021-06-05 14:29:05)
>> Hi,
>>
>> add an option to override auto-detection of cpu count. Defaults to
>> auto-detection, of course.
>>
>> -Thilo
>>
>> From 38612f3e1339354dbaa6be4f36072320ff71c707 Mon Sep 17 00:00:00 2001
>>
James Almer:
> On 6/5/2021 11:27 AM, Anton Khirnov wrote:
>> Memory ordering constraints other than the default (sequentially
>> consistent) can behave in very unintuitive and unexpected ways, and so
>> should be avoided unless there is a strong (typically performance)
>> reason for using them. Thi
On 6/6/2021 8:39 AM, Andreas Rheinhardt wrote:
James Almer:
On 6/5/2021 11:27 AM, Anton Khirnov wrote:
Memory ordering constraints other than the default (sequentially
consistent) can behave in very unintuitive and unexpected ways, and so
should be avoided unless there is a strong (typically pe
Thilo Borgmann:
> Hi,
>
> add an option to override auto-detection of cpu count. Defaults to
> auto-detection, of course.
>
> -Thilo
>
>
> doc/fftools-common-opts.texi | 7 +++
> fftools/cmdutils.c | 27 +++
> fftools/cmdutils.h | 7 +++
>
Quoting Andreas Rheinhardt (2021-06-06 11:13:00)
> Anton Khirnov:
> > Memory ordering constraints other than the default (sequentially
> > consistent) can behave in very unintuitive and unexpected ways, and so
> > should be avoided unless there is a strong (typically performance)
> > reason for usi
The input stream is a raw 16 bit audio one, so trying to read it as a
32 bit one is incorrect. The test can and will autoinsert a resampler
as needed.
Use the oneline comparison for the final result as well, while at it.
Signed-off-by: James Almer
---
tests/fate/ffmpeg.mak | 4 +++-
Am 06.06.21 um 14:35 schrieb Andreas Rheinhardt:
> Thilo Borgmann:
>> Hi,
>>
>> add an option to override auto-detection of cpu count. Defaults to
>> auto-detection, of course.
>>
>> -Thilo
>>
>
>>
>> doc/fftools-common-opts.texi | 7 +++
>> fftools/cmdutils.c | 27 +++
Am 06.06.21 um 14:35 schrieb Andreas Rheinhardt:
> Thilo Borgmann:
>> Hi,
>>
>> add an option to override auto-detection of cpu count. Defaults to
>> auto-detection, of course.
>>
>> -Thilo
>>
>
>>
>> doc/fftools-common-opts.texi | 7 +++
>> fftools/cmdutils.c | 27 +++
Fixes: floating point division by 0
Fixes: -nan is outside the range of representable values of type 'int'
Fixes: Ticket8307
Signed-off-by: Michael Niedermayer
---
libavfilter/af_drmeter.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavfilter/af_drmeter.c b/libavfilter/af_drmeter.
Fixes: floating point division by 0
Fixes: undefined behavior in handling NaN
Fixes: Ticket 8268
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_ciescope.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavfilter/vf_ciescope.c b/libavfilter/vf_ciescope.c
index b3b906f517..f8fe554
I am sorry, what???
___
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".
Fixes: left shift of negative value -1
Fixes: Ticket8270
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_mestimate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavfilter/vf_mestimate.c b/libavfilter/vf_mestimate.c
index daf7fde95f..f1935244c1 100644
--- a/libavfilter/vf_mesti
Fixes: 1.04064e+10 is outside the range of representable values of type 'int'
Fixes: Ticket 8279
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_fftdnoiz.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_fftdnoiz.c b/libavfilter/vf_fftdnoiz.c
index 7f4a6d
Fixes: floating point division by 0
Fixes: Ticket 8269
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_dctdnoiz.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavfilter/vf_dctdnoiz.c b/libavfilter/vf_dctdnoiz.c
index 63b1b29ea2..f09ab19c4d 100644
--- a/libavfilter/vf_dctdnoiz.c
Quoting Thilo Borgmann (2021-06-06 12:44:41)
> Hi,
>
> Am 05.06.21 um 16:33 schrieb Anton Khirnov:
> > Quoting Thilo Borgmann (2021-06-05 14:29:05)
> >> Hi,
> >>
> >> add an option to override auto-detection of cpu count. Defaults to
> >> auto-detection, of course.
> >>
> >> -Thilo
> >>
> >> From
On Sun, Jun 06, 2021 at 09:27:32AM +0300, Valerii Zapodovnikov wrote:
> From: Rémi Achard
>
> Patch should be applied to decode XYZ samples with not native
> decoder in ffmpeg (-c:v libopenjpeg, not -c:v jpeg2000). jpeg2000
> works already.
> Now, this is AFAIK a patch that should be applied afte
Did you even read the commit message? You need to apply a patch to openjpeg
itself. Sigh.
___
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.
Quoting Michael Niedermayer (2021-06-06 15:47:54)
> Fixes: floating point division by 0
> Fixes: Ticket 8269
>
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/vf_dctdnoiz.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavfilter/vf_dctdnoiz.c b/libavfilter/vf_dctdnoiz.c
On Sun, Jun 06, 2021 at 05:42:54PM +0300, Valerii Zapodovnikov wrote:
> Did you even read the commit message? You need to apply a patch to openjpeg
> itself. Sigh.
yes i read your commit message.
you are changing the API/ABI of openjpeg and doing a matching change in
the interface in ffmpeg to ope
Hi Haihao,
On Mon, May 17, 2021 at 11:30 AM Haihao Xiang wrote:
>
> ---
> libavfilter/vf_vpp_qsv.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> index 29ba220665..ec35f85b04 100644
> --- a/libavfilter/vf_vpp
Actually it is not my patch (as should be obvious as From: is not me) and
*NO* changes in API/ABI of openjpeg are happening with upsream patch. As
for your ABI... There is only one correct way to manipulate openjpeg API,
if you did that wrong, it is your problem.
Standard thing: "unexpected that u
On Mon, May 17, 2021 at 11:30 AM Haihao Xiang wrote:
>
> NV12 and P010 are added
>
> $ ffmpeg -init_hw_device qsv -c:v h264_qsv -i input.h264 -vf
> "scale_qsv=format=p010" -f null -
> ---
> libavfilter/vf_vpp_qsv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libav
I hope it is the case since there was a problem with Intel P010 in Intel.
#8055, comment 1, sample_YUV_intel10bits(P010LE).7z
I still do not know what pixel format to force to decode that sample :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
h
On Sun, Jun 06, 2021 at 04:50:41PM +0300, Valerii Zapodovnikov wrote:
> I am sorry, what???
If that is intended as a review comment, please compose
a english sentance which represents what you are trying to convey.
That way others know what you mean.
The goal of review is to improve code
Anyway
So did you fix your gmail account? Also, what happened to FATE? Broken?
BTW, I just logged in my nvidia account through apple id and that email was
marked as spam too, but because of my filter it was not send into spam!
Cool :)
___
ffmpeg-devel mailing l
вс, 6 июн. 2021 г., 18:35 Michael Niedermayer :
> On Sun, Jun 06, 2021 at 04:50:41PM +0300, Valerii Zapodovnikov wrote:
> > I am sorry, what???
>
> If that is intended as a review comment, please compose
> a english sentance which represents what you are trying to convey.
> That way others know wh
On Sun, 2021-06-06 at 22:56 +0800, Linjie Fu wrote:
> Hi Haihao,
>
> On Mon, May 17, 2021 at 11:30 AM Haihao Xiang wrote:
> >
> > ---
> > libavfilter/vf_vpp_qsv.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vp
> I hope it is the case since there was a problem with Intel P010 in Intel.
>
> #8055, comment 1, sample_YUV_intel10bits(P010LE).7z
The MSB 10bit is available for P010 in FFmpeg, however it is the LSB 10bit in
your file.
>
> I still do not know what pixel format to force to decode that sampl
So there are 4 formats two for le and 2 for be? Oogh. Do you know which one
is used for dshow?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-
Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-06-06 11:13:00)
>> Anton Khirnov:
>>> Memory ordering constraints other than the default (sequentially
>>> consistent) can behave in very unintuitive and unexpected ways, and so
>>> should be avoided unless there is a strong (typically performance)
On Sun, Jun 06, 2021 at 04:52:13PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-06-06 15:47:54)
> > Fixes: floating point division by 0
> > Fixes: Ticket 8269
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/vf_dctdnoiz.c | 3 +++
> > 1 file changed, 3 insert
Fixes: Ticket8312
Fixes: Ticket8321
Signed-off-by: Michael Niedermayer
---
libavcodec/elbg.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavcodec/elbg.c b/libavcodec/elbg.c
index b6049c938b..63659dda8b 100644
--- a/libavcodec/elbg.c
+++ b/libavcodec/elb
> So there are 4 formats two for le and 2 for be?
Yes, I think so.
> Oogh. Do you know which one
> is used for dshow?
I didn't use dshow, but I think it should be the format using MSB 10bit, see
https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#overv
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
libavutil/tests/lzo.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavutil/tests/lzo.c b/libavutil/tests/lzo.c
index 0147ab5c1d..a5655dbfc5 100644
--- a/libavutil/tests/lzo.c
+++ b/libavutil/tests/lzo.c
@@ -55,7 +55,6 @@ int mai
From: Matthieu Patou
Needed for HAVE_BIGENDIAN
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
libavutil/tests/audio_fifo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavutil/tests/audio_fifo.c b/libavutil/tests/audio_fifo.c
index e107166eb1..c9d6bfc7db 100644
--- a/libav
From: Matthieu Patou
The function name iszero() may collide with a function in glibc.
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
tests/checkasm/vp9dsp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
i
av_samples_fill_arrays() has been returning the minimum required buffer size
for a while now.
Signed-off-by: James Almer
---
libavutil/samplefmt.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavutil/samplefmt.h b/libavutil/samplefmt.h
index 8cd43ae856..f270199195 1
Signed-off-by: James Almer
---
libavutil/samplefmt.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavutil/samplefmt.c b/libavutil/samplefmt.c
index fc077f6444..c7428940e1 100644
--- a/libavutil/samplefmt.c
+++ b/libavutil/samplefmt.c
@@ -160,13 +160,20 @@ i
Failed to apply, what is the exact way you want the patch?
Kind regards,
Dennis Fleurbaaij
+31 (0) 6 54 21 5365
On Sat, Jun 5, 2021 at 6:12 PM Valerii Zapodovnikov
wrote:
> That did work, cool.
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/capucmebbw-rkt3mw5berkg3cqa+-akryfahclfc36mh2
This reverts commit d6d407d2d758b404af0ce6a8ff46bf164db020a1.
Hack not needed after a2b1dd0ce301450a47c972745a6b33c4c273aa5d.
Will fix #7480 and #8904.
This will include e.g. CODECS="hvc1.2.4.L123.B0" into m3u8.
Signed-off-by: Valerii Zapodovnikov
---
libavformat/dashenc.c | 6 +-
1 file cha
>From a distance, the patch looks like its in the correct format and
everything (generated by git format-patch, right?). Is it against
current HEAD? There may be a conflict
On Mon, Jun 7, 2021 at 8:02 AM Dennis Fleurbaaij
wrote:
>
> Failed to apply, what is the exact way you want the patch?
>
> K
46 matches
Mail list logo