[FFmpeg-devel] [PATCH v4] libsvtav1: Add logical_processors option
From: Christopher Degawa
Used for limiting the size of memory buffers and threads for a target
logical processor count, but does not set thread affinity or the total
amount of threads used, although thread affinities can be controlled
with an additional parameters, it is prefered to add them until
a svtav1-params option or similar is added
Signed-off-by: Christopher Degawa
---
doc/encoders.texi | 6 ++
libavcodec/libsvtav1.c | 7 +++
2 files changed, 13 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index c9c8785afb..7bb97d9dae 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1795,6 +1795,12 @@ Set log2 of the number of rows of tiles to use (0-6).
@item tile_columns
Set log2 of the number of columns of tiles to use (0-4).
+@item logical_processors
+Number of logical processors to run the encoder on, threads are managed by the
OS scheduler.
+Used for limiting the size of memory buffers and threads for a target logical
processor count.
+Does not set thread affinity or total threads, but instead sets t *
logical_processors amount of threads
+with t being the amount of threads libsvtav1 sets per cpu (0 - ncpus).
+
@end table
@section libkvazaar
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index eb6043bcac..087b14099f 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -71,6 +71,8 @@ typedef struct SvtContext {
int tile_columns;
int tile_rows;
+
+unsigned logical_processors;
} SvtContext;
static const struct {
@@ -218,6 +220,8 @@ static int config_enc_params(EbSvtAv1EncConfiguration
*param,
param->tile_columns = svt_enc->tile_columns;
param->tile_rows= svt_enc->tile_rows;
+param->logical_processors = svt_enc->logical_processors;
+
return 0;
}
@@ -533,6 +537,9 @@ static const AVOption options[] = {
{ "tile_columns", "Log2 of number of tile columns to use",
OFFSET(tile_columns), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 4, VE},
{ "tile_rows", "Log2 of number of tile rows to use", OFFSET(tile_rows),
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 6, VE},
+{ "logical_processors", "Number of logical processors to run the encoder
on, used to limit the size of memory buffers and threads used",
OFFSET(logical_processors),
+ AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
+
{NULL},
};
--
2.25.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 V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
> -Original Message- > From: ffmpeg-devel On Behalf Of Nicolas > George > Sent: 2021年3月10日 2:13 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH V5 3/5] libavutil: add side data > AV_FRAME_DATA_BOUNDING_BOXES > > Anton Khirnov (12021-03-09): > > Correct, I object to using private_ref even more strongly than to > > private side data. > > > > I would prefer private_ref to be removed entirely. > > > > All this said, it would be acceptable to make this new side data > > private (or declared unstable) for a clearly limited period of time, > > e.g. 3 months or until the next major bump or so. As long as it's not > > internal indefinitely. > > Then we are on the same page. > Thanks all for your valuable inputs. I'll pursue the final solution for a public new side data. I'll just make this patch set pending, and continue the development for tensorflow object detection support and other filters such as classify, and also ask for more feedbacks from potential customers. The new patch set will be sent out once it is mature enough, at least in my opinion. ___ 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 1/1] Matroid patch: add support for writing additional metadata to filename
Hey Nicolas, Thanks for the comment. I'll split this patch into separate ones and work on getting them approved sequentially then. Feel free to close this thread in favor of the upcoming one I just emailed. *Jiahang (Tak) Li* Deep Learning Engineer, Matroid Inc https://www.matroid.com On Tue, Feb 23, 2021 at 2:02 AM Nicolas George wrote: > tak-matroid (12021-02-22): > > * Support micro seconds for image2 strftime filename > > * Support micro seconds for segment strftime filename > > * Support duration for segment output > > * Allow split on keyframe with NOPTS > > * Add EXT-X-PROGRAM-DATE-TIME parsing to hls.c > > * Add global timestamp (gts) metatdata to AVPacket and AVFrame > > * Support gts for image2 filename > > * Support gts for segment filename > > Please make one patch per functional change. > > No field can be added to AVPacket, as applications are currently allowed > to allocate it themselves. > > Regards, > > -- > Nicolas George > ___ 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] Matroid patch: add support for writing additional metadata to filename
* Support micro seconds for image2 strftime filename
* Support micro seconds for segment strftime filename
* Support duration for segment output
Signed-off-by: tak-matroid
---
libavformat/avformat.h | 7 -
libavformat/img2enc.c | 40 +--
libavformat/segment.c | 61 +-
libavformat/utils.c| 38 +++---
libavutil/time.c | 17
libavutil/time.h | 11
6 files changed, 149 insertions(+), 25 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 7da2f3d98e..f5084f622c 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2808,10 +2808,15 @@ void av_dump_format(AVFormatContext *ic,
* @param path numbered sequence string
* @param number frame number
* @param flags AV_FRAME_FILENAME_FLAGS_*
+ * @param ts frame pts in AV_TIME_BASE_Q
+ * @param duration duration of segment
* @return 0 if OK, -1 on format error
*/
+int av_get_frame_filename3(char *buf, int buf_size,
+ const char *path, int number, int flags, int64_t ts,
double duration);
+
int av_get_frame_filename2(char *buf, int buf_size,
- const char *path, int number, int flags);
+ const char *path, int number, int flags, int64_t ts);
int av_get_frame_filename(char *buf, int buf_size,
const char *path, int number);
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index 0f7a21ffa0..37118d02fc 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -27,7 +27,9 @@
#include "libavutil/log.h"
#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
+#include "libavutil/time.h"
#include "libavutil/time_internal.h"
+#include
#include "avformat.h"
#include "avio_internal.h"
#include "internal.h"
@@ -130,31 +132,40 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
VideoMuxData *img = s->priv_data;
AVIOContext *pb[4] = {0};
char filename[1024];
-AVCodecParameters *par = s->streams[pkt->stream_index]->codecpar;
+AVStream *stream = s->streams[pkt->stream_index];
+AVCodecParameters *par = stream->codecpar;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(par->format);
int ret, i;
int nb_renames = 0;
+int64_t ts = av_rescale_q(pkt->pts, stream->time_base, AV_TIME_BASE_Q);
AVDictionary *options = NULL;
if (img->update) {
av_strlcpy(filename, img->path, sizeof(filename));
-} else if (img->use_strftime) {
-time_t now0;
-struct tm *tm, tmpbuf;
-time();
-tm = localtime_r(, );
-if (!strftime(filename, sizeof(filename), img->path, tm)) {
-av_log(s, AV_LOG_ERROR, "Could not get frame filename with
strftime\n");
-return AVERROR(EINVAL);
+} else if (img->use_strftime || img->frame_pts) {
+char temp_name[sizeof(filename)];
+if (img->use_strftime) {
+struct timeval tv;
+gettimeofday(, NULL);
+if (!av_strftime_micro(temp_name, sizeof(temp_name), img->path,
)) {
+av_log(s, AV_LOG_ERROR, "Could not get frame filename with
strftime\n");
+return AVERROR(EINVAL);
+}
+} else {
+av_strlcpy(temp_name, img->path, sizeof(temp_name));
}
-} else if (img->frame_pts) {
-if (av_get_frame_filename2(filename, sizeof(filename), img->path,
pkt->pts, AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0) {
-av_log(s, AV_LOG_ERROR, "Cannot write filename by pts of the
frames.");
-return AVERROR(EINVAL);
+
+if (img->frame_pts) {
+if (av_get_frame_filename2(filename, sizeof(filename), temp_name,
pkt->pts, AV_FRAME_FILENAME_FLAGS_MULTIPLE, ts) < 0) {
+av_log(s, AV_LOG_ERROR, "Cannot write filename by pts of the
frames.");
+return AVERROR(EINVAL);
+}
+} else {
+av_strlcpy(filename, temp_name, sizeof(filename));
}
} else if (av_get_frame_filename2(filename, sizeof(filename), img->path,
img->img_number,
- AV_FRAME_FILENAME_FLAGS_MULTIPLE) < 0 &&
+ AV_FRAME_FILENAME_FLAGS_MULTIPLE, ts) <
0 &&
img->img_number > 1) {
av_log(s, AV_LOG_ERROR,
"Could not get frame filename number %d from pattern '%s'. "
@@ -162,6 +173,7 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
img->img_number, img->path);
return AVERROR(EINVAL);
}
+
for (i = 0; i < 4; i++) {
av_dict_copy(, img->protocol_opts, 0);
snprintf(img->tmp[i], sizeof(img->tmp[i]), "%s.tmp", filename);
diff --git a/libavformat/segment.c b/libavformat/segment.c
index dff3d0ed48..f4ad3ccceb 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
[FFmpeg-devel] [PATCH 4/8] avutil/avstring: Limit string length in av_escape to range of int
Otherwise the caller can't distinguish the return value from an error.
Signed-off-by: Andreas Rheinhardt
---
libavutil/avstring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index e33d4aac51..832bec750f 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -337,7 +337,7 @@ int av_escape(char **dst, const char *src, const char
*special_chars,
{
AVBPrint dstbuf;
-av_bprint_init(, 1, AV_BPRINT_SIZE_UNLIMITED);
+av_bprint_init(, 1, INT_MAX); /* (int)dstbuf.len must be >= 0 */
av_bprint_escape(, src, special_chars, mode, flags);
if (!av_bprint_is_complete()) {
--
2.27.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] [PATCH 2/8] avcodec/h264_cavlc: Remove redundant check
The only caller to ff_h264_decode_init_vlc() already uses
ff_thread_once() for the call; ergo the check via a simple int with
static storage duration in ff_h264_decode_init_vlc() is redundant.
And if it were not redundant, it would be a potential for data races.
So remove it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_cavlc.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
index 6481992e58..d0548d84f6 100644
--- a/libavcodec/h264_cavlc.c
+++ b/libavcodec/h264_cavlc.c
@@ -325,12 +325,8 @@ static av_cold void init_cavlc_level_tab(void){
}
av_cold void ff_h264_decode_init_vlc(void){
-static int done = 0;
-
-if (!done) {
int i;
int offset;
-done = 1;
chroma_dc_coeff_token_vlc.table = chroma_dc_coeff_token_vlc_table;
chroma_dc_coeff_token_vlc.table_allocated =
chroma_dc_coeff_token_vlc_table_size;
@@ -410,7 +406,6 @@ av_cold void ff_h264_decode_init_vlc(void){
INIT_VLC_USE_NEW_STATIC);
init_cavlc_level_tab();
-}
}
static inline int get_level_prefix(GetBitContext *gb){
--
2.27.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] [PATCH 6/8] avcodec/cbs_sei: Don't use -1th element of array
(This affected only suffix SEI messages; yet no such SEI messages are
currently inserted.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_sei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs_sei.c b/libavcodec/cbs_sei.c
index c49830ad77..2a96db9674 100644
--- a/libavcodec/cbs_sei.c
+++ b/libavcodec/cbs_sei.c
@@ -166,7 +166,7 @@ static int cbs_sei_get_unit(CodedBitstreamContext *ctx,
}
if (i < 0) {
// No VCL units; just put it at the end.
-position = -1;
+position = au->nb_units;
} else {
position = i + 1;
}
--
2.27.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] [PATCH 7/8] avcodec/cbs_sei: Fix leak of AVBufferRef on error
An AVBufferRef (and the corresponding AVBuffer and the underlying actual
buffer) would leak in ff_cbs_sei_add_message() on error in case an error
happened after its creation and before it has been attached to more
permanent storage. Fix this by only creating the AVBufferRef immediately
before attaching it to its intended target position.
(Given that no SEI message currently created is refcounted, the above
can't happen at the moment. But Coverity already nevertheless noticed:
This commit fixes Coverity issue #1473521.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_sei.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/cbs_sei.c b/libavcodec/cbs_sei.c
index 2a96db9674..141e97ec58 100644
--- a/libavcodec/cbs_sei.c
+++ b/libavcodec/cbs_sei.c
@@ -262,14 +262,6 @@ int ff_cbs_sei_add_message(CodedBitstreamContext *ctx,
if (!desc)
return AVERROR(EINVAL);
-if (payload_buf) {
-payload_ref = av_buffer_ref(payload_buf);
-if (!payload_ref)
-return AVERROR(ENOMEM);
-} else {
-payload_ref = NULL;
-}
-
// Find an existing SEI unit or make a new one to add to.
err = cbs_sei_get_unit(ctx, au, prefix, );
if (err < 0)
@@ -285,6 +277,14 @@ int ff_cbs_sei_add_message(CodedBitstreamContext *ctx,
if (err < 0)
return err;
+if (payload_buf) {
+payload_ref = av_buffer_ref(payload_buf);
+if (!payload_ref)
+return AVERROR(ENOMEM);
+} else {
+payload_ref = NULL;
+}
+
message = >messages[list->nb_messages - 1];
message->payload_type = payload_type;
--
2.27.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] [PATCH 3/8] avcodec/h264_cavlc: Reindent after the previous commit
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_cavlc.c | 152
1 file changed, 76 insertions(+), 76 deletions(-)
diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
index d0548d84f6..9f5f692331 100644
--- a/libavcodec/h264_cavlc.c
+++ b/libavcodec/h264_cavlc.c
@@ -324,88 +324,88 @@ static av_cold void init_cavlc_level_tab(void){
}
}
-av_cold void ff_h264_decode_init_vlc(void){
-int i;
-int offset;
-
-chroma_dc_coeff_token_vlc.table = chroma_dc_coeff_token_vlc_table;
-chroma_dc_coeff_token_vlc.table_allocated =
chroma_dc_coeff_token_vlc_table_size;
-init_vlc(_dc_coeff_token_vlc, CHROMA_DC_COEFF_TOKEN_VLC_BITS,
4*5,
- _dc_coeff_token_len [0], 1, 1,
- _dc_coeff_token_bits[0], 1, 1,
+av_cold void ff_h264_decode_init_vlc(void)
+{
+int offset;
+
+chroma_dc_coeff_token_vlc.table = chroma_dc_coeff_token_vlc_table;
+chroma_dc_coeff_token_vlc.table_allocated =
chroma_dc_coeff_token_vlc_table_size;
+init_vlc(_dc_coeff_token_vlc, CHROMA_DC_COEFF_TOKEN_VLC_BITS, 4*5,
+ _dc_coeff_token_len [0], 1, 1,
+ _dc_coeff_token_bits[0], 1, 1,
+ INIT_VLC_USE_NEW_STATIC);
+
+chroma422_dc_coeff_token_vlc.table = chroma422_dc_coeff_token_vlc_table;
+chroma422_dc_coeff_token_vlc.table_allocated =
chroma422_dc_coeff_token_vlc_table_size;
+init_vlc(_dc_coeff_token_vlc, CHROMA422_DC_COEFF_TOKEN_VLC_BITS,
4*9,
+ _dc_coeff_token_len [0], 1, 1,
+ _dc_coeff_token_bits[0], 1, 1,
+ INIT_VLC_USE_NEW_STATIC);
+
+offset = 0;
+for (int i = 0; i < 4; i++) {
+coeff_token_vlc[i].table = coeff_token_vlc_tables + offset;
+coeff_token_vlc[i].table_allocated = coeff_token_vlc_tables_size[i];
+init_vlc(_token_vlc[i], COEFF_TOKEN_VLC_BITS, 4*17,
+ _token_len [i][0], 1, 1,
+ _token_bits[i][0], 1, 1,
INIT_VLC_USE_NEW_STATIC);
-
-chroma422_dc_coeff_token_vlc.table =
chroma422_dc_coeff_token_vlc_table;
-chroma422_dc_coeff_token_vlc.table_allocated =
chroma422_dc_coeff_token_vlc_table_size;
-init_vlc(_dc_coeff_token_vlc,
CHROMA422_DC_COEFF_TOKEN_VLC_BITS, 4*9,
- _dc_coeff_token_len [0], 1, 1,
- _dc_coeff_token_bits[0], 1, 1,
+offset += coeff_token_vlc_tables_size[i];
+}
+/*
+ * This is a one time safety check to make sure that
+ * the packed static coeff_token_vlc table sizes
+ * were initialized correctly.
+ */
+av_assert0(offset == FF_ARRAY_ELEMS(coeff_token_vlc_tables));
+
+for (int i = 0; i < 3; i++) {
+chroma_dc_total_zeros_vlc[i + 1].table =
chroma_dc_total_zeros_vlc_tables[i];
+chroma_dc_total_zeros_vlc[i + 1].table_allocated =
chroma_dc_total_zeros_vlc_tables_size;
+init_vlc(_dc_total_zeros_vlc[i + 1],
+ CHROMA_DC_TOTAL_ZEROS_VLC_BITS, 4,
+ _dc_total_zeros_len [i][0], 1, 1,
+ _dc_total_zeros_bits[i][0], 1, 1,
INIT_VLC_USE_NEW_STATIC);
+}
-offset = 0;
-for(i=0; i<4; i++){
-coeff_token_vlc[i].table = coeff_token_vlc_tables+offset;
-coeff_token_vlc[i].table_allocated =
coeff_token_vlc_tables_size[i];
-init_vlc(_token_vlc[i], COEFF_TOKEN_VLC_BITS, 4*17,
- _token_len [i][0], 1, 1,
- _token_bits[i][0], 1, 1,
- INIT_VLC_USE_NEW_STATIC);
-offset += coeff_token_vlc_tables_size[i];
-}
-/*
- * This is a one time safety check to make sure that
- * the packed static coeff_token_vlc table sizes
- * were initialized correctly.
- */
-av_assert0(offset == FF_ARRAY_ELEMS(coeff_token_vlc_tables));
-
-for(i=0; i<3; i++){
-chroma_dc_total_zeros_vlc[i+1].table =
chroma_dc_total_zeros_vlc_tables[i];
-chroma_dc_total_zeros_vlc[i+1].table_allocated =
chroma_dc_total_zeros_vlc_tables_size;
-init_vlc(_dc_total_zeros_vlc[i+1],
- CHROMA_DC_TOTAL_ZEROS_VLC_BITS, 4,
- _dc_total_zeros_len [i][0], 1, 1,
- _dc_total_zeros_bits[i][0], 1, 1,
- INIT_VLC_USE_NEW_STATIC);
-}
-
-for(i=0; i<7; i++){
-chroma422_dc_total_zeros_vlc[i+1].table =
chroma422_dc_total_zeros_vlc_tables[i];
-chroma422_dc_total_zeros_vlc[i+1].table_allocated =
chroma422_dc_total_zeros_vlc_tables_size;
-init_vlc(_dc_total_zeros_vlc[i+1],
- CHROMA422_DC_TOTAL_ZEROS_VLC_BITS, 8,
- _dc_total_zeros_len [i][0], 1, 1,
- _dc_total_zeros_bits[i][0], 1, 1,
- INIT_VLC_USE_NEW_STATIC);
-}
-
-for(i=0; i<15; i++){
-total_zeros_vlc[i+1].table =
[FFmpeg-devel] [PATCH 8/8] avfilter/vf_nnedi: Fix use of uninitialized value
Fixes Coverity issue #1473546.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_nnedi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_nnedi.c b/libavfilter/vf_nnedi.c
index 4229150668..b273c13944 100644
--- a/libavfilter/vf_nnedi.c
+++ b/libavfilter/vf_nnedi.c
@@ -903,7 +903,7 @@ static void subtract_mean_predictor(PredictorCoefficients
*model)
double softmax_means[256]; // Average of individual softmax filters.
double elliott_means[256]; // Average of individual elliott filters.
-double mean_filter[48 * 6]; // Pointwise average of all softmax filters.
+double mean_filter[48 * 6] = { 0 }; // Pointwise average of all softmax
filters.
double mean_bias;
// Quality 1.
--
2.27.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] [PATCH 5/8] avutil/avstring: Check for memory allocation error in av_escape
av_bprint_finalize() can still fail even when it has been checked that
the AVBPrint is currently complete: Namely if the string was so short
that it fit into the AVBPrint's internal buffer.
Signed-off-by: Andreas Rheinhardt
---
libavutil/avstring.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index 832bec750f..49e8df55aa 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -336,6 +336,7 @@ int av_escape(char **dst, const char *src, const char
*special_chars,
enum AVEscapeMode mode, int flags)
{
AVBPrint dstbuf;
+int ret;
av_bprint_init(, 1, INT_MAX); /* (int)dstbuf.len must be >= 0 */
av_bprint_escape(, src, special_chars, mode, flags);
@@ -343,10 +344,10 @@ int av_escape(char **dst, const char *src, const char
*special_chars,
if (!av_bprint_is_complete()) {
av_bprint_finalize(, NULL);
return AVERROR(ENOMEM);
-} else {
-av_bprint_finalize(, dst);
-return dstbuf.len;
}
+if ((ret = av_bprint_finalize(, dst)) < 0)
+return ret;
+return dstbuf.len;
}
int av_match_name(const char *name, const char *names)
--
2.27.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] [PATCH 1/8] avcodec/cbs: Remove redundant checks for CodedBitstreamContext.codec
Setting this field happens immediately after the allocation in
ff_cbs_init(), so the whole CBS code may presume that any
CodedBitstreamContext has this set. Lots of code already presumed this,
yet ff_cbs_close() did it inconsistently: It checked before checking
whether the CodedBitstreamType has a close function; yet it simply
unconditionally read ctx->codec->priv_class. Coverity complained about
this in issue #1473564, which this commit fixes.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index ecf22b3fdb..c7f69845fb 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -94,7 +94,7 @@ int ff_cbs_init(CodedBitstreamContext **ctx_ptr,
return AVERROR(ENOMEM);
ctx->log_ctx = log_ctx;
-ctx->codec = type;
+ctx->codec = type; /* Must be before any error */
if (type->priv_data_size) {
ctx->priv_data = av_mallocz(ctx->codec->priv_data_size);
@@ -119,7 +119,7 @@ int ff_cbs_init(CodedBitstreamContext **ctx_ptr,
void ff_cbs_flush(CodedBitstreamContext *ctx)
{
-if (ctx->codec && ctx->codec->flush)
+if (ctx->codec->flush)
ctx->codec->flush(ctx);
}
@@ -130,7 +130,7 @@ void ff_cbs_close(CodedBitstreamContext **ctx_ptr)
if (!ctx)
return;
-if (ctx->codec && ctx->codec->close)
+if (ctx->codec->close)
ctx->codec->close(ctx);
av_freep(>write_buffer);
--
2.27.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] FFmpeg 4.4
On 3/9/2021 3:47 PM, Michael Niedermayer wrote: Hi all I will branch release/4.4 soon then like always leave some time for testing, bugfixes, ... and then make FFmeg 4.4 from release/4.4, its too long since 4.3 These three AviSynth demuxer patches should probably go in before 4.4: http://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/264269.html http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/275893.html http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276389.html That third one especially. ___ 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] lavfi: add a libplacebo filter
Mar 9, 2021, 23:36 by ffm...@haasn.xyz: > On Tue, 09 Mar 2021 22:53:18 +0100 Lynne wrote: > >> Sorry, as we discussed on IRC the Vulkan hwcontext should be >> improved first and this filter should be kept as a pure hardware >> filter. >> > > I changed my mind on this because: > > - I think it's reasonably self-contained as is, and actually simpler to > implement this way. > It's simpler because it makes no effort to integrate with anything we use. > - There's no duplication of code within this patch. > There is, it's just hidden in libplacebo. If you integrate with the framework code like in the previous PR, there's no duplication. And no, we will not be removing the current Vulkan filters and we intend to continue expanding them. Not even if you add similar filters to libplacebo. > - Sharing the VkImages directly is simply not a good approach. It > creates an unnecessary API hassle (as demonstrated by the multitude of > solved and unsolved issues surrounding device negotiation, > synchronization, etc.) > It's a good approach since API users work with VkImages. It's more complex because it's explicit. > - Therefore, it's better to share using an agreed-upon mechanism like > a shared memory object exported/imported using the Vulkan API. > There is a generic shared hardware memory export/import format, it's called Vulkan, this is partly why it was created. > - A good API for this already exists (dmabufs). > See above. > - You can already derive a drm device from a vulkan device and export > vulkan hwframes as drmprime frames. > With an extension. Only supported on Linux. Only supported on recent AMD cards and drivers. Which is also buggy and crashes drivers. And the Intel implementation has been sitting as a PR for more than 3 years! You may have the privilege of using it because you lucked out on hardware, but the rest of us are not so lucky. > I plan on adding support for drmprime frames to this filter, which I > think is the cleaner way to avoid the upload/download. But I wanted to > get feedback on the current version, since it's *functionally* complete > as-is. > I won't accept adding drmprime filtering functionality either. This is a pure hardware Vulkan filtering infrastructure. We keep nothing hidden from users when it comes to filtering. > If you're worried about dmabufs being a Linux-only API, I would still > rather see an approach based on Vulkan memory object imports/exports > rather than attempting to share and synchronize the VkImages directly. > Windows still accounts for a huge amount of our userbase. Even on servers which do encoding. And so does Nvidia hardware. In fact, Nvidia transcoding setups are the major users of hardware filtering. > Even just the fact that we can't each enable extensions/features we want > enabled independently is a reason that trying to share a single vulkan > device is a bad idea. Right now the result of that is that vf_libplacebo > atop hwcontext_vulkan would simply be missing out on features and > performance, compared to this version. > That's plain wrong. We wouldn't be missing out on features. I'm sorry, but I'm not going to change my mind on this. I'd really appreciate your suggestions elsewhere, particularly in the are of making our libraries interoperable. ___ 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] lavfi: add a libplacebo filter
On Tue, 09 Mar 2021 22:53:18 +0100 Lynne wrote: > Sorry, as we discussed on IRC the Vulkan hwcontext should be > improved first and this filter should be kept as a pure hardware > filter. I changed my mind on this because: - I think it's reasonably self-contained as is, and actually simpler to implement this way. - There's no duplication of code within this patch. - Sharing the VkImages directly is simply not a good approach. It creates an unnecessary API hassle (as demonstrated by the multitude of solved and unsolved issues surrounding device negotiation, synchronization, etc.) - Therefore, it's better to share using an agreed-upon mechanism like a shared memory object exported/imported using the Vulkan API. - A good API for this already exists (dmabufs). - You can already derive a drm device from a vulkan device and export vulkan hwframes as drmprime frames. I plan on adding support for drmprime frames to this filter, which I think is the cleaner way to avoid the upload/download. But I wanted to get feedback on the current version, since it's *functionally* complete as-is. If you're worried about dmabufs being a Linux-only API, I would still rather see an approach based on Vulkan memory object imports/exports rather than attempting to share and synchronize the VkImages directly. Even just the fact that we can't each enable extensions/features we want enabled independently is a reason that trying to share a single vulkan device is a bad idea. Right now the result of that is that vf_libplacebo atop hwcontext_vulkan would simply be missing out on features and performance, compared to this version. ___ 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] FFmpeg 4.4
On Tue, Mar 9, 2021 at 10:37 PM Willem Riede wrote: > > If I may ask: will that incorporate the AC-4 patches? > The branch will be made from master, if master does not contain them at that point (which it does not right now), then no. - Hendrik ___ 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] lavfi: add a libplacebo filter
On 3/9/2021 6:53 PM, Lynne wrote: Mar 9, 2021, 17:38 by ffm...@haasn.xyz: From: Niklas Haas This filter conceptually maps the libplacebo `pl_renderer` API into libavfilter, which is a high-level image rendering API designed to work with an RGB pipeline internally. As such, there's no way to avoid e.g. chroma interpolation with this filter, although new versions of libplacebo support outputting back to subsampled YCbCr after processing is done. That being said, `pl_renderer` supports automatic integration of the majority of libplacebo's shaders, ranging from debanding to tone mapping, and also supports loading custom mpv-style user shaders, making this API a natural candidate for getting a lot of functionality out of relatively little code. In the future, I may approach this problem either by rewriting this filter to also support a non-renderer codepath, or by upgrading libplacebo's renderer to support a full YCbCr pipeline. It's worth noting that this filter could be extended in the future to support HWframes frames of type AV_PIX_FMT_VULKAN, but this is not currently possible due to API limitations in the vulkan hwaccel. (Although it's also worth pointing out that, apart from a single `pl_vulkan_create` call, the current `vf_libplacebo` code does not depend on vulkan at all - so in theory it could be extended to support OpenGL or other libplacebo backends) Sorry, as we discussed on IRC the Vulkan hwcontext should be improved first and this filter should be kept as a pure hardware filter. Can you explain why should it be a pure hardware filter? Why can't it be committed like this now, then updated to use the Vulkan hwcontext once you improve it? I'm sorry, I know I've been holding up this patch for a few months, but could you wait until I do my job with the hwcontext? I'm already working on dozens of different things and I don't need extra pressure. Others can discuss filter options and such, but do keep in mind this isn't going to be the final version. ___ 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] lavfi: add a libplacebo filter
Mar 9, 2021, 17:38 by ffm...@haasn.xyz: > From: Niklas Haas > > This filter conceptually maps the libplacebo `pl_renderer` API into > libavfilter, which is a high-level image rendering API designed to work > with an RGB pipeline internally. As such, there's no way to avoid e.g. > chroma interpolation with this filter, although new versions of > libplacebo support outputting back to subsampled YCbCr after processing > is done. > > That being said, `pl_renderer` supports automatic integration of the > majority of libplacebo's shaders, ranging from debanding to tone > mapping, and also supports loading custom mpv-style user shaders, making > this API a natural candidate for getting a lot of functionality out of > relatively little code. > > In the future, I may approach this problem either by rewriting this > filter to also support a non-renderer codepath, or by upgrading > libplacebo's renderer to support a full YCbCr pipeline. > > It's worth noting that this filter could be extended in the future to > support HWframes frames of type AV_PIX_FMT_VULKAN, but this is not > currently possible due to API limitations in the vulkan hwaccel. > (Although it's also worth pointing out that, apart from a single > `pl_vulkan_create` call, the current `vf_libplacebo` code does not > depend on vulkan at all - so in theory it could be extended to support > OpenGL or other libplacebo backends) > Sorry, as we discussed on IRC the Vulkan hwcontext should be improved first and this filter should be kept as a pure hardware filter. I'm sorry, I know I've been holding up this patch for a few months, but could you wait until I do my job with the hwcontext? I'm already working on dozens of different things and I don't need extra pressure. Others can discuss filter options and such, but do keep in mind this isn't going to be the final version. ___ 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] FFmpeg 4.4
If I may ask: will that incorporate the AC-4 patches? Thanks, Willem Riede. On Tue, Mar 9, 2021 at 1:47 PM Michael Niedermayer wrote: > Hi all > > I will branch release/4.4 soon > then like always leave some time for testing, bugfixes, ... and then > make FFmeg 4.4 from release/4.4, its too long since 4.3 > > Thanks > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The bravest are surely those who have the clearest vision > of what is before them, glory and danger alike, and yet > notwithstanding go out to meet it. -- Thucydides > ___ > 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] avutils/opt: fix discarded-qualifiers compiler warning
On 3/9/2021 5:30 AM, Nuo Mi wrote:
On Tue, Mar 9, 2021 at 3:17 AM Chad Fraleigh wrote:
On 2/14/2021 10:12 AM, Nuo Mi wrote:
On Mon, Feb 15, 2021 at 2:08 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
Nuo Mi:
---
libavutil/opt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 590146b5fb..c554e9c063 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -1735,7 +1735,7 @@ const AVClass *av_opt_child_class_iterate(const
AVClass *parent, void **iter)
#if FF_API_CHILD_CLASS_NEXT
FF_DISABLE_DEPRECATION_WARNINGS
if (parent->child_class_next) {
-*iter = parent->child_class_next(*iter);
+*iter = (void*)parent->child_class_next(*iter);
return *iter;
}
FF_ENABLE_DEPRECATION_WARNINGS
This doesn't look like a fix; you just silenced a warning.
Yes, but this the only way if we do not change the function signature.
Since a major release is "coming up", now could be the time to fix the
signature to '(..., const void **iter)' and eliminate the non-const cast
kludge across the board for these cases.
Are we plan to remove all warnings before the release?
Or more aggressively, is it feasible to treat all warnings as errors in the
future? :)
I was thinking of just the 14 or so opt iterator functions which are
assign to an AVClass.child_class_iterate (and related code in opt.c /
opt.h / their iterate callers), so they no longer have to do a de-const
(void *) cast to update *iter.
Though, it seems av_filter_iterate() and av_bsf_iterate() (maybe
others?) would need to (/should?) be changed too, as they do the same
non-const argument and are directly chained by child_class_iterate
functions.
___
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] FFmpeg 4.4
On 3/9/2021 5:47 PM, Michael Niedermayer wrote: Hi all I will branch release/4.4 soon then like always leave some time for testing, bugfixes, ... and then make FFmeg 4.4 from release/4.4, its too long since 4.3 Thanks I have three API changes/additions/deprecations on the ml, some for months now, that i want in 4.4 in order for them to be present in the last release using the current major library versions. This is so users have a good amount of time to notice them and adapt their code. It's not be as nice if they start noticing any new deprecations introduced today in a release made several months from now. These are "deprecate av_init_packet() and sizeof(AVPacket) as part of the ABI", "avutil/buffer: change public function and struct size parameter types to size_t", and "avcodec: add a get_encoder_buffer() callback to AVCodecContext". The first two still need to be LGTM's. The latter was LGTM' by Lynne, but I'm still waiting for Mark to give his. ___ 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] FFmpeg 4.4
Hi all I will branch release/4.4 soon then like always leave some time for testing, bugfixes, ... and then make FFmeg 4.4 from release/4.4, its too long since 4.3 Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides 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/2] avformat/mvdec: Allocate extradata only once
On Sat, Jan 02, 2021 at 02:22:32AM +0100, Michael Niedermayer wrote: > Fixes: memleak > Fixes: > 28686/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5822961932173312 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/mvdec.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- 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".
[FFmpeg-devel] [PATCH] avcodec/flacdec: Avoid undefined shift in error case
Fixes: flac_1040988
Reported-by: Thomas Guilbert
Signed-off-by: Michael Niedermayer
---
libavcodec/flacdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index cf6128f897..9e55bc1361 100644
--- a/libavcodec/flacdec.c
+++ b/libavcodec/flacdec.c
@@ -262,7 +262,7 @@ static int decode_residuals(FLACContext *s, int32_t
*decoded, int pred_order)
} else {
int real_limit = tmp ? (INT_MAX >> tmp) + 2 : INT_MAX;
for (; i < samples; i++) {
-int v = get_sr_golomb_flac(, tmp, real_limit, 0);
+int v = get_sr_golomb_flac(, tmp, real_limit, 1);
if (v == 0x8000){
av_log(s->avctx, AV_LOG_ERROR, "invalid residual\n");
return AVERROR_INVALIDDATA;
--
2.17.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] libavcodec/amfenc_hevc: Recommend values for min and max video quantizer scale.
On 3/9/2021 4:05 PM, Ovchinnikov Dmitrii wrote:
Current settings makes bitrate large, than expected, more information:
https://github.com/HandBrake/HandBrake/issues/3447#issue-820490736
Thanks for review! updated to "-1" values.
---
libavcodec/amfenc_hevc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 77e57d2461..890272d135 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -298,6 +298,8 @@ static const AVCodecDefault defaults[] = {
{ "b", "2M" },
{ "g", "250" },
{ "slices", "1" },
+{ "qmin", "-1" },
+{ "qmax", "-1" },
{ NULL},
};
static const AVClass hevc_amf_class = {
Applied, thanks.
___
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] lavc: replace internal use of AV_CODEC_CAP_AUTO_THREADS with an internal cap
AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9a to mark
codecs that spawn threads internally and are able to select an optimal
threads count by themselves (all such codecs are wrappers around
external libraries). It is used by lavc generic code to check whether it
should handle thread_count=0 itself or pass the zero directly to the
codec implementation. Within this meaning, it is clearly supposed to be
an internal cap rather than a public one, since from the viewpoint of a
libavcodec user, lavc ALWAYS handles thread_count=0. Whether it happens
in the generic code or within the codec internals is not a meaningful
difference for the caller.
External aspects of this flag will be dealt with in the following
commit.
---
Also applied the change to libx264 instance I missed previously
---
libavcodec/internal.h | 4
libavcodec/libaomdec.c | 1 +
libavcodec/libaomenc.c | 1 +
libavcodec/libdav1d.c | 3 ++-
libavcodec/libdavs2.c | 1 +
libavcodec/libkvazaar.c | 3 ++-
libavcodec/libopenh264enc.c | 3 ++-
libavcodec/librav1e.c | 2 +-
libavcodec/libsvtav1.c | 1 +
libavcodec/libuavs3d.c | 1 +
libavcodec/libvpxdec.c | 2 ++
libavcodec/libvpxenc.c | 2 ++
libavcodec/libx264.c| 15 ---
libavcodec/libx265.c| 1 +
libavcodec/libxavs.c| 1 +
libavcodec/libxavs2.c | 1 +
libavcodec/pthread.c| 2 +-
libavcodec/utils.c | 2 +-
18 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 400ea508ef..b57b996816 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -74,6 +74,10 @@
* uses ff_thread_report/await_progress().
*/
#define FF_CODEC_CAP_ALLOCATE_PROGRESS (1 << 6)
+/**
+ * Codec handles avctx->thread_count == 0 (auto) internally.
+ */
+#define FF_CODEC_CAP_AUTO_THREADS (1 << 7)
/**
* AVCodec.codec_tags termination value
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 1430a651fe..327a5e18fb 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -237,6 +237,7 @@ AVCodec ff_libaom_av1_decoder = {
.close = aom_free,
.decode = aom_decode,
.capabilities = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
.profiles = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
.wrapper_name = "libaom",
};
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 9a26b5f9ef..f99fdc0b73 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1346,6 +1346,7 @@ AVCodec ff_libaom_av1_encoder = {
.encode2= aom_encode,
.close = aom_free,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
+.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
.profiles = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
.priv_class = _aom,
.defaults = defaults,
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 383e4557b4..93aeab4cb1 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -485,7 +485,8 @@ AVCodec ff_libdav1d_decoder = {
.flush = libdav1d_flush,
.receive_frame = libdav1d_receive_frame,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
-.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE | FF_CODEC_CAP_SETS_PKT_DTS,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE | FF_CODEC_CAP_SETS_PKT_DTS
|
+ FF_CODEC_CAP_AUTO_THREADS,
.priv_class = _class,
.wrapper_name = "libdav1d",
};
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 218f3ec239..f6a03df373 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -222,6 +222,7 @@ AVCodec ff_libdavs2_decoder = {
.decode = davs2_decode_frame,
.flush = davs2_flush,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
+.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
.wrapper_name = "libdavs2",
diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
index d94cf995c8..f75aa4eda3 100644
--- a/libavcodec/libkvazaar.c
+++ b/libavcodec/libkvazaar.c
@@ -341,7 +341,8 @@ AVCodec ff_libkvazaar_encoder = {
.encode2 = libkvazaar_encode,
.close= libkvazaar_close,
-.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
FF_CODEC_CAP_INIT_CLEANUP,
+.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
FF_CODEC_CAP_INIT_CLEANUP |
+FF_CODEC_CAP_AUTO_THREADS,
.wrapper_name = "libkvazaar",
};
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index cf485663e1..cb5deb8b50 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -448,7 +448,8 @@
Re: [FFmpeg-devel] [PATCH V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
Anton Khirnov (12021-03-09): > Correct, I object to using private_ref even more strongly than to > private side data. > > I would prefer private_ref to be removed entirely. > > All this said, it would be acceptable to make this new side data private > (or declared unstable) for a clearly limited period of time, e.g. 3 > months or until the next major bump or so. As long as it's not internal > indefinitely. Then we are on the same page. > This is not even my claim, just something I've seen other people state > repeatedly. People find the tight coupling between filters and graphs to > be limiting. I would like to hear their arguments. Please let me know if you find more accurate instances of these complaints. Regards, -- Nicolas George 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 V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
Quoting Nicolas George (2021-03-09 10:48:50) > Anton Khirnov (12021-03-08): > > The argument for internal side data is literally that it's not good > > enough to be made public. So the option of making it private is used as > > an excuse to avoid designing the format properly. > > This reasoning would apply to using private_ref as well. So I understand > your objection is against any solution that avoids properly designing > the structure. I can easily agree with that. Correct, I object to using private_ref even more strongly than to private side data. I would prefer private_ref to be removed entirely. All this said, it would be acceptable to make this new side data private (or declared unstable) for a clearly limited period of time, e.g. 3 months or until the next major bump or so. As long as it's not internal indefinitely. > > > Lavfi is enough of a black box as it is, no need to make it even more so > > with internal side data formats. > > Please, there nothing of a black box about libavfilter. This is not even my claim, just something I've seen other people state repeatedly. People find the tight coupling between filters and graphs to be limiting. -- Anton Khirnov ___ 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] cmdutils: replace strncpy() with direct assignment
> // Change all the ' --' strings to '~--' so that
> // they can be identified as tokens.
> while ((conflist = strstr(str, " --")) != NULL) {
> -strncpy(conflist, "~--", 3);
> +conflist[0] = '~';
> }
Doesn't this simply replace -- with ~- ?
The comment seems wrong to me...
___
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] lavfi: add a libplacebo filter
Niklas Haas (12021-03-09): > From: Niklas Haas > > This filter conceptually maps the libplacebo `pl_renderer` API into > libavfilter, which is a high-level image rendering API designed to work > with an RGB pipeline internally. As such, there's no way to avoid e.g. > chroma interpolation with this filter, although new versions of > libplacebo support outputting back to subsampled YCbCr after processing > is done. > > That being said, `pl_renderer` supports automatic integration of the > majority of libplacebo's shaders, ranging from debanding to tone > mapping, and also supports loading custom mpv-style user shaders, making > this API a natural candidate for getting a lot of functionality out of > relatively little code. > > In the future, I may approach this problem either by rewriting this > filter to also support a non-renderer codepath, or by upgrading > libplacebo's renderer to support a full YCbCr pipeline. > > It's worth noting that this filter could be extended in the future to > support HWframes frames of type AV_PIX_FMT_VULKAN, but this is not > currently possible due to API limitations in the vulkan hwaccel. > (Although it's also worth pointing out that, apart from a single > `pl_vulkan_create` call, the current `vf_libplacebo` code does not > depend on vulkan at all - so in theory it could be extended to support > OpenGL or other libplacebo backends) > --- > configure | 3 + > libavfilter/Makefile| 1 + > libavfilter/allfilters.c| 1 + > libavfilter/vf_libplacebo.c | 627 > 4 files changed, 632 insertions(+) > create mode 100644 libavfilter/vf_libplacebo.c Thanks for the patch. I have not yet looked at the code itself. Please include some documentation, it would be helpful even for reviewing. Regards, -- Nicolas George 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/2] lavc: replace internal use of AV_CODEC_CAP_AUTO_THREADS with an internal cap
Anton Khirnov:
> AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9a to mark
> codecs that spawn threads internally and are able to select an optimal
> threads count by themselves (all such codecs are wrappers around
> external libraries). It is used by lavc generic code to check whether it
> should handle thread_count=0 itself or pass the zero directly to the
> codec implementation. Within this meaning, it is clearly supposed to be
> an internal cap rather than a public one, since from the viewpoint of a
> libavcodec user, lavc ALWAYS handles thread_count=0. Whether it happens
> in the generic code or within the codec internals is not a meaningful
> difference for the caller.
>
> External aspects of this flag will be dealt with in the following
> commit.
> ---
> libavcodec/internal.h | 4
> libavcodec/libaomdec.c | 1 +
> libavcodec/libaomenc.c | 1 +
> libavcodec/libdav1d.c | 3 ++-
> libavcodec/libdavs2.c | 1 +
> libavcodec/libkvazaar.c | 3 ++-
> libavcodec/libopenh264enc.c | 3 ++-
> libavcodec/librav1e.c | 2 +-
> libavcodec/libsvtav1.c | 1 +
> libavcodec/libuavs3d.c | 1 +
> libavcodec/libvpxdec.c | 2 ++
> libavcodec/libvpxenc.c | 2 ++
> libavcodec/libx264.c| 9 +
> libavcodec/libx265.c| 1 +
> libavcodec/libxavs.c| 1 +
> libavcodec/libxavs2.c | 1 +
> libavcodec/pthread.c| 2 +-
> libavcodec/utils.c | 2 +-
> 18 files changed, 30 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 400ea508ef..b57b996816 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -74,6 +74,10 @@
> * uses ff_thread_report/await_progress().
> */
> #define FF_CODEC_CAP_ALLOCATE_PROGRESS (1 << 6)
> +/**
> + * Codec handles avctx->thread_count == 0 (auto) internally.
> + */
> +#define FF_CODEC_CAP_AUTO_THREADS (1 << 7)
>
> /**
> * AVCodec.codec_tags termination value
> diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
> index 1430a651fe..327a5e18fb 100644
> --- a/libavcodec/libaomdec.c
> +++ b/libavcodec/libaomdec.c
> @@ -237,6 +237,7 @@ AVCodec ff_libaom_av1_decoder = {
> .close = aom_free,
> .decode = aom_decode,
> .capabilities = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1,
> +.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
> .profiles = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
> .wrapper_name = "libaom",
> };
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 9a26b5f9ef..f99fdc0b73 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -1346,6 +1346,7 @@ AVCodec ff_libaom_av1_encoder = {
> .encode2= aom_encode,
> .close = aom_free,
> .capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
> +.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
> .profiles = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
> .priv_class = _aom,
> .defaults = defaults,
> diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
> index 383e4557b4..93aeab4cb1 100644
> --- a/libavcodec/libdav1d.c
> +++ b/libavcodec/libdav1d.c
> @@ -485,7 +485,8 @@ AVCodec ff_libdav1d_decoder = {
> .flush = libdav1d_flush,
> .receive_frame = libdav1d_receive_frame,
> .capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
> -.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_SETS_PKT_DTS,
> +.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_SETS_PKT_DTS |
> + FF_CODEC_CAP_AUTO_THREADS,
> .priv_class = _class,
> .wrapper_name = "libdav1d",
> };
> diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
> index 218f3ec239..f6a03df373 100644
> --- a/libavcodec/libdavs2.c
> +++ b/libavcodec/libdavs2.c
> @@ -222,6 +222,7 @@ AVCodec ff_libdavs2_decoder = {
> .decode = davs2_decode_frame,
> .flush = davs2_flush,
> .capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
> +.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
> .pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
> AV_PIX_FMT_NONE },
> .wrapper_name = "libdavs2",
> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> index d94cf995c8..f75aa4eda3 100644
> --- a/libavcodec/libkvazaar.c
> +++ b/libavcodec/libkvazaar.c
> @@ -341,7 +341,8 @@ AVCodec ff_libkvazaar_encoder = {
> .encode2 = libkvazaar_encode,
> .close= libkvazaar_close,
>
> -.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_INIT_CLEANUP,
> +.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_INIT_CLEANUP |
> +FF_CODEC_CAP_AUTO_THREADS,
>
> .wrapper_name = "libkvazaar",
> };
> diff --git
[FFmpeg-devel] [PATCH] cmdutils: replace strncpy() with direct assignment
Only one character is actually rewritten.
Fixes truncation warnings, such as
warning: ‘strncpy’ output truncated before terminating nul copying 3 bytes from
a string of the same length [-Wstringop-truncation]
in gcc 10.2.0
---
fftools/cmdutils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 8cfca22564..5a457b997b 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1163,13 +1163,13 @@ static void print_buildconf(int flags, int level)
// Change all the ' --' strings to '~--' so that
// they can be identified as tokens.
while ((conflist = strstr(str, " --")) != NULL) {
-strncpy(conflist, "~--", 3);
+conflist[0] = '~';
}
// Compensate for the weirdness this would cause
// when passing 'pkg-config --static'.
while ((remove_tilde = strstr(str, "pkg-config~")) != NULL) {
-strncpy(remove_tilde, "pkg-config ", 11);
+remove_tilde[sizeof("pkg-config~") - 2] = ' ';
}
splitconf = strtok(str, "~");
--
2.30.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] [PATCH 1/2] lavc: replace internal use of AV_CODEC_CAP_AUTO_THREADS with an internal cap
AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9a to mark
codecs that spawn threads internally and are able to select an optimal
threads count by themselves (all such codecs are wrappers around
external libraries). It is used by lavc generic code to check whether it
should handle thread_count=0 itself or pass the zero directly to the
codec implementation. Within this meaning, it is clearly supposed to be
an internal cap rather than a public one, since from the viewpoint of a
libavcodec user, lavc ALWAYS handles thread_count=0. Whether it happens
in the generic code or within the codec internals is not a meaningful
difference for the caller.
External aspects of this flag will be dealt with in the following
commit.
---
libavcodec/internal.h | 4
libavcodec/libaomdec.c | 1 +
libavcodec/libaomenc.c | 1 +
libavcodec/libdav1d.c | 3 ++-
libavcodec/libdavs2.c | 1 +
libavcodec/libkvazaar.c | 3 ++-
libavcodec/libopenh264enc.c | 3 ++-
libavcodec/librav1e.c | 2 +-
libavcodec/libsvtav1.c | 1 +
libavcodec/libuavs3d.c | 1 +
libavcodec/libvpxdec.c | 2 ++
libavcodec/libvpxenc.c | 2 ++
libavcodec/libx264.c| 9 +
libavcodec/libx265.c| 1 +
libavcodec/libxavs.c| 1 +
libavcodec/libxavs2.c | 1 +
libavcodec/pthread.c| 2 +-
libavcodec/utils.c | 2 +-
18 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 400ea508ef..b57b996816 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -74,6 +74,10 @@
* uses ff_thread_report/await_progress().
*/
#define FF_CODEC_CAP_ALLOCATE_PROGRESS (1 << 6)
+/**
+ * Codec handles avctx->thread_count == 0 (auto) internally.
+ */
+#define FF_CODEC_CAP_AUTO_THREADS (1 << 7)
/**
* AVCodec.codec_tags termination value
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 1430a651fe..327a5e18fb 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -237,6 +237,7 @@ AVCodec ff_libaom_av1_decoder = {
.close = aom_free,
.decode = aom_decode,
.capabilities = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1,
+.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
.profiles = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
.wrapper_name = "libaom",
};
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 9a26b5f9ef..f99fdc0b73 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1346,6 +1346,7 @@ AVCodec ff_libaom_av1_encoder = {
.encode2= aom_encode,
.close = aom_free,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
+.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
.profiles = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
.priv_class = _aom,
.defaults = defaults,
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 383e4557b4..93aeab4cb1 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -485,7 +485,8 @@ AVCodec ff_libdav1d_decoder = {
.flush = libdav1d_flush,
.receive_frame = libdav1d_receive_frame,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
-.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE | FF_CODEC_CAP_SETS_PKT_DTS,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE | FF_CODEC_CAP_SETS_PKT_DTS
|
+ FF_CODEC_CAP_AUTO_THREADS,
.priv_class = _class,
.wrapper_name = "libdav1d",
};
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index 218f3ec239..f6a03df373 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -222,6 +222,7 @@ AVCodec ff_libdavs2_decoder = {
.decode = davs2_decode_frame,
.flush = davs2_flush,
.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
+.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P,
AV_PIX_FMT_NONE },
.wrapper_name = "libdavs2",
diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
index d94cf995c8..f75aa4eda3 100644
--- a/libavcodec/libkvazaar.c
+++ b/libavcodec/libkvazaar.c
@@ -341,7 +341,8 @@ AVCodec ff_libkvazaar_encoder = {
.encode2 = libkvazaar_encode,
.close= libkvazaar_close,
-.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
FF_CODEC_CAP_INIT_CLEANUP,
+.caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
FF_CODEC_CAP_INIT_CLEANUP |
+FF_CODEC_CAP_AUTO_THREADS,
.wrapper_name = "libkvazaar",
};
diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index cf485663e1..cb5deb8b50 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -448,7 +448,8 @@ AVCodec ff_libopenh264_encoder = {
.encode2= svc_encode_frame,
.close
[FFmpeg-devel] [PATCH 2/2] lavc: rename AV_CODEC_CAP_AUTO_THREADS->AV_CODEC_CAP_OTHER_THREADS
This cap is currently used to mark multithreading-capable codecs that
wrap external libraries with their own multithreading code. The name is
highly confusing for our API users, since libavcodec ALWAYS handles
thread_count=0 (see commit message in previous commit). Therefore rename
the cap and update its documentation to make its meaning clear.
The old name is kept deprecated until next+1 major bump.
---
doc/APIchanges | 5 +
fftools/cmdutils.c | 6 +++---
libavcodec/codec.h | 9 +++--
libavcodec/libaomdec.c | 2 +-
libavcodec/libaomenc.c | 2 +-
libavcodec/libdav1d.c | 2 +-
libavcodec/libdavs2.c | 2 +-
libavcodec/libkvazaar.c | 2 +-
libavcodec/libopenh264enc.c | 2 +-
libavcodec/librav1e.c | 2 +-
libavcodec/libsvtav1.c | 2 +-
libavcodec/libuavs3d.c | 2 +-
libavcodec/libvpxdec.c | 4 ++--
libavcodec/libvpxenc.c | 4 ++--
libavcodec/libx264.c| 6 +++---
libavcodec/libx265.c| 2 +-
libavcodec/libxavs.c| 2 +-
libavcodec/libxavs2.c | 2 +-
libavcodec/version.h| 5 -
19 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 4027d599e7..1ad67c2f2d 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2017-10-21
API changes, most recent first:
+2021-03-xx - xx - lavc 58.130.100 - codec.h
+ Add AV_CODEC_CAP_OTHER_THREADS as a new name for
+ AV_CODEC_CAP_AUTO_THREADS. AV_CODEC_CAP_AUTO_THREADS
+ is now deprecated.
+
2021-03-04 - xx - lavc 58.128.101 - avcodec.h
Enable err_recognition to be set for encoders.
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 8cfca22564..5e2d3c174b 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1415,7 +1415,7 @@ static void print_codec(const AVCodec *c)
printf("variable ");
if (c->capabilities & (AV_CODEC_CAP_FRAME_THREADS |
AV_CODEC_CAP_SLICE_THREADS |
- AV_CODEC_CAP_AUTO_THREADS))
+ AV_CODEC_CAP_OTHER_THREADS))
printf("threads ");
if (c->capabilities & AV_CODEC_CAP_AVOID_PROBING)
printf("avoidprobe ");
@@ -1432,12 +1432,12 @@ static void print_codec(const AVCodec *c)
printf("Threading capabilities: ");
switch (c->capabilities & (AV_CODEC_CAP_FRAME_THREADS |
AV_CODEC_CAP_SLICE_THREADS |
- AV_CODEC_CAP_AUTO_THREADS)) {
+ AV_CODEC_CAP_OTHER_THREADS)) {
case AV_CODEC_CAP_FRAME_THREADS |
AV_CODEC_CAP_SLICE_THREADS: printf("frame and slice"); break;
case AV_CODEC_CAP_FRAME_THREADS: printf("frame"); break;
case AV_CODEC_CAP_SLICE_THREADS: printf("slice"); break;
-case AV_CODEC_CAP_AUTO_THREADS : printf("auto");break;
+case AV_CODEC_CAP_OTHER_THREADS: printf("other"); break;
default: printf("none");break;
}
printf("\n");
diff --git a/libavcodec/codec.h b/libavcodec/codec.h
index 729df0e304..1ef07d36b0 100644
--- a/libavcodec/codec.h
+++ b/libavcodec/codec.h
@@ -113,9 +113,14 @@
*/
#define AV_CODEC_CAP_PARAM_CHANGE(1 << 14)
/**
- * Codec supports avctx->thread_count == 0 (auto).
+ * Codec supports multithreading through a method other than slice- or
+ * frame-level multithreading. Typically this marks wrappers around
+ * multithreading-capable external libraries.
*/
-#define AV_CODEC_CAP_AUTO_THREADS(1 << 15)
+#define AV_CODEC_CAP_OTHER_THREADS (1 << 15)
+#if FF_API_AUTO_THREADS
+#define AV_CODEC_CAP_AUTO_THREADSAV_CODEC_CAP_OTHER_THREADS
+#endif
/**
* Audio encoder supports receiving a different number of samples in each call.
*/
diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
index 327a5e18fb..1fc0a0001d 100644
--- a/libavcodec/libaomdec.c
+++ b/libavcodec/libaomdec.c
@@ -236,7 +236,7 @@ AVCodec ff_libaom_av1_decoder = {
.init = av1_init,
.close = aom_free,
.decode = aom_decode,
-.capabilities = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1,
+.capabilities = AV_CODEC_CAP_OTHER_THREADS | AV_CODEC_CAP_DR1,
.caps_internal = FF_CODEC_CAP_AUTO_THREADS,
.profiles = NULL_IF_CONFIG_SMALL(ff_av1_profiles),
.wrapper_name = "libaom",
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index f99fdc0b73..2c3c3eb185 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1345,7 +1345,7 @@ AVCodec ff_libaom_av1_encoder = {
.init = av1_init,
.encode2= aom_encode,
.close = aom_free,
-.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AUTO_THREADS,
+.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
.caps_internal =
Re: [FFmpeg-devel] [PATCH] lavfi: add a libplacebo filter
On 3/9/2021 2:18 PM, Niklas Haas wrote:
On Tue, 09 Mar 2021 13:53:20 -0300 James Almer wrote:
On 3/9/2021 1:38 PM, Niklas Haas wrote:
+if (s->skip_av1_grain)
+image.av1_grain = (struct pl_av1_grain_data) {0};
[...]
+if (!s->skip_av1_grain)
+av_frame_remove_side_data(out, AV_FRAME_DATA_FILM_GRAIN_PARAMS);
[...]
+{ "skip_av1_grain", "Disable AV1 grain application",
OFFSET(skip_av1_grain), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DYNAMIC },
How does this work? Does pl_upload_avframe() support parsing the
filmgrain side data? If so, that's pretty cool.
Yes. More specifically, `pl_frame_from_avframe` translates the film
grain side data into `pl_av1_grain_data`, and `pl_render_image` applies
film grain using a compute shader.
Also, I'd prefer if this was inverted. So make it filmgrain or maybe
apply_filmgrain, and of course set it to 1 by default. And it doesn't
need to specify it's for AV1 since the AV_FRAME_DATA_FILM_GRAIN_PARAMS
side data type could be extended to support the H.274 implementation in
the future.
This makes sense. Changed. Upon further consideration, I'm also not sure
if this should really be enabled by default. As I understand it, this
side data is only present if the user specifically disabled film grain
application in the decoder, so overriding that by just moving it to
vf_libplacebo seems like a surprising default.
Yes, film grain is exported as side data instead of being applied by the
decoder when the AV_CODEC_EXPORT_DATA_FILM_GRAIN flag is set in the
AVCodecContext export_side_data field.
So yeah, disabled by default sounds better. The caller may not want
vf_libplacebo to apply it, and instead leave that to some other filter
in the chain, or just use it in some other way after getting the
resulting AVFrame.
___
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] lavfi: add a libplacebo filter
On Tue, 09 Mar 2021 13:53:20 -0300 James Almer wrote:
> On 3/9/2021 1:38 PM, Niklas Haas wrote:
> > +if (s->skip_av1_grain)
> > +image.av1_grain = (struct pl_av1_grain_data) {0};
>
> [...]
>
> > +if (!s->skip_av1_grain)
> > +av_frame_remove_side_data(out, AV_FRAME_DATA_FILM_GRAIN_PARAMS);
>
> [...]
>
> > +{ "skip_av1_grain", "Disable AV1 grain application",
> > OFFSET(skip_av1_grain), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DYNAMIC },
>
> How does this work? Does pl_upload_avframe() support parsing the
> filmgrain side data? If so, that's pretty cool.
Yes. More specifically, `pl_frame_from_avframe` translates the film
grain side data into `pl_av1_grain_data`, and `pl_render_image` applies
film grain using a compute shader.
> Also, I'd prefer if this was inverted. So make it filmgrain or maybe
> apply_filmgrain, and of course set it to 1 by default. And it doesn't
> need to specify it's for AV1 since the AV_FRAME_DATA_FILM_GRAIN_PARAMS
> side data type could be extended to support the H.274 implementation in
> the future.
This makes sense. Changed. Upon further consideration, I'm also not sure
if this should really be enabled by default. As I understand it, this
side data is only present if the user specifically disabled film grain
application in the decoder, so overriding that by just moving it to
vf_libplacebo seems like a surprising default.
___
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] lavfi: add a libplacebo filter
On 3/9/2021 1:38 PM, Niklas Haas wrote:
+if (s->skip_av1_grain)
+image.av1_grain = (struct pl_av1_grain_data) {0};
[...]
+if (!s->skip_av1_grain)
+av_frame_remove_side_data(out, AV_FRAME_DATA_FILM_GRAIN_PARAMS);
[...]
+{ "skip_av1_grain", "Disable AV1 grain application",
OFFSET(skip_av1_grain), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DYNAMIC },
How does this work? Does pl_upload_avframe() support parsing the
filmgrain side data? If so, that's pretty cool.
Also, I'd prefer if this was inverted. So make it filmgrain or maybe
apply_filmgrain, and of course set it to 1 by default. And it doesn't
need to specify it's for AV1 since the AV_FRAME_DATA_FILM_GRAIN_PARAMS
side data type could be extended to support the H.274 implementation in
the future.
___
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] lavfi: add a libplacebo filter
From: Niklas Haas
This filter conceptually maps the libplacebo `pl_renderer` API into
libavfilter, which is a high-level image rendering API designed to work
with an RGB pipeline internally. As such, there's no way to avoid e.g.
chroma interpolation with this filter, although new versions of
libplacebo support outputting back to subsampled YCbCr after processing
is done.
That being said, `pl_renderer` supports automatic integration of the
majority of libplacebo's shaders, ranging from debanding to tone
mapping, and also supports loading custom mpv-style user shaders, making
this API a natural candidate for getting a lot of functionality out of
relatively little code.
In the future, I may approach this problem either by rewriting this
filter to also support a non-renderer codepath, or by upgrading
libplacebo's renderer to support a full YCbCr pipeline.
It's worth noting that this filter could be extended in the future to
support HWframes frames of type AV_PIX_FMT_VULKAN, but this is not
currently possible due to API limitations in the vulkan hwaccel.
(Although it's also worth pointing out that, apart from a single
`pl_vulkan_create` call, the current `vf_libplacebo` code does not
depend on vulkan at all - so in theory it could be extended to support
OpenGL or other libplacebo backends)
---
configure | 3 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_libplacebo.c | 627
4 files changed, 632 insertions(+)
create mode 100644 libavfilter/vf_libplacebo.c
diff --git a/configure b/configure
index d11942fced..859f9de93b 100755
--- a/configure
+++ b/configure
@@ -1794,6 +1794,7 @@ EXTERNAL_LIBRARY_LIST="
libopenmpt
libopenvino
libopus
+libplacebo
libpulse
librabbitmq
librav1e
@@ -3574,6 +3575,7 @@ interlace_filter_deps="gpl"
kerndeint_filter_deps="gpl"
ladspa_filter_deps="ladspa libdl"
lensfun_filter_deps="liblensfun version3"
+libplacebo_filter_deps="libplacebo"
lv2_filter_deps="lv2"
mcdeint_filter_deps="avcodec gpl"
movie_filter_deps="avcodec avformat"
@@ -6406,6 +6408,7 @@ enabled libopus && {
require_pkg_config libopus opus opus_multistream.h
opus_multistream_surround_encoder_create
}
}
+enabled libplacebo&& require_pkg_config libplacebo "libplacebo >=
3.116.0" libplacebo/vulkan.h pl_vulkan_create
enabled libpulse && require_pkg_config libpulse libpulse
pulse/pulseaudio.h pa_context_new
enabled librabbitmq && require_pkg_config librabbitmq "librabbitmq >=
0.7.1" amqp.h amqp_new_connection
enabled librav1e && require_pkg_config librav1e "rav1e >= 0.4.0"
rav1e.h rav1e_context_new
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b2c254ea67..aed1abb374 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -310,6 +310,7 @@ OBJS-$(CONFIG_KIRSCH_FILTER) +=
vf_convolution.o
OBJS-$(CONFIG_LAGFUN_FILTER) += vf_lagfun.o
OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
OBJS-$(CONFIG_LENSFUN_FILTER)+= vf_lensfun.o
+OBJS-$(CONFIG_LIBPLACEBO_FILTER) += vf_libplacebo.o
OBJS-$(CONFIG_LIBVMAF_FILTER)+= vf_libvmaf.o framesync.o
OBJS-$(CONFIG_LIMITER_FILTER)+= vf_limiter.o
OBJS-$(CONFIG_LOOP_FILTER) += f_loop.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 0872c6e0f2..07a411f19e 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -294,6 +294,7 @@ extern AVFilter ff_vf_kirsch;
extern AVFilter ff_vf_lagfun;
extern AVFilter ff_vf_lenscorrection;
extern AVFilter ff_vf_lensfun;
+extern AVFilter ff_vf_libplacebo;
extern AVFilter ff_vf_libvmaf;
extern AVFilter ff_vf_limiter;
extern AVFilter ff_vf_loop;
diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
new file mode 100644
index 00..583def9a1c
--- /dev/null
+++ b/libavfilter/vf_libplacebo.c
@@ -0,0 +1,627 @@
+/*
+ * 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/file.h"
+#include "libavutil/opt.h"
+#include "internal.h"
+#include "scale_eval.h"
+
+#include
+#include
+#include
+
+typedef struct
Re: [FFmpeg-devel] [PATCH] libavcodec/amfenc_hevc: Recommend values for min and max video quantizer scale.
Hi, Am 09.03.21 um 16:57 schrieb Ovchinnikov Dmitrii: > Current settings makes bitrate large, than expected, more information: > https://github.com/HandBrake/HandBrake/issues/3447#issue-820490736 I agree to the comments on your issue tracker[1], that it would be better to solve this by setting qmin/qmax explicitly in handbrake (or whatever application) than by changing their defaults. [1] https://github.com/HandBrake/HandBrake/issues/3447#issuecomment-790178099 -Thilo ___ 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] libavcodec/amfenc_hevc: Recommend values for min and max video quantizer scale.
On 3/9/2021 12:57 PM, Ovchinnikov Dmitrii wrote:
Current settings makes bitrate large, than expected, more information:
https://github.com/HandBrake/HandBrake/issues/3447#issue-820490736
---
libavcodec/amfenc_hevc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
index 77e57d2461..890272d135 100644
--- a/libavcodec/amfenc_hevc.c
+++ b/libavcodec/amfenc_hevc.c
@@ -298,6 +298,8 @@ static const AVCodecDefault defaults[] = {
{ "b", "2M" },
{ "g", "250" },
{ "slices", "1" },
+{ "qmin", "0" },
+{ "qmax", "51" },
How about setting both to -1 instead? That way the encoder defaults
would be used. Assuming there are any, and initialization will not fail
if neither {min,max}_qp_{i,p} and qmin/qmax are set.
{ NULL},
};
static const AVClass hevc_amf_class = {
___
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] nvenc: Fix output dts if encoding with implicitly enabled b-frames
On Tue, 9 Mar 2021, Martin Storsjö wrote:
Since a0949d0bcb0eee2f3fffcf9a4810c0295d14c0dc, the b-frames
setting defaults to -1, which uses the preset's default setting.
If b-frames are enabled, but max_b_frames is kept at <= 0, the
output dts are inconsistent.
---
libavcodec/nvenc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a061dee880..6baeec6d36 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1380,8 +1380,11 @@ static av_cold int nvenc_setup_encoder(AVCodecContext
*avctx)
if (res < 0)
return res;
-if (ctx->encode_config.frameIntervalP > 1)
+if (ctx->encode_config.frameIntervalP > 1) {
avctx->has_b_frames = 2;
+if (avctx->max_b_frames <= 0)
+avctx->max_b_frames = 1;
+}
Or maybe we just should change nvenc_set_timestamp to use has_b_frames
instead if max_b_frames, iirc that's what's used to signal the number of
frames to offset dts elsewhere?
Also, as long as the encoder doesn't use something like b-pyramid,
shifting dts by 1 should be enough, regardless of the number of b-frames
between p-frames.
// Martin
___
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] avutils/opt: fix discarded-qualifiers compiler warning
Nuo Mi (12021-03-09): > Or more aggressively, is it feasible to treat all warnings as errors in the > future? :) No. Warnings come and go, and a lot of new warnings are bogus. For example the new warning that tells you that snprintf(buf, sizeof(buf), "%d", x) will overflow if sizeof(buf) < 11 even though we know that x is between 0 and 10. Regards, -- Nicolas George 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] avutils/opt: fix discarded-qualifiers compiler warning
On Tue, Mar 9, 2021 at 3:17 AM Chad Fraleigh wrote:
> On 2/14/2021 10:12 AM, Nuo Mi wrote:
> > On Mon, Feb 15, 2021 at 2:08 AM Andreas Rheinhardt <
> > andreas.rheinha...@gmail.com> wrote:
> >
> >> Nuo Mi:
> >>> ---
> >>> libavutil/opt.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavutil/opt.c b/libavutil/opt.c
> >>> index 590146b5fb..c554e9c063 100644
> >>> --- a/libavutil/opt.c
> >>> +++ b/libavutil/opt.c
> >>> @@ -1735,7 +1735,7 @@ const AVClass *av_opt_child_class_iterate(const
> >> AVClass *parent, void **iter)
> >>> #if FF_API_CHILD_CLASS_NEXT
> >>> FF_DISABLE_DEPRECATION_WARNINGS
> >>> if (parent->child_class_next) {
> >>> -*iter = parent->child_class_next(*iter);
> >>> +*iter = (void*)parent->child_class_next(*iter);
> >>> return *iter;
> >>> }
> >>> FF_ENABLE_DEPRECATION_WARNINGS
> >>>
> >> This doesn't look like a fix; you just silenced a warning.
> >>
> > Yes, but this the only way if we do not change the function signature.
>
> Since a major release is "coming up", now could be the time to fix the
> signature to '(..., const void **iter)' and eliminate the non-const cast
> kludge across the board for these cases.
Are we plan to remove all warnings before the release?
Or more aggressively, is it feasible to treat all warnings as errors in the
future? :)
>
>
> -Chad
> ___
> 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] DRM decryption with FFmpeg
On Tue, Mar 09, 2021 at 12:58:57PM +0100, Peter White wrote: > DRM is AIDS wrapped in Cancer seasoned with a smidge of Syphilis. That's why I would like to share some code with the community. :) -- zsugabubus ___ 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] nvenc: Fix output dts if encoding with implicitly enabled b-frames
Since a0949d0bcb0eee2f3fffcf9a4810c0295d14c0dc, the b-frames
setting defaults to -1, which uses the preset's default setting.
If b-frames are enabled, but max_b_frames is kept at <= 0, the
output dts are inconsistent.
---
libavcodec/nvenc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a061dee880..6baeec6d36 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1380,8 +1380,11 @@ static av_cold int nvenc_setup_encoder(AVCodecContext
*avctx)
if (res < 0)
return res;
-if (ctx->encode_config.frameIntervalP > 1)
+if (ctx->encode_config.frameIntervalP > 1) {
avctx->has_b_frames = 2;
+if (avctx->max_b_frames <= 0)
+avctx->max_b_frames = 1;
+}
if (ctx->encode_config.rcParams.averageBitRate > 0)
avctx->bit_rate = ctx->encode_config.rcParams.averageBitRate;
--
2.24.3 (Apple Git-128)
___
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] DRM decryption with FFmpeg
On Tue, Mar 09, 2021 at 12:48:45PM +0100, zsugabubus wrote: > Hi, > > On Tue, Mar 09, 2021 at 10:54:22AM +0100, Paul B Mahol wrote: > > We do not accept DRM code. > > Hmm. And what about only accepting files that are considered legal? DRM is AIDS wrapped in Cancer seasoned with a smidge of Syphilis. ___ 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] DRM decryption with FFmpeg
Hi,
On Tue, Mar 09, 2021 at 10:54:22AM +0100, Paul B Mahol wrote:
> We do not accept DRM code.
Hmm. And what about only accepting files that are considered legal?
AVEncryption{,Init}Info and friends are already present. Would it be
much different? They are also take an important role.
And what about just simply submitting patches to the mailing list?
(Without accepting or caring about it at all.) Is that okay?
Thanks,
zsugabubus
___
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] DRM decryption with FFmpeg
> 2021年3月9日 下午5:44，zsugabubus 写道： > > Hi all, > > I was not able to find any patches or mails, only two open tickets that > mention DRM decryption in some way: > > https://trac.ffmpeg.org/ticket/1793 > https://trac.ffmpeg.org/ticket/1800 > > ...however there were no updates for years. I do not know it is because > the lack of interest or the lack of manpower but I would like to help > making some progress in this topic. > > There were any plans/ideas about how DRM encrypted content should be > handled (other than those tickets above)? I mean API or such. Or was > that all the discussion about it and it is totally okay if somebody just > submits some code for RFC? > > Thanks, > zsugabubus > ___ > 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". Hi , Maybe you want do it with Nachiket Tarate, he is trying to do it. Hi Nachiket, Maybe you want get a good partner to implement fmp4 AES-SAMPLE in hls? Thanks Steven Liu ___ 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] DRM decryption with FFmpeg
We do not accept DRM code. ___ 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] DRM decryption with FFmpeg
Hi all, I was not able to find any patches or mails, only two open tickets that mention DRM decryption in some way: https://trac.ffmpeg.org/ticket/1793 https://trac.ffmpeg.org/ticket/1800 ...however there were no updates for years. I do not know it is because the lack of interest or the lack of manpower but I would like to help making some progress in this topic. There were any plans/ideas about how DRM encrypted content should be handled (other than those tickets above)? I mean API or such. Or was that all the discussion about it and it is totally okay if somebody just submits some code for RFC? Thanks, zsugabubus ___ 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 V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
Anton Khirnov (12021-03-08): > As does the likelihood that anybody will actually do any work to polish > this. Fair enough. > The argument for internal side data is literally that it's not good > enough to be made public. So the option of making it private is used as > an excuse to avoid designing the format properly. This reasoning would apply to using private_ref as well. So I understand your objection is against any solution that avoids properly designing the structure. I can easily agree with that. > Lavfi is enough of a black box as it is, no need to make it even more so > with internal side data formats. Please, there nothing of a black box about libavfilter. Regards, -- Nicolas George 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] avcodec/h264_slice: don't copy frame data during error concealment
We will test vaapi for this patch. But I am more curious about the software decoder behaviors. This approach just ref the yuv. Not the intermedia data(like mv, macroblock type) Will it have problem if missed frame selected as colPic (Figure 8-2 in spec). > -Original Message- > From: ffmpeg-devel On Behalf Of > Hendrik Leppkes > Sent: Tuesday, March 9, 2021 3:44 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: don't copy frame > data during error concealment > > On Tue, Mar 9, 2021 at 3:39 AM James Almer wrote: > > > > In addition to the fact that av_image_copy() cannot handle hardware > > pixel formats, h->short_ref[0]->f may not even be writable at this point. > > > > Based on a patch by Hendrik Leppkes. > > > > Signed-off-by: James Almer > > --- > > This is an alternative to "avcodec/h264_slice: properly handle missing > > reference frames with hwaccel", given that I noticed that the target > > frame is not writable for example when running fate-h264-missing-frame. > > > > To keep the current behavior of copying the frame data instead of > > making a reference, I also tried to do ff_thread_release_buffer() -> > > ff_thread_get_buffer() -> av_frame_copy(), which worked with software > > decoding, but when using the d3d11va hwaccel the av_frame_copy() call > would fail. > > > > There is a warning above this code that makes it sound like making > > references is not ideal, but considering h->short_ref[0] is not > > writable here it feels like it could be an outdated comment that someone > forgot to remove. > > > > Looks more thorough then my original change. I was worried about the > comment also, but I think it may have been from before the days of ref- > counting, frame threading, and all that (the comment appeared with the > original code in e2983d6eac7b0bb563886c6f97c4ce0385b2018d, 2010) > > Perhaps the comment should be removed if we are going to reference now > anyway? > > - Hendrik > ___ > 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 V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES
Unacceptable. Filter should use frame metadata instead. Stop avoiding this crucial subject. On Mon, Mar 8, 2021 at 8:44 PM Anton Khirnov wrote: > Quoting Nicolas George (2021-03-08 16:32:08) > > Anton Khirnov (12021-03-08): > > > I see no reason to believe the format will become more public-worthy > > > with time. > > > > Just the fact that as months pass, the likelihood we notice something > > that requires a deep change decreases. > > > > As does the likelihood that anybody will actually do any work to polish > this. > > > Do you have any actual argument against internal side data, beyond "I do > > not like it"? > > The argument for internal side data is literally that it's not good > enough to be made public. So the option of making it private is used as > an excuse to avoid designing the format properly. > Lavfi is enough of a black box as it is, no need to make it even more so > with internal side data formats. > > -- > Anton Khirnov > ___ > 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".
