On 16-10-2019 01:21 AM, Gyan wrote:
On 16-10-2019 01:11 AM, Andriy Gelman wrote:
On Sun, 06. Oct 01:49, Andriy Gelman wrote:
From: Andriy Gelman
The pointer fp after the call to chromaprint_get_raw_fingerpoint()
points to an array of uint32_t whereas the current code assumed just
a
so, we can make a filter more general to accept different network
models, by adding a data type convertion after getting data from network.
After we add dt field into struct DNNData, it becomes the same as
DNNInputData, so merge them with one struct: DNNData.
Signed-off-by: Guo, Yejun
---
This filter accepts all the dnn networks which do image processing
on RGB-based format. Currently, frame with formats rgb24 and bgr24
are supported. Other formats such as gray and YUV can be supported
in separated filters. The dnn network can accept RGB data in float32
or uint8 format. And the dnn
Unlike other tf.*.conv2d layers, tf.nn.conv2d does not create many
nodes (within a scope) in the graph, it just acts like other layers.
tf.nn.conv2d only creates one node in the graph, and no internal
nodes such as 'kernel' are created.
The format of native model file is also changed, a flag
to support dnn networks more general, we need to know the input info
of the dnn model.
background:
The data type of dnn model's input could be float32, uint8 or fp16, etc.
And the w/h of input image could be fixed or variable.
Signed-off-by: Guo, Yejun
---
libavfilter/dnn/dnn_backend_native.c
From: Andriy Gelman
Test hevc-mp4annexb-pps:
Test contains 64 PPS that are signalled in extradata.
Different PPS are referenced by the VCL nal units during the mp4 to
annexb conversion.
Test hevc-mp4annexb-sps:
Access units contain PPS that reference different cached SPS nal
units.
---
From: Andriy Gelman
Since the original extradata is in HVCC format, there is no need to
segment the output extradata into nal units.
---
libavcodec/hevc_mp4toannexb_bsf.c | 66 ---
1 file changed, 34 insertions(+), 32 deletions(-)
diff --git
From: Andriy Gelman
Fixes #7799
Currently, the mp4toannexb filter always inserts the same extradata at
the start of the first IRAP unit. As in ticket #7799, this can lead to
decoding errors if modified parameter sets are signalled in-band.
Decoding errors/visual artifacts are also present in
Changes in v6:
- Store parameter sets with startcode
- Use helper functions to reset index in GetBitContext
- Replace get_ue_golomb_long by get_ue_golomb
--
Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Andreas,
On Thu, 01. Jan 00:00, Andreas Rheinhardt wrote:
> Andriy Gelman:
> > From: Andriy Gelman
> >
> > Fixes #7799
> >
> > Currently, the mp4toannexb filter always inserts the same extradata at
> > the start of the first IRAP unit. As in ticket #7799, this can lead to
> > decoding errors
Signed-off-by: Andreas Rheinhardt
---
Resending because of a merge conflict with version 2 of the memleak
patch I just sent.
libavformat/matroskaenc.c | 41 ++-
1 file changed, 15 insertions(+), 26 deletions(-)
diff --git a/libavformat/matroskaenc.c
instead of replicating its behaviour.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 3f9bd3445d..b924a64b03 100644
---
The Matroska muxer up until now leaked memory in two scenarios:
1. If an error happened during writing the trailer, as
mkv_write_trailer() returned early without cleaning up.
2. If mkv_write_header() indicated success despite an error in the
underlying AVIOContext. In this case
On Tue, Oct 15, 2019 at 04:41:36PM +0200, Michael Niedermayer wrote:
> On Mon, Oct 14, 2019 at 06:27:07PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > tests/fate/filter-video.mak | 3 ++
> >
From: Limin Wang
Signed-off-by: Limin Wang
---
tests/fate/filter-video.mak | 3 ++
tests/ref/fate/filter-unsharp-yuv420p10 | 55 +
2 files changed, 58 insertions(+)
create mode 100644 tests/ref/fate/filter-unsharp-yuv420p10
diff --git
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Zhao Zhili
> Sent: Wednesday, October 16, 2019 12:21 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhao Zhili
> Subject: [FFmpeg-devel] [PATCH 2/2] FATE/dnn: add .gitignore
>
> ---
>
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Pedro Arthur
> Sent: Wednesday, October 16, 2019 6:01 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V3 3/3] avfilter/dnn: unify the layer load
>
On Tue, Oct 15, 2019, at 3:06 PM, Mark Niebur wrote:
> This should be fixed already on master? I checked a few hours ago and was
> able to repro.
Yes. Paul made the commit less than 10 minutes ago.
Fixes: Ticket8152
Signed-off-by: Michael Niedermayer
---
libavformat/flvenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index fb1dede7ae..eb52b473b8 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -928,6 +928,12 @@
This should be fixed already on master? I checked a few hours ago and was
able to repro.
On Tue, Oct 15, 2019, 5:03 PM Paul B Mahol wrote:
> Should be fixed.
>
> On 10/16/19, Mark Niebur wrote:
> > I'm sorry for not specifying. In the case that data is not ready from
> > ctx->inputs[1] after
ISO/IEC 14496-3:2005(E): "Each entry of P_one[ ][ ] is in the range of 1 to
128, corresponding to a probability of 1/256 to 128/256 of the next error bit
(bit E, See Figure 10.5)..."
Fixes: Timeout (42sec ->1sec)
Fixes:
Fixes: Timeout (too long -> 42sec)
Fixes:
18181/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DST_fuzzer-5736646250594304
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/dstdec.c | 8
Should be fixed.
On 10/16/19, Mark Niebur wrote:
> I'm sorry for not specifying. In the case that data is not ready from
> ctx->inputs[1] after crossfade is over, ff_inlink_consume_frame will return
> 0 and not set the frame pointer. If ff_outlink_frame_wanted is still 0, the
> function will
I'm sorry for not specifying. In the case that data is not ready from
ctx->inputs[1] after crossfade is over, ff_inlink_consume_frame will return 0
and not set the frame pointer. If ff_outlink_frame_wanted is still 0, the
function will fall through to the code filtering the frame, although
On 10/15/19, Mark Niebur wrote:
> I just checked out master and I see the fix you mentioned. This does not
> completely fix acrossfade for me. I also had to apply the following patch:
What this patch fixes?
> diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
> index
Em ter, 15 de out de 2019 às 02:29, Guo, Yejun
escreveu:
>
>
> > -Original Message-
> > From: Guo, Yejun
> > Sent: Wednesday, October 09, 2019 10:08 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Guo, Yejun
> > Subject: [PATCH V3 3/3] avfilter/dnn: unify the layer load function in
> native
I just checked out master and I see the fix you mentioned. This does not
completely fix acrossfade for me. I also had to apply the following patch:
diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
index 195fb65..446aa0a 100644
--- a/libavfilter/af_afade.c
+++
Would this be on master or some other branch?
> On Oct 15, 2019, at 2:26 PM, Paul B Mahol wrote:
>
> On 10/15/19, Mark Niebur wrote:
>> Hello,
>> I'm trying to debug an issue I'm seeing where the filter "acrossfade"
>> produces a segfault. This seemingly only happens in docker containers, and
On Sat, Oct 05, 2019 at 11:41:03PM +0200, Michael Niedermayer wrote:
> Fixes:
> 17886/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5728165124636672
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael
On 10/15/19, Mark Niebur wrote:
> Hello,
> I'm trying to debug an issue I'm seeing where the filter "acrossfade"
> produces a segfault. This seemingly only happens in docker containers, and
> I am seeing it when running a rather large filter chain. I'm trying to get
> to the bottom of it, but
Hello,
I'm trying to debug an issue I'm seeing where the filter "acrossfade" produces
a segfault. This seemingly only happens in docker containers, and I am seeing
it when running a rather large filter chain. I'm trying to get to the bottom
of it, but it would be really helpful to understand
On 16-10-2019 01:11 AM, Andriy Gelman wrote:
On Sun, 06. Oct 01:49, Andriy Gelman wrote:
From: Andriy Gelman
The pointer fp after the call to chromaprint_get_raw_fingerpoint() points to an
array of uint32_t whereas the current code assumed just a char stream. Thus
when writing the raw
On Sun, 06. Oct 01:49, Andriy Gelman wrote:
> From: Andriy Gelman
>
> The pointer fp after the call to chromaprint_get_raw_fingerpoint() points to
> an array of uint32_t whereas the current code assumed just a char stream.
> Thus when writing the raw fingerprint, the output would be truncated
On 10/15/19, James Almer wrote:
> On 10/15/2019 2:36 PM, Paul B Mahol wrote:
>> Fixes #8281
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/frame_thread_encoder.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/frame_thread_encoder.c
>>
On 10/15/2019 2:36 PM, Paul B Mahol wrote:
> Fixes #8281
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/frame_thread_encoder.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/frame_thread_encoder.c
> b/libavcodec/frame_thread_encoder.c
> index
Fixes #8281
Signed-off-by: Paul B Mahol
---
libavcodec/frame_thread_encoder.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/frame_thread_encoder.c
b/libavcodec/frame_thread_encoder.c
index 949bc69f81..ffee242b76 100644
--- a/libavcodec/frame_thread_encoder.c
---
How about add AV_FRAME_DATA_NONE to AVFrameSideDataType?
libavfilter/f_sidedata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/f_sidedata.c b/libavfilter/f_sidedata.c
index 381da5a052..4210dcac4c 100644
--- a/libavfilter/f_sidedata.c
+++
Signed-off-by: Paul B Mahol
---
libavfilter/atadenoise.h | 36 +++
libavfilter/vf_atadenoise.c | 16 +--
libavfilter/x86/Makefile | 2 +
libavfilter/x86/vf_atadenoise.asm| 150 +++
libavfilter/x86/vf_atadenoise_init.c | 40
---
tests/dnn/.gitignore | 4
1 file changed, 4 insertions(+)
create mode 100644 tests/dnn/.gitignore
diff --git a/tests/dnn/.gitignore b/tests/dnn/.gitignore
new file mode 100644
index 00..5eedaaa56d
--- /dev/null
+++ b/tests/dnn/.gitignore
@@ -0,0 +1,4 @@
+/dnn-layer-conv2d-test
---
libavcodec/tests/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/tests/.gitignore b/libavcodec/tests/.gitignore
index 56ddb2cbeb..a01a700e2d 100644
--- a/libavcodec/tests/.gitignore
+++ b/libavcodec/tests/.gitignore
@@ -9,6 +9,7 @@
/fft-fixed32
/golomb
On 10/15/2019 12:00 PM, Paul B Mahol wrote:
> LGTM
>
> On 10/15/19, James Almer wrote:
>> Fixes ticket #8273.
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/latmenc.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/latmenc.c
On 10/15/2019 12:55 PM, Paul B Mahol wrote:
> On 10/15/19, James Almer wrote:
>> On 10/15/2019 12:21 PM, Paul B Mahol wrote:
>>> +;--
>>> +; void ff_filter_row(const uint8_t *src, uint8_t *dst,
>>> +;
LGTM
On 10/15/19, James Almer wrote:
> Fixes ticket #8273.
>
> Signed-off-by: James Almer
> ---
> libavformat/latmenc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/latmenc.c b/libavformat/latmenc.c
> index db867ebf1a..5ae677f5da 100644
> ---
On 10/15/19, James Almer wrote:
> On 10/15/2019 12:21 PM, Paul B Mahol wrote:
>> +;--
>> +; void ff_filter_row(const uint8_t *src, uint8_t *dst,
>> +;const uint8_t **srcf,
>> +;int
On 10/15/2019 12:21 PM, Paul B Mahol wrote:
> +;--
> +; void ff_filter_row(const uint8_t *src, uint8_t *dst,
> +;const uint8_t **srcf,
> +;int w, int mid, int size,
> +;
Signed-off-by: Paul B Mahol
---
libavfilter/atadenoise.h | 36 +++
libavfilter/vf_atadenoise.c | 16 +--
libavfilter/x86/Makefile | 2 +
libavfilter/x86/vf_atadenoise.asm| 147 +++
libavfilter/x86/vf_atadenoise_init.c | 40
On Mon, Oct 14, 2019 at 09:22:42PM +0800, hwren wrote:
> Signed-off-by: hwren
> ---
> libavcodec/libxavs2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Never trust a computer, one
Fixes ticket #8273.
Signed-off-by: James Almer
---
libavformat/latmenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/latmenc.c b/libavformat/latmenc.c
index db867ebf1a..5ae677f5da 100644
--- a/libavformat/latmenc.c
+++ b/libavformat/latmenc.c
@@ -176,7
On Mon, Oct 14, 2019 at 06:27:07PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> tests/fate/filter-video.mak | 3 ++
> tests/ref/fate/filter-unsharp-yuv420p10 | 55 +
> 2 files changed, 58 insertions(+)
>
Several members of structures denote offsets inside dynamic buffers and
therefore always fit into an int. So it is unnecessary to use an int64_t
for them.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
The Matroska muxer currently only adds CuePoints in three cases:
a) For video keyframes. b) For the first audio frame in a new cluster if
in dash-mode. c) For subtitles. This means that ordinary Matroska audio
files won't have any cues which impedes seeking.
This commit changes this. For every
Contains renaming of variables (e.g. mkv_write_cues() contained
variables called tracknum that actually contain the index of a track in
s->streams and not the track number (which can differ in case an
explicit dash track number is set)).
Signed-off-by: Andreas Rheinhardt
---
mkv_start_new_cluster() actually didn't start a new cluster, but ended
the old one instead and emitted a debug message that it had started a
new cluster. This has been changed: The debug message has been moved to
the place that really starts a new cluster and the function has been
renamed to
When creating dash streams, the track number is externally prescribed
and not derived from the number of streams in the AVFormatContext. Up
until now, a track number of zero was allowed, although this is an
illegal track number; furthermore, it was not checked whether the number
of tracks for a
In order to indicate that the frames in a BlockGroup are not keyframes,
one has to add a ReferenceBlock element containing the timestamp of a
reference block that has already been written. The timestamp ought to be
relative to the timestamp of the block it is attached to. Yet the
Matroska muxer
The Matroska muxer groups index entries with the same pts together in
order to save a few bytes. Because of Matroska's variable-length length
fields, mkv_write_cues() does this by first finding out how many index
entries will be grouped together before actually writing them.
Currently, it is
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 42 ++-
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 4b32130a94..63ad6e47b4 100644
--- a/libavformat/matroskaenc.c
Signed-off-by: Andreas Rheinhardt
---
The easiest way to hit this memleak is by supplying an unreasonably low
number to reserve_index_space.
libavformat/matroskaenc.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/matroskaenc.c
On Mon, Oct 14, 2019 at 10:12:45PM +0200, Michael Niedermayer wrote:
> On Sun, Oct 13, 2019 at 06:45:16AM +0800, Limin Wang wrote:
> > On Sat, Oct 12, 2019 at 11:46:58PM +0200, Michael Niedermayer wrote:
> > > On Sat, Oct 12, 2019 at 06:58:21PM +0800, lance.lmw...@gmail.com wrote:
> > > > From:
From: Limin Wang
Threading is to avoid a core cpu being occupied fully with other filters like
scale,
regarding performance, if your cpu frequency is very high, the gain is very
small, but
with more cores and fewer cpu MHz cpus, you will get more improvements.
The following is my testing
On Mon, Oct 14, 2019 at 10:06:55PM +0200, Michael Niedermayer wrote:
> On Sun, Oct 13, 2019 at 10:51:49AM +1100, Peter Ross wrote:
> > On Sat, Oct 12, 2019 at 06:53:05PM -0300, James Almer wrote:
> > > On 10/12/2019 5:47 PM, Michael Niedermayer wrote:
> > > > On Fri, Oct 11, 2019 at 08:51:54PM
Signed-off-by: Zhengxu Huang
Signed-off-by: Hassene Tmar
Signed-off-by: Jun Zhao
Signed-off-by: Jing Sun
---
configure| 4 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libsvt_hevc.c | 497 +++
MFXVideoENCODE_Query calls CheckVideoParamQueryLike in MSDK and
will determine whether to set param.mfx.TargetKbps to the allowed
minTargetKbps according to the bitrate_limit in extco2 buffer.
Thus q->param.ExtParam must be set before MFXVideoENCODE_Query in case
minTargetKbps is written to
63 matches
Mail list logo
