On Fri, 2021-08-06 at 10:10 +0800, Haihao Xiang wrote:
> The SDK may insert picture timing SEI for hevc and the code to set mfx
> parameter has been added in qsvenc, however the corresponding option is
> missing in the hevc option array
> ---
> libavcodec/qsvenc_hevc.c | 1 +
> 1 file changed, 1 i
On Mon, 2021-04-12 at 09:47 +0800, Zhang yuankun wrote:
> This patch will fix following command:
> ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.264 \
> -vf 'scale_vaapi=w=7680:h=4096' -c:v vp9_vaapi output.ivf
>
> Max width of a vp9 tile is 4096. If the source frame > 4096, we need
Ping for this patch.
May be my understanding of this part is not correct enough,
Please tell me, thx
-Yu Yang
> 2021年12月20日 上午11:03，Yy 写道：
>
> Ping for this patch.
> -Yu Yang
>
>> 2021年12月15日 上午10:17，Yu Yang 写道：
>>
>> From: Yu Yang
>>
>> '*src' and '*avctx' point to the same memory. It is
> 2021年12月24日 上午11:43，zhilizhao(赵志立) 写道：
>
>
>
>> On Dec 23, 2021, at 3:10 PM, Steven Liu wrote:
>>
>> Try to get context from the moov atom when the hoov before moov atom,
>> because the streams info get a possible incorrect when there have both
>> hoov and moov atom. So add and ignore_hoo
On Fri, 2021-12-10 at 13:38 +0800, Wenbin Chen wrote:
> From: nyanmisaka
>
> mfxHDLPair was added to qsv, so modify qsv->opencl map function as well.
> Now the following commandline works:
>
> ffmpeg -v verbose -init_hw_device vaapi=va:/dev/dri/renderD128 \
> -init_hw_device qsv=qs@va -init_hw_d
From: Limin Wang
Note:
nvenc sdk will truncated user data unregistered SEI if the size > 503.
for example, hardcode its size to 504, trace_headers will report below error:
Invalid SEI message: payload_size too large (504 504 bytes).
Signed-off-by: Limin Wang
---
libavcodec/nvenc.c | 2 +-
On Fri, 2021-12-24 at 04:08 +0100, Andreas Rheinhardt wrote:
> Xiang, Haihao:
> > On Fri, 2021-12-24 at 03:20 +0100, Andreas Rheinhardt wrote:
> > > Xiang, Haihao:
> > > > On Fri, 2021-09-24 at 18:37 +0200, Andreas Rheinhardt wrote:
> > > > > Signed-off-by: Andreas Rheinhardt
> > > > > ---
> > > >
> On Dec 23, 2021, at 3:10 PM, Steven Liu wrote:
>
> Try to get context from the moov atom when the hoov before moov atom,
> because the streams info get a possible incorrect when there have both
> hoov and moov atom. So add and ignore_hoov option for try to get
> moov context by user.
>
> Si
There are no encoders for interlaced dct that support 4:4:4.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 0ac8886246..15b6669e46 100644
--
encode_mb() calls encode_mb_internal() three times, once
for each supported chroma format. The reason for this is
that some chroma format dependent parameters can then be
inlined as encode_mb_internal() is marked as av_always_inline.
Yet the most basic parameters based upon chroma format have
not b
This allows to remove the spurious dependencies of mpegvideo encoders
on error_resilience; some other components that do not use mpegvideo
to its fullest turned out to not need it either.
Adding a new CONFIG_EXTRA needs a reconfigure to take effect.
In order to force this a few unnecessary headers
This will allow to disable this code altogether when
all decoders are disabled.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile| 2 +-
libavcodec/mpegvideo.c | 582 +---
libavcodec/mpegvideo.h | 22 ++
libavcodec/mpegvideo_dec.c | 583
An AVCodecContext's private data is always allocated
in avcodec_open2() and calling avcodec_flush_buffers()
on an unopened AVCodecContext (or an already closed one)
is not allowed (and will crash before the decoder's flush
function is even called).
Signed-off-by: Andreas Rheinhardt
---
libavcode
It is only used for decoders.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 8b16b4ec0b..c0ba91e864 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvid
Xiang, Haihao:
> On Fri, 2021-12-24 at 03:20 +0100, Andreas Rheinhardt wrote:
>> Xiang, Haihao:
>>> On Fri, 2021-09-24 at 18:37 +0200, Andreas Rheinhardt wrote:
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tests/avcodec.c | 38 ++
1 file
On Fri, 2021-12-24 at 03:20 +0100, Andreas Rheinhardt wrote:
> Xiang, Haihao:
> > On Fri, 2021-09-24 at 18:37 +0200, Andreas Rheinhardt wrote:
> > > Signed-off-by: Andreas Rheinhardt
> > > ---
> > > libavcodec/tests/avcodec.c | 38 ++
> > > 1 file changed, 38 i
Xiang, Haihao:
> On Fri, 2021-09-24 at 18:37 +0200, Andreas Rheinhardt wrote:
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/tests/avcodec.c | 38 ++
>> 1 file changed, 38 insertions(+)
>>
>> diff --git a/libavcodec/tests/avcodec.c b/libavcodec/tests
On Fri, 2021-09-24 at 18:37 +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/tests/avcodec.c | 38 ++
> 1 file changed, 38 insertions(+)
>
> diff --git a/libavcodec/tests/avcodec.c b/libavcodec/tests/avcodec.c
> index 551
On Thu, Dec 23, 2021 at 10:15:27PM +0100, Michael Niedermayer wrote:
> Fixes: division by zero
> Fixes:
> 42814/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-4787014237552640
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-
> -Original Message-
> From: Soft Works
> Sent: Thursday, December 23, 2021 12:25 AM
> To: FFmpeg development discussions and patches
> Subject: GitHub Integration
>
> Hi,
>
> holidays are approaching and I got a little present for all of you
> even though it won’t be something for eve
Michael Niedermayer:
> Fixes: left shift of 255 by 24 places cannot be represented in type 'int'
> Fixes:
> 42766/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CDGRAPHICS_fuzzer-5142826105569280
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/project
Fixes: signed integer overflow: 2147483542 + 128 cannot be represented in type
'int'
Fixes:
42812/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-6344057861832704
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Mich
Fixes: left shift of 255 by 24 places cannot be represented in type 'int'
Fixes:
42766/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CDGRAPHICS_fuzzer-5142826105569280
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael N
Fixes: Timeout
Fixes:
42667/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TARGA_fuzzer-5619236075077632
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/targa.c | 11 ++-
1 file cha
We do not support this as we multiply by 1000
Fixes: signed integer overflow: -45318575073853696 * 1000 cannot be represented
in type 'long'
Fixes:
42804/clusterfuzz-testcase-minimized-ffmpeg_dem_LIVE_FLV_fuzzer-4630325425209344
Found-by: continuous fuzzing process
https://github.com/google/oss
Fixes: division by zero
Fixes:
42814/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-4787014237552640
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mvdec.c | 3 +++
1 file changed, 3 in
> -Original Message-
> From: ffmpeg-devel On Behalf Of Timo
> Rothenpieler
> Sent: Thursday, December 23, 2021 3:17 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] GitHub Integration
>
> On 23.12.2021 14:59, Tomas Härdin wrote:
> > This sounds like something that will cau
> -Original Message-
> From: ffmpeg-devel On Behalf Of Tomas
> Härdin
> Sent: Thursday, December 23, 2021 3:00 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] GitHub Integration
>
> ons 2021-12-22 klockan 23:24 + skrev Soft Works:
> > Hi,
> >
> > h
On 23.12.2021 14:59, Tomas Härdin wrote:
This sounds like something that will cause problems in the long run.
Github will inevitably be brought into the project's workflow. People
will start submitting tickets on Github rather than our trac. And so
on.
issues are disabled on Github.
Otherwise,
On Fri, 2021-11-26 at 19:29 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Anton
> > Khirnov
> > Sent: Friday, November 26, 2021 8:12 PM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH v4 1/1] avutils/hwcontext
ons 2021-12-22 klockan 23:24 + skrev Soft Works:
> Hi,
>
> holidays are approaching and I got a little present for all of you
> even though it won’t be something for everybody.
>
> A while ago I had committed to prepare a test setup for integrating
> GitHub in a similar way as the Git devel
On Mon, Dec 20, 2021 at 03:32:05PM +0100, Anton Khirnov wrote:
> 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
On Mon, Dec 20, 2021 at 12:57:00AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (same growing chunk is decoded to failure repeatedly)
> Fixes:
> 42582/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-6531195591065600
>
> Found-by: continuous fuzzing process
> https://github.com
On Thu, Dec 23, 2021 at 01:35:31AM -0600, rcombs wrote:
> Fixes P210/P410 cases introduced (and broken) in
> 88d804b7ffa20caab2e8e2809da974c41f7fd8fc
> ---
> libswscale/x86/swscale.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libswscale/x86/swscale.c b/libswscal
On Mon, Dec 20, 2021 at 04:37:35PM +0800, Shiyou Yin wrote:
>
>
> > 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
On Thu, Dec 23, 2021 at 12:54:58PM +0530, Gyan Doshi wrote:
>
>
> On 2021-12-23 03:04 am, Michael Niedermayer wrote:
> > On Wed, Dec 22, 2021 at 06:17:28PM +0530, Gyan Doshi wrote:
> > > ---
> > > libavformat/mov.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/lib
On Thu, Dec 16, 2021 at 06:12:14PM -0600, rcombs wrote:
> ---
> libswscale/output.c | 8 ++--
> libswscale/utils.c | 16
> libswscale/version.h | 2 +-
> 3 files changed, 15 insertions(+), 11 deletions(-)
breaks MIPS
TESTfilter-pixfmts-pad
--- src/tests/ref/fate/fil
It is partially possible if it is inlined whether
we deal with MPEG-1/2, because no_rounding is never set
for MPEG-1/2.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 73b91b459c..7626f97be5 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -2166,10 +2166,11 @@
This is possible if CONFIG_SMALL is not true.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 5e1a1522a2..73b91b459c 100644
--- a/libavcodec/mpegvideo.c
+++
Whether lowres is in use or not is inlined in
mpv_reconstruct_mb_internal(), so one can use the fact
that lowres is always zero during encoding to evaluate
the checks for whether one is encoding or not at compile-time
when one is in lowres mode.
Also reorder the main check to check for whether it i
It doesn't exist.
Signed-off-by: Andreas Rheinhardt
---
Apart from the mpeg4 decoder no mpegvideo decoder sets
bits_per_raw_sample. Should it be set (in ff_mpv_decode_init())?
libavcodec/mpegvideo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpegvideo.c b/lib
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_motion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mpegvideo_motion.c b/libavcodec/mpegvideo_motion.c
index 427bc96887..876a7375f8 100644
--- a/libavcodec/mpegvideo_motion.c
+++ b/libavcodec/mpegvi
Only the decoder ever used it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wmv2.c| 44
libavcodec/wmv2dec.c | 44
2 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/libavcodec/wmv2.c
The very first check in this if-else if-else if construct is
"if (s->encoding ||", i.e. in case of the WMV2 encoder the else
branches are never executed.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 43f27514b0..4c3e0fa8bf 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcode
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg12dec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index b75b2c9ea2..e7961c1498 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1790,13 +1790,
Signed-off-by: Andreas Rheinhardt
---
How could this ever happen? And why did it go unnoticed for so long?
(Btw: skip_count is nearly unused: It is only used to write its value
to the file in case this is the first pass of a two-pass encoding;
said value is read in the second pass, but not used.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg12dec.c | 1 +
libavcodec/mpeg12enc.c | 58 +-
libavcodec/mpegvideo.h | 9 ---
3 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index
It is only used here.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg12enc.c | 26 +-
libavcodec/mpegvideo.h | 1 -
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index abb0a4b29f..97df5523cc 100644
The a53_cc option is only useful and meaningful for MPEG-2,
yet it was accidentally added for all mpegvideo-based encoders.
This means that it is possible for a53_cc to be set for other
encoders as well.
This commit changes this and reroutes a53_cc to the dummy field
in MpegEncContext for all codec
It is a H.263 option.
Signed-off-by: Andreas Rheinhardt
---
There is unfortunately another call to update_mb_info()
that is not immediately followed (or preceded) by some ff_h263_*
function; otherwise one could have easily moved this to
a h263-specific place.
libavcodec/mpegvideo_enc.c | 6 +++-
Signed-off-by: Andreas Rheinhardt
---
libavcodec/speedhqenc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/speedhqenc.c b/libavcodec/speedhqenc.c
index 8f8b791164..967774931c 100644
--- a/libavcodec/speedhqenc.c
+++ b/libavcodec/speedhqenc.c
@@ -213,8 +2
On Tue, 2021-12-21 at 23:18 +0800, Zhong Li wrote:
> It is more clear and easily to detect the issues similar to commit
> 3857ecbe70e81cb6ad7a7f155c311e8522b93b3e
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsvenc.c | 38 +++---
> 1 file changed, 19 insertions(
On Thu, 2021-12-23 at 10:26 +0800, Wenbin Chen wrote:
> Fix #7830
> When we upload a frame that is not padded as MSDK requires, we create a
> new AVFrame to copy data. The frame's padding data is uninitialized so
> it brings run to run problem. For example, If we run the following
> command servera
From: Limin Wang
Most of user data unregistered SEIs are privated data which defined by user/
encoder. currently, the user data unregistered SEIs found in input are forwarded
as side-data to encoders directly, it'll cause the reencoded output including
some
useless UDU SEIs.
I prefer to add one
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul B
> Mahol
> Sent: Thursday, December 23, 2021 8:36 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] GitHub Integration
>
> Topic name is deeply misleading.
What would you say?
Bridge, Interfa
57 matches
Mail list logo
