Am 31.05.21 um 20:54 schrieb Lynne:
> May 31, 2021, 19:59 by nomis...@web.de:
>
>> Hi everyone. Back in March 2020 a set of patches for AC-4 support into
>> FFmpeg was posted on this
>> list. As these patches are not integrated in FFmpeg the HandBrake team was
>> considering if we should
>> add t
>On 5/31/21, 6:00 PM, "Przemysław Sobala" wrote:
>
>Could any maintainer take a look at that?
Pushed with minor indentation changes.
Thanks,
Karthick
>--
>Best regards
>Przemysław Sobala
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://f
Clang is more strict on the type of asm operands, float or double
type variable should use constraint 'f', integer variable should
use constraint 'r'.
Signed-off-by: Jin Bo
---
libavcodec/mips/constants.c | 89 +++--
libavcodec/mips/constants.h | 88 +++--
libavcodec/
This is used for dshow, though may be swapped endianness there.
Fixes #8454. fate-pixdesc-p010le and be will have to be updated.
---
libavcodec/raw.c | 3 +++
libavformat/nut.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index 079d5c5d10..7efc0156ca
Clang is more strict on the type of asm operands, float or double
type variable should use constraint 'f', integer variable should
use constraint 'r'.
Signed-off-by: Jin Bo
---
libavcodec/mips/constants.c | 89 +++--
libavcodec/mips/constants.h | 88 +++--
libavcodec/
Clang is more strict on the type of asm operands, float or double
type variable should use constraint 'f', integer variable should
use constraint 'r'.
Signed-off-by: Jin Bo
---
libavcodec/mips/constants.c | 89 +++--
libavcodec/mips/constants.h | 88 +++--
libavcodec/
> This patchset clean up scale_qsv and deinterlace_qsv filters, and take
> the two filters as the special cases of vpp_qsv, so vf_scale_qsv.c and
> vf_deinterlace_qsv.c can be deleted from FFmpeg. In addition, a few
> small features are added in this patchset.
> ---
>
Hi Zhong and Mark,
Could
On 2021-05-24 22:15, Andreas Rheinhardt wrote:
michael.di...@xaymar.com:
From: Michael Fabian 'Xaymar' Dirks
Adds "timestamp_precision" to the available options for Matroska muxing.
The option enables users and developers to change the precision of the
time stamps in the Matroska container up
May 31, 2021, 19:59 by nomis...@web.de:
> Hi everyone. Back in March 2020 a set of patches for AC-4 support into FFmpeg
> was posted on this
> list. As these patches are not integrated in FFmpeg the HandBrake team was
> considering if we should
> add them to the internal FFmpeg patches for HandB
---
libavutil/video_enc_params.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavutil/video_enc_params.c b/libavutil/video_enc_params.c
index b9cdafddbb..7d903af385 100644
--- a/libavutil/video_enc_params.c
+++ b/libavutil/video_enc_params.c
@@ -29,10 +29,14 @@
Plan to push tomorrow.
On 2021-05-29 14:34, Gyan Doshi wrote:
---
I faced the same issue as the poster in
https://lists.ffmpeg.org/pipermail/ffmpeg-user/2018-March/039038.html
After patch, start_time is correct as well as monotonicity of ts.
doc/demuxers.texi | 6 ++
libavformat/isom
Hi everyone. Back in March 2020 a set of patches for AC-4 support into FFmpeg
was posted on this
list. As these patches are not integrated in FFmpeg the HandBrake team was
considering if we should
add them to the internal FFmpeg patches for HandBrake. We are aware, that this
patches are WIP and
Am Do., 27. Mai 2021 um 17:08 Uhr schrieb James Almer :
>
> Signed-off-by: James Almer
> ---
> libavutil/mem.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/mem.h b/libavutil/mem.h
> index e21a1feaae..c876111afb 100644
> --- a/libavutil/mem.h
> +++ b/l
Valerii Zapodovnikov wrote:
>This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
>But I also added some clarifications so that nobody mixes primaries
>with matrix again. SMPTE 240 and 170 primaires are the same, while
>matrix coeff. are different, because 240 is derived from 170's new
>p
It's useful for test client which pass streamid to ffmpeg/ffplay.
For example, use ffmpeg to test streamid support in VLC:
./ffmpeg -v info -re -i foo.mp4 -c copy -f mpegts -mode listener
srt://127.0.0.1:9000
./vlc srt://127.0.0.1:9000?streamid=foobar
---
libavformat/libsrt.c | 22 +--
"avctx->bits_per_raw_sample" always returns 0.
Tested with 24 Bit ALAC. The result is bit-perfect.
Fix #7287.
Co-authored-by: Davis
---
libavcodec/audiotoolboxdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
ind
Co-authored-by: Davis
---
libavcodec/audiotoolboxdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index cbd381ef12..c7e1760645 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -303,
On 5/31/2021 5:09 AM, Anton Khirnov wrote:
Quoting James Almer (2021-05-23 00:09:02)
This is in preparation for the following commit.
Signed-off-by: James Almer
---
libavutil/mem.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/libavutil/mem.c b/libav
On 5/24/2021 5:43 PM, Michael Niedermayer wrote:
This should fix some minor race condition
Untested (no testcase, the flag is not tested by fate)
Signed-off-by: Michael Niedermayer
---
libavcodec/error_resilience.c | 3 +++
libavcodec/h264dec.c | 5 -
2 files changed, 3 inserti
On 5/31/2021 6:02 AM, Anton Khirnov wrote:
Quoting Michael Niedermayer (2021-05-24 22:43:55)
This should fix some minor race condition
Untested (no testcase, the flag is not tested by fate)
How will this fix the race? It is still modifying a shared struct.
s->cur_pic.f->decode_error_flags is
This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
But I also added some clarifications so that nobody mixes primaries
with matrix again. SMPTE 240 and 170 primaires are the same, while
matrix coeff. are different, because 240 is derived from 170's new
primaries and white point while 170
Could any maintainer take a look at that?
--
Best regards
Przemysław Sobala
___
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
Will update (and fix another typo I missed, "primairies"). BTW, that is
what H.273 says!
"ITU-T H.273 (2016) was published as a twin text technically aligned with
ISO/IEC 23001-8:2016 and its Amendment 1. After ISO/IEC 23001-8:2016 was
split into three parts in 2019 and renumbered as ISO/IEC 23091
On 5/31/2021 7:03 AM, Anton Khirnov wrote:
Include only the headers that are actually needed.
---
libavcodec/cbs.c | 1 +
libavcodec/cbs.h | 7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index bbfafb6530..8d50ea1432 100644
--- a/
On 5/31/2021 6:26 AM, Anton Khirnov wrote:
There seems to be no compelling reason for it to be inline.
---
libavutil/mem.c | 18 ++
libavutil/mem.h | 19 +--
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
inde
Valerii Zapodovnikov wrote:
- * These values match the ones defined by ISO/IEC 23001-8_2013 § 7.1.
+ * These values match the ones defined by ISO/IEC
23001-8_2013 § 7.1 and ITU-T H.273.
FYI: ISO/IEC 23001-8:2016 has been withdrawn. Its information
can be found now in ISO/IEC 23091-1:2018, I
This mostly reverts 785bfb1d7bb8de567c3aac1d9cc369b55ac9fb7b.
But I also added some clarifications so that nobody mixes primaries
with matrix again. SMPTE 240 and 170 primaires are the same, while
matrix coeff. are different, because 240 is derived from 170's new
primaries and white point while 170
---
tools/uncoded_frame.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/uncoded_frame.c b/tools/uncoded_frame.c
index 3f850d344d..f441d3fbdc 100644
--- a/tools/uncoded_frame.c
+++ b/tools/uncoded_frame.c
@@ -6,6 +6,7 @@
#include "libavfilter/avfilter.h"
#include "libavfilter/buffersi
---
doc/APIchanges| 3 ++-
libavcodec/avcodec.h | 8
libavcodec/codec_id.h | 9 +
3 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 731d55f10d..71095ac78e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -16,7 +16,8 @
Do not rely on including it indirectly through get_bits.h->avcodec.h
---
Needed before 12/25, somehow missed it.
---
libavcodec/hevc_sei.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
index c67dbceb6c..4b6bfddeb9 100644
--- a/libavcodec/hevc_s
Include only the headers that are actually needed.
---
libavcodec/cbs.c | 1 +
libavcodec/cbs.h | 7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index bbfafb6530..8d50ea1432 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -25,6
Hi !
Kind reminder.
Regards,
Mehdi
On Tue, May 11, 2021 at 4:07 PM Mehdi Sabwat wrote:
> Hi!
>
> Ping, can someone please review?
>
> Thanks,
> Regards
>
> On Tue, Apr 27, 2021 at 1:57 AM Mehdi Sabwat
> wrote:
>
>> From: Mehdi Sabwat
>>
>> Fix configure test to allow it to have the right suf
There seems to be no compelling reason for it to be inline.
---
libavutil/mem.c | 18 ++
libavutil/mem.h | 19 +--
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index a52d33d4a6..063635fb22 100644
--- a/libavutil/
Quoting Zhao Zhili (2021-05-27 17:34:55)
> It's useful for test client which pass streamid to ffmpeg/ffplay.
> For example, use ffmpeg to test streamid support in VLC:
> ./ffmpeg -v info -re -i foo.mp4 -c copy -f mpegts -mode listener
> srt://127.0.0.1:9000
> ./vlc srt://127.0.0.1:9000?streamid=fo
Quoting Michael Niedermayer (2021-05-24 22:43:55)
> This should fix some minor race condition
> Untested (no testcase, the flag is not tested by fate)
How will this fix the race? It is still modifying a shared struct.
--
Anton Khirnov
___
ffmpeg-devel
Anton Khirnov (12021-05-31):
> This is starting to look way too ugly for something exposed in a public
> header.
The fact it resides in a public header is just a limitation of C's
linking model. The code itself is internal source, users should not look
at it.
Regards,
--
Nicolas George
sign
Quoting James Almer (2021-05-27 17:06:57)
> Signed-off-by: James Almer
> ---
> libavutil/mem.h | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/mem.h b/libavutil/mem.h
> index e21a1feaae..c876111afb 100644
> --- a/libavutil/mem.h
> +++ b/libavutil/mem.h
Quoting James Almer (2021-05-23 00:09:02)
> This is in preparation for the following commit.
>
> Signed-off-by: James Almer
> ---
> libavutil/mem.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index fa227f5e12..c
---
libswscale/swscale.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index cc3700c704..74da1bf42c 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -866,6 +866,7 @@ int attribute_align_arg sws_scale(struct SwsCo
Reindent after previous commit, rewrap long lines.
---
libswscale/swscale.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 867995c9c7..7dbe0f59c5 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -847
Reindent after previous commit, split long lines.
---
libswscale/swscale.c | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 876dc05442..72285c3547 100644
--- a/libswscale/swscale.c
+++ b/li
Call the scaler function directly rather than through a function
pointer. Drop the now-unused return value from ff_getSwsFunc() and
rename the function to reflect its new role.
This will be useful in the following commits, where it will become
important that the amount of output is different for s
Also, return an error code on failure rather than 0.
---
libswscale/swscale.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 74da1bf42c..73bc0c5617 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -912,1
---
libswscale/swscale.c | 29 ++---
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 72285c3547..867995c9c7 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -842,6 +842,22 @@ static int scale_g
Currently existing sws_scale() accepts as input a user-determined slice
of input data and produces an indeterminate number of output lines.
Since the calling code does not know the amount of output, it cannot
easily parallelize scaling by calling sws_scale() simultaneously on
different parts of the
---
libavfilter/vf_scale.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 37899de6a1..cdd7c4da0d 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -658,6 +658,7 @@ static int scale_frame
It does not interact in any way with the code setting up the image
pointers/strides, so it should not be intermixed with it.
---
libswscale/swscale.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 2d6ed95cfb..b9b2826911
---
libavfilter/vf_scale.c | 182 +++--
1 file changed, 141 insertions(+), 41 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index cdd7c4da0d..87317393bd 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -106,8 +106,
---
libavfilter/vf_scale.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 759499395f..8516919556 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -328,16 +328,24 @@ static av_c
---
libswscale/swscale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 73bc0c5617..270adcc072 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -918,7 +918,7 @@ int attribute_align_arg sws_scale(struct SwsContext
Place it right after the input parameter validation. There is no point
in performing any setup if the sws_scale() call won't do anything.
---
libswscale/swscale.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 270adcc07
Not the input link. The function does nothing with the link except
extract the private context from it.
---
libavfilter/vf_scale.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 8516919556..37899de6a1 100644
---
---
libswscale/swscale.c | 20
libswscale/swscale_internal.h | 6 ++
libswscale/utils.c| 3 +++
3 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 37c7cf60dd..2db40a6807 100644
--- a/libs
It does not interact in any way with the code setting up the image
pointers/strides, so it should not be intermixed with it.
---
libswscale/swscale.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index b9b2826911..3b03fd16dd 1
---
libswscale/swscale.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 7dbe0f59c5..1cf89e4684 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -883,11 +883,6 @@ int attribute_align_arg sws_scale(stru
Also, fail with an error code rather than 0.
---
libswscale/swscale.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 1cf89e4684..37c7cf60dd 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -890
Makes it more clear that resetting it does not interact with the scaling
code that it is currently intermixed with.
---
libswscale/swscale.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 4b577ef263..cc3700c704 100644
-
---
libswscale/swscale.c | 53 +---
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 9743c56295..876dc05442 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -811,6 +811,34 @@ sta
---
libswscale/swscale.c | 100 +--
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 7690f81450..05e716dcc9 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -738,34 +738,34 @@ st
---
libswscale/swscale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 05e716dcc9..9743c56295 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -833,7 +833,7 @@ int attribute_align_arg sws_scale(struct SwsContext
---
libswscale/swscale.c | 150 ++-
1 file changed, 77 insertions(+), 73 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 6b73c71e41..7690f81450 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -736,6 +736,81 @@ sta
There used to be more code inside them, but it was removed in
6de58b49032a206985602effec91e5e46c886ea2.
---
libswscale/swscale.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 12160a169a..6b73c71e41 100644
--- a/libswscal
Quoting Michael Niedermayer (2021-05-28 22:15:51)
> Fixes: Ticket8003
> Fixes: CVE-2020-20453
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/aacenc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> index aa223cf25
fix problem when set x to odd number in nv12 by cuda,
test step:
1. ffmpeg -f lavfi testsrc2=s=176x144 -pix_fmt nv12 -t 1 output_overlay.yuv
1. ffmpeg -f lavfi testsrc2=s=352x288 -pix_fmt nv12 -t 1 output_main.yuv
before this patch:
overlay_cuda=x=0:y=0 will right,
overlay_cuda=x=3:y=0 will wrong,
Quoting James Almer (2021-05-24 19:20:19)
> On 7/7/2019 5:15 PM, Michael Niedermayer wrote:
> > On Fri, Jun 21, 2019 at 07:15:17AM -0700, Amir Pauker wrote:
> >> set AVFrame decode_error_flags in case h->slice_ctx->er.error_occurred is
> >> set
> >> after the call to ff_h264_execute_decode_slices.
Am 2021-05-27 22:38, Stephen Hutchinson wrote:
The change seems okay, but the comment and commit message need to
explain what's going on better, because the confusion that's erupted
over this seems to derive from the rather poor way the AviSynth
documentation describes the difference between fie
66 matches
Mail list logo