Re: [FFmpeg-devel] [PATCH 05/35] avdevice/dshow: set no-seek flags
Just resend them (without any -v2). ___ 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] libavcodec: r12b decoder
Hi Carl, Thanks for the question. The four letter "r12b" format code is from the DeckLink documentation; there are other described formats there as well such as r12l, r10b, r10l and r210. I'm using DirectShow which signals the encoding to downstream components through the use of FOURCC codes and hence for this filter to be of any use in such applications there needs to be a way to identify it. r210 from their docs has already gained some traction as a fourcc and hence adding the others in a similar vein seemed a reasonable approach. "r12b" also sounds reasonable to me as a fourcc: it starts with an r, indicative of RGB formats, and the bit/pixel + endianness didn't seem unreasonable. Also I could find no other fourcc's used for this and hence I added it. Kind regards, Dennis Fleurbaaij On Tue, Jun 8, 2021 at 1:57 AM Carl Eugen Hoyos wrote: > > > Von meinem iPhone gesendet > > > Am 07.06.2021 um 12:09 schrieb Dennis Fleurbaaij < > m...@dennisfleurbaaij.com>: > > > > Pulled master and re-applied to resolve version update conflict > > > R12B is a format used by BlackMagic DeckLink cards > > How does the card produce avi files / why are you adding a fourcc? > > Please elaborate, Carl Eugen > ___ > 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] fftools/ffplay: 240M matrix is not the same as BT.601
вт, 8 июн. 2021 г., 5:28 Michael Bradshaw : > I'll just chime in and say: > > FIXME comments aren't that helpful. It would be more helpful to av_log when > you detect you've hit an unsupported situation. > How should I know what are unsupported situations? I mean sure, sYCC (BT.709 primaries with BT.601 matrix and sRGB transfer) is such a case, but I am not sure what else and it is impossible to detect it (also BT.601 matrix with classic BT.601/709/2020 transfer and SMPTE C primaries, like on trac)). Because were it possible, I would have JUST FIXED IT. Also, that will still be not enough as primaries must be also color managed, except ffplay does not support color managment. BT.601 matrix vs BT.709 matrix vs BT.2020-ncl matrix is not all, I hope you understand that. With the case BT.2020-ncl it is not it that make it that bad for BT.2100 (HDR). It is PQ transfer function. Not even primaries. As for SMPTE 240M vs BT.601 Y'CbCr matrices: yes, they're different. But > SDL doesn't support SMPTE 240M. It only supports: > Yes, I know that. Can you imagine?? Oh, my. > SDL_YUV_CONVERSION_JPEG, /**< Full range JPEG */ > SDL_YUV_CONVERSION_BT601, /**< BT.601 (the default) */ > SDL_YUV_CONVERSION_BT709, /**< BT.709 */ > (and automatic, but that's just BT.601 + BT.709) > > It's probably better to fall back to using BT.709 matrix for SMPTE 240M > (with a warning log) since BT.709 is closer to SMPTE 240M than BT.601 is. > No. This uses sRGB transfer. sRGB transfer is not close BT.709 OETF (or its BT.1886 EOTF) because sRGB is an EOTF in by itself. Please do not say it again. ___ > 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] libavcodec: r12b decoder
BTW, who knows how to show warnings on make job on patchwork? Only if make fate fails you can see it, but not otherwise. Also, md5 warnings, when you are going to fix those?? https://patchwork.ffmpeg.org/project/ffmpeg/patch/CAPUCmECSxQwMtttmRqTC-JtOpcfUB9SVQ8ZPZOHULFL9=2d...@mail.gmail.com/ ___ 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/vf_overlay_cuda: support expression of x y position
It'd probably make sense to also copy over the option for evaluating the expression per-frame or on init. Given that this is usually going to run much faster than the software overlay filter, the slight overhead from the expression could be much more severe. Looks good otherwise, and for what I care, the per-frame/init option can also be added in a later patch. smime.p7s Description: S/MIME Cryptographic 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 v2] avfilter/vf_overlay_cuda: support expression of x y position
and add per-frame / init mode for it.
Signed-off-by: Steven Liu
---
libavfilter/vf_overlay_cuda.c | 153 --
1 file changed, 144 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_overlay_cuda.c b/libavfilter/vf_overlay_cuda.c
index 8a4d2c4312..b2ed8de24e 100644
--- a/libavfilter/vf_overlay_cuda.c
+++ b/libavfilter/vf_overlay_cuda.c
@@ -30,6 +30,7 @@
#include "libavutil/hwcontext.h"
#include "libavutil/hwcontext_cuda_internal.h"
#include "libavutil/cuda_check.h"
+#include "libavutil/eval.h"
#include "avfilter.h"
#include "framesync.h"
@@ -41,6 +42,9 @@
#define BLOCK_X 32
#define BLOCK_Y 16
+#define MAIN0
+#define OVERLAY 1
+
static const enum AVPixelFormat supported_main_formats[] = {
AV_PIX_FMT_NV12,
AV_PIX_FMT_YUV420P,
@@ -54,6 +58,38 @@ static const enum AVPixelFormat supported_overlay_formats[]
= {
AV_PIX_FMT_NONE,
};
+enum var_name {
+VAR_MAIN_W,VAR_MW,
+VAR_MAIN_H,VAR_MH,
+VAR_OVERLAY_W, VAR_OW,
+VAR_OVERLAY_H, VAR_OH,
+VAR_X,
+VAR_Y,
+VAR_N,
+VAR_POS,
+VAR_T,
+VAR_VARS_NB
+};
+
+enum EvalMode {
+EVAL_MODE_INIT,
+EVAL_MODE_FRAME,
+EVAL_MODE_NB
+};
+
+static const char *const var_names[] = {
+"main_w","W", ///< width of the mainvideo
+"main_h","H", ///< height of the mainvideo
+"overlay_w", "w", ///< width of the overlay video
+"overlay_h", "h", ///< height of the overlay video
+"x",
+"y",
+"n",///< number of frame
+"pos", ///< position in the file
+"t",///< timestamp expressed in seconds
+NULL
+};
+
/**
* OverlayCUDAContext
*/
@@ -73,9 +109,14 @@ typedef struct OverlayCUDAContext {
FFFrameSync fs;
+int eval_mode;
int x_position;
int y_position;
+double var_values[VAR_VARS_NB];
+char *x_expr, *y_expr;
+
+AVExpr *x_pexpr, *y_pexpr;
} OverlayCUDAContext;
/**
@@ -89,6 +130,49 @@ static int format_is_supported(const enum AVPixelFormat
formats[], enum AVPixelF
return 0;
}
+static inline int normalize_xy(double d, int chroma_sub)
+{
+if (isnan(d))
+return INT_MAX;
+return (int)d & ~((1 << chroma_sub) - 1);
+}
+
+static void eval_expr(AVFilterContext *ctx)
+{
+OverlayCUDAContext *s = ctx->priv;
+
+s->var_values[VAR_X] = av_expr_eval(s->x_pexpr, s->var_values, NULL);
+s->var_values[VAR_Y] = av_expr_eval(s->y_pexpr, s->var_values, NULL);
+/* It is necessary if x is expressed from y */
+s->var_values[VAR_X] = av_expr_eval(s->x_pexpr, s->var_values, NULL);
+
+s->x_position = normalize_xy(s->var_values[VAR_X], 1);
+
+/* the cuda pixel format is using hwaccel, y_position unnecessary
normalize y */
+s->y_position = s->var_values[VAR_Y];
+}
+
+static int set_expr(AVExpr **pexpr, const char *expr, const char *option, void
*log_ctx)
+{
+int ret;
+AVExpr *old = NULL;
+
+if (*pexpr)
+old = *pexpr;
+ret = av_expr_parse(pexpr, expr, var_names,
+NULL, NULL, NULL, NULL, 0, log_ctx);
+if (ret < 0) {
+av_log(log_ctx, AV_LOG_ERROR,
+ "Error when evaluating the expression '%s' for %s\n",
+ expr, option);
+*pexpr = old;
+return ret;
+}
+
+av_expr_free(old);
+return 0;
+}
+
/**
* Helper checks if we can process main and overlay pixel formats
*/
@@ -151,10 +235,8 @@ static int overlay_cuda_blend(FFFrameSync *fs)
CUcontext dummy, cuda_ctx = ctx->hwctx->cuda_ctx;
AVFrame *input_main, *input_overlay;
-const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(inlink->format);
-int hsub = pix_desc->log2_chroma_w;
-int vsub = pix_desc->log2_chroma_h;
+int pos = 0;
ctx->cu_ctx = cuda_ctx;
@@ -183,8 +265,24 @@ static int overlay_cuda_blend(FFFrameSync *fs)
return ret;
}
-ctx->x_position &= (1 << hsub) - 1;
-ctx->y_position &= (1 << vsub) - 1;
+if (ctx->eval_mode == EVAL_MODE_FRAME) {
+pos = input_main->pkt_pos;
+ctx->var_values[VAR_N] = inlink->frame_count_out;
+ctx->var_values[VAR_T] = input_main->pts == AV_NOPTS_VALUE ?
+NAN : input_main->pts * av_q2d(inlink->time_base);
+ctx->var_values[VAR_POS] = pos == -1 ? NAN : pos;
+ctx->var_values[VAR_OVERLAY_W] = ctx->var_values[VAR_OW] =
input_overlay->width;
+ctx->var_values[VAR_OVERLAY_H] = ctx->var_values[VAR_OH] =
input_overlay->height;
+ctx->var_values[VAR_MAIN_W ] = ctx->var_values[VAR_MW] =
input_main->width;
+ctx->var_values[VAR_MAIN_H ] = ctx->var_values[VAR_MH] =
input_main->height;
+
+eval_expr(avctx);
+
+av_log(avctx, AV_LOG_DEBUG, "n:%f t:%f pos:%f x:%f xi:%d y:%f yi:%d\n",
+ ctx->var_values[VAR_N], ctx->var_values[VAR_T],
ctx->var_values[VAR_POS],
+ ctx->var_values[VAR_X], ctx->x_position,
+ ctx->var_values[VAR_Y], ctx->y_positio
Re: [FFmpeg-devel] [PATCH 21/35] avdevice: capabilities API details no longer public
Diederick C. Niehorster: > On Tue, Jun 8, 2021 at 1:54 AM Andreas Rheinhardt < > andreas.rheinha...@outlook.com> wrote: > >> Diederick Niehorster: >>> NB: will break build, makes needed corresponding changes to avformat. >>> >> >> Then said changes should be part of this patch. Patches should be >> logically self-contained and atomic; this is not the same as splitting >> by file/library. >> >> But that is a moot point: James already told you a better way to fix this. >> > > Made sense. But indeed, James' way of doing it obviates that next patch > changing avformat.h > > >>> --- a/libavdevice/internal.h >>> +++ b/libavdevice/internal.h >> >> We prefer the order libavutil-libavcodec-libavformat (the reverse of >> linking order). >> > > fixed. > > >>> + * AVOption table used by devices to implement device capabilities API. >> Should not be used by a user. >> >> That last part is superfluous, as (external) users by definition have no >> business looking into internal.h. >> > > Ah yes, copy paste.. Fixed. > > >>> + */ >>> +extern const AVOption av_device_capabilities[]; >> >> Don't use this name: av_* is our namespace for public symbols. Our >> linker script makes sure that all symbols that start with av_* are >> exported; whether they are in a public header is irrelevant. >> Not exporting the symbol in the first place also solves the problem of >> users using it despite it not being part of the API. >> (I btw don't know whether said linker script is used on Windows.) >> > > I changed it to a ff_ prefix. Is that correct? Yes (presuming there are (or will eventually be) users of this in different translation units). - 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".
[FFmpeg-devel] [PATCH 02/33] avdevice/dshow: add use_video_device_timestamps to docs
Signed-off-by: Diederick Niehorster
---
doc/indevs.texi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index b377924c2f..685b1357a6 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -611,6 +611,12 @@ Save the currently used video capture filter device and its
parameters (if the filter supports it) to a file.
If a file with the same name exists it will be overwritten.
+@item use_video_device_timestamps
+If set to @option{false}, the timestamp for video frames will be
+derived from the wallclock instead of the timestamp provided by
+the capture device. This allows working around devices that
+provide unreliable timestamps.
+
@end table
@subsection Examples
--
2.28.0.windows.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 05/33] avdevice/dshow: set no-seek flags
avdevice/dshow is a realtime device and as such does not support seeking.
Therefore, its demuxer format should define the AVFMT_NOBINSEARCH,
AVFMT_NOGENSEARCH and AVFMT_NO_BYTE_SEEK flags.
With these flags set, attempting to seek (with e.g. avformat_seek_file())
correctly yields -1 (operation not permitted) instead of -22 (invalid argument).
This actually seems to apply to many other devices, at least the gdigrab, v4l2,
vfwcap, x11grab, fbdev, kmsgrab and android_camera devices, from reading the
source.
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 2e9f9ddf3f..389daa6380 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -1336,6 +1336,6 @@ const AVInputFormat ff_dshow_demuxer = {
.read_header= dshow_read_header,
.read_packet= dshow_read_packet,
.read_close = dshow_read_close,
-.flags = AVFMT_NOFILE,
+.flags = AVFMT_NOFILE | AVFMT_NOBINSEARCH | AVFMT_NOGENSEARCH |
AVFMT_NO_BYTE_SEEK,
.priv_class = &dshow_class,
};
--
2.28.0.windows.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 05/35] avdevice/dshow: set no-seek flags
didn't have the patchst anymore and already processed comments in later patches, so 02/35 and 05/35 became out of 33. Noticed that too late. Hope that doesn't confuse anything. Else we'll get it on -v2 of this series (which there will certainly be), where i think i'll throttle sending a bit (somehow). On Tue, Jun 8, 2021 at 11:34 AM Valerii Zapodovnikov wrote: > Just resend them (without any -v2). > ___ > 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] avfilter/vf_overlay_cuda: support expression of x y position
Timo Rothenpieler 于2021年6月8日周二 下午6:23写道： > > It'd probably make sense to also copy over the option for evaluating the > expression per-frame or on init. > Given that this is usually going to run much faster than the software > overlay filter, the slight overhead from the expression could be much > more severe. Thanks for your comments Timo, I update the patch version 2 right now. https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210608104503.25677-1-liuq...@kuaishou.com/ > > Looks good otherwise, and for what I care, the per-frame/init option can > also be added in a later patch. > > ___ > 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". Thanks Steven ___ 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] videotoolboxenc: enable constant quality with -q:v on Apple Silicon Macs and use b-frames für HEVC and H264 and b-pyramid for HEVC.
Hi,
Am 19.03.21 um 19:54 schrieb Rick Kern:
On Fri, Jan 22, 2021 at 3:28 PM wrote:
From: Simone Karin Lehmann
Signed-off-by: Simone Karin Lehmann
Applied
---
libavcodec/videotoolboxenc.c | 54
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 400401550a..e8cbc9dd4d 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -224,7 +224,7 @@ typedef struct VTEncContext {
int64_t require_sw;
bool flushing;
-bool has_b_frames;
+int has_b_frames;
bool warned_color_range;
/* can't be bool type since AVOption will access it as int */
@@ -1014,6 +1014,12 @@ static int get_cv_ycbcr_matrix(AVCodecContext
*avctx, CFStringRef *matrix) {
return 0;
}
+// constant quality only on Macs with Apple Silicon
+static bool vtenc_qscale_enabled(void)
+{
+return TARGET_OS_OSX && TARGET_CPU_ARM64;
+}
+
This breaks compilation for me on OSX 10.10.5 Yosemite.
TARGET_OS_OSX is too new and undefined in TargetConditionals.h here.
Can you test if
return !TARGET_OS_OSX && TARGET_CPU_ARM64;
does the same thing for you on newer OSX? (That's what I read what other
projects do to avoid it)
CC libavcodec/videotoolboxenc.o
warning: unknown warning option '-Werror=partial-availability'; did you mean
'-Werror=availability'?
[-Wunknown-warning-option]
warning: unknown warning option '-Wno-bool-operation'; did you mean
'-Wno-bool-conversion'?
[-Wunknown-warning-option]
libavcodec/videotoolboxenc.c:1041:12: error: use of undeclared identifier
'TARGET_OS_OSX'
return TARGET_OS_OSX && TARGET_CPU_ARM64;
^
2 warnings and 1 error generated.
make: *** [libavcodec/videotoolboxenc.o] Error 1
-Thilo
static int vtenc_create_encoder(AVCodecContext *avctx,
CMVideoCodecType codec_type,
CFStringRef profile_level,
@@ -1025,7 +1031,9 @@ static int vtenc_create_encoder(AVCodecContext
*avctx,
VTEncContext *vtctx = avctx->priv_data;
SInt32 bit_rate = avctx->bit_rate;
SInt32 max_rate = avctx->rc_max_rate;
+Float32 quality = avctx->global_quality / FF_QP2LAMBDA;
CFNumberRef bit_rate_num;
+CFNumberRef quality_num;
CFNumberRef bytes_per_second;
CFNumberRef one_second;
CFArrayRef data_rate_limits;
@@ -1056,15 +1064,33 @@ static int vtenc_create_encoder(AVCodecContext
*avctx,
return AVERROR_EXTERNAL;
}
-bit_rate_num = CFNumberCreate(kCFAllocatorDefault,
- kCFNumberSInt32Type,
- &bit_rate);
-if (!bit_rate_num) return AVERROR(ENOMEM);
+if (avctx->flags & AV_CODEC_FLAG_QSCALE && !vtenc_qscale_enabled()) {
+av_log(avctx, AV_LOG_ERROR, "Error: -q:v qscale not available for
encoder. Use -b:v bitrate instead.\n");
+return AVERROR_EXTERNAL;
+}
+
+if (avctx->flags & AV_CODEC_FLAG_QSCALE) {
+quality = quality >= 100 ? 1.0 : quality / 100;
+quality_num = CFNumberCreate(kCFAllocatorDefault,
+ kCFNumberFloat32Type,
+ &quality);
+if (!quality_num) return AVERROR(ENOMEM);
-status = VTSessionSetProperty(vtctx->session,
-
kVTCompressionPropertyKey_AverageBitRate,
- bit_rate_num);
-CFRelease(bit_rate_num);
+status = VTSessionSetProperty(vtctx->session,
+ kVTCompressionPropertyKey_Quality,
+ quality_num);
+CFRelease(quality_num);
+} else {
+bit_rate_num = CFNumberCreate(kCFAllocatorDefault,
+ kCFNumberSInt32Type,
+ &bit_rate);
+if (!bit_rate_num) return AVERROR(ENOMEM);
+
+status = VTSessionSetProperty(vtctx->session,
+
kVTCompressionPropertyKey_AverageBitRate,
+ bit_rate_num);
+CFRelease(bit_rate_num);
+}
if (status) {
av_log(avctx, AV_LOG_ERROR, "Error setting bitrate property:
%d\n", status);
@@ -1333,6 +1359,7 @@ static int vtenc_configure_encoder(AVCodecContext
*avctx)
}
vtctx->codec_id = avctx->codec_id;
+avctx->max_b_frames = 16;
if (vtctx->codec_id == AV_CODEC_ID_H264) {
vtctx->get_param_set_func =
CMVideoFormatDescriptionGetH264ParameterSetAtIndex;
@@ -1340,7 +1367,7 @@ static int vtenc_configure_encoder(AVCodecContext
*avctx)
vtctx->has_b_frames = avctx->max_b_frames > 0;
if(vtctx->has_b_frames && vtctx->profile == H264_PROF_BASELINE){
av_log(avctx, AV_LOG_WARNING, "Cannot use B-frames with
baseline profile. Output will not contain B-frames.\n");
-vtctx->has_b_frames = false;
+vtctx->h
Re: [FFmpeg-devel] [PATCH 10/35] fftools: provide media type info for devices
Diederick Niehorster (12021-06-08): > fftools now print info about what media type(s), if any, are provided > by sink and source avdevices. Furthermore, printing is done with > av_log instead of printf as the latter doesn't handle characters in > some device names correctly (e.g. "Microphone Array (Intel® Smart > Sound Technology (Intel® SST))" is printed incorrectly). > > Signed-off-by: Diederick Niehorster > --- > fftools/cmdutils.c | 41 +++-- > 1 file changed, 31 insertions(+), 10 deletions(-) The feature looks useful. But the printing must go to stdout, not to logging, because it is meant to be readable by scripts. 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 11/35] avformat: add control_message function to AVInputFormat
Diederick Niehorster (12021-06-08): > Control messages are useful for programmatic control of not only outdevs but > also indevs. > Bumping avformat version. > > Signed-off-by: Diederick Niehorster > --- > libavdevice/avdevice.c | 8 +--- > libavformat/avformat.h | 6 ++ > libavformat/version.h | 4 ++-- > 3 files changed, 13 insertions(+), 5 deletions(-) Looks good to me thanks. Maybe wrap the commit message at 60 columns. 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 13/35] avdevice: adding control message requesting to show config dialog
Diederick Niehorster (12021-06-08):
> This control message can be used to programmatically ask a device to show its
> configuration dialog.
> Bumping avdevice version.
>
> Signed-off-by: Diederick Niehorster
> ---
> libavdevice/avdevice.h | 10 ++
> libavdevice/version.h | 2 +-
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/libavdevice/avdevice.h b/libavdevice/avdevice.h
> index 6f24976dcc..4fbdf6aabc 100644
> --- a/libavdevice/avdevice.h
> +++ b/libavdevice/avdevice.h
> @@ -190,6 +190,16 @@ enum AVAppToDevMessageType {
> */
> AV_APP_TO_DEV_GET_VOLUME = MKBETAG('G', 'V', 'O', 'L'),
> AV_APP_TO_DEV_GET_MUTE = MKBETAG('G', 'M', 'U', 'T'),
> +
> +/**
> + * Request to show configuration dialog.
> + *
> + * If device has a configuration dialog of type indicated by
> + * data, show it.
> + *
> + * data: int.
?
> + */
> +AV_APP_TO_DEV_CONFIG = MKBETAG('C', 'O', 'N', 'F'),
> };
>
> /**
> diff --git a/libavdevice/version.h b/libavdevice/version.h
> index 6e593ba00e..0381d6cd0d 100644
> --- a/libavdevice/version.h
> +++ b/libavdevice/version.h
> @@ -28,7 +28,7 @@
> #include "libavutil/version.h"
>
> #define LIBAVDEVICE_VERSION_MAJOR 59
> -#define LIBAVDEVICE_VERSION_MINOR 1
> +#define LIBAVDEVICE_VERSION_MINOR 2
> #define LIBAVDEVICE_VERSION_MICRO 100
>
> #define LIBAVDEVICE_VERSION_INT AV_VERSION_INT(LIBAVDEVICE_VERSION_MAJOR, \
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 20/35] avdevice/avdevice: clean up avdevice_capabilities_create
Diederick Niehorster (12021-06-08):
> Draw implementation in line with that of avdevice_list_devices
>
> Signed-off-by: Diederick Niehorster
> ---
> libavdevice/avdevice.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
> index 695b9143af..d73d36e1dd 100644
> --- a/libavdevice/avdevice.c
> +++ b/libavdevice/avdevice.c
> @@ -100,12 +100,15 @@ int
> avdevice_capabilities_create(AVDeviceCapabilitiesQuery **caps, AVFormatConte
> AVDictionary **device_options)
> {
> int ret;
> -av_assert0(s && caps);
> +av_assert0(s);
> +av_assert0(caps);
> av_assert0(s->iformat || s->oformat);
> if ((s->oformat && !s->oformat->create_device_capabilities) ||
> -(s->iformat && !s->iformat->create_device_capabilities))
> +(s->iformat && !s->iformat->create_device_capabilities)) {
> +*caps = NULL;
> return AVERROR(ENOSYS);
> -*caps = av_mallocz(sizeof(**caps));
> +}
> +*caps = av_mallocz(sizeof(AVDeviceCapabilitiesQuery));
var = malloc(sizeof(*var)) is preferred over var = malloc(type), because
if you change the type of var, it happens in another part of the code
and you would have to remember to change it here too.
> if (!(*caps))
> return AVERROR(ENOMEM);
> (*caps)->device_context = s;
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]avfilter: add Intel IPP library based x86 optimized video scaling filter
> -Original Message- > From: ffmpeg-devel On Behalf Of Jan > Ekström > If you just go without any rhetoric and just look at what "nonfree" > (which IMHO is an awful name for the configuration option, it's just > "non-distributable") > > We can start with the history of the option - originally added in > 3fe142e2555ec8b527f2ff4cc517c015a114e91a (Jan, 2008) - to denote that due > to the libamrnb/libamrwb wrappers being based on reference code, them > being effectively not compatibly licensed even if someone was nice enough > to make an open source wrapper around them. So it was all about open > source, just licensing incompatibilities that were found out (just like some > AAC library was later found to re-utilize reference code which was not under > a friendly license). > > Then if we look at what the nonfree option is currently utilized for: > > capture card hardware integration (1): > decklink > > open source that just happens to have incompatible licensing with regards to > GPL (3): > libfdk_aac > openssl > libtls > > (old) CUDA SDK things (3): > cuda_nvcc > cuda_sdk > libnpp I thought there were more.. > Thus looking at both historical point of that option, as well as its current > uses, > I don't see there's any reason to include a wrapper for a closed source > scaling > library that does not benefit the project (it re-implements already existing > capability). [...] An answer, too good to contradict, unfortunately ;-) Even free from ideology. Much respected. Thanks, softworkz ___ 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 26/35] avdevice: Add internal helpers for querying device capabilities
On Tue, Jun 08, 2021 at 01:04:05AM +0200, Diederick Niehorster wrote:
> Signed-off-by: Diederick Niehorster
> ---
> libavdevice/internal.h | 31 +++
> libavdevice/utils.c| 48 ++
> libavdevice/version.h | 2 +-
> 3 files changed, 80 insertions(+), 1 deletion(-)
brakes build
CC libavdevice/utils.o
libavdevice/utils.c:64:29: error: field ‘query_type’ has incomplete type
enum DshowCapQueryType query_type;
^~
libavdevice/utils.c: In function ‘ff_device_get_query_type’:
libavdevice/utils.c:86:20: error: incompatible types when returning type ‘const
AVDeviceCapabilitiesQueryTypeEntry * {aka const struct
AVDeviceCapabilitiesQueryTypeEntry *}’ but ‘enum AVDeviceCapabilitiesQueryType’
was expected
return query_table[i].query_type;
^~~
libavdevice/utils.c: In function ‘ff_device_get_query_component_name’:
libavdevice/utils.c:101:43: warning: comparison between pointer and integer
if (query_table[i].query_type == query_type)
^~
ffbuild/common.mak:67: recipe for target 'libavdevice/utils.o' failed
make: *** [libavdevice/utils.o] Error 1
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- 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] Fix memory allocation problem. Related to ticket #9264.
From: houlei
Signed-off-by: houlei
---
libavdevice/xv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavdevice/xv.c b/libavdevice/xv.c
index 24ba3179f6..7e15c178b6 100644
--- a/libavdevice/xv.c
+++ b/libavdevice/xv.c
@@ -296,10 +296,11 @@ static int write_picture(AVFormatContext *s, uint8_t
*input_data[4],
{
XVContext *xv = s->priv_data;
XvImage *img = xv->yuv_image;
-uint8_t *data[3] = {
+uint8_t *data[4] = {
img->data + img->offsets[0],
img->data + img->offsets[1],
-img->data + img->offsets[2]
+img->data + img->offsets[2],
+img->data + img->offsets[3]
};
/* Check messages. Window might get closed. */
--
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] MAINTAINERS: Add Haihao Xiang for qsv
Signed-off-by: Zhong Li --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index dcac46003e..39ce91b755 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -226,7 +226,7 @@ Codecs: ptx.c Ivo van Poorten qcelp*Reynaldo H. Verdejo Pinochet qdm2.c, qdm2data.hRoberto Togni - qsv* Mark Thompson, Zhong Li + qsv* Mark Thompson, Zhong Li, Haihao Xiang qtrle.c Mike Melanson ra144.c, ra144.h, ra288.c, ra288.hRoberto Togni resample2.c Michael Niedermayer -- 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 25/35] avutil/opt: add av_opt_to_string
Diederick Niehorster (12021-06-08):
> This function allows formatting an option value stored in a double (such as
> the min and max fields of an AVOption, or min_value and max_value of an
> AVOptionRange) properly, e.g. 1 for a AV_OPT_TYPE_PIXEL_FMT -> yuyv422.
> Useful when printing more info about an option than just its value. Usage
> will be shown in upcoming device_get_capabilities example. av_opt_get (body
> changed) still passes FATE.
Please wrap this.
>
> Signed-off-by: Diederick Niehorster
> ---
> libavutil/opt.c | 93 +
> libavutil/opt.h | 12 +-
> libavutil/version.h | 2 +-
> 3 files changed, 89 insertions(+), 18 deletions(-)
>
> diff --git a/libavutil/opt.c b/libavutil/opt.c
> index ab127b30fa..3e385852eb 100644
> --- a/libavutil/opt.c
> +++ b/libavutil/opt.c
> @@ -776,24 +776,14 @@ static void format_duration(char *buf, size_t size,
> int64_t d)
> *(--e) = 0;
> }
>
> -int av_opt_get(void *obj, const char *name, int search_flags, uint8_t
> **out_val)
> +static int print_option(void* dst, enum AVOptionType type, int search_flags,
> uint8_t** out_val)
I really do not like the fact that it always makes a dynamic allocation,
especially since in most cases we know the buffer has a small bounded
size.
I'd rather have AVWriter here, but in the meantime, please consider
using AVBPrint.
> {
> -void *dst, *target_obj;
> -const AVOption *o = av_opt_find2(obj, name, NULL, 0, search_flags,
> &target_obj);
> -uint8_t *bin, buf[128];
> +uint8_t* bin, buf[128];
Here and everywhere, the pointer mark belongs with the variable name.
This is an obvious example of why: written like this, it seems that bin
and buf[128] are both uint8_t*. Correctly written, it's obvious that
only bin is a pointer.
> int len, i, ret;
> int64_t i64;
>
> -if (!o || !target_obj || (o->offset<=0 && o->type != AV_OPT_TYPE_CONST))
> -return AVERROR_OPTION_NOT_FOUND;
> -
> -if (o->flags & AV_OPT_FLAG_DEPRECATED)
> -av_log(obj, AV_LOG_WARNING, "The \"%s\" option is deprecated: %s\n",
> name, o->help);
> -
> -dst = (uint8_t *)target_obj + o->offset;
> -
> buf[0] = 0;
> -switch (o->type) {
> +switch (type) {
> case AV_OPT_TYPE_BOOL:
> ret = snprintf(buf, sizeof(buf), "%s", (char
> *)av_x_if_null(get_bool_name(*(int *)dst), "invalid"));
> break;
> @@ -819,9 +809,6 @@ int av_opt_get(void *obj, const char *name, int
> search_flags, uint8_t **out_val)
> case AV_OPT_TYPE_RATIONAL:
> ret = snprintf(buf, sizeof(buf), "%d/%d", ((AVRational *)dst)->num,
> ((AVRational *)dst)->den);
> break;
> -case AV_OPT_TYPE_CONST:
> -ret = snprintf(buf, sizeof(buf), "%f", o->default_val.dbl);
> -break;
I think you should have left the case here.
> case AV_OPT_TYPE_STRING:
> if (*(uint8_t **)dst) {
> *out_val = av_strdup(*(uint8_t **)dst);
> @@ -889,6 +876,80 @@ int av_opt_get(void *obj, const char *name, int
> search_flags, uint8_t **out_val)
> return *out_val ? 0 : AVERROR(ENOMEM);
> }
>
> +int av_opt_get(void *obj, const char *name, int search_flags, uint8_t
> **out_val)
> +{
> +void *dst, *target_obj;
> +const AVOption *o = av_opt_find2(obj, name, NULL, 0, search_flags,
> &target_obj);
> +uint8_t buf[128];
> +int ret;
> +
> +if (!o || !target_obj || (o->offset<=0 && o->type != AV_OPT_TYPE_CONST))
> +return AVERROR_OPTION_NOT_FOUND;
> +
> +if (o->flags & AV_OPT_FLAG_DEPRECATED)
> +av_log(obj, AV_LOG_WARNING, "The \"%s\" option is deprecated: %s\n",
> name, o->help);
> +
> +dst = (uint8_t *)target_obj + o->offset;
> +
> +
> +if (o->type != AV_OPT_TYPE_CONST)
> +return print_option(dst, o->type, search_flags, out_val);
> +
> +// special case for a const
> +ret = snprintf(buf, sizeof(buf), "%f", o->default_val.dbl);
> +if (ret >= sizeof(buf))
> +return AVERROR(EINVAL);
> +*out_val = av_strdup(buf);
> +return *out_val ? 0 : AVERROR(ENOMEM);
> +}
> +int av_opt_to_string(double val, enum AVOptionType type, uint8_t** out_val)
> +{
> +*out_val = NULL;
> +
> +switch (type) {
> +case AV_OPT_TYPE_FLAGS:
> +case AV_OPT_TYPE_BOOL:
> +case AV_OPT_TYPE_INT:
> +case AV_OPT_TYPE_PIXEL_FMT:
> +case AV_OPT_TYPE_SAMPLE_FMT:
> +{
> +int temp = lrint(val);
> +return print_option(&temp, type, 0, out_val);
> +}
> +case AV_OPT_TYPE_INT64:
> +case AV_OPT_TYPE_DURATION:
> +case AV_OPT_TYPE_CHANNEL_LAYOUT:
> +{
> +int64_t temp = llrint(val);
> +return print_option(&temp, type, 0, out_val);
> +}
> +case AV_OPT_TYPE_UINT64:
> +{
> +uint64_t temp = llrint(val);
> +return print_option(&temp, type, 0, out_val);
> +}
> +case AV_OPT_TYPE_FLOAT:
> +{
> +float temp = (float)val;
> +return print_option(&temp, type
Re: [FFmpeg-devel] [PATCH 17/35] avdevice/dshow: discover source color range/space/etc
On Tue, Jun 08, 2021 at 01:03:56AM +0200, Diederick Niehorster wrote: > Enabled discovering a DirectShow device's color range, space, primaries, > transfer characteristics and chroma location, if the device exposes that > information. Sets them in the stream's codecpars. > > Signed-off-by: Diederick Niehorster > Co-authored-by: Valerii Zapodovnikov > --- > libavdevice/dshow.c | 231 +++- > 1 file changed, 230 insertions(+), 1 deletion(-) seems to break build on mingw64 here CC libavdevice/dshow.o src/libavdevice/dshow.c:58:44: error: unknown type name ‘DXVA_ExtendedFormat’ static enum AVColorRange dshow_color_range(DXVA_ExtendedFormat* fmt_info) ^~~ src/libavdevice/dshow.c:82:44: error: unknown type name ‘DXVA_ExtendedFormat’ static enum AVColorSpace dshow_color_space(DXVA_ExtendedFormat* fmt_info) ^~~ src/libavdevice/dshow.c:137:52: error: unknown type name ‘DXVA_ExtendedFormat’ static enum AVColorPrimaries dshow_color_primaries(DXVA_ExtendedFormat* fmt_info) ^~~ src/libavdevice/dshow.c:174:59: error: unknown type name ‘DXVA_ExtendedFormat’ static enum AVColorTransferCharacteristic dshow_color_trc(DXVA_ExtendedFormat* fmt_info) ^~~ src/libavdevice/dshow.c:229:47: error: unknown type name ‘DXVA_ExtendedFormat’ static enum AVChromaLocation dshow_chroma_loc(DXVA_ExtendedFormat* fmt_info) ^~~ src/libavdevice/dshow.c: In function ‘dshow_get_device_media_types’: src/libavdevice/dshow.c:396:23: warning: unused variable ‘ctx’ [-Wunused-variable] struct dshow_ctx *ctx = avctx->priv_data; ^~~ src/libavdevice/dshow.c: In function ‘dshow_get_device_list’: src/libavdevice/dshow.c:643:23: warning: unused variable ‘ctx’ [-Wunused-variable] struct dshow_ctx *ctx = avctx->priv_data; ^~~ src/libavdevice/dshow.c: In function ‘dshow_cycle_formats’: src/libavdevice/dshow.c:712:13: error: unknown type name ‘DXVA_ExtendedFormat’ DXVA_ExtendedFormat *extended_format_info = NULL; ^~~ src/libavdevice/dshow.c:725:41: error: ‘AMCONTROL_COLORINFO_PRESENT’ undeclared (first use in this function) if (v->dwControlFlags & AMCONTROL_COLORINFO_PRESENT) ^~~ src/libavdevice/dshow.c:725:41: note: each undeclared identifier is reported only once for each function it appears in src/libavdevice/dshow.c:726:45: error: ‘DXVA_ExtendedFormat’ undeclared (first use in this function) extended_format_info = (DXVA_ExtendedFormat*)&v->dwControlFlags; ^~~ src/libavdevice/dshow.c:726:65: error: expected expression before ‘)’ token extended_format_info = (DXVA_ExtendedFormat*)&v->dwControlFlags; ^ src/libavdevice/dshow.c:749:51: error: implicit declaration of function ‘dshow_color_range’; did you mean ‘ff_color_frame’? [-Werror=implicit-function-declaration] enum AVColorRange col_range = dshow_color_range(extended_format_info); ^ ff_color_frame src/libavdevice/dshow.c:750:51: error: implicit declaration of function ‘dshow_color_space’; did you mean ‘ff_color_frame’? [-Werror=implicit-function-declaration] enum AVColorSpace col_space = dshow_color_space(extended_format_info); ^ ff_color_frame src/libavdevice/dshow.c:751:54: error: implicit declaration of function ‘dshow_color_primaries’; did you mean ‘dshow_cycle_formats’? [-Werror=implicit-function-declaration] enum AVColorPrimaries col_prim = dshow_color_primaries(extended_format_info); ^ dshow_cycle_formats src/libavdevice/dshow.c:752:66: error: implicit declaration of function ‘dshow_color_trc’ [-Werror=implicit-function-declaration] enum AVColorTransferCharacteristic col_trc = dshow_color_trc(extended_format_info); ^~~ src/libavdevice/dshow.c:753:56: error: implicit declaration of function ‘dshow_chroma_loc’; did you mean ‘dshow_read_close’? [-Werror=implicit-function-declaration] enum AVChromaLocation chroma_loc = dshow_chro
Re: [FFmpeg-devel] [PATCH] fftools/ffplay: 240M matrix is not the same as BT.601
Wait a second. SDL_SetYUVConversionMode does not support 444? You are setting it to mode = SDL_YUV_CONVERSION_AUTOMATIC if it is 444, which I suppose works on just the size of frame? Then this cannot be fixed, I suppose? There is a workround above, as I said. ___ 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 3/3] avcodec/vc2enc: Check for non negative slice bounds
On Tue, Jun 01, 2021 at 09:33:15AM +0200, Michael Niedermayer wrote: > Fixes: invalid shifts > Fixes: Ticket 8221 > > Signed-off-by: Michael Niedermayer > --- > libavcodec/vc2enc.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway 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/rpl: Check for EOF and zero framesize
On Sat, Jun 05, 2021 at 04:31:42PM +0200, Michael Niedermayer wrote: > Fixes: Infinite loop > Fixes: > 34751/clusterfuzz-testcase-minimized-ffmpeg_dem_RPL_fuzzer-5439330800762880 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/rpl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- 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 1/3] avcodec/dpx: fix off by 1 in bits_per_color check
On Sun, May 16, 2021 at 09:38:59PM +0200, Michael Niedermayer wrote: > Fixes: CID1476303 Bad bit shift operation > > Signed-off-by: Michael Niedermayer > --- > libavcodec/dpx.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus 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/3] checkasm/vp9dsp: rename the iszero function to is_zero
On 6/7/2021 6:23 PM, Ronald S. Bultje wrote:
Hi,
On Sun, Jun 6, 2021 at 10:42 PM James Almer wrote:
From: Matthieu Patou
The function name iszero() may collide with a function in glibc.
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
tests/checkasm/vp9dsp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
index 99c023899f..44b02d60a2 100644
--- a/tests/checkasm/vp9dsp.c
+++ b/tests/checkasm/vp9dsp.c
@@ -294,7 +294,7 @@ static int copy_subcoefs(int16_t *out, const int16_t
*in, enum TxfmMode tx,
return eob;
}
-static int iszero(const int16_t *c, int sz)
+static int is_zero(const int16_t *c, int sz)
{
int n;
@@ -362,8 +362,8 @@ static void check_itxfm(void)
call_ref(dst0, sz * SIZEOF_PIXEL, subcoef0, eob);
call_new(dst1, sz * SIZEOF_PIXEL, subcoef1, eob);
if (memcmp(dst0, dst1, sz * sz * SIZEOF_PIXEL) ||
-!iszero(subcoef0, sz * sz * SIZEOF_COEF) ||
-!iszero(subcoef1, sz * sz * SIZEOF_COEF))
+!is_zero(subcoef0, sz * sz * SIZEOF_COEF) ||
+!is_zero(subcoef1, sz * sz * SIZEOF_COEF))
fail();
bench_new(dst, sz * SIZEOF_PIXEL, coef, eob);
--
2.31.1
LGTM.
Ronald
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] lavfi/drawtext: Add localtime_ms for millisecond precision
Hi,
add %{localtime_ms} function to the drawtext filter. Same as %{localtime} but
with additional millisecond part.
-Thilo
From f3b32f3e2b01f50b4fa41f8432ccd5a5eeea1ec1 Mon Sep 17 00:00:00 2001
From: Kirill Pugin
Date: Tue, 8 Jun 2021 18:32:45 +0200
Subject: [PATCH] lavfi/drawtext: Add localtime_ms for millisecond precision
Suggested-By: ffm...@fb.com
---
doc/filters.texi | 4
libavfilter/vf_drawtext.c | 20 +++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 78faf767cf..bf073e0560 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10953,6 +10953,10 @@ It can accept an argument: a strftime() format string.
The time at which the filter is running, expressed in the local time zone.
It can accept an argument: a strftime() format string.
+@item localtime_ms
+Same as @code{localtime} but with millisecond precision.
+It can accept an argument: a strftime() format string.
+
@item metadata
Frame metadata. Takes one or two arguments.
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 382d589e26..684f954236 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -53,6 +53,7 @@
#include "libavutil/parseutils.h"
#include "libavutil/timecode.h"
#include "libavutil/time_internal.h"
+#include "libavutil/time.h"
#include "libavutil/tree.h"
#include "libavutil/lfg.h"
#include "libavutil/detection_bbox.h"
@@ -1049,11 +1050,27 @@ static int func_strftime(AVFilterContext *ctx, AVBPrint
*bp,
struct tm tm;
time(&now);
-if (tag == 'L')
+if (tag == 'L' || tag == 'M')
localtime_r(&now, &tm);
else
tm = *gmtime_r(&now, &tm);
av_bprint_strftime(bp, fmt, &tm);
+
+if (tag == 'M') {
+char ms[5] = {0};
+// get time returns time since epoch in micro seconds, localtime_r
would
+// already take care of representing seconds part, so we need to get
+// milliseconds, to do that we round up microseconds to seconds
+// then convert seconds back to microseconds - this will drop
microsecond
+// precision, then compute difference between av_gettime result and
+// rounded up sec -> usec representation and convert that to
milliseconds
+int64_t usecs = av_gettime();
+int64_t secs = usecs / 100;
+int64_t msec_delta = (usecs - secs * 100) / 1000;
+snprintf(ms, 5, ".%03d", (int)msec_delta);
+av_bprint_append_data(bp, ms, 4);
+}
+
return 0;
}
@@ -1153,6 +1170,7 @@ static const struct drawtext_function {
{ "pts", 0, 3, 0, func_pts },
{ "gmtime",0, 1, 'G', func_strftime },
{ "localtime", 0, 1, 'L', func_strftime },
+{ "localtime_ms", 0, 1, 'M', func_strftime },
{ "frame_num", 0, 0, 0, func_frame_num },
{ "n", 0, 0, 0, func_frame_num },
{ "metadata", 1, 2, 0, func_metadata },
--
2.20.1 (Apple Git-117)
___
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/drawtext: Add localtime_ms for millisecond precision
Plese resend it in new thread but rename it to .txt. 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".
Re: [FFmpeg-devel] [PATCH] lavfi/drawtext: Add localtime_ms for millisecond precision
Valerii Zapodovnikov: > Plese resend it in new thread but rename it to .txt. thanks. Why should he do so? - 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] lavfi/drawtext: Add localtime_ms for millisecond precision
Oh, so it worked on patchwork? Strnge, okay then. No need to. ___ 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/drawtext: Add localtime_ms for millisecond precision
Am 08.06.21 um 18:52 schrieb Valerii Zapodovnikov: > Oh, so it worked on patchwork? Strnge, okay then. No need to. Please read [1] and [2]. Please keep all old text and do inline-commenting. -Thilo [1] http://ffmpeg.org/developer.html [2] http://ffmpeg.org/mailing-list-faq.html ___ 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/drawtext: Add localtime_ms for millisecond precision
вт, 8 июн. 2021 г., 19:57 Thilo Borgmann : > Am 08.06.21 um 18:52 schrieb Valerii Zapodovnikov: > > Oh, so it worked on patchwork? Strnge, okay then. No need to. > > Please read [1] and [2]. Please keep all old text and do inline-commenting. > > -Thilo > No. > > [1] http://ffmpeg.org/developer.html > [2] http://ffmpeg.org/mailing-list-faq.html > ___ > 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] [PATCH] Null check of &s->internal before attempting to free dict and pkt - avoid Null pointer dereference crash
---
libavformat/utils.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index fe8eaa6cb3..73a7d13123 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4331,9 +4331,11 @@ void avformat_free_context(AVFormatContext *s)
}
av_freep(&s->chapters);
av_dict_free(&s->metadata);
-av_dict_free(&s->internal->id3v2_meta);
-av_packet_free(&s->internal->pkt);
-av_packet_free(&s->internal->parse_pkt);
+if (&s->internal) {
+av_dict_free(&s->internal->id3v2_meta);
+av_packet_free(&s->internal->pkt);
+av_packet_free(&s->internal->parse_pkt);
+}
av_freep(&s->streams);
flush_packet_queue(s);
av_freep(&s->internal);
--
2.19.1.windows.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] Rename SRT's streamid to srt_streamid to avoid a conflict with standard streamid option
this one http://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/280949.html does a better job. please merge Best Regards, Sergey чт, 3 июн. 2021 г. в 13:37, Sergey Ilinykh : > Default streamid is some numeric value and not used by SRT code. Instead > SRT has its own string streamid. Current code has the same option name for > both and this causes a conflict when ffmpeg is started from a terminal. > > The attached patch fixes it by renaming SRT's "streamid" to "srt_streamid" > > Best Regards, > Sergey > ___ 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] Null check of &s->internal before attempting to free dict and pkt - avoid Null pointer dereference crash
Robert Beyer:
> ---
> libavformat/utils.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index fe8eaa6cb3..73a7d13123 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4331,9 +4331,11 @@ void avformat_free_context(AVFormatContext *s)
> }
> av_freep(&s->chapters);
> av_dict_free(&s->metadata);
> -av_dict_free(&s->internal->id3v2_meta);
> -av_packet_free(&s->internal->pkt);
> -av_packet_free(&s->internal->parse_pkt);
> +if (&s->internal) {
> +av_dict_free(&s->internal->id3v2_meta);
> +av_packet_free(&s->internal->pkt);
> +av_packet_free(&s->internal->parse_pkt);
> +}
> av_freep(&s->streams);
> flush_packet_queue(s);
> av_freep(&s->internal);
>
1. Checking for &s->internal is nonsense: If s is not NULL and points to
an AVFormatContext, &s->internal is so, too. You want to check for
s->internal.
2. avformat_alloc_context() (the only function that directly allocates
AVFormatContexts) ensures that every successfully allocated
AVFormatContext has an AVFormatInternal set, so the issue should just
not happen. If it does happen for you, then please provide the necessary
details to reproduce it.
- 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] lavfi/drawtext: Add localtime_ms for millisecond precision
Valerii Zapodovnikov (12021-06-08): > Oh, so it worked on patchwork? Strnge, okay then. No need to. Thilo's mail was very fine. If patchwork does not accept it, then patchwork needs fixing, not Thilo's mail. Valerii Zapodovnikov (12021-06-08): > No. ? 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] lavfi/drawtext: Add localtime_ms for millisecond precision
Am 08.06.21 um 19:00 schrieb Valerii Zapodovnikov: > вт, 8 июн. 2021 г., 19:57 Thilo Borgmann : > >> Am 08.06.21 um 18:52 schrieb Valerii Zapodovnikov: >>> Oh, so it worked on patchwork? Strnge, okay then. No need to. >> >> Please read [1] and [2]. Please keep all old text and do inline-commenting. >> >> -Thilo >> > > No. In ignoring our rules for the mailing list as stated in [3] you just got yourself banned. -Thilo [3] http://ffmpeg.org/contact.html#MailingLists >> >> [1] http://ffmpeg.org/developer.html >> [2] http://ffmpeg.org/mailing-list-faq.html >> ___ >> 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] Null check of &s->internal before attempting to free dict and pkt - avoid Null pointer dereference crash
Andreas Rheinhardt:
In my test case:
avformat_open_input(pInputContext, ...) returns an error code
Attempts to free the (allocated?) context memory then causes a NULL reference
exception when accessing &s->internal->id3v2_meta, etc. since &s->internal is
NULL.
avformat_free_context(pInputContext)
- Robert.
-Original Message-
From: ffmpeg-devel On Behalf Of Andreas
Rheinhardt
Sent: June 8, 2021 1:21 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] Null check of &s->internal before
attempting to free dict and pkt - avoid Null pointer dereference crash
Robert Beyer:
> ---
> libavformat/utils.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index fe8eaa6cb3..73a7d13123 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4331,9 +4331,11 @@ void avformat_free_context(AVFormatContext *s)
> }
> av_freep(&s->chapters);
> av_dict_free(&s->metadata);
> -av_dict_free(&s->internal->id3v2_meta);
> -av_packet_free(&s->internal->pkt);
> -av_packet_free(&s->internal->parse_pkt);
> +if (&s->internal) {
> +av_dict_free(&s->internal->id3v2_meta);
> +av_packet_free(&s->internal->pkt);
> +av_packet_free(&s->internal->parse_pkt);
> +}
> av_freep(&s->streams);
> flush_packet_queue(s);
> av_freep(&s->internal);
>
1. Checking for &s->internal is nonsense: If s is not NULL and points to
an AVFormatContext, &s->internal is so, too. You want to check for
s->internal.
2. avformat_alloc_context() (the only function that directly allocates
AVFormatContexts) ensures that every successfully allocated
AVFormatContext has an AVFormatInternal set, so the issue should just
not happen. If it does happen for you, then please provide the necessary
details to reproduce it.
- 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".
___
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] Null check of &s->internal before attempting to free dict and pkt - avoid Null pointer dereference crash
Robert Beyer:
> Andreas Rheinhardt:
>
> In my test case:
> avformat_open_input(pInputContext, ...) returns an error code
> > Attempts to free the (allocated?) context memory then causes a NULL
reference exception when accessing &s->internal->id3v2_meta, etc. since
&s->internal is NULL.
> avformat_free_context(pInputContext)
>
If avformat_open_input() returns an error, then it has freed the
AVFormatContext itself (if it was provided one) and set the pointer to
the AVFormatContext to NULL. Using this pointer in
avformat_free_context() is safe, because of the very first check (for
whether the AVFormatContext is NULL) in avformat_free_context(). But if
you used a preallocated AVFormatContext (I guess you do?) in
avformat_open_input() and use multiple pointers to said AVFormatContext,
then all the other pointers (except the one actually used in
avformat_open_input()) have become dangling and using them in
avformat_free_context() is a use-after-free.
- Andreas
PS: AVFormatContexts used in conjunction with avformat_open_input() need
to be closed by avformat_close_input().
PPS: Don't top-post here.
> - Robert.
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Andreas
> Rheinhardt
> Sent: June 8, 2021 1:21 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Null check of &s->internal before
> attempting to free dict and pkt - avoid Null pointer dereference crash
>
> Robert Beyer:
>> ---
>> libavformat/utils.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index fe8eaa6cb3..73a7d13123 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -4331,9 +4331,11 @@ void avformat_free_context(AVFormatContext *s)
>> }
>> av_freep(&s->chapters);
>> av_dict_free(&s->metadata);
>> -av_dict_free(&s->internal->id3v2_meta);
>> -av_packet_free(&s->internal->pkt);
>> -av_packet_free(&s->internal->parse_pkt);
>> +if (&s->internal) {
>> +av_dict_free(&s->internal->id3v2_meta);
>> +av_packet_free(&s->internal->pkt);
>> +av_packet_free(&s->internal->parse_pkt);
>> +}
>> av_freep(&s->streams);
>> flush_packet_queue(s);
>> av_freep(&s->internal);
>>
> 1. Checking for &s->internal is nonsense: If s is not NULL and points to
> an AVFormatContext, &s->internal is so, too. You want to check for
> s->internal.
> 2. avformat_alloc_context() (the only function that directly allocates
> AVFormatContexts) ensures that every successfully allocated
> AVFormatContext has an AVFormatInternal set, so the issue should just
> not happen. If it does happen for you, then please provide the necessary
> details to reproduce it.
>
> - 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] libavcodec: r12b decoder
Thanks again for the review Andreas. I've addressed the comments:
- moved back to the C90+ style which was in other decoders as well.
- The buffer size check makes sense and I've added that, I'm unsure
about how ffmpeg exactly handles alignment in some cases so I've opted to
stay on the lenient side and only check if it's too small (I see that
pattern more often such as in in r210.c)
- Once you said "shift", I understood what you meant with the "& 0xF0"
comment, it's not about the interaction with the data before it, which I
was thinking you meant, it's just totally not needed and I agree with that.
So that has been cleaned up.
- removed two unused includes
- updated to the latest master
(There are warnings generated during build as Valerii also points out in
his reply, in the previous patch it was md5, this time there are a few
others. These do not stem from this PR for as far as I can see.)
Kind regards,
Dennis Fleurbaaij
On Mon, Jun 7, 2021 at 10:33 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Dennis Fleurbaaij:
> > Thanks for the review Andreas!
> >
> > I've addressed all your concerns besides the "& in the define", I didn't
> > know that the binary AND is implicit in this situation, any link for
> this?
> > Even if it is, I just find it much more pleasing to see the & there
> > somehow, is there some leniency for personal preference?
> >
>
> The lower nibble doesn't survive the right shift; and given that
> GET_FF() returns an uint8_t, there are no bits higher than 0xFF anyway.
>
> I have no objection to keeping the "&".
>
> >
> > +for (h = 0; h < avctx->height; h++) {
> > +g_dst = (uint16_t *)g_line;
> > +b_dst = (uint16_t *)b_line;
> > +r_dst = (uint16_t *)r_line;
> > +
>
> C90 disallows declarations in the middle of blocks, but it allows them
> at the beginning of *any* block, not only the outermost block of a
> function. You can declare these variables here.
>
> And we also allow for loops with variable declarations, i.e. you may
> declare h (and w later) via "for (int h = 0;". (This is illegal in C90.)
>
>
> Your code currently does not check the size of the input packet: It
> needs to be at least height * width / PIXELS_PER_BLOCK *
> BYTES_PER_BLOCK, but it doesn't check that (and I guess that too big
> packets are also invalid?).
>
> - 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".
>
From f66434cd65c5590c500e49eb6338aaa3a1c71a80 Mon Sep 17 00:00:00 2001
From: Dennis Fleurbaaij
Date: Tue, 8 Jun 2021 18:55:02 +0200
Subject: [PATCH] libavcodec: r12b decoder added
R12B is a format used by BlackMagic DeckLink cards, it is
a big-endian 12bpp RGB format which packs 8 pixels into 36
bytes.
Signed-off-by: Dennis Fleurbaaij
---
Changelog | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/codec_id.h | 1 +
libavcodec/r12bdec.c| 141
libavcodec/version.h| 4 +-
libavformat/riff.c | 1 +
8 files changed, 155 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/r12bdec.c
diff --git a/Changelog b/Changelog
index b9d5188cf6..d0717072eb 100644
--- a/Changelog
+++ b/Changelog
@@ -7,6 +7,7 @@ version :
- ADPCM IMA Acorn Replay decoder
- Argonaut Games CVG demuxer
- Argonaut Games CVG muxer
+- r12b decoder
version 4.4:
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 4fa8d7ab10..cfef9d57ff 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -575,6 +575,7 @@ OBJS-$(CONFIG_QTRLE_ENCODER) += qtrleenc.o
OBJS-$(CONFIG_R10K_DECODER)+= r210dec.o
OBJS-$(CONFIG_R10K_ENCODER)+= r210enc.o
OBJS-$(CONFIG_R210_DECODER)+= r210dec.o
+OBJS-$(CONFIG_R12B_DECODER)+= r12bdec.o
OBJS-$(CONFIG_R210_ENCODER)+= r210enc.o
OBJS-$(CONFIG_RA_144_DECODER) += ra144dec.o ra144.o celp_filters.o
OBJS-$(CONFIG_RA_144_ENCODER) += ra144enc.o ra144.o celp_filters.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 623db2a9fa..8db7e730a6 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -266,6 +266,7 @@ extern const AVCodec ff_qtrle_encoder;
extern const AVCodec ff_qtrle_decoder;
extern const AVCodec ff_r10k_encoder;
extern const AVCodec ff_r10k_decoder;
+extern const AVCodec ff_r12b_decoder;
extern const AVCodec ff_r210_encoder;
extern const AVCodec ff_r210_decoder;
extern const AVCodec ff_rasc_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 35527dcc37..ef58d73576 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1856,6 +1856,13 @@ static const AVCodecDescriptor codec_descripto
Re: [FFmpeg-devel] [PATCH] Null check of &s->internal before attempting to free dict and pkt - avoid Null pointer dereference crash
> -Original Message-
> From: ffmpeg-devel On Behalf Of Andreas
> Rheinhardt
> Sent: June 8, 2021 1:21 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Null check of &s->internal before
> attempting to free dict and pkt - avoid Null pointer dereference crash
>
> Robert Beyer:
>> ---
>> libavformat/utils.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index fe8eaa6cb3..73a7d13123 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -4331,9 +4331,11 @@ void avformat_free_context(AVFormatContext *s)
>> }
>> av_freep(&s->chapters);
>> av_dict_free(&s->metadata);
>> -av_dict_free(&s->internal->id3v2_meta);
>> -av_packet_free(&s->internal->pkt);
>> -av_packet_free(&s->internal->parse_pkt);
>> +if (&s->internal) {
>> +av_dict_free(&s->internal->id3v2_meta);
>> +av_packet_free(&s->internal->pkt);
>> +av_packet_free(&s->internal->parse_pkt);
>> +}
>> av_freep(&s->streams);
>> flush_packet_queue(s);
>> av_freep(&s->internal);
>>
> 1. Checking for &s->internal is nonsense: If s is not NULL and points to
> an AVFormatContext, &s->internal is so, too. You want to check for
> s->internal.
> 2. avformat_alloc_context() (the only function that directly allocates
> AVFormatContexts) ensures that every successfully allocated
> AVFormatContext has an AVFormatInternal set, so the issue should just
> not happen. If it does happen for you, then please provide the necessary
> details to reproduce it.
>
> - Andreas
> From: ffmpeg-devel On Behalf Of Andreas
> Rheinhardt
> Sent: June 8, 2021 1:38 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Null check of &s->internal before
> attempting to free dict and pkt - avoid Null pointer dereference crash
>
> Robert Beyer:
> > Andreas Rheinhardt:
> >
> > In my test case:
> > avformat_open_input(pInputContext, ...) returns an error code
> > > Attempts to free the (allocated?) context memory then causes a NULL
> reference exception when accessing &s->internal->id3v2_meta, etc. since
> &s->internal is NULL.
> > avformat_free_context(pInputContext)
> >
>
> If avformat_open_input() returns an error, then it has freed the
> AVFormatContext itself (if it was provided one) and set the pointer to
> the AVFormatContext to NULL.
Thank you - it's not obvious that the context is automatically freed on
avformat_open_input failure.
> Using this pointer in
> avformat_free_context() is safe, because of the very first check (for
> whether the AVFormatContext is NULL) in avformat_free_context(). But if
> you used a preallocated AVFormatContext (I guess you do?) in
> avformat_open_input() and use multiple pointers to said AVFormatContext,
> then all the other pointers (except the one actually used in
> avformat_open_input()) have become dangling and using them in
> avformat_free_context() is a use-after-free.
And there's the bug! I have the context pointer allocated and retained in a
class, but dereferenced in the open call, which results in a use-after-free
from the pointer in the class object.
You're also correct about the (s->internal) check ... wouldn't hurt to add it,
in case internal is/can ever be null.
Thank you.
> - Andreas
>
> PS: AVFormatContexts used in conjunction with avformat_open_input() need
> to be closed by avformat_close_input().
> PPS: Don't top-post here.
Fixed. Thanks ... learning the ropes/rules.
Cheers,
Robert.
___
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] Null check of &s->internal before attempting to free dict and pkt - avoid Null pointer dereference crash
Robert Beyer:
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Andreas
>> Rheinhardt
>> Sent: June 8, 2021 1:21 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH] Null check of &s->internal before
>> attempting to free dict and pkt - avoid Null pointer dereference crash
>>
>> Robert Beyer:
>>> ---
>>> libavformat/utils.c | 8 +---
>>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>>> index fe8eaa6cb3..73a7d13123 100644
>>> --- a/libavformat/utils.c
>>> +++ b/libavformat/utils.c
>>> @@ -4331,9 +4331,11 @@ void avformat_free_context(AVFormatContext *s)
>>> }
>>> av_freep(&s->chapters);
>>> av_dict_free(&s->metadata);
>>> -av_dict_free(&s->internal->id3v2_meta);
>>> -av_packet_free(&s->internal->pkt);
>>> -av_packet_free(&s->internal->parse_pkt);
>>> +if (&s->internal) {
>>> +av_dict_free(&s->internal->id3v2_meta);
>>> +av_packet_free(&s->internal->pkt);
>>> +av_packet_free(&s->internal->parse_pkt);
>>> +}
>>> av_freep(&s->streams);
>>> flush_packet_queue(s);
>>> av_freep(&s->internal);
>>>
>> 1. Checking for &s->internal is nonsense: If s is not NULL and points to
>> an AVFormatContext, &s->internal is so, too. You want to check for
>> s->internal.
>> 2. avformat_alloc_context() (the only function that directly allocates
>> AVFormatContexts) ensures that every successfully allocated
>> AVFormatContext has an AVFormatInternal set, so the issue should just
>> not happen. If it does happen for you, then please provide the necessary
>> details to reproduce it.
>>
>> - Andreas
>
>> From: ffmpeg-devel On Behalf Of Andreas
>> Rheinhardt
>> Sent: June 8, 2021 1:38 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH] Null check of &s->internal before
>> attempting to free dict and pkt - avoid Null pointer dereference crash
>>
>> Robert Beyer:
>>> Andreas Rheinhardt:
>>>
>>> In my test case:
>>> avformat_open_input(pInputContext, ...) returns an error code
Attempts to free the (allocated?) context memory then causes a NULL
>> reference exception when accessing &s->internal->id3v2_meta, etc. since
>> &s->internal is NULL.
>>> avformat_free_context(pInputContext)
>>>
>>
>> If avformat_open_input() returns an error, then it has freed the
>> AVFormatContext itself (if it was provided one) and set the pointer to
>> the AVFormatContext to NULL.
>
> Thank you - it's not obvious that the context is automatically freed on
> avformat_open_input failure.
>
>From the documentation: "Note that a user-supplied AVFormatContext will
be freed on failure."
>> Using this pointer in
>> avformat_free_context() is safe, because of the very first check (for
>> whether the AVFormatContext is NULL) in avformat_free_context(). But if
>> you used a preallocated AVFormatContext (I guess you do?) in
>> avformat_open_input() and use multiple pointers to said AVFormatContext,
>> then all the other pointers (except the one actually used in
>> avformat_open_input()) have become dangling and using them in
>> avformat_free_context() is a use-after-free.
>
> And there's the bug! I have the context pointer allocated and retained in a
> class, but dereferenced in the open call, which results in a use-after-free
> from the pointer in the class object.
Then you need to make sure that these pointers are in sync after
avformat_open_input(). The easiest way is to use the pointer in the
class object itself (if that is possible). But anyway, this is no longer
about developing FFmpeg itself, so it doesn't belong on this list any more.
>
> You're also correct about the (s->internal) check ... wouldn't hurt to add
> it, in case internal is/can ever be null.
>
It can never be NULL; if it is ever NULL, we should crash so that the
bug that made it NULL is not silently ignored (in your case it meant
that a use-after-free (which already happened before using s->internal
in any way) has been found).
> Thank you.
>
>> - Andreas
>>
>> PS: AVFormatContexts used in conjunction with avformat_open_input() need
>> to be closed by avformat_close_input().
>> PPS: Don't top-post here.
>
> Fixed. Thanks ... learning the ropes/rules.
>
> Cheers,
> Robert.
>
___
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] Revert "avformat/dashenc: Disable writing CODECS tag for HEVC streams"
>
>
>On 6/7/21, 12:01 PM, "Valerii Zapodovnikov" wrote:
>
>This reverts commit d6d407d2d758b404af0ce6a8ff46bf164db020a1.
>Hack not needed after a2b1dd0ce301450a47c972745a6b33c4c273aa5d.
>Will fix #7480 and #8904.
>This will include e.g. CODECS="hvc1.2.4.L123.B0" into m3u8.
Pushed.
Thanks, Karthick
>
>Signed-off-by: Valerii Zapodovnikov
>---
> libavformat/dashenc.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
>diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>index 810ab22416..8a626c15a4 100644
>--- a/libavformat/dashenc.c
>+++ b/libavformat/dashenc.c
>@@ -1312,7 +1312,6 @@ static int write_manifest(AVFormatContext *s, int final)
> AVStream *st = s->streams[i];
> OutputStream *os = &c->streams[i];
> char *agroup = NULL;
>-char *codec_str_ptr = NULL;
> int stream_bitrate = os->muxer_overhead;
> if (os->bit_rate > 0)
> stream_bitrate += os->bit_rate;
>@@ -1331,13 +1330,10 @@ static int write_manifest(AVFormatContext *s, int
>final)
> av_strlcat(codec_str, ",", sizeof(codec_str));
> av_strlcat(codec_str, audio_codec_str, sizeof(codec_str));
> }
>-if (st->codecpar->codec_id != AV_CODEC_ID_HEVC) {
>-codec_str_ptr = codec_str;
>-}
> get_hls_playlist_name(playlist_file, sizeof(playlist_file),
> NULL, i);
> ff_hls_write_stream_info(st, c->m3u8_out, stream_bitrate,
> playlist_file, agroup,
>- codec_str_ptr, NULL, NULL);
>+ codec_str, NULL, NULL);
> }
>
> } else {
>--
>2.30.2
>
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>
>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] fftools/ffplay: 240M matrix is not the same as BT.601
On Tue, 8 Jun 2021, Valerii Zapodovnikov wrote: Wait a second. SDL_SetYUVConversionMode does not support 444? You are setting it to mode = SDL_YUV_CONVERSION_AUTOMATIC if it is 444, which I suppose works on just the size of frame? SDL itself does not support YUV444 pixel format, by the time the frame is uploaded into an SDL texture, it is already got converted into one of the pixel formats the SDL renderer supports via acceleration. And that is usually RGB, YUV420 and for some renderers YUYV422/UYVY422. Regards, Marton ___ 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: Pass the HDR10+ metadata to the packet side data in VP9 encoder
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing it
to the AVPacket side data.
---
doc/APIchanges | 2 +
libavcodec/avpacket.c | 1 +
libavcodec/decode.c| 1 +
libavcodec/libvpxenc.c | 99 ++
libavcodec/packet.h| 8
libavcodec/version.h | 4 +-
6 files changed, 113 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index c46f4d5304..60995579e5 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,8 @@ libavutil: 2021-04-27
API changes, most recent first:
+2021-05-25 - 8c88a66d3c - lavc 59.2.100 - packet.h
+ Add AV_PKT_DATA_DYNAMIC_HDR10_PLUS
2021-04-27 - cb3ac722f4 - lavc 59.0.100 - avcodec.h
Constified AVCodecParserContext.parser.
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 7383d12d3e..800bee3489 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -289,6 +289,7 @@ const char *av_packet_side_data_name(enum
AVPacketSideDataType type)
case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
case AV_PKT_DATA_DOVI_CONF: return "DOVI configuration
record";
case AV_PKT_DATA_S12M_TIMECODE: return "SMPTE ST 12-1:2014
timecode";
+case AV_PKT_DATA_DYNAMIC_HDR10_PLUS: return "HDR10+ Dynamic
Metadata (SMPTE 2094-40)";
}
return NULL;
}
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 75bc7ad98e..40f688e40c 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1488,6 +1488,7 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
{ AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
{ AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE },
{ AV_PKT_DATA_S12M_TIMECODE, AV_FRAME_DATA_S12M_TIMECODE
},
+{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
};
if (IS_EMPTY(pkt) && av_fifo_size(avctx->internal->pkt_props) >=
sizeof(*pkt))
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 66bad444d0..d15cf29766 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -64,6 +64,11 @@ struct FrameListData {
struct FrameListData *next;
};
+typedef struct FrameHDR10Plus {
+int64_t pts;
+AVBufferRef *hdr10_plus;
+} FrameHDR10Plus;
+
typedef struct VPxEncoderContext {
AVClass *class;
struct vpx_codec_ctx encoder;
@@ -121,6 +126,8 @@ typedef struct VPxEncoderContext {
int tune_content;
int corpus_complexity;
int tpl_model;
+int discard_hdr10_plus;
+AVFifoBuffer *hdr10_plus_fifo;
/**
* If the driver does not support ROI then warn the first time we
* encounter a frame with ROI side data.
@@ -316,6 +323,55 @@ static av_cold void free_frame_list(struct FrameListData
*list)
}
}
+static av_cold int add_hdr10_plus(AVFifoBuffer *fifo, struct FrameHDR10Plus
*data)
+{
+int err = av_fifo_grow(fifo, sizeof(*data));
+if (err < 0)
+return err;
+av_fifo_generic_write(fifo, data, sizeof(*data), NULL);
+return 0;
+}
+
+static av_cold void free_hdr10_plus(struct FrameHDR10Plus *p)
+{
+if (!p)
+return;
+av_buffer_unref(&p->hdr10_plus);
+av_free(p);
+}
+
+static av_cold void free_hdr10_plus_fifo(AVFifoBuffer **fifo)
+{
+FrameHDR10Plus *frame_hdr10_plus = NULL;
+while (av_fifo_size(*fifo) >= sizeof(FrameHDR10Plus)) {
+av_fifo_generic_read(*fifo, frame_hdr10_plus, sizeof(FrameHDR10Plus),
NULL);
+free_hdr10_plus(frame_hdr10_plus);
+}
+av_fifo_freep(fifo);
+}
+
+static int copy_hdr10_plus_to_pkt(AVFifoBuffer *fifo, AVPacket *pkt)
+{
+FrameHDR10Plus *frame_hdr10_plus;
+uint8_t *data;
+if (av_fifo_size(fifo) < 1)
+return 0;
+
+av_fifo_generic_read(fifo, frame_hdr10_plus, sizeof(*frame_hdr10_plus),
NULL);
+if (!frame_hdr10_plus || !pkt || !frame_hdr10_plus->hdr10_plus ||
frame_hdr10_plus->pts != pkt->pts)
+return 0;
+
+data = av_packet_new_side_data(pkt, AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
frame_hdr10_plus->hdr10_plus->size);
+if (!data) {
+free_hdr10_plus(frame_hdr10_plus);
+return AVERROR(ENOMEM);
+}
+memcpy(data, frame_hdr10_plus->hdr10_plus->data,
frame_hdr10_plus->hdr10_plus->size);
+free_hdr10_plus(frame_hdr10_plus);
+
+return 0;
+}
+
static av_cold int codecctl_int(AVCodecContext *avctx,
enum vp8e_enc_control_id id, int val)
{
@@ -384,6 +440,8 @@ static av_cold int vpx_free(AVCodecContext *avctx)
av_freep(&ctx->twopass_stats.buf);
av_freep(&avctx->stats_out);
free_frame_list(ctx->coded_frame_list);
+if (ctx->hdr10_plus_fifo)
+
Re: [FFmpeg-devel] [PATCH] avcodec: Pass the HDR10+ metadata to the packet side data in VP9 encoder
Mohammad Izadi:
> HDR10+ metadata is stored in the bit stream for HEVC. The story is different
> for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
> passed to packet side data an stored in the container (mkv) for VP9.
>
> This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
> it to the AVPacket side data.
> ---
> doc/APIchanges | 2 +
> libavcodec/avpacket.c | 1 +
> libavcodec/decode.c| 1 +
> libavcodec/libvpxenc.c | 99 ++
> libavcodec/packet.h| 8
> libavcodec/version.h | 4 +-
> 6 files changed, 113 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index c46f4d5304..60995579e5 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,8 @@ libavutil: 2021-04-27
>
>
> API changes, most recent first:
> +2021-05-25 - 8c88a66d3c - lavc 59.2.100 - packet.h
> + Add AV_PKT_DATA_DYNAMIC_HDR10_PLUS
>
> 2021-04-27 - cb3ac722f4 - lavc 59.0.100 - avcodec.h
>Constified AVCodecParserContext.parser.
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 7383d12d3e..800bee3489 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -289,6 +289,7 @@ const char *av_packet_side_data_name(enum
> AVPacketSideDataType type)
> case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
> case AV_PKT_DATA_DOVI_CONF: return "DOVI configuration
> record";
> case AV_PKT_DATA_S12M_TIMECODE: return "SMPTE ST 12-1:2014
> timecode";
> +case AV_PKT_DATA_DYNAMIC_HDR10_PLUS: return "HDR10+ Dynamic
> Metadata (SMPTE 2094-40)";
> }
> return NULL;
> }
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 75bc7ad98e..40f688e40c 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1488,6 +1488,7 @@ int ff_decode_frame_props(AVCodecContext *avctx,
> AVFrame *frame)
> { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
> { AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE
> },
> { AV_PKT_DATA_S12M_TIMECODE,
> AV_FRAME_DATA_S12M_TIMECODE },
> +{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
> AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
> };
>
> if (IS_EMPTY(pkt) && av_fifo_size(avctx->internal->pkt_props) >=
> sizeof(*pkt))
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 66bad444d0..d15cf29766 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -64,6 +64,11 @@ struct FrameListData {
> struct FrameListData *next;
> };
>
> +typedef struct FrameHDR10Plus {
> +int64_t pts;
> +AVBufferRef *hdr10_plus;
> +} FrameHDR10Plus;
> +
> typedef struct VPxEncoderContext {
> AVClass *class;
> struct vpx_codec_ctx encoder;
> @@ -121,6 +126,8 @@ typedef struct VPxEncoderContext {
> int tune_content;
> int corpus_complexity;
> int tpl_model;
> +int discard_hdr10_plus;
> +AVFifoBuffer *hdr10_plus_fifo;
> /**
> * If the driver does not support ROI then warn the first time we
> * encounter a frame with ROI side data.
> @@ -316,6 +323,55 @@ static av_cold void free_frame_list(struct FrameListData
> *list)
> }
> }
>
> +static av_cold int add_hdr10_plus(AVFifoBuffer *fifo, struct FrameHDR10Plus
> *data)
> +{
> +int err = av_fifo_grow(fifo, sizeof(*data));
> +if (err < 0)
> +return err;
> +av_fifo_generic_write(fifo, data, sizeof(*data), NULL);
> +return 0;
> +}
> +
> +static av_cold void free_hdr10_plus(struct FrameHDR10Plus *p)
> +{
> +if (!p)
> +return;
> +av_buffer_unref(&p->hdr10_plus);
> +av_free(p);
> +}
> +
> +static av_cold void free_hdr10_plus_fifo(AVFifoBuffer **fifo)
> +{
> +FrameHDR10Plus *frame_hdr10_plus = NULL;
> +while (av_fifo_size(*fifo) >= sizeof(FrameHDR10Plus)) {
> +av_fifo_generic_read(*fifo, frame_hdr10_plus,
> sizeof(FrameHDR10Plus), NULL);
Did you ever test this with the fifo being nonempty? (It will segfault.)
> +free_hdr10_plus(frame_hdr10_plus);
> +}
> +av_fifo_freep(fifo);
> +}
> +
> +static int copy_hdr10_plus_to_pkt(AVFifoBuffer *fifo, AVPacket *pkt)
> +{
> +FrameHDR10Plus *frame_hdr10_plus;
> +uint8_t *data;
> +if (av_fifo_size(fifo) < 1)
> +return 0;
> +
> +av_fifo_generic_read(fifo, frame_hdr10_plus, sizeof(*frame_hdr10_plus),
> NULL);
> +if (!frame_hdr10_plus || !pkt || !frame_hdr10_plus->hdr10_plus ||
> frame_hdr10_plus->pts != pkt->pts)
> +return 0;
> +
> +data = av_packet_new_side_data(pkt, AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
> frame_hdr10_plus->hdr10_plus->size);
> +if (!data) {
> +free_hdr10_plus(frame_hdr10_plus);
> +return AVERROR(ENOMEM);
> +}
> +memcpy(data, frame_hdr10_plus->hdr10_plus->data,
> frame_hdr10_plus->hdr10_plus->size);
> +free_hdr10_plus(frame_hdr10_plus);
Re: [FFmpeg-devel] [PATCH 26/35] avdevice: Add internal helpers for querying device capabilities
On Tue, Jun 8, 2021 at 3:30 PM Michael Niedermayer wrote: > On Tue, Jun 08, 2021 at 01:04:05AM +0200, Diederick Niehorster wrote: > > brakes build > CC libavdevice/utils.o > libavdevice/utils.c:64:29: error: field ‘query_type’ has incomplete type > enum DshowCapQueryType query_type; > ^~ > libavdevice/utils.c: In function ‘ff_device_get_query_type’: > argh! This slipped through and actually built and worked fine with the msvc-toolchain (implicit int?). That toolchain throws a lot of warnings, didn't spot this one in the noise. Fixed! ___ 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: Pass the HDR10+ metadata to the packet side data in VP9 encoder
On Mon, Jun 7, 2021 at 12:59 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Michael Niedermayer: > > On Mon, Jun 07, 2021 at 10:39:19AM -0700, Mohammad Izadi wrote: > >> HDR10+ metadata is stored in the bit stream for HEVC. The story is > different for VP9 and cannot store the metadata in the bit stream. HDR10+ > should be passed to packet side data an stored in the container (mkv) for > VP9. > >> > >> This CL is taking HDR10+ from AVFrame side data in libvpxenc and is > passing it to the AVPacket side data. > >> --- > >> doc/APIchanges | 2 + > >> libavcodec/avpacket.c | 1 + > >> libavcodec/decode.c| 1 + > >> libavcodec/libvpxenc.c | 98 ++ > >> libavcodec/packet.h| 8 > >> libavcodec/version.h | 4 +- > >> 6 files changed, 112 insertions(+), 2 deletions(-) > > > > still crashing ... > > > > heres a test with a fate sample: > > > > -i ~/fate/msmpeg4v1/mpg4.avi -vcodec libvpx -y vpx.webm > > > > > > frame= 50 fps=0.7 q=0.0 Lsize= 58kB time=00:00:01.63 bitrate= > 288.0kbits/s speed=0.0229x > > video:57kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB > muxing overhead: 1.558648% > > ==26333== Invalid read of size 4 > > ==26333==at 0x1220B5E: av_fifo_size (fifo.c:79) > > ==26333==by 0x9F64C5: free_hdr10_plus_fifo (libvpxenc.c:346) > > ==26333==by 0x9F699D: vpx_free (libvpxenc.c:443) > > ==26333==by 0x7A20D6: avcodec_close (avcodec.c:472) > > ==26333==by 0xAE5002: avcodec_free_context (options.c:163) > > ==26333==by 0x24AC0F: ffmpeg_cleanup (ffmpeg.c:609) > > ==26333==by 0x24258A: exit_program (cmdutils.c:135) > > ==26333==by 0x25C5AF: main (ffmpeg.c:5034) > > ==26333== Address 0x24 is not stack'd, malloc'd or (recently) free'd > > > > > The reason is that the fifo is not allocated unconditionally, but when > freeing it is checked whether the fifo is empty even when the fifo has > never been allocated at all. > Fixed. Verified and passes now. > > - 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". > ___ 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: Pass the HDR10+ metadata to the packet side data in VP9 encoder
Andreas Rheinhardt:
> Mohammad Izadi:
>> HDR10+ metadata is stored in the bit stream for HEVC. The story is different
>> for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
>> passed to packet side data an stored in the container (mkv) for VP9.
>>
>> This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
>> it to the AVPacket side data.
>> ---
>> doc/APIchanges | 2 +
>> libavcodec/avpacket.c | 1 +
>> libavcodec/decode.c| 1 +
>> libavcodec/libvpxenc.c | 99 ++
>> libavcodec/packet.h| 8
>> libavcodec/version.h | 4 +-
>> 6 files changed, 113 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index c46f4d5304..60995579e5 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -13,6 +13,8 @@ libavutil: 2021-04-27
>>
>>
>> API changes, most recent first:
>> +2021-05-25 - 8c88a66d3c - lavc 59.2.100 - packet.h
>> + Add AV_PKT_DATA_DYNAMIC_HDR10_PLUS
>>
>> 2021-04-27 - cb3ac722f4 - lavc 59.0.100 - avcodec.h
>>Constified AVCodecParserContext.parser.
>> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
>> index 7383d12d3e..800bee3489 100644
>> --- a/libavcodec/avpacket.c
>> +++ b/libavcodec/avpacket.c
>> @@ -289,6 +289,7 @@ const char *av_packet_side_data_name(enum
>> AVPacketSideDataType type)
>> case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
>> case AV_PKT_DATA_DOVI_CONF: return "DOVI configuration
>> record";
>> case AV_PKT_DATA_S12M_TIMECODE: return "SMPTE ST 12-1:2014
>> timecode";
>> +case AV_PKT_DATA_DYNAMIC_HDR10_PLUS: return "HDR10+ Dynamic
>> Metadata (SMPTE 2094-40)";
>> }
>> return NULL;
>> }
>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>> index 75bc7ad98e..40f688e40c 100644
>> --- a/libavcodec/decode.c
>> +++ b/libavcodec/decode.c
>> @@ -1488,6 +1488,7 @@ int ff_decode_frame_props(AVCodecContext *avctx,
>> AVFrame *frame)
>> { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
>> { AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE
>> },
>> { AV_PKT_DATA_S12M_TIMECODE,
>> AV_FRAME_DATA_S12M_TIMECODE },
>> +{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
>> AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
>> };
>>
>> if (IS_EMPTY(pkt) && av_fifo_size(avctx->internal->pkt_props) >=
>> sizeof(*pkt))
>> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
>> index 66bad444d0..d15cf29766 100644
>> --- a/libavcodec/libvpxenc.c
>> +++ b/libavcodec/libvpxenc.c
>> @@ -64,6 +64,11 @@ struct FrameListData {
>> struct FrameListData *next;
>> };
>>
>> +typedef struct FrameHDR10Plus {
>> +int64_t pts;
>> +AVBufferRef *hdr10_plus;
>> +} FrameHDR10Plus;
>> +
>> typedef struct VPxEncoderContext {
>> AVClass *class;
>> struct vpx_codec_ctx encoder;
>> @@ -121,6 +126,8 @@ typedef struct VPxEncoderContext {
>> int tune_content;
>> int corpus_complexity;
>> int tpl_model;
>> +int discard_hdr10_plus;
>> +AVFifoBuffer *hdr10_plus_fifo;
>> /**
>> * If the driver does not support ROI then warn the first time we
>> * encounter a frame with ROI side data.
>> @@ -316,6 +323,55 @@ static av_cold void free_frame_list(struct
>> FrameListData *list)
>> }
>> }
>>
>> +static av_cold int add_hdr10_plus(AVFifoBuffer *fifo, struct FrameHDR10Plus
>> *data)
>> +{
>> +int err = av_fifo_grow(fifo, sizeof(*data));
>> +if (err < 0)
>> +return err;
>> +av_fifo_generic_write(fifo, data, sizeof(*data), NULL);
>> +return 0;
>> +}
>> +
>> +static av_cold void free_hdr10_plus(struct FrameHDR10Plus *p)
>> +{
>> +if (!p)
>> +return;
>> +av_buffer_unref(&p->hdr10_plus);
>> +av_free(p);
>> +}
>> +
>> +static av_cold void free_hdr10_plus_fifo(AVFifoBuffer **fifo)
>> +{
>> +FrameHDR10Plus *frame_hdr10_plus = NULL;
>> +while (av_fifo_size(*fifo) >= sizeof(FrameHDR10Plus)) {
>> +av_fifo_generic_read(*fifo, frame_hdr10_plus,
>> sizeof(FrameHDR10Plus), NULL);
>
> Did you ever test this with the fifo being nonempty? (It will segfault.)
>
>> +free_hdr10_plus(frame_hdr10_plus);
>> +}
>> +av_fifo_freep(fifo);
>> +}
>> +
>> +static int copy_hdr10_plus_to_pkt(AVFifoBuffer *fifo, AVPacket *pkt)
>> +{
>> +FrameHDR10Plus *frame_hdr10_plus;
>> +uint8_t *data;
>> +if (av_fifo_size(fifo) < 1)
>> +return 0;
>> +
>> +av_fifo_generic_read(fifo, frame_hdr10_plus, sizeof(*frame_hdr10_plus),
>> NULL);
And so will this here in all likelihood, because you try to write
sizeof(*frame_hdr10_plus) bytes to a random address (namely to
frame_hdr10_plus, which is uninitialized).
>> +if (!frame_hdr10_plus || !pkt || !frame_hdr10_plus->hdr10_plus ||
>> frame_hdr10_plus->pts != pkt->pts)
>> +return 0;
>> +
>> +data = av_packet_new_s
[FFmpeg-devel] [PATCH] dashenc: Write out DASH manifest immediately in streaming mode
When streaming mode is enabled with fMP4/CMAF for DASH output, the
segment files are available to read by players as soon as the first byte
is written instead of only after the file is fully written. The DASH
manifest currently only gets written when the final write to the segment
file occurs. This means that players cannot stream the first segment
while it is being written.
When -lhls is enabled with MP4 segments the HLS manifest is written
immediately to advertise the in-flight segments. This change adds the
same behavior for the DASH manifest so players can stream it
immediately.
---
libavformat/dashenc.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 810ab22416..ea3c76b802 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -2271,6 +2271,14 @@ static int dash_write_packet(AVFormatContext *s,
AVPacket *pkt)
if (ret < 0) {
return handle_io_open_error(s, ret, os->temp_path);
}
+
+// in streaming mode, the segments are available for playing
+// before fully written but the manifest is needed so that
+// clients and discover the segment filenames.
+if (c->streaming && os->segment_type == SEGMENT_TYPE_MP4) {
+write_manifest(s, 0);
+}
+
if (c->lhls) {
char *prefetch_url = use_rename ? NULL : os->filename;
write_hls_media_playlist(os, s, pkt->stream_index, 0,
prefetch_url);
--
2.31.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] dashenc: Write out DASH manifest immediately in streaming mode
On 08.06.2021 21:03, Kevin LaFlamme wrote: When streaming mode is enabled with fMP4/CMAF for DASH output, the segment files are available to read by players as soon as the first byte is written instead of only after the file is fully written. The DASH manifest currently only gets written when the final write to the segment file occurs. This means that players cannot stream the first segment while it is being written. Is this really a good idea? Imagine the files are being served by a http server. The server will stat() the file, and then send that size to the client in the HTTP headers. If now a Client reads that file way early, it will receive an incomplete version of the file. HTTP servers don't typically are capable of streaming files that are actively being written to. Reading a file while it's being written to is also not sensible possible or behaves in potentially unexpected ways, depending on the OS. When -lhls is enabled with MP4 segments the HLS manifest is written immediately to advertise the in-flight segments. This change adds the same behavior for the DASH manifest so players can stream it immediately. smime.p7s Description: S/MIME Cryptographic 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] dashenc: Write out DASH manifest immediately in streaming mode
For streaming mode with fragmented MP4 the intention is to have the client read a partial file since it’s broken up into sequential boxes that are playable independently. This doesn’t change the segment files themselves or how they are written, it just writes a full index file ahead of time. Even currently, the manifest gets written after the first segment is written and the player can immediately attempt to start reading the second segment before it’s fully written. This is the same thing that the “-lhls” is doing in the block below, writing out the HLS manifest immediately so that it contains X-EXT-PREFETCH fields for the partial segment files. Currently, if you have a low latency DASH stream with “-ldash” and “-streaming” and the player joins in the middle of the stream everything works and it starts playing from the middle of the current segment. This means even with 10 second segments you can have latency < 1sec of the live edge. However, this doesn’t work for the very first segment because the manifest isn’t available to the player yet. I have a low-latency player where I’m seeing this issue right now and this addresses the problem, and seems consistent with the “-lhls” handling below, but happy to make changes if there is something else I’m missing. Kevin LaFlamme Director of Engineering (Front End) 774.265.0382 (m) aiera.com On Jun 8, 2021, 3:10 PM -0400, Timo Rothenpieler , wrote: > On 08.06.2021 21:03, Kevin LaFlamme wrote: > > When streaming mode is enabled with fMP4/CMAF for DASH output, the > > segment files are available to read by players as soon as the first byte > > is written instead of only after the file is fully written. The DASH > > manifest currently only gets written when the final write to the segment > > file occurs. This means that players cannot stream the first segment > > while it is being written. > > Is this really a good idea? > Imagine the files are being served by a http server. > The server will stat() the file, and then send that size to the client > in the HTTP headers. > If now a Client reads that file way early, it will receive an incomplete > version of the file. HTTP servers don't typically are capable of > streaming files that are actively being written to. > > Reading a file while it's being written to is also not sensible possible > or behaves in potentially unexpected ways, depending on the OS. > > > When -lhls is enabled with MP4 segments the HLS manifest is written > > immediately to advertise the in-flight segments. This change adds the > > same behavior for the DASH manifest so players can stream it > > immediately. > > > > ___ > 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 v3] lavc/aomdec: Allow RGB decoding
On Sat, Jun 5, 2021 at 10:16 PM Valerii Zapodovnikov
wrote:
>
> Yes, RGB is signalled by Identity matrix if and only if XYZ is not
> in transfer. XYZ primaries are just normal primaries that can be
> used for normal RGB, no problem, so I do not check for them.
> No need to test for sRGB primaries (that is AVCOL_PRI_BT709), as
> ffplay does not know what that is (is not color managed), but mpv
> will do that automatically. This will also support other transfers
> like DCI-P3 / DCI-D65 one, et cetera. See libvpxdec.c.
> Also the default AV1 decoder is libdav1d, which is not affected.
> For XYZ support someone should add correct pixel format in the code.
>
> Signed-off-by: Valerii Zapodovnikov
> ---
> libavcodec/libaomdec.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/libaomdec.c b/libavcodec/libaomdec.c
> index 6e7324a832..156e644263 100644
> --- a/libavcodec/libaomdec.c
> +++ b/libavcodec/libaomdec.c
> @@ -134,15 +134,27 @@ static int set_pix_fmt(AVCodecContext *avctx, struct
> aom_image *img)
> case AOM_IMG_FMT_I444:
> case AOM_IMG_FMT_I44416:
> if (img->bit_depth == 8) {
> -avctx->pix_fmt = AV_PIX_FMT_YUV444P;
> +if (avctx->colorspace == AVCOL_SPC_RGB && avctx->color_trc !=
> AVCOL_TRC_SMPTE428) {
This doesn't match the check in libdav1d.c. I think you should be able
to get the same information here.
___
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] dashenc: Write out DASH manifest immediately in streaming mode
On 08.06.2021 21:24, Kevin LaFlamme wrote: For streaming mode with fragmented MP4 the intention is to have the client read a partial file since it’s broken up into sequential boxes that are playable independently. This doesn’t change the segment files themselves or how they are written, it just writes a full index file ahead of time. Even currently, the manifest gets written after the first segment is written and the player can immediately attempt to start reading the second segment before it’s fully written. This is the same thing that the “-lhls” is doing in the block below, writing out the HLS manifest immediately so that it contains X-EXT-PREFETCH fields for the partial segment files. Currently, if you have a low latency DASH stream with “-ldash” and “-streaming” and the player joins in the middle of the stream everything works and it starts playing from the middle of the current segment. This means even with 10 second segments you can have latency < 1sec of the live edge. However, this doesn’t work for the very first segment because the manifest isn’t available to the player yet. I have a low-latency player where I’m seeing this issue right now and this addresses the problem, and seems consistent with the “-lhls” handling below, but happy to make changes if there is something else I’m missing. Yes, I'm aware that that's how it's supposed to work in theory. But does that work with any HTTP server? Do they really manage to stream the file while it's being written to? Or does this need special software to serve the file? And in turn, will it break for a user just pointing apache/nginx at such a list? smime.p7s Description: S/MIME Cryptographic 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 3/3] avcodec/ttadata: Add sentinel at the end of ff_tta_shift_1
Fixes: out of array access
Fixes:
34933/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TTA_fuzzer-5629322560929792
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ttadata.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/ttadata.c b/libavcodec/ttadata.c
index bf793a4cc8..aa9f418a7d 100644
--- a/libavcodec/ttadata.c
+++ b/libavcodec/ttadata.c
@@ -30,7 +30,8 @@ const uint32_t ff_tta_shift_1[] = {
0x0100, 0x0200, 0x0400, 0x0800,
0x1000, 0x2000, 0x4000, 0x8000,
0x8000, 0x8000, 0x8000, 0x8000,
-0x8000, 0x8000, 0x8000, 0x8000
+0x8000, 0x8000, 0x8000, 0x8000,
+0x
};
const uint32_t * const ff_tta_shift_16 = ff_tta_shift_1 + 4;
--
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".
[FFmpeg-devel] [PATCH 2/3] avformat/mov: Check for duplicate mdcv
Fixes: memleak
Fixes:
34932/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5456227658235904
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6c99a67ff5..47a8e41236 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5396,7 +5396,7 @@ static int mov_read_mdcv(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
sc = c->fc->streams[c->fc->nb_streams - 1]->priv_data;
-if (atom.size < 24) {
+if (atom.size < 24 || sc->mastering) {
av_log(c->fc, AV_LOG_ERROR, "Invalid Mastering Display Color Volume
box\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".
[FFmpeg-devel] [PATCH 1/3] avformat/flvdec: Check data before casting
Fixes: -nan is outside the range of representable values of type 'long'
Fixes: signed integer overflow: 1000 * -9223372036854775808 cannot be
represented in type 'long'
Fixes:
34890/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-5334208657620992
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/flvdec.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 6bd6c8c944..60d1a5c654 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -682,7 +682,11 @@ static int amf_parse_object(AVFormatContext *s, AVStream
*astream,
av_dict_set(&s->metadata, key, str_val, 0);
} else if (amf_type == AMF_DATA_TYPE_STRING) {
av_dict_set(&s->metadata, key, str_val, 0);
-} else if (amf_type == AMF_DATA_TYPE_DATE) {
+} else if ( amf_type == AMF_DATA_TYPE_DATE
+ && isfinite(date.milliseconds)
+ && date.milliseconds > INT64_MIN/1000
+ && date.milliseconds < INT64_MAX/1000
+ ) {
// timezone is ignored, since there is no easy way to offset the
UTC
// timestamp into the specified timezone
avpriv_dict_set_timestamp(&s->metadata, key, 1000 *
(int64_t)date.milliseconds);
--
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] dashenc: Write out DASH manifest immediately in streaming mode
To serve it in a truly streaming way does require some special purpose server or configuration, but the `@availabilityTimeComplete` field that is written into the manifest is supposed to indicate to the client making the request whether or not the segment file is complete at the time it becomes available. In streaming mode, this is set to false so the client should expect that it can get a partial segment between the available start time and the segment duration. So as each box is written to the file, it should be safe for the HTTP server to send the partial segment file that is currently on disk. And the DASH spec specifically indicates whether or not to expect a partial file for the segment being requested. If the client can’t handle a partial file and is still making an attempt to request it before it’s fully available (which is calculable from the information in the manifest), the client wouldn’t be respecting the DASH spec. Kevin LaFlamme Director of Engineering (Front End) 774.265.0382 (m) aiera.com On Jun 8, 2021, 3:34 PM -0400, Timo Rothenpieler , wrote: > On 08.06.2021 21:24, Kevin LaFlamme wrote: > > For streaming mode with fragmented MP4 the intention is to have the client > > read a partial file since it’s broken up into sequential boxes that are > > playable independently. This doesn’t change the segment files themselves or > > how they are written, it just writes a full index file ahead of time. > > > > Even currently, the manifest gets written after the first segment is > > written and the player can immediately attempt to start reading the second > > segment before it’s fully written. > > > > This is the same thing that the “-lhls” is doing in the block below, > > writing out the HLS manifest immediately so that it contains X-EXT-PREFETCH > > fields for the partial segment files. > > > > Currently, if you have a low latency DASH stream with “-ldash” and > > “-streaming” and the player joins in the middle of the stream everything > > works and it starts playing from the middle of the current segment. This > > means even with 10 second segments you can have latency < 1sec of the live > > edge. However, this doesn’t work for the very first segment because the > > manifest isn’t available to the player yet. > > > > I have a low-latency player where I’m seeing this issue right now and this > > addresses the problem, and seems consistent with the “-lhls” handling > > below, but happy to make changes if there is something else I’m missing. > > Yes, I'm aware that that's how it's supposed to work in theory. > But does that work with any HTTP server? > Do they really manage to stream the file while it's being written to? > Or does this need special software to serve the file? And in turn, will > it break for a user just pointing apache/nginx at such a list? > > > ___ > 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 10/35] fftools: provide media type info for devices
On Tue, Jun 8, 2021 at 1:57 PM Nicolas George wrote: > > The feature looks useful. But the printing must go to stdout, not to > logging, because it is meant to be readable by scripts. Done. Only problem is that now a device of mine that should be called "Microphone Array (Intel® Smart Sound Technology (Intel® SST))" is instead printed as "Intel┬« Smart Sound Technology (Intel┬« SST)". Since devices are selected by name for some avdevices (dshow), thats an issue. Googling tells me that printing UTF-8 (which is whats returned by dshow's get_device_list) with printf is complicated to say the least on Windows. It all works when logging because log.c has implemented win_console_puts(), which looks like it would be easy to make available more broadly. Do you see a solution that would allow printing the device name correctly? Thanks! Dee ___ 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 11/35] avformat: add control_message function to AVInputFormat
On Tue, Jun 8, 2021 at 2:00 PM Nicolas George wrote: > Maybe wrap the commit message at 60 columns. Will do ___ 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] fftools/ffplay: 240M matrix is not the same as BT.601
On Tue, 8 Jun 2021, Valerii Zapodovnikov wrote: Can you merge my mxfdec patch? Thank you. I'd give at least a week for the mxf maintainer to respond before pushing. Listen, it is commonly known that ffplay is broken, Carl agrees. MPV is not broken and is perfect according to reference calculator here. https://res18h39.netlify.app/color I did send you a sample in my "v1" patch (this is not v2, since v1 had wrong title, so v2 would be wrong thing to do, I just superseeded patch on patchwork). But for your comfort here it is again: Patchwork statuses are rarely monitored, so IMHO it is better to use v2 in the mailing list even for cases like this. https://trac.ffmpeg.org/attachment/ticket/9167/2.mp4 (also read #9167). Just *use* the sample above and ffplay it without any flags and ffplay with -vf scale=in_color_matrix=bt601,format=gbrp. Both attempts gets me 238,77,44. If you get something else, then I guess it is SDL version / renderer / OS / HW dependant? With MPV, it is 237,77,44 for me. I do not really care about ffplay, Ok. I care about Chromium (since I work on it) and now VLC. You can carefully read those two issues that use the sample above too. https://code.videolan.org/videolan/vlc/-/issues/25651 https://code.videolan.org/videolan/vlc/-/issues/25676 As you can see from those issues I know a lot about YCbCr and read the first documents from back when ITU-R was CCI(R). I even know that BT.709 was first defined in CCIR Rec. XA/11 1986-90f, a.k.a. IWP 11/6-2108 (Canada). That is not something you can fimd on the Internet, only in ITU-R archives (wikipedia is me, I wrote it there). So, please, stop with this. I do respect your knowledge regarding colorspaces, but I cannot reproduce the issue in 8862, therefore the FIXME makes no sense to me. So applied the patch without it. Regards, Marton ___ 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 13/35] avdevice: adding control message requesting to show config dialog
On Tue, Jun 8, 2021 at 2:02 PM Nicolas George wrote: > > Diederick Niehorster (12021-06-08): > > +/** > > + * Request to show configuration dialog. > > + * > > + * If device has a configuration dialog of type indicated by > > + * data, show it. > > + * > > + * data: int. > > ? Do i understand correctly that you would like it documented what this int means? It would be avdevice-specific. If a device has multiple dialogs, the int allows indicating which is to be shown. Would adding "data: int: indicates which dialog to show. Meaning is device specific." work? Thanks, Dee ___ 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 20/35] avdevice/avdevice: clean up avdevice_capabilities_create
On Tue, Jun 8, 2021 at 2:09 PM Nicolas George wrote: > > Diederick Niehorster (12021-06-08): > > -*caps = av_mallocz(sizeof(**caps)); > > +*caps = av_mallocz(sizeof(AVDeviceCapabilitiesQuery)); > > var = malloc(sizeof(*var)) is preferred over var = malloc(type), because > if you change the type of var, it happens in another part of the code > and you would have to remember to change it here too. Reverted. Thanks, Dee ___ 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 25/35] avutil/opt: add av_opt_to_string
On Tue, Jun 8, 2021 at 4:32 PM Nicolas George wrote:
>
> Diederick Niehorster (12021-06-08):
> Please wrap this.
Will do.
> > -int av_opt_get(void *obj, const char *name, int search_flags, uint8_t
> > **out_val)
> > +static int print_option(void* dst, enum AVOptionType type, int
> > search_flags, uint8_t** out_val)
>
> I really do not like the fact that it always makes a dynamic allocation,
> especially since in most cases we know the buffer has a small bounded
> size.
>
> I'd rather have AVWriter here, but in the meantime, please consider
> using AVBPrint.
The guts of this function is unchanged from av_opt_get, just moved
here, should i address this in this patch, or is it a separate issue?
Happy to do either.
> > {
> > -void *dst, *target_obj;
> > -const AVOption *o = av_opt_find2(obj, name, NULL, 0, search_flags,
> > &target_obj);
> > -uint8_t *bin, buf[128];
>
> > +uint8_t* bin, buf[128];
>
> Here and everywhere, the pointer mark belongs with the variable name.
> This is an obvious example of why: written like this, it seems that bin
> and buf[128] are both uint8_t*. Correctly written, it's obvious that
> only bin is a pointer.
Absolutely, auto-formatter got me.
> > -case AV_OPT_TYPE_CONST:
> > -ret = snprintf(buf, sizeof(buf), "%f", o->default_val.dbl);
> > -break;
>
> I think you should have left the case here.
ok
> > int av_opt_get_dict_val(void *obj, const char *name, int search_flags,
> > AVDictionary **out_val);
> > +/**
>
> Empty line please.
done.
> > + * Format option value and output to string.
> > + * @param[in] val an option value that can be represented as a double.
> > + * @param[in] type of the option.
> > + * @param[out] out_val value of the option will be written here
> > + * @return >=0 on success, a negative error code otherwise
> > + *
> > + * @note the returned string will be av_malloc()ed and must be av_free()ed
> > by the caller
> > + */
> > +int av_opt_to_string(double val, enum AVOptionType type, uint8_t
> > **out_val);
>
> If it only works for number-like options, then the name should reflect
> it, and the documentation should state it.
>
> Also, I have reservations about using double here: large integers cannot
> be accurately coded with double.
I understand your concerns. Perhaps its good to think about the use
case (which is more narrow than the current name suggests):
av_opt_query_ranges and the device capabilities API return a bunch of
AVOptionRange, which contains the fields:
double value_min, value_max;
I need a function to format these properly (e.g. "yuyv422" instead of
1), and that does not take a AVOption as input, since these min and
max values are not stored in an AVOption (and this new function could
be used for formatting the values stored in the fields double min and
double max in an AVOption as well). Hence the input to the function is
double.
I agree thats not ideal, nor is it great that values are stored as
doubles in a AVOptionRange, since that limits its use to things
representable as double (which arguably anything with a range is,
logically, but as you said, double can't represent everything). My
ideal solution would be to change the following def in AVOption:
union {
int64_t i64;
double dbl;
const char *str;
/* TODO those are unused now */
AVRational q;
} default_val;
into a named union, and use that for the default_val of an AVOption,
and for AVOptionRange's value_min and value_max. (and possibly also
for AVOption's min and max fields, but that may be too big a change).
Thats a significant API change, but AVOptionRange is hardly used in
the ffmpeg code base (I have no idea about user code, but since
they're hardly exposed, i'd expect the same?), but would allow
expressing ranges precisely, regardless of type. That would make a
more general to_string function possible as well.
Anyway, I'd be pretty happy with the solution of just adding a
function with a restricted use case and better name. What do you
think?
Thanks and all the best,
Dee
___
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] libavcodec: r12b decoder
Trying to get patchwork to pick up patch from thread.
Kind regards,
Dennis Fleurbaaij
From f66434cd65c5590c500e49eb6338aaa3a1c71a80 Mon Sep 17 00:00:00 2001
From: Dennis Fleurbaaij
Date: Tue, 8 Jun 2021 18:55:02 +0200
Subject: [PATCH] libavcodec: r12b decoder added
R12B is a format used by BlackMagic DeckLink cards, it is
a big-endian 12bpp RGB format which packs 8 pixels into 36
bytes.
Signed-off-by: Dennis Fleurbaaij
---
Changelog | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/codec_id.h | 1 +
libavcodec/r12bdec.c| 141
libavcodec/version.h| 4 +-
libavformat/riff.c | 1 +
8 files changed, 155 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/r12bdec.c
diff --git a/Changelog b/Changelog
index b9d5188cf6..d0717072eb 100644
--- a/Changelog
+++ b/Changelog
@@ -7,6 +7,7 @@ version :
- ADPCM IMA Acorn Replay decoder
- Argonaut Games CVG demuxer
- Argonaut Games CVG muxer
+- r12b decoder
version 4.4:
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 4fa8d7ab10..cfef9d57ff 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -575,6 +575,7 @@ OBJS-$(CONFIG_QTRLE_ENCODER) += qtrleenc.o
OBJS-$(CONFIG_R10K_DECODER)+= r210dec.o
OBJS-$(CONFIG_R10K_ENCODER)+= r210enc.o
OBJS-$(CONFIG_R210_DECODER)+= r210dec.o
+OBJS-$(CONFIG_R12B_DECODER)+= r12bdec.o
OBJS-$(CONFIG_R210_ENCODER)+= r210enc.o
OBJS-$(CONFIG_RA_144_DECODER) += ra144dec.o ra144.o celp_filters.o
OBJS-$(CONFIG_RA_144_ENCODER) += ra144enc.o ra144.o celp_filters.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 623db2a9fa..8db7e730a6 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -266,6 +266,7 @@ extern const AVCodec ff_qtrle_encoder;
extern const AVCodec ff_qtrle_decoder;
extern const AVCodec ff_r10k_encoder;
extern const AVCodec ff_r10k_decoder;
+extern const AVCodec ff_r12b_decoder;
extern const AVCodec ff_r210_encoder;
extern const AVCodec ff_r210_decoder;
extern const AVCodec ff_rasc_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 35527dcc37..ef58d73576 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1856,6 +1856,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("Digital Pictures SGA Video"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_R12B,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "r12b",
+.long_name = NULL_IF_CONFIG_SMALL("Uncompressed RGB 12-bit 8px in
36B"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
/* various PCM "codecs" */
{
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 83e1dbb4b3..ecfdbc46c0 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -306,6 +306,7 @@ enum AVCodecID {
AV_CODEC_ID_CRI,
AV_CODEC_ID_SIMBIOSIS_IMX,
AV_CODEC_ID_SGA_VIDEO,
+AV_CODEC_ID_R12B,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
start of audio codecs
diff --git a/libavcodec/r12bdec.c b/libavcodec/r12bdec.c
new file mode 100644
index 00..986f96e687
--- /dev/null
+++ b/libavcodec/r12bdec.c
@@ -0,0 +1,141 @@
+/*
+ * r12b decoder
+ *
+ * Copyright (c) 2021 Dennis Fleurbaaij
+ *
+ * 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 "avcodec.h"
+#include "internal.h"
+
+#define WORDS_PER_BLOCK 9
+#define PIXELS_PER_BLOCK 8
+#define BYTES_PER_BLOCK 36
+
+static av_cold int decode_init(AVCodecContext *avctx)
+{
+avctx->pix_fmt = AV_PIX_FMT_GBRP12LE;
+avctx->bits_per_raw_sample = 12;
+
+return 0;
+}
+
+static int decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
+AVPacket *avpkt)
+{
+int ret;
+uint8_t *g_line, *b_line, *r_line;
+
+AVFrame *pic = data;
+const uint8_t* src = avpkt->data;
+const int blocks_per_line = avctx->width / PIXELS_PER_BLOCK;
+
+if (avctx->width % PIXELS_PER_BLOCK != 0) {
+av
Re: [FFmpeg-devel] [PATCH v2] avformat/libsrt: log streamid in listener mode
On Tue, 1 Jun 2021, Zhao Zhili wrote:
It's useful for test client which pass streamid to ffmpeg/ffplay.
For example, use ffmpeg to test streamid support in VLC:
./ffmpeg -v info -re -i foo.mp4 -c copy -f mpegts -mode listener
srt://127.0.0.1:9000
./vlc srt://127.0.0.1:9000?streamid=foobar
---
libavformat/libsrt.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index c1e96f700e..613997c501 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -153,6 +153,15 @@ static int libsrt_neterrno(URLContext *h)
return os_errno ? AVERROR(os_errno) : AVERROR_UNKNOWN;
}
+static int libsrt_getsockopt(URLContext *h, int fd, SRT_SOCKOPT optname, const
char * optnamestr, void * optval, int * optlen)
+{
+if (srt_getsockopt(fd, 0, optname, optval, optlen) < 0) {
+av_log(h, AV_LOG_ERROR, "failed to get option %s on socket: %s\n",
optnamestr, srt_getlasterror_str());
+return AVERROR(EIO);
+}
+return 0;
+}
+
static int libsrt_socket_nonblock(int socket, int enable)
{
int ret, blocking = enable ? 0 : 1;
@@ -224,6 +233,8 @@ static int libsrt_listen(int eid, int fd, const struct
sockaddr *addr, socklen_t
{
int ret;
int reuse = 1;
+char streamid[512] = {};
+int streamid_len = sizeof(streamid);
if (srt_setsockopt(fd, SOL_SOCKET, SRTO_REUSEADDR, &reuse, sizeof(reuse))) {
av_log(h, AV_LOG_WARNING, "setsockopt(SRTO_REUSEADDR) failed\n");
}
@@ -242,6 +253,8 @@ static int libsrt_listen(int eid, int fd, const struct
sockaddr *addr, socklen_t
return libsrt_neterrno(h);
if (libsrt_socket_nonblock(ret, 1) < 0)
av_log(h, AV_LOG_DEBUG, "libsrt_socket_nonblock failed\n");
+if (!libsrt_getsockopt(h, ret, SRTO_STREAMID, "SRTO_STREAMID", streamid,
&streamid_len))
+av_log(h, AV_LOG_VERBOSE, "accept streamid [%s], length %d\n",
streamid, streamid_len);
Does it make sense to print the length? Shouldn't this be
("accepted streamid [%.*s]\n", streamid_len, streamid)
instead to avoid overreads at 512 byte streamids, or dumping garbage if it
is not 0 terminated? (You can also avoid 0 initialization that way).
Thanks,
Marton
return ret;
}
@@ -276,15 +289,6 @@ static int libsrt_setsockopt(URLContext *h, int fd,
SRT_SOCKOPT optname, const c
return 0;
}
-static int libsrt_getsockopt(URLContext *h, int fd, SRT_SOCKOPT optname, const
char * optnamestr, void * optval, int * optlen)
-{
-if (srt_getsockopt(fd, 0, optname, optval, optlen) < 0) {
-av_log(h, AV_LOG_ERROR, "failed to get option %s on socket: %s\n",
optnamestr, srt_getlasterror_str());
-return AVERROR(EIO);
-}
-return 0;
-}
-
/* - The "POST" options can be altered any time on a connected socket.
They MAY have also some meaning when set prior to connecting; such
option is SRTO_RCVSYN, which makes connect/accept call asynchronous.
--
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".
___
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/libsrt: workaround conflict with ffmpeg cmdline option
On Fri, 4 Jun 2021, Zhao Zhili wrote:
Add 'srt_streamid' option as an alias for 'streamid'.
---
doc/protocols.texi | 3 +++
libavformat/libsrt.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 8371f83059..8b21ce046e 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1558,6 +1558,9 @@ This option doesn’t make sense in Rendezvous connection;
the result
might be that simply one side will override the value from the other
side and it’s the matter of luck which one would win
+@item srt_streamid=@var{string}
+Alias for @samp{streamid} to avoid conflict with ffmpeg command line option.
+
@item smoother=@var{live|file}
The type of Smoother used for the transmission for that socket, which
is responsible for the transmission and congestion control. The Smoother
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 6ea6c35c53..afbf01fc87 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -134,6 +134,7 @@ static const AVOption libsrt_options[] = {
{ "lossmaxttl", "Maximum possible packet reorder tolerance",
OFFSET(lossmaxttl), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
{ "minversion", "The minimum SRT version that is required from the
peer", OFFSET(minversion), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
INT_MAX, .flags = D|E },
{ "streamid", "A string of up to 512 characters that an Initiator can pass
to a Responder", OFFSET(streamid), AV_OPT_TYPE_STRING, { .str = NULL },
.flags = D|E },
+{ "srt_streamid", "A string of up to 512 characters that an Initiator can
pass to a Responder", OFFSET(streamid), AV_OPT_TYPE_STRING, { .str = NULL },
.flags = D|E },
{ "smoother", "The type of Smoother used for the transmission for that
socket", OFFSET(smoother), AV_OPT_TYPE_STRING, { .str = NULL },
.flags = D|E },
{ "messageapi", "Enable message API",
OFFSET(messageapi), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1,
.flags = D|E },
{ "transtype", "The transmission type for the socket",
OFFSET(transtype),AV_OPT_TYPE_INT, { .i64 = SRTT_INVALID }, SRTT_LIVE, SRTT_INVALID,
.flags = D|E, "transtype" },
--
2.31.1
Thanks, applied.
Regards,
Marton
___
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 2/2] avformat/libsrt: add tsbpd option
On Sat, 5 Jun 2021, Marton Balint wrote:
On Fri, 4 Jun 2021, Zhao Zhili wrote:
From: Zhao Zhili
---
v2: update doc
LGTM for the set.
Applied, thanks.
Marton
doc/protocols.texi | 5 +
libavformat/libsrt.c | 5 -
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 8b21ce046e..d3095c88c6 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1610,6 +1610,11 @@ Default is -1. -1 means auto (off with 0 seconds in
live mode, on with 180
seconds in file mode). The range for this option is integers in the
0 - @code{INT_MAX}.
+@item tsbpd=@var{1|0}
+When true, use Timestamp-based Packet Delivery mode. The default behavior
+depends on the transmission type: enabled in live mode, disabled in file
+mode.
+
@end table
For more information see: @url{https://github.com/Haivision/srt}.
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 5298725ad5..d02b7a95ec 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -90,6 +90,7 @@ typedef struct SRTContext {
int messageapi;
SRT_TRANSTYPE transtype;
int linger;
+int tsbpd;
} SRTContext;
#define D AV_OPT_FLAG_DECODING_PARAM
@@ -141,6 +142,7 @@ static const AVOption libsrt_options[] = {
{ "live", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = SRTT_LIVE },
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
{ "file", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = SRTT_FILE },
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
{ "linger", "Number of seconds that the socket waits for unsent
data when closing", OFFSET(linger), AV_OPT_TYPE_INT, { .i64
= -1 }, -1, INT_MAX, .flags = D|E },
+{ "tsbpd", "Timestamp-based packet delivery",
OFFSET(tsbpd),AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1,
.flags = D|E },
{ NULL }
};
@@ -356,7 +358,8 @@ static int libsrt_set_options_pre(URLContext *h, int
fd)
#endif
(s->messageapi >= 0 && libsrt_setsockopt(h, fd, SRTO_MESSAGEAPI,
"SRTO_MESSAGEAPI", &s->messageapi, sizeof(s->messageapi)) < 0) ||
(s->payload_size >= 0 && libsrt_setsockopt(h, fd, SRTO_PAYLOADSIZE,
"SRTO_PAYLOADSIZE", &s->payload_size, sizeof(s->payload_size)) < 0) ||
-((h->flags & AVIO_FLAG_WRITE) && libsrt_setsockopt(h, fd,
SRTO_SENDER, "SRTO_SENDER", &yes, sizeof(yes)) < 0)) {
+((h->flags & AVIO_FLAG_WRITE) && libsrt_setsockopt(h, fd,
SRTO_SENDER, "SRTO_SENDER", &yes, sizeof(yes)) < 0) ||
+(s->tsbpd >= 0 && libsrt_setsockopt(h, fd, SRTO_TSBPDMODE,
"SRTO_TSBPDMODE", &s->tsbpd, sizeof(s->tsbpd)) < 0)) {
return AVERROR(EIO);
}
--
2.31.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 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] Fix memory allocation problem. Related to ticket #9264.
On Tue, 8 Jun 2021, hou...@uniontech.com wrote:
From: houlei
Signed-off-by: houlei
---
libavdevice/xv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavdevice/xv.c b/libavdevice/xv.c
index 24ba3179f6..7e15c178b6 100644
--- a/libavdevice/xv.c
+++ b/libavdevice/xv.c
@@ -296,10 +296,11 @@ static int write_picture(AVFormatContext *s, uint8_t
*input_data[4],
{
XVContext *xv = s->priv_data;
XvImage *img = xv->yuv_image;
-uint8_t *data[3] = {
+uint8_t *data[4] = {
img->data + img->offsets[0],
img->data + img->offsets[1],
-img->data + img->offsets[2]
+img->data + img->offsets[2],
+img->data + img->offsets[3]
This does not look good, img->offsets[3] is probably not valid, because
img->offsets and img->pitches are both arrays of img->num_planes, which is
3... So to be correct, img->pitches should also be copied to a 4 long
array, and that should be passed to av_image_copy, but the 4th value can
be left as 0 both for pitches and data.
Regards,
Marton
};
/* Check messages. Window might get closed. */
--
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 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] libavcodec: r12b decoder
Am Di., 8. Juni 2021 um 11:52 Uhr schrieb Dennis Fleurbaaij : > The four letter "r12b" format code is from the DeckLink documentation; > there are other described formats there as well such as r12l, r10b, r10l > and r210. I'm using DirectShow which signals the encoding to downstream > components through the use of FOURCC codes and hence for this filter to be > of any use in such applications there needs to be a way to identify it. This does not sound like a good reason to add a new fourcc. > r210 from their docs has already gained some traction as a fourcc and hence > adding the others in a similar vein seemed a reasonable approach. "r12b" > also sounds reasonable to me as a fourcc: it starts with an r, indicative > of RGB formats, and the bit/pixel + endianness didn't seem unreasonable. > Also I could find no other fourcc's used for this and hence I added it. The change to riff.c should at least be an independent patch. Carl Eugen ___ 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] lavfi/vf_drawtext.c: fix CID 1485003
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting
> Fu
> Sent: 2021年6月4日 10:23
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/2] lavfi/vf_drawtext.c: fix CID 1485003
>
> CID 1485003: Memory - illegal accesses (UNINIT)
> Using uninitialized value "sd".
>
> Signed-off-by: Ting Fu
> ---
> libavfilter/vf_drawtext.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> index 382d589e26..c4c09894e4 100644
> --- a/libavfilter/vf_drawtext.c
> +++ b/libavfilter/vf_drawtext.c
> @@ -1554,7 +1554,7 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *frame)
> AVFrameSideData *sd;
> int loop = 1;
>
> -if (s->text_source == AV_FRAME_DATA_DETECTION_BBOXES && sd) {
> +if (s->text_source == AV_FRAME_DATA_DETECTION_BBOXES) {
> sd = av_frame_get_side_data(frame,
> AV_FRAME_DATA_DETECTION_BBOXES);
> if (sd) {
> header = (AVDetectionBBoxHeader *)sd->data;
> --
thanks, will push soon.
___
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] dashenc: Write out DASH manifest immediately in streaming mode
I just realized there’s probably a more straightforward explanation: The scenario you brought up is already happening for all segments after the first one, and this changes just makes the first one do the same thing. The following scenario happens even without this change: Say you have a stream with "-streaming" and "-use_template" set and a segment duration of 10 seconds. While the first segment is being written there is no manifest, but then the first segment and manifest are written and the segment segment starts to be written. At 15 seconds in a client requests the manifest. It wants to be 2 seconds behind the live edge (13 second seek position) so it calculates which segment name it needs, which is the second one, and makes a request for it even though it's only partially written. And this could currently happen for any segment index > 1. With the proposed change this same thing just now happens on the first segment as well. I'm definitely happy to try a different approach to fix the underlying issue if I'm misunderstanding something or this reasoning is incorrect, but this "seems" right to me from my understanding of the spec and the behaviors I've witnessed so far. Kevin LaFlamme Director of Engineering (Front End) 774.265.0382 (m) aiera.com On Jun 8, 2021, 4:03 PM -0400, Kevin LaFlamme , wrote: > To serve it in a truly streaming way does require some special purpose server > or configuration, but the `@availabilityTimeComplete` field that is written > into the manifest is supposed to indicate to the client making the request > whether or not the segment file is complete at the time it becomes available. > In streaming mode, this is set to false so the client should expect that it > can get a partial segment between the available start time and the segment > duration. > > So as each box is written to the file, it should be safe for the HTTP server > to send the partial segment file that is currently on disk. And the DASH spec > specifically indicates whether or not to expect a partial file for the > segment being requested. If the client can’t handle a partial file and is > still making an attempt to request it before it’s fully available (which is > calculable from the information in the manifest), the client wouldn’t be > respecting the DASH spec. > > Kevin LaFlamme > Director of Engineering (Front End) > 774.265.0382 (m) > aiera.com > On Jun 8, 2021, 3:34 PM -0400, Timo Rothenpieler , > wrote: > > On 08.06.2021 21:24, Kevin LaFlamme wrote: > > > For streaming mode with fragmented MP4 the intention is to have the > > > client read a partial file since it’s broken up into sequential boxes > > > that are playable independently. This doesn’t change the segment files > > > themselves or how they are written, it just writes a full index file > > > ahead of time. > > > > > > Even currently, the manifest gets written after the first segment is > > > written and the player can immediately attempt to start reading the > > > second segment before it’s fully written. > > > > > > This is the same thing that the “-lhls” is doing in the block below, > > > writing out the HLS manifest immediately so that it contains > > > X-EXT-PREFETCH fields for the partial segment files. > > > > > > Currently, if you have a low latency DASH stream with “-ldash” and > > > “-streaming” and the player joins in the middle of the stream everything > > > works and it starts playing from the middle of the current segment. This > > > means even with 10 second segments you can have latency < 1sec of the > > > live edge. However, this doesn’t work for the very first segment because > > > the manifest isn’t available to the player yet. > > > > > > I have a low-latency player where I’m seeing this issue right now and > > > this addresses the problem, and seems consistent with the “-lhls” > > > handling below, but happy to make changes if there is something else I’m > > > missing. > > > > Yes, I'm aware that that's how it's supposed to work in theory. > > But does that work with any HTTP server? > > Do they really manage to stream the file while it's being written to? > > Or does this need special software to serve the file? And in turn, will > > it break for a user just pointing apache/nginx at such a list? > > > > > > ___ > > 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] [PATCH 2/2] Fix memory allocation problem. Related to ticket #9264.
From: houlei
Signed-off-by: houlei
---
libavdevice/xv.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavdevice/xv.c b/libavdevice/xv.c
index 24ba3179f6..7e15c178b6 100644
--- a/libavdevice/xv.c
+++ b/libavdevice/xv.c
@@ -296,10 +296,11 @@ static int write_picture(AVFormatContext *s, uint8_t
*input_data[4],
{
XVContext *xv = s->priv_data;
XvImage *img = xv->yuv_image;
-uint8_t *data[3] = {
+uint8_t *data[4] = {
img->data + img->offsets[0],
img->data + img->offsets[1],
-img->data + img->offsets[2]
+img->data + img->offsets[2],
+img->data + img->offsets[3]
};
/* Check messages. Window might get closed. */
--
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 2/2] Fix memory allocation problem. Related to ticket #9264.
From: houlei Signed-off-by: houlei --- libavdevice/xv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavdevice/xv.c b/libavdevice/xv.c index 7e15c178b6..8f9a2cb5c0 100644 --- a/libavdevice/xv.c +++ b/libavdevice/xv.c @@ -300,7 +300,7 @@ static int write_picture(AVFormatContext *s, uint8_t *input_data[4], img->data + img->offsets[0], img->data + img->offsets[1], img->data + img->offsets[2], -img->data + img->offsets[3] +0 }; /* Check messages. Window might get closed. */ -- 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 1/2] lavc/qsvdec: fix pts
The time base used for compressed bitstream and video frame in the SDK
is { 1, 9 }. [1][2]
This can avoid the error message below from the muxer.
$> ffmpeg -hwaccel qsv -c:v hevc_qsv -i input.h265 -f null -
...
[null @ 0x561c24f6f2f0] Application provided invalid, non monotonically
increasing dts to muxer in stream 0: 2 >= 2
[1]https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#mfxbitstream
[2]https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#mfxframedata
---
libavcodec/qsvdec.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index f543defb18..622750927c 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -46,6 +46,16 @@
#include "qsv.h"
#include "qsv_internal.h"
+static const AVRational mfx_tb = { 1, 9 };
+
+#define PTS_TO_MFX_PTS(pts, pts_tb) ((pts) == AV_NOPTS_VALUE ? \
+MFX_TIMESTAMP_UNKNOWN : pts_tb.num ? \
+av_rescale_q(pts, pts_tb, mfx_tb) : pts)
+
+#define MFX_PTS_TO_PTS(mfx_pts, pts_tb) ((mfx_pts) == MFX_TIMESTAMP_UNKNOWN ? \
+AV_NOPTS_VALUE : pts_tb.num ? \
+av_rescale_q(mfx_pts, mfx_tb, pts_tb) : mfx_pts)
+
typedef struct QSVContext {
// the session used for decoding
mfxSession session;
@@ -308,7 +318,7 @@ static int qsv_decode_header(AVCodecContext *avctx,
QSVContext *q,
bs.Data = avpkt->data;
bs.DataLength = avpkt->size;
bs.MaxLength = bs.DataLength;
-bs.TimeStamp = avpkt->pts;
+bs.TimeStamp = PTS_TO_MFX_PTS(avpkt->pts, avctx->pkt_timebase);
if (avctx->field_order == AV_FIELD_PROGRESSIVE)
bs.DataFlag |= MFX_BITSTREAM_COMPLETE_FRAME;
} else
@@ -456,7 +466,7 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
bs.Data = avpkt->data;
bs.DataLength = avpkt->size;
bs.MaxLength = bs.DataLength;
-bs.TimeStamp = avpkt->pts;
+bs.TimeStamp = PTS_TO_MFX_PTS(avpkt->pts, avctx->pkt_timebase);
if (avctx->field_order == AV_FIELD_PROGRESSIVE)
bs.DataFlag |= MFX_BITSTREAM_COMPLETE_FRAME;
}
@@ -544,7 +554,7 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
outsurf = &out_frame->surface;
-frame->pts = outsurf->Data.TimeStamp;
+frame->pts = MFX_PTS_TO_PTS(outsurf->Data.TimeStamp,
avctx->pkt_timebase);
frame->repeat_pict =
outsurf->Info.PicStruct & MFX_PICSTRUCT_FRAME_TRIPLING ? 4 :
@@ -748,6 +758,9 @@ static av_cold int qsv_decode_init(AVCodecContext *avctx)
goto fail;
}
+if (!avctx->pkt_timebase.num)
+av_log(avctx, AV_LOG_WARNING, "Invalid pkt_timebase, passing
timestamps as-is.\n");
+
return 0;
fail:
qsv_decode_close(avctx);
--
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".
[FFmpeg-devel] [PATCH 2/2] lavfi/vf_vpp_qsv: fix the time_base for outlink
Since commit 89ffcd1, the pts on output pad is in the time base of the input link, not the time base of the output link when EOF is reached, so a filter after vpp_qsv might output some unexpected frames. In order to avoid this issue, use the same time base for input and ouput links The issue can be triggered with the command below: $> ffmpeg -hwaccel qsv -c:v hevc_qsv -i input.h265 -vf "vpp_qsv=w=1920:h=1080,fps=fps=60" -f null - [out_0_0 @ 0x55eb017b5060] 100 buffers queued in out_0_0, something may be wrong. [out_0_0 @ 0x55eb017b5060] 1000 buffers queued in out_0_0, something may be wrong. [out_0_0 @ 0x55eb017b5060] 1 buffers queued in out_0_0, something may be wrong. --- libavfilter/vf_vpp_qsv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c index b9ab5c6490..74d1d51e7c 100644 --- a/libavfilter/vf_vpp_qsv.c +++ b/libavfilter/vf_vpp_qsv.c @@ -303,7 +303,7 @@ static int config_output(AVFilterLink *outlink) outlink->w = vpp->out_width; outlink->h = vpp->out_height; outlink->frame_rate = vpp->framerate; -outlink->time_base = av_inv_q(vpp->framerate); +outlink->time_base = inlink->time_base; param.filter_frame = NULL; param.num_ext_buf = 0; -- 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 17/35] avdevice/dshow: discover source color range/space/etc
On Tue, Jun 8, 2021 at 5:01 PM Michael Niedermayer wrote: > On Tue, Jun 08, 2021 at 01:03:56AM +0200, Diederick Niehorster wrote: > > Enabled discovering a DirectShow device's color range, space, primaries, > transfer characteristics and chroma location, if the device exposes that > information. Sets them in the stream's codecpars. > > > > Signed-off-by: Diederick Niehorster > > Co-authored-by: Valerii Zapodovnikov > > --- > > libavdevice/dshow.c | 231 +++- > > 1 file changed, 230 insertions(+), 1 deletion(-) > > seems to break build on mingw64 here > > CC libavdevice/dshow.o > src/libavdevice/dshow.c:58:44: error: unknown type name > ‘DXVA_ExtendedFormat’ > static enum AVColorRange dshow_color_range(DXVA_ExtendedFormat* fmt_info) > ^~~ > Oh no! Seems all those are not defined in the MinGW headers. Luckily there is the equivalent (see https://docs.microsoft.com/en-us/windows/win32/medfound/extended-color-information#color-space-in-media-types) DXVA2_ExtendedFormat struct which is defined in the MinGW headers. So i have switched to using that (well documented whats going on), seems to work fine. Cheers, Dee ___ 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".
