Signed-off-by: Wenlong Ding
---
libavfilter/dnn/dnn_backend_native_layer_mathunary.c | 4
libavfilter/dnn/dnn_backend_native_layer_mathunary.h | 1 +
tools/python/convert_from_tensorflow.py | 3 ++-
tools/python/convert_header.py | 2 +-
4 files changed, 8
Signed-off-by: Wenlong Ding
---
tests/dnn/dnn-layer-mathunary-test.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/dnn/dnn-layer-mathunary-test.c
b/tests/dnn/dnn-layer-mathunary-test.c
index a8c5ab0224..0d81f582f9 100644
--- a/tests/dnn/dnn-layer-mathunary-test.c
+++ b/tests/dnn/
Ping.
чт, 11 мар. 2021 г. в 10:14, Вадим Бездушный :
> Ping.
>
> вт, 9 мар. 2021 г. в 00:05, Вадим Бездушный :
>
>> Ping.
>>
>> This change is quite simple and should be quick to review. Feel free to
>> ask any questions
>>
>> On Mon, 1 Mar 2021, 14:54 Vadym Bezdushnyi,
>> wrote:
>>
>>> Add an a
Hi everyone!
We're planning on using FFmpeg's segment muxer [1] to split radio
recordings for archival preservation usage (*).
Works pretty well! (except for some warnings, but that's another issue).
Would it be possible to have a "segment_overlap" option, to add some
time before/after each
On Wed, Feb 24, 2021 at 9:44 AM Fei Wang wrote:
>
> The option allow user to set diffenent scaling mode from
> auto/low-power/high-quality.
>
> More details:
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#mfxExtVPPScaling
>
> Signed-off-by: Fei Wang
> ---
> libavfi
Hello everyone! :)
FFmpeg's segment muxer [1] is very useful and very configurable already,
and I was wondering if it would be possible to add the possibility for
splitting based on something like information given in an additional
(text)file?
Each line of the textfile would contain the foll
> I disagree, if I use 180 hfov and 180 vfov it should not have extra areas
but only half of previous input.
Not sure I follow - the ih_fov and vh_fov refer to the input (i.e. the
fisheye image). If you wanted to restrict the FoV of the output, surely the
way to do that would be to implement and u
On 3/22/2021 3:35 AM, Andreas Rheinhardt wrote:
88d80cb97528d52dac3178cf5393d6095eca6200 changed the type of
PutBitContext.BitBuf to uint64_t; it used to be an uint32_t.
While said structure is not public, it is nevertheless used by
certain avpriv functions and therefore crosses library boundarie
This reverts commit cea7c19cda0ea1630ae1de8c102ab14231b9db10.
Until an API is added to make index_entries public in a proper way, we should
keep this here.
Signed-off-by: James Almer
---
Some library users looked at these fields since they are apparently pretty
useful, so at least for 4.4 we sho
On 3/22/2021 11:48 AM, James Almer wrote:
This reverts commit cea7c19cda0ea1630ae1de8c102ab14231b9db10.
Until an API is added to make index_entries public in a proper way, we should
keep this here.
Signed-off-by: James Almer
---
Some library users looked at these fields since they are apparent
On Mon, Mar 22, 2021 at 1:35 PM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:
> > I disagree, if I use 180 hfov and 180 vfov it should not have extra
> areas but only half of previous input.
>
> Not sure I follow - the ih_fov and vh_fov refer to the input (i.e. the
> fisheye image).
This is my first ffmpeg patch, so I am not sure what else I need to do to
get it reviewed and submitted. Could someone please let me know? Thanks!
On Wed, Mar 17, 2021 at 5:28 PM Alok Priyadarshi wrote:
> This produces true wallclock time at rtp source instead of the
> local wallclock time at rt
On 3/17/2021 9:28 PM, Alok Priyadarshi wrote:
This produces true wallclock time at rtp source instead of the
local wallclock time at rtp client.
---
libavformat/internal.h | 8
libavformat/rtpdec.c | 10 ++
libavformat/utils.c| 9 +
3 files changed, 27 insert
James Almer:
> On 3/22/2021 3:35 AM, Andreas Rheinhardt wrote:
>> 88d80cb97528d52dac3178cf5393d6095eca6200 changed the type of
>> PutBitContext.BitBuf to uint64_t; it used to be an uint32_t.
>> While said structure is not public, it is nevertheless used by
>> certain avpriv functions and therefore
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/s337m.c | 13 ++---
> 1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/libavformat/s337m.c b/libavformat/s337m.c
> index 9e3c8ed1ba..9d1b52eb61 100644
> --- a/libavformat/s337m.c
> +++ b/libavfor
Andreas Rheinhardt:
> Originally added in 12f996edfab67b65af0ff1ee829f9eeabb025b0f
> behind #if 0; aebb56e1844d61965c97e95534c3ae0da69df028 then
> removed the #if and replaced it by using av_dlog. Then commit
> 1a3eb042c704dea190c644def5b32c9cee8832b8 replaced this with av_log
> at trace level. Yet
Andreas Rheinhardt:
> Currently, ff_read_packet() sometimes forwards the return value of
> AVInputFormat.read_packet() (which should be zero on success, but isn't
> for all demuxers) and sometimes it overwrites this with zero.
> Furthermore, it uses two variables, one for the read_packet return val
Andreas Rheinhardt:
> This makes av_read_frame() return packets with proper timestamps.
> As a result, seeking now works in combination with streamcopy.
> A FATE-test for this has been added.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/s337m.c| 1 +
> tests/fate/demux.mak
Andreas Rheinhardt:
> It takes care of zeroing padding (which has been forgotten here).
> Also rename the size variable to indicate that this is not the size
> of the current slice.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/svq3.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 del
Fixes: crash
Fixes: check_pkt.mp4
Found-by: Rafael Dutra
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_slice.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 14b945756b..910d8b8848 100644
--- a/libavcodec
Signed-off-by: Michael Niedermayer
---
tools/target_dem_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dem_fuzzer.c b/tools/target_dem_fuzzer.c
index af1840b359..90b7acefe2 100644
--- a/tools/target_dem_fuzzer.c
+++ b/tools/target_dem_fuzzer.c
@@ -189,6 +189,7 @@ int LL
Fixes: out of array access
Fixes:
31201/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-4627865612189696.fuzz
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mpegvideo.c | 7 ++
Fixes: OOM
Fixes:
31220/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6033383962574848
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 d
Fixes: Timeout
Fixes:
31464/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-4843965653319680
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed,
Fixes: null pointer dereference
Fixes: h264_slice_header_init.mp4
Found-by: Rafael Dutra
Tested-by: Rafael Dutra
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_slice.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 910d8
On Mon, Mar 22, 2021 at 10:05 PM Michael Niedermayer
wrote:
>
> Fixes: crash
> Fixes: check_pkt.mp4
>
> Found-by: Rafael Dutra
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_slice.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/h264_slice
On 3/22/2021 5:58 PM, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer
---
tools/target_dem_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dem_fuzzer.c b/tools/target_dem_fuzzer.c
index af1840b359..90b7acefe2 100644
--- a/tools/target_dem_fuzzer.c
+++ b
As discussed during the last developer meeting, I am in need of new hardware to
work on Vulkan filtering, hwcontext, AV1 VAAPI decoding, new assembly and
general development on FFmpeg and projects involving the FFmpeg libraries.
I was requested to post what I'd like on the mailing list for discuss
On Mon, Mar 22, 2021 at 10:12:47PM +0100, Hendrik Leppkes wrote:
> On Mon, Mar 22, 2021 at 10:05 PM Michael Niedermayer
> wrote:
> >
> > Fixes: crash
> > Fixes: check_pkt.mp4
> >
> > Found-by: Rafael Dutra
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/h264_slice.c | 5 ++---
> >
---
libavcodec/qsv.c | 27 +++
libavcodec/qsv_internal.h | 8 +++-
libavcodec/qsvdec.c | 8 +---
3 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 6e3154e1a3..879e109092 100644
--- a/libavcodec
When AV_CODEC_EXPORT_DATA_FILM_GRAIN is present, AV1 decoder should
disable film grain application and export the corresponding side data
---
libavcodec/qsv_internal.h | 3 ++
libavcodec/qsvdec.c | 88 +++
2 files changed, 91 insertions(+)
diff --git a/l
On 3/19/2021 2:58 AM, Andreas Rheinhardt wrote:
One can simply reuse AVFormatInternal.parse_pkt instead.
Signed-off-by: Andreas Rheinhardt
---
libavformat/internal.h | 12 ++--
libavformat/utils.c| 29 ++---
2 files changed, 20 insertions(+), 21 deletions
On Mon, 2021-03-22 at 14:27 +0800, wenbin.c...@intel.com wrote:
> From: "Chen,Wenbin"
>
> FFmpeg-qsv decoder reinit codec when width and height change, but there
> are not only resolution change need to reinit codec. I change it to use
> return value from DecodeFrameAsync() to decide whether deco
What exactly is your definition of fisheye?
The definition I'm working with is the equidistant fisheye projection as
described here: https://wiki.panotools.org/Fisheye_Projection, i.e. r = f *
theta
That mapping works for any theta, and you can have a circular image with a
field of view of up to
On Mon, 2021-03-22 at 14:31 +0800, wenbin.c...@intel.com wrote:
> From: "Chen,Wenbin"
>
> MSDK recognizes both yuv420p10 and yuv420p9 as MFX_FOURCC_P010, but param
> are different. When decode yuv420p9 video, ffmpeg-qsv will use
> yuv420p10le to configure surface which is different with param fro
On Mon, 2021-03-22 at 14:35 +0800, wenbin.c...@intel.com wrote:
> From: "Chen,Wenbin"
>
> ChromaForamt for mjpeg-qsv is always set to yuv420, and this will be
> wrong when encode other pixel format (for example yuyv422). I change
> this assignment to be adaptive to pix_fmt.
>
> Signed-off-by: We
---
libavformat/rtpenc_mpegts.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
index 28522f8913..d501d09590 100644
--- a/libavformat/rtpenc_mpegts.c
+++ b/libavformat/rtpenc_mpegts.c
@@ -20,6 +2
---
libavformat/rtpenc_mpegts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
index d501d09590..22881461e4 100644
--- a/libavformat/rtpenc_mpegts.c
+++ b/libavformat/rtpenc_mpegts.c
@@ -77,6 +77,7 @@ static int rtp_mpegts_write_header
---
libavformat/rtpenc_mpegts.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
index 22881461e4..f7ee5a4448 100644
--- a/libavformat/rtpenc_mpegts.c
+++ b/libavformat/rtpenc_mpegts.c
@@ -29,6 +29,7 @@ typedef stru
On Mon, 2021-03-22 at 14:43 +0800, wenbin.c...@intel.com wrote:
> From: "Chen,Wenbin"
>
> qsvvpp align the width and height with 16, and that may lead to error.
> For example, when we use qsvvpp to resize frame to 1080p, qsvvpp will
> align frame to 1088 which is different from the height of
> en
On Tue, Mar 23, 2021 at 5:00 AM Daniel Playfair Cal <
daniel.playfair@gmail.com> wrote:
> What exactly is your definition of fisheye?
>
Take look at source code. I do not see how your definition matches one in
source code.
>
> The definition I'm working with is the equidistant fisheye proje
> -Original Message-
> From: Xiang, Haihao
> Sent: Tuesday, March 23, 2021 11:49 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Chen, Wenbin
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec: reinit decoder
> according to decode() return value
>
> On Mon, 2021-03-22 at 14:27 +0800, wenbi
Do you agree with my definition or not? And which code are you referring to
- the master branch or my patches?
I'd like to get these patches to a point where they can be applied, but
it's going to be difficult if we can't agree on the goal.
On Tue, Mar 23, 2021 at 5:15 PM Paul B Mahol wrote:
>
> -Original Message-
> From: Xiang, Haihao
> Sent: Tuesday, March 23, 2021 12:10 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Chen, Wenbin
> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec: use the param from
> decodeHeader to configure surface
>
> On Mon, 2021-03-22 at 14:31 +0800, we
44 matches
Mail list logo
