[FFmpeg-devel] [PATCH v2 5/6] avcodec/cbs_jpeg: Use memcpy when writing pictures
This is possible because the size of a scan header is always a multiple
of a byte.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_jpeg.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index b189cbd9b7..64fe70beab 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -330,7 +330,7 @@ static int cbs_jpeg_write_scan(CodedBitstreamContext *ctx,
PutBitContext *pbc)
{
JPEGRawScan *scan = unit->content;
-int i, err;
+int err;
err = cbs_jpeg_write_scan_header(ctx, pbc, &scan->header);
if (err < 0)
@@ -340,8 +340,12 @@ static int cbs_jpeg_write_scan(CodedBitstreamContext *ctx,
if (scan->data_size * 8 > put_bits_left(pbc))
return AVERROR(ENOSPC);
-for (i = 0; i < scan->data_size; i++)
-put_bits(pbc, 8, scan->data[i]);
+av_assert0(put_bits_count(pbc) % 8 == 0);
+
+flush_put_bits(pbc);
+
+memcpy(put_bits_ptr(pbc), scan->data, scan->data_size);
+skip_put_bytes(pbc, scan->data_size);
}
return 0;
--
2.20.1
___
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".
[FFmpeg-devel] [PATCH v2 3/6] avcodec/cbs_vp9: Write frame data directly
Writing a unit (always a frame) in cbs_vp9 used an intermediate buffer
to write the frame header followed by the frame data that was copied
into said buffer. Afterwards, the final buffer for the frame was
allocated and everything copied into this buffer. But it is trivial to
compute the needed size of the final buffer after having written the
header, so one can allocate the final buffer immediately and copy the
frame data directly into it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs.c | 4
libavcodec/cbs_internal.h | 6 --
libavcodec/cbs_vp9.c | 25 +++--
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 0badb192d9..9ad2641f6d 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -306,6 +306,10 @@ static int cbs_write_unit_data(CodedBitstreamContext *ctx,
init_put_bits(&pbc, ctx->write_buffer, ctx->write_buffer_size);
ret = ctx->codec->write_unit(ctx, unit, &pbc);
+if (ret == 1) {
+// write_unit has already finished the unit.
+return 0;
+}
if (ret < 0) {
if (ret == AVERROR(ENOSPC)) {
// Overflow.
diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 4c5a535ca6..5768baa9ca 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -44,8 +44,10 @@ typedef struct CodedBitstreamType {
int (*read_unit)(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit);
-// Write the data bitstream from unit->content into pbc.
-// Return value AVERROR(ENOSPC) indicates that pbc was too small.
+// Write the data bitstream from unit->content into pbc or into unit->data.
+// Return value AVERROR(ENOSPC) indicates that pbc was too small;
+// 1 indicates that the unit has already been finished by write_unit
+// (i.e. unit->data and unit->data_ref have been allocated and filled).
int (*write_unit)(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit,
PutBitContext *pbc);
diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index 42e4dcf5ac..bc074c4631 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -526,6 +526,7 @@ static int cbs_vp9_write_unit(CodedBitstreamContext *ctx,
PutBitContext *pbc)
{
VP9RawFrame *frame = unit->content;
+size_t data_size, header_size;
int err;
err = cbs_vp9_write_frame(ctx, pbc, frame);
@@ -535,16 +536,28 @@ static int cbs_vp9_write_unit(CodedBitstreamContext *ctx,
// Frame must be byte-aligned.
av_assert0(put_bits_count(pbc) % 8 == 0);
+data_size = header_size = put_bits_count(pbc) / 8;
+unit->data_bit_padding = 0;
+flush_put_bits(pbc);
+
if (frame->data) {
-if (frame->data_size > put_bits_left(pbc) / 8)
-return AVERROR(ENOSPC);
+if (frame->data_size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
+ - header_size)
+return AVERROR(ENOMEM);
-flush_put_bits(pbc);
-memcpy(put_bits_ptr(pbc), frame->data, frame->data_size);
-skip_put_bytes(pbc, frame->data_size);
+data_size += frame->data_size;
}
-return 0;
+err = ff_cbs_alloc_unit_data(ctx, unit, data_size);
+if (err < 0)
+return err;
+
+memcpy(unit->data, pbc->buf, header_size);
+
+if (frame->data)
+memcpy(unit->data + header_size, frame->data, frame->data_size);
+
+return 1;
}
static int cbs_vp9_assemble_fragment(CodedBitstreamContext *ctx,
--
2.20.1
___
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".
[FFmpeg-devel] [PATCH v2 2/6] avcodec/cbs: Fix potential overflow
The number of bits in a PutBitContext must fit into an int, yet nothing
guaranteed the size argument cbs_write_unit_data() uses in init_put_bits()
to be in the range 0..INT_MAX / 8. This has been changed.
Furthermore, the check 8 * data_size > data_bit_start that there is
data beyond the initial padding when writing mpeg2 or H.264/5 slices
could also overflow, so divide it by 8 to get an equivalent check
without this problem.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs.c | 4 +++-
libavcodec/cbs_h2645.c | 2 +-
libavcodec/cbs_mpeg2.c | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index ab3eadb534..0badb192d9 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -309,7 +309,9 @@ static int cbs_write_unit_data(CodedBitstreamContext *ctx,
if (ret < 0) {
if (ret == AVERROR(ENOSPC)) {
// Overflow.
-ctx->write_buffer_size *= 2;
+if (ctx->write_buffer_size == INT_MAX / 8)
+return AVERROR(ENOMEM);
+ctx->write_buffer_size = FFMIN(2 * ctx->write_buffer_size, INT_MAX
/ 8);
goto reallocate_and_try_again;
}
// Write failed for some other reason.
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 923f77dcb4..88fa0029cd 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1101,7 +1101,7 @@ static int
cbs_h2645_write_slice_data(CodedBitstreamContext *ctx,
const uint8_t *pos = data + data_bit_start / 8;
av_assert0(data_bit_start >= 0 &&
- 8 * data_size > data_bit_start);
+ data_size > data_bit_start / 8);
if (data_size * 8 + 8 > put_bits_left(pbc))
return AVERROR(ENOSPC);
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index a9cc4a4cf8..13d871cc89 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -337,7 +337,7 @@ static int cbs_mpeg2_write_slice(CodedBitstreamContext *ctx,
uint8_t *pos = slice->data + slice->data_bit_start / 8;
av_assert0(slice->data_bit_start >= 0 &&
- 8 * slice->data_size > slice->data_bit_start);
+ slice->data_size > slice->data_bit_start / 8);
if (slice->data_size * 8 + 8 > put_bits_left(pbc))
return AVERROR(ENOSPC);
--
2.20.1
___
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".
[FFmpeg-devel] [PATCH v2 4/6] avcodec/cbs_h2645: Write slice data directly
Up until now, writing the data of a slice uses an intermediate buffer
into which the unit (both header as well as the rest) is assembled
before being copied into a freshly allocated buffer. But given that one
has a very good upper bound on the size needed before one starts copying
the slice data, one can allocate the buffer in advance, copy the already
written header into it and directly assemble the rest of the unit in
this buffer.
It proved easier to potentially allocate one byte more and decrement
the size afterwards if it needs to be decremented than to calculate the
exact amount in advance. It is even easier than the current way of
determining whether the last byte needs to be written or not.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h2645.c | 65 --
1 file changed, 31 insertions(+), 34 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 88fa0029cd..c946ca5893 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1094,24 +1094,33 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext
*ctx,
}
static int cbs_h2645_write_slice_data(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit,
PutBitContext *pbc, const uint8_t *data,
size_t data_size, int data_bit_start)
{
size_t rest = data_size - (data_bit_start + 7) / 8;
+int size = (put_bits_count(pbc) - data_bit_start + 7) / 8;
const uint8_t *pos = data + data_bit_start / 8;
+int err;
av_assert0(data_bit_start >= 0 &&
data_size > data_bit_start / 8);
-if (data_size * 8 + 8 > put_bits_left(pbc))
-return AVERROR(ENOSPC);
+if (data_size > INT_MAX / 8 - size)
+return AVERROR(ENOMEM);
-if (!rest)
-goto rbsp_stop_one_bit;
+// size might be one too big if in- and output are misaligned.
+size += data_size;
+
+err = ff_cbs_alloc_unit_data(ctx, unit, size);
+if (err < 0)
+return err;
-// First copy the remaining bits of the first byte
-// The above check ensures that we do not accidentally
-// copy beyond the rbsp_stop_one_bit.
+// Rebase pbc onto the new buffer.
+memcpy(unit->data, pbc->buf, put_bits_ptr(pbc) - pbc->buf);
+rebase_put_bits(pbc, unit->data, size);
+
+// First copy the remaining bits of the first byte.
if (data_bit_start % 8)
put_bits(pbc, 8 - data_bit_start % 8,
*pos++ & MAX_UINT_BITS(8 - data_bit_start % 8));
@@ -1122,33 +1131,25 @@ static int
cbs_h2645_write_slice_data(CodedBitstreamContext *ctx,
// This happens normally for CABAC.
flush_put_bits(pbc);
memcpy(put_bits_ptr(pbc), pos, rest);
-skip_put_bytes(pbc, rest);
} else {
// If not, we have to copy manually.
-// rbsp_stop_one_bit forces us to special-case
-// the last byte.
-uint8_t temp;
-int i;
-for (; rest > 4; rest -= 4, pos += 4)
+for (; rest >= 4; rest -= 4, pos += 4)
put_bits32(pbc, AV_RB32(pos));
-for (; rest > 1; rest--, pos++)
+for (; rest > 0; rest--, pos++)
put_bits(pbc, 8, *pos);
-rbsp_stop_one_bit:
-temp = rest ? *pos : *pos & MAX_UINT_BITS(8 - data_bit_start % 8);
+flush_put_bits(pbc);
-av_assert0(temp);
-i = ff_ctz(*pos);
-temp = temp >> i;
-i = rest ? (8 - i) : (8 - i - data_bit_start % 8);
-put_bits(pbc, i, temp);
-if (put_bits_count(pbc) % 8)
-put_bits(pbc, 8 - put_bits_count(pbc) % 8, 0);
+// Correct size if it is too big because of misalignment.
+if (!unit->data[size - 1])
+unit->data_size = size - 1;
}
-return 0;
+unit->data_bit_padding = 0;
+
+return 1;
}
static int cbs_h264_write_nal_unit(CodedBitstreamContext *ctx,
@@ -1207,11 +1208,9 @@ static int cbs_h264_write_nal_unit(CodedBitstreamContext
*ctx,
return err;
if (slice->data) {
-err = cbs_h2645_write_slice_data(ctx, pbc, slice->data,
- slice->data_size,
- slice->data_bit_start);
-if (err < 0)
-return err;
+return cbs_h2645_write_slice_data(ctx, unit, pbc, slice->data,
+ slice->data_size,
+ slice->data_bit_start);
} else {
// No slice data - that was just the header.
// (Bitstream may be unaligned!)
@@ -1341,11 +1340,9 @@ static int cbs_h265_write_nal_unit(CodedBitstreamContext
*ctx,
return err;
if (slice->data) {
-err = cbs_h2645_write_slice_data(ctx, pbc, slice->data,
-
[FFmpeg-devel] [PATCH v2 6/6] avcodec/cbs_jpeg: Write scan data directly
Writing the scan element in cbs_jpeg used an intermediate buffer
to write the scan header followed by the scan data that was copied
into said buffer. Afterwards, the final buffer for the element was
allocated and everything copied into this buffer. But it is trivial to
compute the needed size of the final buffer after having written the
header, so one can allocate the final buffer immediately and copy the
scan data directly into it, avoiding a memcpy.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_jpeg.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index 64fe70beab..25321bce35 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -337,15 +337,25 @@ static int cbs_jpeg_write_scan(CodedBitstreamContext *ctx,
return err;
if (scan->data) {
-if (scan->data_size * 8 > put_bits_left(pbc))
-return AVERROR(ENOSPC);
+size_t header_size = put_bits_count(pbc) / 8;
av_assert0(put_bits_count(pbc) % 8 == 0);
+if (scan->data_size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
+ - header_size)
+return AVERROR(ENOMEM);
+
+err = ff_cbs_alloc_unit_data(ctx, unit, header_size + scan->data_size);
+if (err < 0)
+return err;
+
flush_put_bits(pbc);
+unit->data_bit_padding = 0;
+
+memcpy(unit->data, pbc->buf, header_size);
+memcpy(unit->data + header_size, scan->data, scan->data_size);
-memcpy(put_bits_ptr(pbc), scan->data, scan->data_size);
-skip_put_bytes(pbc, scan->data_size);
+return 1;
}
return 0;
--
2.20.1
___
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".
[FFmpeg-devel] [PATCH v2 1/6] avcodec/cbs: Factor out common code for writing units
All cbs-functions to write units share a common pattern:
1. They check whether they have a write buffer (that is used to store
the unit's data until the needed size becomes known after writing the
unit when a dedicated buffer will be allocated).
2. They use this buffer for a PutBitContext.
3. The (codec-specific) writing takes place through the PutBitContext.
4. The return value is checked. AVERROR(ENOSPC) here always indicates
that the buffer was too small and leads to a reallocation of said
buffer.
5. The final buffer will be allocated and the data copied.
This commit factors this common code out in a single function in cbs.c.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs.c | 64 ++---
libavcodec/cbs.h | 7
libavcodec/cbs_av1.c | 59 +++---
libavcodec/cbs_av1.h | 4 ---
libavcodec/cbs_h2645.c| 67 ++-
libavcodec/cbs_h2645.h| 7
libavcodec/cbs_internal.h | 6 ++--
libavcodec/cbs_jpeg.c | 64 +++--
libavcodec/cbs_jpeg.h | 7
libavcodec/cbs_mpeg2.c| 62 +++-
libavcodec/cbs_mpeg2.h| 4 ---
libavcodec/cbs_vp9.c | 61 ++-
libavcodec/cbs_vp9.h | 4 ---
13 files changed, 94 insertions(+), 322 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 1a43cd2694..ab3eadb534 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -95,10 +95,12 @@ int ff_cbs_init(CodedBitstreamContext **ctx_ptr,
ctx->log_ctx = log_ctx;
ctx->codec = type;
-ctx->priv_data = av_mallocz(ctx->codec->priv_data_size);
-if (!ctx->priv_data) {
-av_freep(&ctx);
-return AVERROR(ENOMEM);
+if (type->priv_data_size) {
+ctx->priv_data = av_mallocz(ctx->codec->priv_data_size);
+if (!ctx->priv_data) {
+av_freep(&ctx);
+return AVERROR(ENOMEM);
+}
}
ctx->decompose_unit_types = NULL;
@@ -120,6 +122,7 @@ void ff_cbs_close(CodedBitstreamContext **ctx_ptr)
if (ctx->codec && ctx->codec->close)
ctx->codec->close(ctx);
+av_freep(&ctx->write_buffer);
av_freep(&ctx->priv_data);
av_freep(ctx_ptr);
}
@@ -280,6 +283,57 @@ int ff_cbs_read(CodedBitstreamContext *ctx,
return cbs_read_fragment_content(ctx, frag);
}
+static int cbs_write_unit_data(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit)
+{
+PutBitContext pbc;
+int ret;
+
+if (!ctx->write_buffer) {
+// Initial write buffer size is 1MB.
+ctx->write_buffer_size = 1024 * 1024;
+
+reallocate_and_try_again:
+ret = av_reallocp(&ctx->write_buffer, ctx->write_buffer_size);
+if (ret < 0) {
+av_log(ctx->log_ctx, AV_LOG_ERROR, "Unable to allocate a "
+ "sufficiently large write buffer (last attempt "
+ "%"SIZE_SPECIFIER" bytes).\n", ctx->write_buffer_size);
+return ret;
+}
+}
+
+init_put_bits(&pbc, ctx->write_buffer, ctx->write_buffer_size);
+
+ret = ctx->codec->write_unit(ctx, unit, &pbc);
+if (ret < 0) {
+if (ret == AVERROR(ENOSPC)) {
+// Overflow.
+ctx->write_buffer_size *= 2;
+goto reallocate_and_try_again;
+}
+// Write failed for some other reason.
+return ret;
+}
+
+// Overflow but we didn't notice.
+av_assert0(put_bits_count(&pbc) <= 8 * ctx->write_buffer_size);
+
+if (put_bits_count(&pbc) % 8)
+unit->data_bit_padding = 8 - put_bits_count(&pbc) % 8;
+else
+unit->data_bit_padding = 0;
+
+flush_put_bits(&pbc);
+
+ret = ff_cbs_alloc_unit_data(ctx, unit, put_bits_count(&pbc) / 8);
+if (ret < 0)
+return ret;
+
+memcpy(unit->data, ctx->write_buffer, unit->data_size);
+
+return 0;
+}
int ff_cbs_write_fragment_data(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag)
@@ -295,7 +349,7 @@ int ff_cbs_write_fragment_data(CodedBitstreamContext *ctx,
av_buffer_unref(&unit->data_ref);
unit->data = NULL;
-err = ctx->codec->write_unit(ctx, unit);
+err = cbs_write_unit_data(ctx, unit);
if (err < 0) {
av_log(ctx->log_ctx, AV_LOG_ERROR, "Failed to write unit %d "
"(type %"PRIu32").\n", i, unit->type);
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index 7c341bffe7..cdb777d111 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -210,6 +210,13 @@ typedef struct CodedBitstreamContext {
* From AV_LOG_*; defaults to AV_LOG_TRACE.
*/
int trace_level;
+
+/**
+ * Write buffer. Used as intermediate buffer when writing units.
+ * For internal use of cbs only.
+ */
+uint8_t *write_buffer;
+size_t write_buffer_size;
} CodedBitstreamContext;
diff --git
[FFmpeg-devel] [PATCH v2 0/6] Improve writing units
This patchset supersedes my earlier patches [1], [2], [3]. The main difference between the earlier version is that I have avoided the repetition in [2] by factoring out the common parts of writing units into a single function in cbs.c. This does not hinder the efforts of reducing memcpy in any way: Then as now one can easily signal via the return value whether a unit is already finished or whether it is only within the write buffer. - Andreas [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/252979.html [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253022.html [3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253023.html Andreas Rheinhardt (6): avcodec/cbs: Factor out common code for writing units avcodec/cbs: Fix potential overflow avcodec/cbs_vp9: Write frame data directly avcodec/cbs_h2645: Write slice data directly avcodec/cbs_jpeg: Use memcpy when writing pictures avcodec/cbs_jpeg: Write scan data directly libavcodec/cbs.c | 70 ++-- libavcodec/cbs.h | 7 ++ libavcodec/cbs_av1.c | 59 ++--- libavcodec/cbs_av1.h | 4 -- libavcodec/cbs_h2645.c| 134 ++ libavcodec/cbs_h2645.h| 7 -- libavcodec/cbs_internal.h | 8 ++- libavcodec/cbs_jpeg.c | 88 +++-- libavcodec/cbs_jpeg.h | 7 -- libavcodec/cbs_mpeg2.c| 64 ++ libavcodec/cbs_mpeg2.h| 4 -- libavcodec/cbs_vp9.c | 64 +- libavcodec/cbs_vp9.h | 4 -- 13 files changed, 162 insertions(+), 358 deletions(-) -- 2.20.1 ___ 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".
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the encoding and output procedure of encoder
On Thu, 14 Nov 2019, 18:29 Fu, Linjie, wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Fu,
> > Linjie
> > Sent: Monday, November 11, 2019 17:43
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the
> > encoding and output procedure of encoder
> >
> > > -Original Message-
> > > From: Fu, Linjie
> > > Sent: Friday, November 8, 2019 00:32
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie
> > > Subject: [PATCH] lavc/vaapi_encode: Async the encoding and output
> > > procedure of encoder
> > >
> > > Currently, vaapi encodes a pic if all its references are ready,
> > > and then outputs it immediately by calling vaapi_encode_output.
> > >
> > > However, while working on output procedure, hardware is be able to
> > > cope with encoding tasks in the meantime to have the better
> performance.
> > >
> > > So a more efficient way is to send all the pics with available refs to
> > > hardware to allow encoding while output.
> > >
> > > It's what vaapi originally did before the regression, and the
> performance
> > > could be improved for ~20%.
> > >
> > > CMD:
> > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> > > -hwaccel_output_format vaapi -i
> > bbb_sunflower_1080p_30fps_normal.mp4
> > > -c:v h264_vaapi -f h264 -y /dev/null
> > >
> > > Source:
> > > https://download.blender.org/demo/movies/BBB/
> > >
> > > Before:
> > > ~164 fps
> > > After:
> > > ~198 fps
> > >
> > > Fix #7706.
> > >
> > > Signed-off-by: Linjie Fu
> > > ---
> > > libavcodec/vaapi_encode.c | 27 +++
> > > 1 file changed, 19 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > index 3be9159d37..aceb268315 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -1109,17 +1109,28 @@ int
> > > ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> > > return AVERROR(EAGAIN);
> > > }
> > >
> > > +pick_next:
> > > pic = NULL;
> > > err = vaapi_encode_pick_next(avctx, &pic);
> > > -if (err < 0)
> > > -return err;
> > > -av_assert0(pic);
> > > +if (!err) {
> > > +av_assert0(pic);
> > >
> > > -pic->encode_order = ctx->encode_order++;
> > > +pic->encode_order = ctx->encode_order++;
> > >
> > > -err = vaapi_encode_issue(avctx, pic);
> > > -if (err < 0) {
> > > -av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> > > +err = vaapi_encode_issue(avctx, pic);
> > > +if (err < 0) {
> > > +av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> > > +return err;
> > > +}
> > > +goto pick_next;
> > > +} else if (err == AVERROR(EAGAIN)) {
> > > +for (pic = ctx->pic_start; pic; pic = pic->next)
> > > +if (pic->encode_issued && !pic->encode_complete &&
> > > +pic->encode_order == ctx->output_order)
> > > +break;
> > > +if (!pic)
> > > +return err;
> > > +} else {
> > > return err;
> > > }
> > >
> > > @@ -1143,7 +1154,7 @@ int
> > > ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> > > av_log(avctx, AV_LOG_DEBUG, "Output packet: pts %"PRId64"
> > > dts %"PRId64".\n",
> > > pkt->pts, pkt->dts);
> > >
> > > -ctx->output_order = pic->encode_order;
> > > +ctx->output_order++;
> > > vaapi_encode_clear_old(avctx);
> > >
> > > return 0;
> >
> > Ping.
>
> Ping for this.
> Any advice or comment would be appreciated.
>
> Thanks,
> Linjie
>
The drop is even more severe on AMD hardware with VAAPI.
___
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".
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the encoding and output procedure of encoder
On Sun, 17 Nov 2019, 06:36 Dennis Mungai, wrote:
>
>
> On Thu, 14 Nov 2019, 18:29 Fu, Linjie, wrote:
>
>> > -Original Message-
>> > From: ffmpeg-devel On Behalf Of Fu,
>> > Linjie
>> > Sent: Monday, November 11, 2019 17:43
>> > To: ffmpeg-devel@ffmpeg.org
>> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Async the
>> > encoding and output procedure of encoder
>> >
>> > > -Original Message-
>> > > From: Fu, Linjie
>> > > Sent: Friday, November 8, 2019 00:32
>> > > To: ffmpeg-devel@ffmpeg.org
>> > > Cc: Fu, Linjie
>> > > Subject: [PATCH] lavc/vaapi_encode: Async the encoding and output
>> > > procedure of encoder
>> > >
>> > > Currently, vaapi encodes a pic if all its references are ready,
>> > > and then outputs it immediately by calling vaapi_encode_output.
>> > >
>> > > However, while working on output procedure, hardware is be able to
>> > > cope with encoding tasks in the meantime to have the better
>> performance.
>> > >
>> > > So a more efficient way is to send all the pics with available refs to
>> > > hardware to allow encoding while output.
>> > >
>> > > It's what vaapi originally did before the regression, and the
>> performance
>> > > could be improved for ~20%.
>> > >
>> > > CMD:
>> > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
>> > > -hwaccel_output_format vaapi -i
>> > bbb_sunflower_1080p_30fps_normal.mp4
>> > > -c:v h264_vaapi -f h264 -y /dev/null
>> > >
>> > > Source:
>> > > https://download.blender.org/demo/movies/BBB/
>> > >
>> > > Before:
>> > > ~164 fps
>> > > After:
>> > > ~198 fps
>> > >
>> > > Fix #7706.
>> > >
>> > > Signed-off-by: Linjie Fu
>> > > ---
>> > > libavcodec/vaapi_encode.c | 27 +++
>> > > 1 file changed, 19 insertions(+), 8 deletions(-)
>> > >
>> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>> > > index 3be9159d37..aceb268315 100644
>> > > --- a/libavcodec/vaapi_encode.c
>> > > +++ b/libavcodec/vaapi_encode.c
>> > > @@ -1109,17 +1109,28 @@ int
>> > > ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
>> > > return AVERROR(EAGAIN);
>> > > }
>> > >
>> > > +pick_next:
>> > > pic = NULL;
>> > > err = vaapi_encode_pick_next(avctx, &pic);
>> > > -if (err < 0)
>> > > -return err;
>> > > -av_assert0(pic);
>> > > +if (!err) {
>> > > +av_assert0(pic);
>> > >
>> > > -pic->encode_order = ctx->encode_order++;
>> > > +pic->encode_order = ctx->encode_order++;
>> > >
>> > > -err = vaapi_encode_issue(avctx, pic);
>> > > -if (err < 0) {
>> > > -av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
>> > > +err = vaapi_encode_issue(avctx, pic);
>> > > +if (err < 0) {
>> > > +av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
>> > > +return err;
>> > > +}
>> > > +goto pick_next;
>> > > +} else if (err == AVERROR(EAGAIN)) {
>> > > +for (pic = ctx->pic_start; pic; pic = pic->next)
>> > > +if (pic->encode_issued && !pic->encode_complete &&
>> > > +pic->encode_order == ctx->output_order)
>> > > +break;
>> > > +if (!pic)
>> > > +return err;
>> > > +} else {
>> > > return err;
>> > > }
>> > >
>> > > @@ -1143,7 +1154,7 @@ int
>> > > ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
>> > > av_log(avctx, AV_LOG_DEBUG, "Output packet: pts %"PRId64"
>> > > dts %"PRId64".\n",
>> > > pkt->pts, pkt->dts);
>> > >
>> > > -ctx->output_order = pic->encode_order;
>> > > +ctx->output_order++;
>> > > vaapi_encode_clear_old(avctx);
>> > >
>> > > return 0;
>> >
>> > Ping.
>>
>> Ping for this.
>> Any advice or comment would be appreciated.
>>
>> Thanks,
>> Linjie
>>
>
> The drop is even more severe on AMD hardware with VAAPI.
>
Without this patch, perf regression on AMD VAAPI is almost 40%. On Intel
hardware (HSW+) it's closer to 30% in the worst case scenarios.
>
>
___
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".
Re: [FFmpeg-devel] [PATCH] [PATCH] avcodec: Add more kCVImageBufferColorPrimaries to videotoolboxenc
> On Nov 16, 2019, at 7:03 PM, Nomis101 wrote: > > Thanks for reviewing. Would be nice, if somebody could push to master then. > I can't. > > I’ll test it out tomorrow and push. > >> Am 15.11.19 um 15:58 schrieb Limin Wang: >>> On Sun, Nov 03, 2019 at 01:20:38AM +0100, Nomis101 wrote: >>> --- >>> libavcodec/videotoolboxenc.c | 8 >>> 1 file changed, 8 insertions(+) >>> >>> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c >>> index 40a7f643e0..cc08cf6a50 100644 >>> --- a/libavcodec/videotoolboxenc.c >>> +++ b/libavcodec/videotoolboxenc.c >>> @@ -894,6 +894,14 @@ static int get_cv_color_primaries(AVCodecContext >>> *avctx, >>> *primaries = NULL; >>> break; >>> >>> +case AVCOL_PRI_BT470BG: >>> +*primaries = kCVImageBufferColorPrimaries_EBU_3213; >>> +break; >>> + >>> +case AVCOL_PRI_SMPTE170M: >>> +*primaries = kCVImageBufferColorPrimaries_SMPTE_C; >>> +break; >>> + >> lgtm >> >>> case AVCOL_PRI_BT709: >>> *primaries = kCVImageBufferColorPrimaries_ITU_R_709_2; >>> break; >>> -- >>> 2.21.0 (Apple Git-122) >>> >>> ___ >>> 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". >> ___ >> 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". > > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH] [PATCH] avcodec: Add more kCVImageBufferColorPrimaries to videotoolboxenc
Thanks for reviewing. Would be nice, if somebody could push to master then. I can't. Am 15.11.19 um 15:58 schrieb Limin Wang: > On Sun, Nov 03, 2019 at 01:20:38AM +0100, Nomis101 wrote: >> --- >> libavcodec/videotoolboxenc.c | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c >> index 40a7f643e0..cc08cf6a50 100644 >> --- a/libavcodec/videotoolboxenc.c >> +++ b/libavcodec/videotoolboxenc.c >> @@ -894,6 +894,14 @@ static int get_cv_color_primaries(AVCodecContext *avctx, >> *primaries = NULL; >> break; >> >> +case AVCOL_PRI_BT470BG: >> +*primaries = kCVImageBufferColorPrimaries_EBU_3213; >> +break; >> + >> +case AVCOL_PRI_SMPTE170M: >> +*primaries = kCVImageBufferColorPrimaries_SMPTE_C; >> +break; >> + > lgtm > >> case AVCOL_PRI_BT709: >> *primaries = kCVImageBufferColorPrimaries_ITU_R_709_2; >> break; >> -- >> 2.21.0 (Apple Git-122) >> >> ___ >> 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". > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mp3dec: Check that the frame fits within the probe buffer
On Thu, Nov 07, 2019 at 10:25:31PM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/mp3dec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mp3dec: Check for occurances of headers within frames during probing
On Sat, Nov 16, 2019 at 02:57:47PM +0100, Paul B Mahol wrote: > lgtm will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 5/5] avcodec/mjpeg_parser: Make parser a bit more robust with unclean input
On Fri, Oct 11, 2019 at 12:40:11AM +0200, Michael Niedermayer wrote: > Helps: test_roman.mjpeg (note this is not really just mjpeg) > > Signed-off-by: Michael Niedermayer > --- > libavcodec/mjpeg_parser.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/mov: fix typo in help text
On Sat, Nov 16, 2019 at 12:33:59AM +0800, Zhao Zhili wrote: > --- > libavformat/mov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/put_bits: Relax requirements to rebase PutBitContext
On Sat, Nov 16, 2019 at 06:24:29AM +0100, Andreas Rheinhardt wrote: > The earlier requirement was for the new buffer to be bigger than the old > one. This has been relaxed to only demand that the new buffer can hold > all the data written so far. This is in preparation for further commits. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/put_bits.h | 20 ++-- > 1 file changed, 10 insertions(+), 10 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH] lavf/rtmpproto: fix the playpath truncation if the len > 512
On Fri, Nov 15, 2019 at 07:46:33PM +0800, Jun Zhao wrote: > From: Jun Zhao > > fix the playpath truncation if the len > 512 > > Found-by: liuwenhuang > Signed-off-by: Jun Zhao > --- > libavformat/rtmpproto.c |8 +--- > 1 files changed, 5 insertions(+), 3 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 2/4] avformat/mpeg: Remove secondary packet for reading VobSub
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> When vobsub_read_packet() reads a packet, it uses a dedicated AVPacket
>> to get the subtitle timing and position from an FFDemuxSubtitlesQueue
>> (which has been filled with this data during reading the idx file in
>> vobsub_read_header); afterwards the actual subtitle data is read into
>> the packet destined for output and the timing and position are copied
>> to this packet. Afterwards, the local packet is unreferenced.
>>
>> This can be simplified: Simply use the output packet to get the timing
>> and position from the FFDemuxSubtitlesQueue. The packet's size will be
>> zero afterwards, so that it can be directly used to read the actual
>> subtitle data. This makes copying the packet fields as well as
>> unreferencing the local packet unecessary and also removes an instance
>> of usage of sizeof(AVPacket) in libavformat.
>>
>> The only difference is that the returned packet will already be flagged
>> as a keyframe. This currently only happens in compute_pkt_fields().
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/mpeg.c | 23 +++
>> 1 file changed, 7 insertions(+), 16 deletions(-)
>>
>> diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
>> index bd182e4429..7daa72f7ce 100644
>> --- a/libavformat/mpeg.c
>> +++ b/libavformat/mpeg.c
>> @@ -912,7 +912,6 @@ static int vobsub_read_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> FFDemuxSubtitlesQueue *q;
>> AVIOContext *pb = vobsub->sub_ctx->pb;
>> int ret, psize, total_read = 0, i;
>> -AVPacket idx_pkt = { 0 };
>>
>> int64_t min_ts = INT64_MAX;
>> int sid = 0;
>> @@ -927,24 +926,22 @@ static int vobsub_read_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> }
>> }
>> q = &vobsub->q[sid];
>> -ret = ff_subtitles_queue_read_packet(q, &idx_pkt);
>> +/* The returned packet will have size zero,
>> + * so that it can be directly used with av_grow_packet. */
>> +ret = ff_subtitles_queue_read_packet(q, pkt);
>> if (ret < 0)
>> return ret;
>>
>> /* compute maximum packet size using the next packet position. This is
>> * useful when the len in the header is non-sense */
>> if (q->current_sub_idx < q->nb_subs) {
>> -psize = q->subs[q->current_sub_idx].pos - idx_pkt.pos;
>> +psize = q->subs[q->current_sub_idx].pos - pkt->pos;
>> } else {
>> int64_t fsize = avio_size(pb);
>> -psize = fsize < 0 ? 0x : fsize - idx_pkt.pos;
>> +psize = fsize < 0 ? 0x : fsize - pkt->pos;
>> }
>>
>> -avio_seek(pb, idx_pkt.pos, SEEK_SET);
>> -
>> -av_init_packet(pkt);
>> -pkt->size = 0;
>> -pkt->data = NULL;
>> +avio_seek(pb, pkt->pos, SEEK_SET);
>>
>> do {
>> int n, to_read, startcode;
>> @@ -968,7 +965,7 @@ static int vobsub_read_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> total_read += pkt_size;
>>
>> /* the current chunk doesn't match the stream index (unlikely) */
>> -if ((startcode & 0x1f) != s->streams[idx_pkt.stream_index]->id)
>> +if ((startcode & 0x1f) != s->streams[pkt->stream_index]->id)
>> break;
>>
>> ret = av_grow_packet(pkt, to_read);
>> @@ -980,16 +977,10 @@ static int vobsub_read_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> pkt->size -= to_read - n;
>> } while (total_read < psize);
>>
>> -pkt->pts = pkt->dts = idx_pkt.pts;
>> -pkt->pos = idx_pkt.pos;
>> -pkt->stream_index = idx_pkt.stream_index;
>> -
>> -av_packet_unref(&idx_pkt);
>> return 0;
>>
>> fail:
>> av_packet_unref(pkt);
>> -av_packet_unref(&idx_pkt);
>> return ret;
>> }
>>
>>
> Ping.
>
> - Andreas
>
Another ping for the three unmerged patches of this patchset.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cbs_av1: fix reading reference order hint in skip_mode_params()
On 11/16/2019 11:56 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Nov 15, 2019 at 1:44 PM James Almer wrote:
>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/cbs_av1_syntax_template.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/cbs_av1_syntax_template.c
>> b/libavcodec/cbs_av1_syntax_template.c
>> index 806b302de6..c843cfa02b 100644
>> --- a/libavcodec/cbs_av1_syntax_template.c
>> +++ b/libavcodec/cbs_av1_syntax_template.c
>> @@ -882,7 +882,7 @@ static int
>> FUNC(skip_mode_params)(CodedBitstreamContext *ctx, RWContext *rw,
>> forward_idx = -1;
>> backward_idx = -1;
>> for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
>> -ref_hint = priv->ref[i].order_hint;
>> +ref_hint = priv->ref[current->ref_frame_idx[i]].order_hint;
>> dist = cbs_av1_get_relative_dist(seq, ref_hint,
>> current->order_hint);
>> if (dist < 0) {
>> @@ -913,7 +913,7 @@ static int
>> FUNC(skip_mode_params)(CodedBitstreamContext *ctx, RWContext *rw,
>>
>> second_forward_idx = -1;
>> for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
>> -ref_hint = priv->ref[i].order_hint;
>> +ref_hint =
>> priv->ref[current->ref_frame_idx[i]].order_hint;
>> if (cbs_av1_get_relative_dist(seq, ref_hint,
>>forward_hint) < 0) {
>> if (second_forward_idx < 0 ||
>
>
> LGTM, thanks.
>
> Ronald
Applied.
___
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".
[FFmpeg-devel] [PATCH] avfilter: add axcorrelate filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 32 +++
libavfilter/Makefile | 1 +
libavfilter/af_axcorrelate.c | 378 +++
libavfilter/allfilters.c | 1 +
4 files changed, 412 insertions(+)
create mode 100644 libavfilter/af_axcorrelate.c
diff --git a/doc/filters.texi b/doc/filters.texi
index e48f9c99e5..3b6f2d5ec7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2527,6 +2527,38 @@ ffmpeg -i INPUT -af atrim=end_sample=1000
@end itemize
+@section axcorrelate
+Calculate normalized cross-correlation between two input audio streams.
+Resulted samples are always between -1 and 1 inclusive.
+If result is 1 it means two input samples are highly correlated in that
selected segment.
+Result 0 means they are not correlated at all.
+If result is -1 it means two input samples are out of phase, which means they
cancel each
+other.
+
+The filter accepts the following options:
+
+@table @option
+@item size
+Set size of segment over which cross-correlation is calculated.
+Default is 256. Allowed range is from 2 to 131072.
+
+@item algo
+Set algorithm for cross-correlation. Can be @code{slow} or @code{fast}.
+Default is @code{slow}. Fast algorithm assumes mean values over any given
segment
+are always zero and thus need much less calculations to make.
+This is generally not true, but is valid for typical audio streams.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Calculate correlation between channels in stereo audio stream:
+@example
+ffmpeg -i stereo.wav -af channelsplit,axcorrelate=size=1024:algo=fast
correlation.wav
+@end example
+@end itemize
+
@section bandpass
Apply a two-pole Butterworth band-pass filter with central
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fce930360d..dc80358cc7 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -88,6 +88,7 @@ OBJS-$(CONFIG_ASTATS_FILTER) += af_astats.o
OBJS-$(CONFIG_ASTREAMSELECT_FILTER) += f_streamselect.o framesync.o
OBJS-$(CONFIG_ATEMPO_FILTER) += af_atempo.o
OBJS-$(CONFIG_ATRIM_FILTER) += trim.o
+OBJS-$(CONFIG_AXCORRELATE_FILTER)+= af_axcorrelate.o
OBJS-$(CONFIG_AZMQ_FILTER) += f_zmq.o
OBJS-$(CONFIG_BANDPASS_FILTER) += af_biquads.o
OBJS-$(CONFIG_BANDREJECT_FILTER) += af_biquads.o
diff --git a/libavfilter/af_axcorrelate.c b/libavfilter/af_axcorrelate.c
new file mode 100644
index 00..861903b0f1
--- /dev/null
+++ b/libavfilter/af_axcorrelate.c
@@ -0,0 +1,378 @@
+/*
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/audio_fifo.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+
+#include "audio.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "filters.h"
+#include "internal.h"
+
+typedef struct AudioXCorrelateContext {
+const AVClass *class;
+
+int size;
+int algo;
+int64_t pts;
+
+AVAudioFifo *fifo[2];
+AVFrame *cache[2];
+AVFrame *mean_sum[2];
+AVFrame *num_sum;
+AVFrame *den_sum[2];
+int used;
+
+int (*xcorrelate)(AVFilterContext *ctx, AVFrame *out);
+} AudioXCorrelateContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats;
+AVFilterChannelLayouts *layouts;
+static const enum AVSampleFormat sample_fmts[] = {
+AV_SAMPLE_FMT_FLTP,
+AV_SAMPLE_FMT_NONE
+};
+int ret;
+
+layouts = ff_all_channel_counts();
+if (!layouts)
+return AVERROR(ENOMEM);
+ret = ff_set_common_channel_layouts(ctx, layouts);
+if (ret < 0)
+return ret;
+
+formats = ff_make_format_list(sample_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ret = ff_set_common_formats(ctx, formats);
+if (ret < 0)
+return ret;
+
+formats = ff_all_samplerates();
+if (!formats)
+return AVERROR(ENOMEM);
+return ff_set_common_samplerates(ctx, formats);
+}
+
+static float mean_sum(const float *in, int size)
+{
+float mean_sum = 0.f;
+
+for (int i = 0; i < size; i++)
+mean_sum += in[i];
+
+return mean_sum
Re: [FFmpeg-devel] [PATCH v3 2/2] FATE: add a test for colorbalance
On Fri, Nov 15, 2019 at 11:12:49PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > tests/fate/filter-video.mak | 12 > tests/ref/fate/filter-colorbalance | 8 > tests/ref/fate/filter-colorbalance-gbrap| 8 > tests/ref/fate/filter-colorbalance-gbrap-16 | 8 > tests/ref/fate/filter-colorbalance-rgba64 | 8 > 5 files changed, 44 insertions(+) > create mode 100644 tests/ref/fate/filter-colorbalance > create mode 100644 tests/ref/fate/filter-colorbalance-gbrap > create mode 100644 tests/ref/fate/filter-colorbalance-gbrap-16 > create mode 100644 tests/ref/fate/filter-colorbalance-rgba64 Tested on x86-32/64, mingw32/64, arm & mips qemu [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH v2] avutil/eval: add function to track variable use
On 16-11-2019 08:12 pm, Michael Niedermayer wrote: On Sat, Nov 16, 2019 at 05:39:56PM +0530, Gyan wrote: As suggested by Michael in the review for the vf_scale patch, new eval function tracks count of all variables in a parsed expression in an array. Thanks, Gyan doc/APIchanges |3 +++ libavutil/eval.c| 16 libavutil/eval.h| 10 ++ libavutil/version.h |4 ++-- 4 files changed, 31 insertions(+), 2 deletions(-) 80811d88b86179421be789e85ccb9fb78db978e0 v2-0001-avutil-eval-add-function-to-track-variable-use.patch From 6d4d8ab2b582991ccb787d18d14be31256a785aa Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Sat, 2 Nov 2019 20:16:42 +0530 Subject: [PATCH v2] avutil/eval: add function to track variable use LGTM Will apply. Thanks, Gyan ___ 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".
[FFmpeg-devel] [PATCH] avfilter/Makefile: add missing dependency for scale_cuda
Was missing since initial commit. Gyan From 470dfb6bcbe3ff1341a3aca77ebc92b5c7acbdbe Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Sat, 16 Nov 2019 20:48:10 +0530 Subject: [PATCH] avfilter/Makefile: add missing dependency for scale_cuda scale_cuda includes scale.h --- libavfilter/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/Makefile b/libavfilter/Makefile index fce930360d..6838d5c986 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -359,7 +359,7 @@ OBJS-$(CONFIG_ROBERTS_OPENCL_FILTER) += vf_convolution_opencl.o opencl.o OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o OBJS-$(CONFIG_SCALE_FILTER) += vf_scale.o scale.o -OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o vf_scale_cuda.ptx.o +OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o vf_scale_cuda.ptx.o scale.o OBJS-$(CONFIG_SCALE_NPP_FILTER) += vf_scale_npp.o scale.o OBJS-$(CONFIG_SCALE_QSV_FILTER) += vf_scale_qsv.o OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o vaapi_vpp.o -- 2.24.0___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cbs_av1: fix reading reference order hint in skip_mode_params()
Hi,
On Fri, Nov 15, 2019 at 1:44 PM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_av1_syntax_template.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/cbs_av1_syntax_template.c
> b/libavcodec/cbs_av1_syntax_template.c
> index 806b302de6..c843cfa02b 100644
> --- a/libavcodec/cbs_av1_syntax_template.c
> +++ b/libavcodec/cbs_av1_syntax_template.c
> @@ -882,7 +882,7 @@ static int
> FUNC(skip_mode_params)(CodedBitstreamContext *ctx, RWContext *rw,
> forward_idx = -1;
> backward_idx = -1;
> for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
> -ref_hint = priv->ref[i].order_hint;
> +ref_hint = priv->ref[current->ref_frame_idx[i]].order_hint;
> dist = cbs_av1_get_relative_dist(seq, ref_hint,
> current->order_hint);
> if (dist < 0) {
> @@ -913,7 +913,7 @@ static int
> FUNC(skip_mode_params)(CodedBitstreamContext *ctx, RWContext *rw,
>
> second_forward_idx = -1;
> for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
> -ref_hint = priv->ref[i].order_hint;
> +ref_hint =
> priv->ref[current->ref_frame_idx[i]].order_hint;
> if (cbs_av1_get_relative_dist(seq, ref_hint,
>forward_hint) < 0) {
> if (second_forward_idx < 0 ||
LGTM, thanks.
Ronald
___
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".
Re: [FFmpeg-devel] [PATCH v2] avutil/eval: add function to track variable use
On Sat, Nov 16, 2019 at 05:39:56PM +0530, Gyan wrote: > As suggested by Michael in the review for the vf_scale patch, new eval > function tracks count of all variables in a parsed > expression in an array. > > Thanks, > Gyan > doc/APIchanges |3 +++ > libavutil/eval.c| 16 > libavutil/eval.h| 10 ++ > libavutil/version.h |4 ++-- > 4 files changed, 31 insertions(+), 2 deletions(-) > 80811d88b86179421be789e85ccb9fb78db978e0 > v2-0001-avutil-eval-add-function-to-track-variable-use.patch > From 6d4d8ab2b582991ccb787d18d14be31256a785aa Mon Sep 17 00:00:00 2001 > From: Gyan Doshi > Date: Sat, 2 Nov 2019 20:16:42 +0530 > Subject: [PATCH v2] avutil/eval: add function to track variable use LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mp3dec: Check for occurances of headers within frames during probing
lgtm
On 11/7/19, Michael Niedermayer wrote:
> From: Limin Wang
>
> Fixes misdetection of zYLx.wav
>
> Co-Author: Michael Niedermayer
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mp3dec.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 6848415657..eb40362548 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -73,7 +73,7 @@ static int mp3_read_probe(const AVProbeData *p)
> int frames, ret;
> int framesizes, max_framesizes;
> uint32_t header;
> -const uint8_t *buf, *buf0, *buf2, *end;
> +const uint8_t *buf, *buf0, *buf2, *buf3, *end;
>
> buf0 = p->buf;
> end = p->buf + p->buf_size - sizeof(uint32_t);
> @@ -88,11 +88,19 @@ static int mp3_read_probe(const AVProbeData *p)
> buf2 = buf;
> for(framesizes = frames = 0; buf2 < end; frames++) {
> MPADecodeHeader h;
> +int header_emu = 0;
>
> header = AV_RB32(buf2);
> ret = avpriv_mpegaudio_decode_header(&h, header);
> if (ret != 0 || end - buf2 < h.frame_size)
> break;
> +
> +for (buf3 = buf2 + 4; buf3 < buf2 + h.frame_size; buf3++) {
> +uint32_t next_sync = AV_RB32(buf3);
> +header_emu += (next_sync & MP3_MASK) == (header &
> MP3_MASK);
> +}
> +if (header_emu > 2)
> +break;
> buf2 += h.frame_size;
> framesizes += h.frame_size;
> }
> --
> 2.23.0
>
> ___
> 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".
___
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".
Re: [FFmpeg-devel] [PATCH 5/5] avcodec/mjpeg_parser: Make parser a bit more robust with unclean input
So you gonna commit this or not? Are there obvious drawbacks?
On 10/11/19, Michael Niedermayer wrote:
> Helps: test_roman.mjpeg (note this is not really just mjpeg)
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mjpeg_parser.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
> index 07a6b2bdc6..c642b2ecbc 100644
> --- a/libavcodec/mjpeg_parser.c
> +++ b/libavcodec/mjpeg_parser.c
> @@ -50,7 +50,7 @@ static int find_frame_end(MJPEGParserContext *m, const
> uint8_t *buf, int buf_siz
> for(i=0; i state= (state<<8) | buf[i];
> if(state>=0xFFC0 && state<=0xFFFE){
> -if(state>=0xFFD8 && state<=0xFFD8){
> +if(state>=0xFFD8FFC0 && state<=0xFFD8){
> i++;
> vop_found=1;
> break;
> @@ -76,12 +76,14 @@ static int find_frame_end(MJPEGParserContext *m, const
> uint8_t *buf, int buf_siz
> for(; i state= (state<<8) | buf[i];
> if(state>=0xFFC0 && state<=0xFFFE){
> -if(state>=0xFFD8 && state<=0xFFD8){
> +if(state>=0xFFD8FFC0 && state<=0xFFD8){
> pc->frame_start_found=0;
> pc->state=0;
> return i-3;
> } else if(state<0xFFD0 || state>0xFFD9){
> m->size= (state&0x)-1;
> +if (m->size >= 0x8000)
> +m->size = 0;
> }
> }
> if(m->size>0){
> --
> 2.23.0
>
> ___
> 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".
___
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".
Re: [FFmpeg-devel] [PATCH v1 4/4] fate/filter-video: add 10bit test for unsharp filter
On Fri, Nov 15, 2019 at 11:03:35PM +0800, Limin Wang wrote: > On Mon, Oct 21, 2019 at 08:33:07PM +0200, Michael Niedermayer wrote: > > On Mon, Oct 21, 2019 at 03:55:50PM +0800, Limin Wang wrote: > > > 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 ++ > > > > > tests/ref/fate/filter-unsharp-yuv420p10 | 55 > > > > > + > > > > > 2 files changed, 58 insertions(+) > > > > > create mode 100644 tests/ref/fate/filter-unsharp-yuv420p10 > > > > > > > > fails on mips > > > > > > Michael, I have cross compile a mips version and verify v2 update patch > > > has pass the filter-unsharp-yuv420p10 fate testing, > > > please feedback if you have failes still. Below is info: > > > > the latest patch corrects the failure > > thx > > ping, please help to merge it if no further comment. have all parts of the patchset been reviewed ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH] avfilter/scale: allow dynamic output via expressions
On Fri, Nov 15, 2019 at 11:10:26AM +0530, Gyan wrote:
>
>
> On 15-11-2019 04:01 am, Michael Niedermayer wrote:
> >On Thu, Nov 14, 2019 at 11:12:23PM +0530, Gyan wrote:
> >>
> >>On 14-11-2019 01:12 am, Michael Niedermayer wrote:
> >>>Moving and changing code at the same time makes it hard to see th
> >>>difference.
> >>>Idealy all code moves should be seperate from changes to the code.
> >>>
> >>>also more generally, spliting this patch up would simpify review
> >>Split into two. First patch mostly moves code and keeps existing
> >>functionality. 2nd patch introduces new features and requires the new eval
> >>function.
> >>
> >>Thanks,
> >>Gyan
> >> Makefile |4 -
> >> scale.c| 72 +-
> >> vf_scale.c | 192
> >> -
> >> 3 files changed, 196 insertions(+), 72 deletions(-)
> >>77579fdbd7add3be08bada5ee401df41f60ea236
> >>v2-0001-avfilter-scale-shift-ff_scale_eval_dimensions-inl.patch
> >> From 359f538703865c8ebeda16b5d1846d2cf1cf9c4d Mon Sep 17 00:00:00 2001
> >>From: Gyan Doshi
> >>Date: Thu, 14 Nov 2019 21:08:32 +0530
> >>Subject: [PATCH v2 1/2] avfilter/scale: shift ff_scale_eval_dimensions
> >>inline
> >>
> >>This is a perfunctory change in preparation of adding
> >>direct animation support to scale and scale2ref filters
> >>---
> >> libavfilter/Makefile | 4 +-
> >> libavfilter/scale.c| 72 +---
> >> libavfilter/vf_scale.c | 192 -
> >> 3 files changed, 196 insertions(+), 72 deletions(-)
> >>
> >>diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> >>index fce930360d..f1f6994574 100644
> >>--- a/libavfilter/Makefile
> >>+++ b/libavfilter/Makefile
> >>@@ -358,12 +358,12 @@ OBJS-$(CONFIG_ROBERTS_OPENCL_FILTER) +=
> >>vf_convolution_opencl.o opencl.o
> >> opencl/convolution.o
> >> OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
> >> OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
> >>-OBJS-$(CONFIG_SCALE_FILTER) += vf_scale.o scale.o
> >>+OBJS-$(CONFIG_SCALE_FILTER) += vf_scale.o
> >> OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o
> >> vf_scale_cuda.ptx.o
> >> OBJS-$(CONFIG_SCALE_NPP_FILTER) += vf_scale_npp.o scale.o
> >> OBJS-$(CONFIG_SCALE_QSV_FILTER) += vf_scale_qsv.o
> >> OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
> >> vaapi_vpp.o
> >>-OBJS-$(CONFIG_SCALE2REF_FILTER) += vf_scale.o scale.o
> >>+OBJS-$(CONFIG_SCALE2REF_FILTER) += vf_scale.o
> >> OBJS-$(CONFIG_SCROLL_FILTER) += vf_scroll.o
> >> OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
> >> OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
> >>diff --git a/libavfilter/scale.c b/libavfilter/scale.c
> >>index eaee95fac6..668aa04622 100644
> >>--- a/libavfilter/scale.c
> >>+++ b/libavfilter/scale.c
> >>@@ -60,49 +60,6 @@ enum var_name {
> >> VARS_NB
> >> };
> >>-/**
> >>- * This must be kept in sync with var_names so that it is always a
> >>- * complete list of var_names with the scale2ref specific names
> >>- * appended. scale2ref values must appear in the order they appear
> >>- * in the var_name_scale2ref enum but also be below all of the
> >>- * non-scale2ref specific values.
> >>- */
> >>-static const char *const var_names_scale2ref[] = {
> >>-"PI",
> >>-"PHI",
> >>-"E",
> >>-"in_w", "iw",
> >>-"in_h", "ih",
> >>-"out_w", "ow",
> >>-"out_h", "oh",
> >>-"a",
> >>-"sar",
> >>-"dar",
> >>-"hsub",
> >>-"vsub",
> >>-"ohsub",
> >>-"ovsub",
> >>-"main_w",
> >>-"main_h",
> >>-"main_a",
> >>-"main_sar",
> >>-"main_dar", "mdar",
> >>-"main_hsub",
> >>-"main_vsub",
> >>-NULL
> >>-};
> >>-
> >>-enum var_name_scale2ref {
> >>-VAR_S2R_MAIN_W,
> >>-VAR_S2R_MAIN_H,
> >>-VAR_S2R_MAIN_A,
> >>-VAR_S2R_MAIN_SAR,
> >>-VAR_S2R_MAIN_DAR, VAR_S2R_MDAR,
> >>-VAR_S2R_MAIN_HSUB,
> >>-VAR_S2R_MAIN_VSUB,
> >>-VARS_S2R_NB
> >>-};
> >>-
> >> int ff_scale_eval_dimensions(void *log_ctx,
> >> const char *w_expr, const char *h_expr,
> >> AVFilterLink *inlink, AVFilterLink *outlink,
> >>@@ -115,16 +72,7 @@ int ff_scale_eval_dimensions(void *log_ctx,
> >> int factor_w, factor_h;
> >> int eval_w, eval_h;
> >> int ret;
> >>-const char scale2ref = outlink->src->nb_inputs == 2 &&
> >>outlink->src->inputs[1] == inlink;
> >>-double var_values[VARS_NB + VARS_S2R_NB], res;
> >>-const AVPixFmtDescriptor *main_desc;
> >>-const AVFilterLink *main_link;
> >>-const char *const *names = scale2ref ? var_names_scale2ref : var_names;
> >>-
> >>-if (scale2ref) {
> >>-main_link = outlink->src->inputs[0];
> >>-main_desc = av_pix_fmt_desc_get(main_link->format);
> >>-}
> >>+
[FFmpeg-devel] [PATCH v2] avutil/eval: add function to track variable use
As suggested by Michael in the review for the vf_scale patch, new eval
function tracks count of all variables in a parsed
expression in an array.
Thanks,
Gyan
From 6d4d8ab2b582991ccb787d18d14be31256a785aa Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Sat, 2 Nov 2019 20:16:42 +0530
Subject: [PATCH v2] avutil/eval: add function to track variable use
1)Some filters allow cross-referenced expressions e.g. x=y+10. In
such cases, filters evaluate expressions multiple times for
successful evaluation of all expressions. If the expression for one or
more variables contains a RNG, the result may vary across evaluation
leading to inconsistent values across the cross-referenced expressions.
2)A related case is circular expressions e.g. x=y+10 and y=x+10 which
cannot be succesfully resolved.
3)Certain filter variables may only be applicable in specific eval modes
and lead to a failure of evaluation in other modes e.g. pts is only relevant
for frame eval mode.
At present, there is no reliable means to identify these occurrences and
thus the error messages provided are broad or inaccurate. The helper
function introduced - av_expr_count_vars - allows developers to identify
the use and count of variables in expressions and thus tailor the error
message, allow for a graceful fallback and/or decide evaluation order.
---
doc/APIchanges | 3 +++
libavutil/eval.c| 16
libavutil/eval.h| 10 ++
libavutil/version.h | 4 ++--
4 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 48168f82e6..f39eda7afc 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
API changes, most recent first:
+2019-11-16 - xx - lavu 56.36.100 - eval API
+ Add av_expr_count_vars().
+
2019-10-14 - f3746d31f9 - lavu 56.35.101 - opt.h
Add AV_OPT_FLAG_RUNTIME_PARAM.
diff --git a/libavutil/eval.c b/libavutil/eval.c
index 48832979e2..62d2ae938b 100644
--- a/libavutil/eval.c
+++ b/libavutil/eval.c
@@ -735,6 +735,22 @@ end:
return ret;
}
+int av_expr_count_vars(AVExpr *e, unsigned *counter, int size)
+{
+int i;
+
+if (!e || !counter || !size)
+return AVERROR(EINVAL);
+
+for (i = 0; e->type != e_const && i < 3 && e->param[i]; i++)
+av_expr_count_vars(e->param[i], counter, size);
+
+if (e->type == e_const && e->a.const_index < size)
+counter[e->a.const_index]++;
+
+return 0;
+}
+
double av_expr_eval(AVExpr *e, const double *const_values, void *opaque)
{
Parser p = { 0 };
diff --git a/libavutil/eval.h b/libavutil/eval.h
index dacd22b96e..9bdb10cca2 100644
--- a/libavutil/eval.h
+++ b/libavutil/eval.h
@@ -86,6 +86,16 @@ int av_expr_parse(AVExpr **expr, const char *s,
*/
double av_expr_eval(AVExpr *e, const double *const_values, void *opaque);
+/**
+ * Track the presence of variables and their number of occurrences in a parsed
expression
+ *
+ * @param counter a zero-initialized array where the count of each variable
will be stored
+ * @param size size of array
+ * @return 0 on success, a negative value indicates that no expression or
array was passed
+ * or size was zero
+ */
+int av_expr_count_vars(AVExpr *e, unsigned *counter, int size);
+
/**
* Free a parsed expression previously created with av_expr_parse().
*/
diff --git a/libavutil/version.h b/libavutil/version.h
index 27d663baf1..af3abf7265 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,8 +79,8 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 56
-#define LIBAVUTIL_VERSION_MINOR 35
-#define LIBAVUTIL_VERSION_MICRO 101
+#define LIBAVUTIL_VERSION_MINOR 36
+#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
--
2.24.0___
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".
