Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit and 10-bit
> -Original Message- > From: ffmpeg-devel On Behalf Of > Mark Thompson > Sent: Wednesday, February 26, 2020 06:59 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvdec: add decode support > for HEVC 4:2:2 8-bit and 10-bit > > On 25/02/2020 02:01, Linjie Fu wrote: > > Enables HEVC Range Extension decoding support for 4:2:2 8/10 bit > > on ICL+ (gen11 +) platform. > > > > Signed-off-by: Linjie Fu > > --- > > libavcodec/qsv.c | 12 > > libavutil/hwcontext_qsv.c | 22 ++ > > 2 files changed, 34 insertions(+) > > Should this be gated somehow to stop it being run on Windows? There it will > probably fail in some ugly way inside the D3D code which doesn't support > YUYV formats. Yes, thanks for pointing this out, fixed and verified on windows, no crash observed anymore in the D3D path for windows. > Similarly, do you need a specific libva version or is that already implied by > the > libmfx version? IMHO it's implied by libmfx version already. A successfully built MSDK with API version > 1.27 should have supported VA_FOURCC_Y210 [1] in libva. [1] https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/shared/src/libmfx_allocator_vaapi.cpp#L87 Thanks, - Linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit and 10-bit
Enables HEVC Range Extension decoding support (Linux) for 4:2:2 8/10 bit
on ICL+ (gen11 +) platform.
Signed-off-by: Linjie Fu
---
[v2]: restrict to support on Linux.
libavcodec/qsv.c | 16
libavutil/hwcontext_qsv.c | 24
2 files changed, 40 insertions(+)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index db98c75..171a8d6 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -195,6 +195,12 @@ enum AVPixelFormat ff_qsv_map_fourcc(uint32_t fourcc)
case MFX_FOURCC_NV12: return AV_PIX_FMT_NV12;
case MFX_FOURCC_P010: return AV_PIX_FMT_P010;
case MFX_FOURCC_P8: return AV_PIX_FMT_PAL8;
+#if CONFIG_VAAPI
+case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422;
+#if QSV_VERSION_ATLEAST(1, 27)
+case MFX_FOURCC_Y210: return AV_PIX_FMT_Y210;
+#endif
+#endif
}
return AV_PIX_FMT_NONE;
}
@@ -211,6 +217,16 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t
*fourcc)
case AV_PIX_FMT_P010:
*fourcc = MFX_FOURCC_P010;
return AV_PIX_FMT_P010;
+#if CONFIG_VAAPI
+case AV_PIX_FMT_YUV422P:
+*fourcc = MFX_FOURCC_YUY2;
+return AV_PIX_FMT_YUYV422;
+#if QSV_VERSION_ATLEAST(1, 27)
+case AV_PIX_FMT_YUV422P10:
+*fourcc = MFX_FOURCC_Y210;
+return AV_PIX_FMT_Y210;
+#endif
+#endif
default:
return AVERROR(ENOSYS);
}
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index b1b6740..4306c6e3 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -44,6 +44,10 @@
#include "pixdesc.h"
#include "time.h"
+#define QSV_VERSION_ATLEAST(MAJOR, MINOR) \
+(MFX_VERSION_MAJOR > (MAJOR) || \
+ MFX_VERSION_MAJOR == (MAJOR) && MFX_VERSION_MINOR >= (MINOR))
+
typedef struct QSVDevicePriv {
AVBufferRef *child_device_ctx;
} QSVDevicePriv;
@@ -103,6 +107,14 @@ static const struct {
{ AV_PIX_FMT_BGRA, MFX_FOURCC_RGB4 },
{ AV_PIX_FMT_P010, MFX_FOURCC_P010 },
{ AV_PIX_FMT_PAL8, MFX_FOURCC_P8 },
+#if CONFIG_VAAPI
+{ AV_PIX_FMT_YUYV422,
+ MFX_FOURCC_YUY2 },
+#if QSV_VERSION_ATLEAST(1, 27)
+{ AV_PIX_FMT_Y210,
+ MFX_FOURCC_Y210 },
+#endif
+#endif
};
static uint32_t qsv_fourcc_from_pix_fmt(enum AVPixelFormat pix_fmt)
@@ -773,7 +785,19 @@ static int map_frame_to_surface(const AVFrame *frame,
mfxFrameSurface1 *surface)
surface->Data.R = frame->data[0] + 2;
surface->Data.A = frame->data[0] + 3;
break;
+#if CONFIG_VAAPI
+case AV_PIX_FMT_YUYV422:
+surface->Data.Y = frame->data[0];
+surface->Data.U = frame->data[0] + 1;
+surface->Data.V = frame->data[0] + 3;
+break;
+case AV_PIX_FMT_Y210:
+surface->Data.Y16 = (mfxU16 *)frame->data[0];
+surface->Data.U16 = (mfxU16 *)frame->data[0] + 1;
+surface->Data.V16 = (mfxU16 *)frame->data[0] + 3;
+break;
+#endif
default:
return MFX_ERR_UNSUPPORTED;
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH, v2 2/2] lavc/qsvenc: add encode support for HEVC 4:2:2 8-bit and 10-bit
Enables HEVC Range Extension encoding support (Linux) for 4:2:2 8/10 bit
on ICL+ (gen11 +) platform with VMEPAK.
Signed-off-by: Linjie Fu
---
[v2]: restrict to support on Linux
libavcodec/qsv.c | 2 ++
libavcodec/qsvenc.c | 4 +++-
libavcodec/qsvenc_hevc.c | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 171a8d6..1772007 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -219,10 +219,12 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t
*fourcc)
return AV_PIX_FMT_P010;
#if CONFIG_VAAPI
case AV_PIX_FMT_YUV422P:
+case AV_PIX_FMT_YUYV422:
*fourcc = MFX_FOURCC_YUY2;
return AV_PIX_FMT_YUYV422;
#if QSV_VERSION_ATLEAST(1, 27)
case AV_PIX_FMT_YUV422P10:
+case AV_PIX_FMT_Y210:
*fourcc = MFX_FOURCC_Y210;
return AV_PIX_FMT_Y210;
#endif
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 52b4e43..571a711 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -66,6 +66,7 @@ static const struct {
{ MFX_PROFILE_HEVC_MAIN,"main" },
{ MFX_PROFILE_HEVC_MAIN10, "main10"},
{ MFX_PROFILE_HEVC_MAINSP, "mainsp"},
+{ MFX_PROFILE_HEVC_REXT,"rext" },
#endif
};
@@ -544,7 +545,8 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
q->param.mfx.FrameInfo.CropH = avctx->height;
q->param.mfx.FrameInfo.AspectRatioW = avctx->sample_aspect_ratio.num;
q->param.mfx.FrameInfo.AspectRatioH = avctx->sample_aspect_ratio.den;
-q->param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420;
+q->param.mfx.FrameInfo.ChromaFormat = MFX_CHROMAFORMAT_YUV420 +
+!desc->log2_chroma_w +
!desc->log2_chroma_h;
q->param.mfx.FrameInfo.BitDepthLuma = desc->comp[0].depth;
q->param.mfx.FrameInfo.BitDepthChroma = desc->comp[0].depth;
q->param.mfx.FrameInfo.Shift = desc->comp[0].depth > 8;
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index 27e2232..298b575 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -240,6 +240,7 @@ static const AVOption options[] = {
{ "main",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_MAIN
}, INT_MIN, INT_MAX, VE, "profile" },
{ "main10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_MAIN10
}, INT_MIN, INT_MAX, VE, "profile" },
{ "mainsp", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_MAINSP
}, INT_MIN, INT_MAX, VE, "profile" },
+{ "rext",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_REXT
}, INT_MIN, INT_MAX, VE, "profile" },
{ "gpb", "1: GPB (generalized P/B frame); 0: regular P frame",
OFFSET(qsv.gpb), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE},
--
2.7.4
___
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] [avfomat/rtp: source ips lost when specified as URL options] Patch for ffmpeg using rtp protocol where sources option is not retained
Thanks, just thought you might have another idea, as it works just was not sure
if I was accomplishing it in the right way.
Ya, I submitted the patch formally. Let’s see what’s a review comes back like.
Thanks
> On 26 Feb 2020, at 05:10, Jun Li wrote:
>
>
>
>
>> On Tue, Feb 25, 2020 at 5:01 AM Ross Nicholson wrote:
>> Hey Jun Li,
>>
>> I noticed you have submitted some patches which work around the same code
>> area's that I submitted for. Your patches look quite tidy and well thought
>> out so I was wondering if you could look at this patch and see if I'm going
>> about it in the right way.
>>
>> I'm not sure this area of ffmpeg currently has a maintainer currently so the
>> patches may be difficult to progress.
>>
>> Ross
>>
>>> On Tue, 11 Feb 2020 at 22:42, Ross Nicholson wrote:
>>> The patch was created as a workaround to an issue from in kodi (apologies,
>>> it's a rather long thread):
>>> https://forum.kodi.tv/showthread.php?tid=350901&pid=2923550#pid2923550
>>>
>>> As an example, here is a URL: rtp://87.141.215.251@232.0.10.234:1
>>>
>>> Taking this URL we should be able to either reformat it to:
>>> rtp://232.0.10.234:1?sources=87.141.215.251 or pass the sources as an
>>> av_dict to avfomat_open_input.
>>>
>>> Neither option works however. Instead the above workaround was created but
>>> it's not really the right way to fix this. Would be great to get some
>>> guidance on the right place to fix this in the right way.
>>>
>>> Thanks in advance.
>>>
On Tue, 11 Feb 2020 at 22:30, phunkyfish wrote:
---
libavformat/rtsp.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 859defa592..f922055134 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2334,7 +2334,9 @@ static int sdp_read_header(AVFormatContext *s)
RTSPStream *rtsp_st;
int size, i, err;
char *content;
+const char *p, *sp="", *sources="", *sp2, *sources2;
char url[1024];
+char sources_buf[1024];
if (!ff_network_init())
return AVERROR(EIO);
@@ -2360,6 +2362,16 @@ static int sdp_read_header(AVFormatContext *s)
av_freep(&content);
if (err) goto fail;
+/* Search for sources= tag in original URL for rtp protocol only */
+if (strncmp(s->url, "rtp://", 6) == 0) {
+p = strchr(s->url, '?');
+if (p && av_find_info_tag(sources_buf, sizeof(sources_buf),
"sources", p)) {
+/* av_log(s, AV_LOG_VERBOSE, "sdp_read_header found sources
%s\n", sources_buf); */
+sp = sources_buf;
+sources = "&sources=";
+}
+}
+
/* open each RTP stream */
for (i = 0; i < rt->nb_rtsp_streams; i++) {
char namebuf[50];
@@ -2377,12 +2389,22 @@ static int sdp_read_header(AVFormatContext *s)
av_dict_free(&opts);
goto fail;
}
+
+/* Prepare to add sources to the url to be opened.
+ Otherwise the join to the source specific muliticast will
be missing */
+sources2 = sources;
+sp2 = sp;
+/* ignore sources from original URL, when sources are already
set in rtsp_st */
+if (rtsp_st->nb_include_source_addrs > 0)
+sources2 = sp2 = "";
+
ff_url_join(url, sizeof(url), "rtp", NULL,
namebuf, rtsp_st->sdp_port,
-
"?localport=%d&ttl=%d&connect=%d&write_to_source=%d",
+
"?localport=%d&ttl=%d&connect=%d&write_to_source=%d%s%s",
rtsp_st->sdp_port, rtsp_st->sdp_ttl,
rt->rtsp_flags & RTSP_FLAG_FILTER_SRC ? 1 : 0,
-rt->rtsp_flags & RTSP_FLAG_RTCP_TO_SOURCE ? 1 :
0);
+rt->rtsp_flags & RTSP_FLAG_RTCP_TO_SOURCE ? 1 : 0,
+sources2, sp2);
append_source_addrs(url, sizeof(url), "sources",
rtsp_st->nb_include_source_addrs,
--
2.20.1 (Apple Git-117)
>
> Hi Ross,
> I am not sure I understand your requirement clearly, an alternative way is to
> save the url in sdp(maybe in rtp_read_header?) and read it out in
> sdp_read_header. But I am not sure which field can carry this info (maybe uri
> attribute ?).
>
> Since you already have the code change, why now send it as a formal patch so
> that FFmpeg maintainers/experts can have a review ?
>
> -Jun
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_program_opencl: allow setting kernel per plane
On 2/25/20, Mark Thompson wrote:
> On 24/02/2020 10:01, Paul B Mahol wrote:
>> Fixes #7190
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> doc/filters.texi| 22
>> libavfilter/vf_program_opencl.c | 64 ++---
>> 2 files changed, 65 insertions(+), 21 deletions(-)
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 70fd7a4cc7..6b10f649b9 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -21302,6 +21302,17 @@ Number of inputs to the filter. Defaults to 1.
>> @item size, s
>> Size of output frames. Defaults to the same as the first input.
>>
>> +@item kernel2
>> +Kernel name in program for 2nd plane, if not set kernel from option
>> +@var{kernel} is used.
>> +
>> +@item kernel3
>> +Kernel name in program for 3nd plane, if not set kernel from option
>> +@var{kernel} is used.
>
> Why this default? The kernel for the second plane feels a more obvious
> choice to me for cases like yuv420p.
It is easier.
>
>> +
>> +@item kernel4
>> +Kernel name in program for 4nd plane, if not set kernel from option
>> +@var{kernel} is used.
>> @end table
>>
>> The program source file must contain a kernel function with the given
>> name,
>
> An example using it would be nice to show the intended setup.
Example is omitted because its trivial.
>
>> @@ -22488,6 +22499,17 @@ Pixel format to use for the generated frames.
>> This must be set.
>> @item rate, r
>> Number of frames generated every second. Default value is '25'.
>>
>> +@item kernel2
>> +Kernel name in program for 2nd plane, if not set kernel from option
>> +@var{kernel} is used.
>> +
>> +@item kernel3
>> +Kernel name in program for 3nd plane, if not set kernel from option
>> +@var{kernel} is used.
>> +
>> +@item kernel4
>> +Kernel name in program for 4nd plane, if not set kernel from option
>> +@var{kernel} is used.
>> @end table
>>
>> For details of how the program loading works, see the
>> @ref{program_opencl}
>> diff --git a/libavfilter/vf_program_opencl.c
>> b/libavfilter/vf_program_opencl.c
>> index ec25e931f5..f748b15037 100644
>> --- a/libavfilter/vf_program_opencl.c
>> +++ b/libavfilter/vf_program_opencl.c
>> @@ -33,14 +33,14 @@ typedef struct ProgramOpenCLContext {
>>
>> int loaded;
>> cl_uint index;
>> -cl_kernel kernel;
>> +cl_kernel kernel[4];
>> cl_command_queuecommand_queue;
>>
>> FFFrameSync fs;
>> AVFrame **frames;
>>
>> const char *source_file;
>> -const char *kernel_name;
>> +const char *kernel_name[4];
>> int nb_inputs;
>> int width, height;
>> enum AVPixelFormat source_format;
>> @@ -66,15 +66,17 @@ static int program_opencl_load(AVFilterContext *avctx)
>> return AVERROR(EIO);
>> }
>>
>> -ctx->kernel = clCreateKernel(ctx->ocf.program, ctx->kernel_name,
>> &cle);
>> -if (!ctx->kernel) {
>> -if (cle == CL_INVALID_KERNEL_NAME) {
>> -av_log(avctx, AV_LOG_ERROR, "Kernel function '%s' not found
>> in "
>> - "program.\n", ctx->kernel_name);
>> -} else {
>> -av_log(avctx, AV_LOG_ERROR, "Failed to create kernel: %d.\n",
>> cle);
>> +for (int i = 0; i < 4; i++) {
>
> I don't think it's a good idea to make kernel objects for absent planes, and
> it should be an error to provide more kernels than planes.
I disagree.
>
>> +ctx->kernel[i] = clCreateKernel(ctx->ocf.program,
>> ctx->kernel_name[i] ? ctx->kernel_name[i] : ctx->kernel_name[0], &cle);
>
> Since the kernel you end up with is exactly the same, perhaps you would be
> better making only the named kernels and then choosing later which one to
> use rather than having many copies of the same object.
>
My way is much simpler.
> (Also, please avoid overlong lines.)
>
>> +if (!ctx->kernel[i]) {
>> +if (cle == CL_INVALID_KERNEL_NAME) {
>> +av_log(avctx, AV_LOG_ERROR, "Kernel function '%s' not
>> found in "
>> + "program.\n", ctx->kernel_name[i] ?
>> ctx->kernel_name[i] : ctx->kernel_name[0]);
>> +} else {
>> +av_log(avctx, AV_LOG_ERROR, "Failed to create kernel%d:
>> %d.\n", i, cle);
>> +}
>> +return AVERROR(EIO);
>> }
>> -return AVERROR(EIO);
>> }
>>
>> ctx->loaded = 1;
>> @@ -108,14 +110,14 @@ static int program_opencl_run(AVFilterContext
>> *avctx)
>> if (!dst)
>> break;
>>
>> -cle = clSetKernelArg(ctx->kernel, 0, sizeof(cl_mem), &dst);
>> +cle = clSetKernelArg(ctx->kernel[plane], 0, sizeof(cl_mem),
>> &dst);
>> if (cle != CL_SUCCESS) {
>> av_log(avctx, AV_LOG_ERROR, "Failed to set kernel "
>> "destination image argument: %d.\n", cle);
>> err = AVERROR_UNKNOWN;
>> goto fail;
>> }
>> -
Re: [FFmpeg-devel] [PATCH V2] libswscale/x86/yuv2rgb: Fix Segmentation Fault when load unaligned data
Am Mi., 26. Feb. 2020 um 03:58 Uhr schrieb Ting Fu : > > Fixes ticket #8532 Patch applied. Thank you, 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 001/244] Add a new channel layout API
Hendrik Leppkes (12020-02-25): > Standards designed by committee like all this MPEG stuff are full of > features that noone uses. Its usually indicative of the following > replacement standard dumping them again. Instead, they threw in a > bunch of new things of questionable use that will disappear in the > next standard once again. I agree, it's a very weak argument. But it's still infinitely superior to the absence of arguments in "I don't think anything uses". > I don't think we should be blindly following what some other group > thinks, but critically judge everything we're implementing here. I am not suggesting following anything blindly. But files using this feature can exist out there, so the question is whether to accept an API that cannot handle them without loss of information. 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 001/244] Add a new channel layout API
Anton Khirnov (12020-02-25): > As far as I can tell, the Apple API linked above does not support that > either. The way of describing the channel layout is given by > mChannelLayoutTag, which can be either > - kAudioChannelLayoutTag_UseChannelBitmap, which is effectively > equivalent to our current API, or the new API's LAYOUT_NATIVE > - one of several predefined layouts, which can be mapped either to > LAYOUT_NATIVE or LAYOUT_CUSTOM > - kAudioChannelLayoutTag_UseChannelDescriptions, which cannot be > represented in the current API, but is effectively equivalent to the > new API's LAYOUT_CUSTOM > The AudioChannelDescription struct contains: > * AudioChannelFlags, which apply to coordinates > * three floats, which are the coordinates > * AudioChannelLabel, which is uint32 similar to our AVChannel > > I see no support for any custom free-form text labels of the kind you > want me to add. The link above does not describe an API, it describe a format. A format that can contain several channels with the FL (example) disposition. Even if there are no labels attached, users need an interface to specify one: "the first FL channel", "the second FL channel", for example. Your proposal does not have it, it needs it. > In addition to Hendrik's reply (which I agree with), support for this > can be later added through a new layout type if someone really needs it. > I see no reason to spend effort implementing functionality that is not > actually used for anything. It's the second time you propose to extend the API later like that. I am glad you realize the API you proposed is insufficient and needs extending, but I am worried that you don't realize that extending later for needs that we see now is a terrible idea. It's a terrible idea because it requires more work, and because the extension will always stay second class compared to the initial code, and unsupported in all the places in the code that will not be updated for it. Since we were lucky to see we need a way of attaching data to channels before including the API, we'll include it in the API from the start. It's too bad it will require dynamic allocation and make the handling of the structure as a whole more clumsy, but it seems it was unavoidable. We could use simply a per-channel metadata dictionary, it would allow both the speaker coordinate in this spec and the free-form label that I want. Alternatively, we can use a more typed approach, like side data. 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] Fixing rare dshow input crash
Am Mi., 26. Feb. 2020 um 06:57 Uhr schrieb Roger Pack : > > Original bigger patch is enough for now. Please merge, thanks! What happened to your git account? 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 v3] avfilter: add overlay vaapi filter
On Wed, Feb 26, 2020 at 13:53:34 +0800, Xinpeng Sun wrote: > configure | 3 + > doc/filters.texi | 51 > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_overlay_vaapi.c | 426 + This will ultimately also require a Changelog entry and a minor version bump. But wait for more reviews first before reposting. Cheers, Moritz ___ 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 03/12] lavfi: drop vf_qp
Am 25.02.20 um 11:28 schrieb Anton Khirnov:
> Quoting Thilo Borgmann (2020-02-24 23:07:48)
>> Am 24.02.20 um 22:41 schrieb Lou Logan:
>>> On Mon, Feb 24, 2020, at 3:37 AM, Anton Khirnov wrote:
It fundamentally depends on an API that has been deprecated for five
years, has seen no commits since that time and is of highly dubious
usefulness.
---
doc/filters.texi| 32 ---
libavfilter/Makefile| 1 -
libavfilter/allfilters.c| 1 -
libavfilter/vf_qp.c | 183
tests/fate/filter-video.mak | 7 +-
tests/ref/fate/filter-pp2 | 1 -
tests/ref/fate/filter-pp3 | 1 -
7 files changed, 1 insertion(+), 225 deletions(-)
delete mode 100644 libavfilter/vf_qp.c
delete mode 100644 tests/ref/fate/filter-pp2
delete mode 100644 tests/ref/fate/filter-pp3
>>>
>>> Fine with me. I've never seen it used by anyone.
>>
>> I'm not fine with it. Declaring it's {use | use case} not existent is
>> no arguments whatsoever in reality.
>>
>> Also, removing some functionality needs an argument - it is not
>> keeping some functionality needs an argument.
>
> I disagree with that. Keeping code around is not free, as Vittorio
> already said - it is a burden in many ways. So I believe all code needs
> continued justification for its existence - not just "it was added in
> the past so it stays in forever". Note that I'm not saying it needs to
> be mainstream or very popular - I am fine with obscure features that
> are only useful to a few people in highly special cases (given they are
> not unduly intrusive and those people are willing to maintain them). But
> so far in this thread, there has been no actual use presented for
> exporting and passing around QP tables. None whatsoever.
>
> Most objections here are like yours - it's a) a feature and b) someone
> somewhere sometime might conceivably want to use it, so it must not be
> removed. Michael's reponse is the only one that comes close to having a
> use case, but even he says that he's unsure of the usefulness of the
> actual QP tables and that it's largely theoretical.
>
> I believe I did more structural changes to the libraries than most
> people and in my experience these obsolete features from mplayer days
> are a MASSIVE maintenance pain. The amount of effort required to keep
> them working is simply not justified when essentially nobody uses them.
>
> IMO these demands that they all be preserved forever is endangering the
> project. If making changes becomes too hard, people stop making them.
> They move to other places that are less hostile to change. We are at
> risk of turning into a repository of obscure old codecs and filters and
> getting overtaken by leaner projects like dav1d (yes it's supposed to be
> AV1-only, but that can change).
>
>>
>> Nobody technically elaborates Paul's statement that it should go into side
>> data. WTF? The compromise isn't even considered?
>>
>> Let's dig some trenches, shall we?
>>
>> And how come some obvious "use cases" / "needs" like [1] come into play? Or
>> do we declare not continued discussions non-existent now, too?
>
> The patch in your link is not using this API. Precisely because this API
> is inadequate for anything newer than MPEG4 ASP. If anything, it's an
> additional argument in favor of my patches.
My actual point about that patch was that there is a use case to extract QP
tables for more current codecs. Suggests this use case is also there for less
current ones which says we should not just remove this possibility.
If that patch is avoiding the deprecated things, could it be applied to the
older codes and supersede vf_qp? (And I have no clue whether or not)
And would that not go into the direction Paul suggested?
>> And how comes, if Michael's investigation, that all of this is based on use
>> of _a function_ that is deprecated instead of direct access of AVFrame's
>> fields is the cause of all of this?
>>
>> Shame on all of us.
>
> WTF? What shame?
I am ashamed that I do read most arguments here as merely black-and-white
statements.
That might be considered, as I admit, as an overreaction and I probably should
not have written.
However, that is also why I suggested to dig trenches.
> I am sending patches, in good faith, that I believe will improve the
> project. People may (and do) object to them. As long as the discussion
> is civil, constructive and in good faith (so far it mostly is), I see no
> reason for any shame.
Yes and please continue to do so. That I did not criticize.
Also yes, I don't see it non-civil and hopefully it will stay that way.
I see it, however, way less constructive as it could and should be.
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with sub
Re: [FFmpeg-devel] [PATCH 03/12] lavfi: drop vf_qp
Yo, On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote: > > The patch in your link is not using this API. Precisely because this API > > is inadequate for anything newer than MPEG4 ASP. If anything, it's an > > additional argument in favor of my patches. > > My actual point about that patch was that there is a use case to > extract QP tables for more current codecs. Suggests this use case is > also there for less current ones which says we should not just remove > this possibility. I think this is the right question: "Are there actual valid use cases to do it?" I remember that last year, there was an extractqp for h264 patches from Google, for example. Any other question is basically less important. If that is useful, then, we should update the API and remove the old API. If it is not, then, let's remove everything. Best, -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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 4/4] avfilter/vf_paletteuse: Forward error codes
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/vf_paletteuse.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
> index 255c9d79e3..408cff786e 100644
> --- a/libavfilter/vf_paletteuse.c
> +++ b/libavfilter/vf_paletteuse.c
> @@ -912,12 +912,12 @@ static int apply_palette(AVFilterLink *inlink, AVFrame
> *in, AVFrame **outf)
>s->last_out, out, &x, &y, &w, &h);
> av_frame_unref(s->last_in);
> av_frame_unref(s->last_out);
> -if (av_frame_ref(s->last_in, in) < 0 ||
> -av_frame_ref(s->last_out, out) < 0 ||
> -av_frame_make_writable(s->last_in) < 0) {
> +if ((ret = av_frame_ref(s->last_in, in)) < 0 ||
> +(ret = av_frame_ref(s->last_out, out)) < 0 ||
> +(ret = av_frame_make_writable(s->last_in)) < 0) {
> av_frame_free(&out);
> *outf = NULL;
> -return AVERROR(ENOMEM);
> +return ret;
> }
>
> ff_dlog(ctx, "%dx%d rect: (%d;%d) -> (%d,%d) [area:%dx%d]\n",
>
Ping.
- 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 4/4] avfilter/vf_paletteuse: Forward error codes
lgtm
On 1/27/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavfilter/vf_paletteuse.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
> index 255c9d79e3..408cff786e 100644
> --- a/libavfilter/vf_paletteuse.c
> +++ b/libavfilter/vf_paletteuse.c
> @@ -912,12 +912,12 @@ static int apply_palette(AVFilterLink *inlink, AVFrame
> *in, AVFrame **outf)
>s->last_out, out, &x, &y, &w, &h);
> av_frame_unref(s->last_in);
> av_frame_unref(s->last_out);
> -if (av_frame_ref(s->last_in, in) < 0 ||
> -av_frame_ref(s->last_out, out) < 0 ||
> -av_frame_make_writable(s->last_in) < 0) {
> +if ((ret = av_frame_ref(s->last_in, in)) < 0 ||
> +(ret = av_frame_ref(s->last_out, out)) < 0 ||
> +(ret = av_frame_make_writable(s->last_in)) < 0) {
> av_frame_free(&out);
> *outf = NULL;
> -return AVERROR(ENOMEM);
> +return ret;
> }
>
> ff_dlog(ctx, "%dx%d rect: (%d;%d) -> (%d,%d) [area:%dx%d]\n",
> --
> 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] [PATCH 03/12] lavfi: drop vf_qp
On 2/26/20, Jean-Baptiste Kempf wrote: > Yo, > > On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote: >> > The patch in your link is not using this API. Precisely because this API >> > is inadequate for anything newer than MPEG4 ASP. If anything, it's an >> > additional argument in favor of my patches. >> >> My actual point about that patch was that there is a use case to >> extract QP tables for more current codecs. Suggests this use case is >> also there for less current ones which says we should not just remove >> this possibility. > > I think this is the right question: > "Are there actual valid use cases to do it?" > > I remember that last year, there was an extractqp for h264 patches from > Google, for example. > > Any other question is basically less important. > > If that is useful, then, we should update the API and remove the old API. > If it is not, then, let's remove everything. > It is useful as already proved. Please refrain from ignoring obvious facts. > Best, > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > 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/mux: allow non-monotonic ts with AVFMT_NOTIMESTAMPS
Anssi Hannula:
> Allow non-monotonic input timestamps for muxers with no timestamps at
> all (AVFMT_NOTIMESTAMPS).
>
> This is frequently hit when muxing TrueHD with spdifenc as many MKV
> files use 1ms timestamps while TrueHD frames are shorter than that
> (1/1200 sec for 48kHz-based and 1/1102.5 sec for 44.1kHz-based rates).
> ---
> libavformat/mux.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index 3533932a58..ba6695badb 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -622,7 +622,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s,
> AVStream *st, AVPacket *
> }
>
> if (st->cur_dts && st->cur_dts != AV_NOPTS_VALUE &&
> -((!(s->oformat->flags & AVFMT_TS_NONSTRICT) &&
> +((!(s->oformat->flags & (AVFMT_NOTIMESTAMPS | AVFMT_TS_NONSTRICT)) &&
>st->codecpar->codec_type != AVMEDIA_TYPE_SUBTITLE &&
>st->codecpar->codec_type != AVMEDIA_TYPE_DATA &&
>st->cur_dts >= pkt->dts) || st->cur_dts > pkt->dts)) {
>
The change looks good, but the description is suboptimal: Your change
does not blindly allow non-monotonic timestamps. It just drops the
requirement of strictly monotonic dts for muxers with
AVFMT_NOTIMESTAMPS. This is enough to fix the issue with TrueHD and
1/1000 timebases (which also exists for the null muxer).
- 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 03/12] lavfi: drop vf_qp
On Wed, Feb 26, 2020, at 15:46, Paul B Mahol wrote: > On 2/26/20, Jean-Baptiste Kempf wrote: > > Yo, > > > > On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote: > >> > The patch in your link is not using this API. Precisely because this API > >> > is inadequate for anything newer than MPEG4 ASP. If anything, it's an > >> > additional argument in favor of my patches. > >> > >> My actual point about that patch was that there is a use case to > >> extract QP tables for more current codecs. Suggests this use case is > >> also there for less current ones which says we should not just remove > >> this possibility. > > > > I think this is the right question: > > "Are there actual valid use cases to do it?" > > > > I remember that last year, there was an extractqp for h264 patches from > > Google, for example. > > > > Any other question is basically less important. > > > > If that is useful, then, we should update the API and remove the old API. > > If it is not, then, let's remove everything. > > > > It is useful as already proved. Please refrain from ignoring obvious facts. Please learn how to talk nicely to people, that will help quite a bit. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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 03/12] lavfi: drop vf_qp
Am 26.02.20 um 16:26 schrieb Jean-Baptiste Kempf: > On Wed, Feb 26, 2020, at 15:46, Paul B Mahol wrote: >> On 2/26/20, Jean-Baptiste Kempf wrote: >>> Yo, >>> >>> On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote: > The patch in your link is not using this API. Precisely because this API > is inadequate for anything newer than MPEG4 ASP. If anything, it's an > additional argument in favor of my patches. My actual point about that patch was that there is a use case to extract QP tables for more current codecs. Suggests this use case is also there for less current ones which says we should not just remove this possibility. >>> >>> I think this is the right question: >>> "Are there actual valid use cases to do it?" >>> >>> I remember that last year, there was an extractqp for h264 patches from >>> Google, for example. That should be the patch I linked to. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add .mailmap
Hi Steven,
On Mon, Feb 24, 2020, at 2:03 AM, Steven Liu wrote:
> [...]
> How can I get the script :D
>
> Thanks
>
> Steven
I won't be looking to upstream this script (the other one yes), but I will
share it here for you. You'll have to excuse my poor scripting :)
--
Josh
#!/usr/bin/env perl
use warnings;
use strict;
# cpan List::MoreUtils JSON
use Encode qw(decode);
use List::MoreUtils qw(uniq);
sub trim { my $s = shift; $s =~ s/^\s+|\s+$//g; return $s };
my @shortlog = split /\n/, decode('UTF-8', `git shortlog -sne --since="last 36
months"`, Encode::FB_CROAK);
my %assembly = ();
my %developers = ();
foreach my $line (@shortlog) {
my ($count, $name, $email) = $line =~ m/^ *(\d+) *(.*?) <(.*?)>/;
# ignore
$email =~ s/ at /@/;
$name = trim $name;
if (exists($developers{$name})) {
$developers{$name}{commit_count} += $count;
push @{$developers{$name}{email}}, $email;
} else {
$developers{$name} = {
commit_count => $count,
email => [$email],
};
}
}
foreach my $key (keys %developers) {
# many people with different emails, only care about frequent committers
if ($developers{$key}{commit_count} >= 20) {
$developers{$key}{email} = [uniq @{$developers{$key}{email}}];
if (scalar @{$developers{$key}{email}} > 1) {
foreach my $email (@{$developers{$key}{email}}) {
print "$email ";
}
print "\n";
}
}
}
___
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] avformat/mp3dec: Count last partial frame in probe.
Fixes: regression
Fixes: Ticket8511
Signed-off-by: Michael Niedermayer
---
libavformat/mp3dec.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 71a4ed706d..70cceb79f8 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -87,20 +87,26 @@ static int mp3_read_probe(const AVProbeData *p)
for (framesizes = frames = 0; buf2 < end; frames++) {
MPADecodeHeader h;
int header_emu = 0;
+int available;
header = AV_RB32(buf2);
ret = avpriv_mpegaudio_decode_header(&h, header);
-if (ret != 0 || end - buf2 < h.frame_size)
+if (ret != 0)
break;
-for (buf3 = buf2 + 4; buf3 < buf2 + h.frame_size; buf3++) {
+available = FFMIN(h.frame_size, end - buf2);
+for (buf3 = buf2 + 4; buf3 < buf2 + available; buf3++) {
uint32_t next_sync = AV_RB32(buf3);
header_emu += (next_sync & MP3_MASK) == (header & MP3_MASK);
}
if (header_emu > 2)
break;
-buf2 += h.frame_size;
framesizes += h.frame_size;
+if (end - buf2 < h.frame_size) {
+frames++;
+break;
+}
+buf2 += h.frame_size;
}
max_frames = FFMAX(max_frames, frames);
max_framesizes = FFMAX(max_framesizes, framesizes);
--
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 03/12] lavfi: drop vf_qp
First of all, thanks for trying to clean up deprecated API On Wed, Feb 26, 2020 at 6:03 AM Jean-Baptiste Kempf wrote: > Yo, > > On Wed, Feb 26, 2020, at 14:27, Thilo Borgmann wrote: > > > The patch in your link is not using this API. Precisely because this > API > > > is inadequate for anything newer than MPEG4 ASP. If anything, it's an > > > additional argument in favor of my patches. > > > > My actual point about that patch was that there is a use case to > > extract QP tables for more current codecs. Suggests this use case is > > also there for less current ones which says we should not just remove > > this possibility. > > I think this is the right question: > "Are there actual valid use cases to do it?" > yes, there is a use case for extracting QP per block: To analyze and visualize QP to validate/analyze Rate Control when we enable Adaptive QP and ROI for example. Most people who works on Rate Control know that the choice of the right MV/QP/block type is really important for quality. In today world, you will have to license existing software to visualize the QP, but if you want to do this over +10k video, and analyze QP based on some stats we expect to have, you need some libraries to do it. People could write some codec parser to extract the QP per block, but this is almost re-implementing part of libavcodec. Today, for example, when we want to visualize QP, we use libavcodec to decode the frame, use another piece of code to extract the QP and overlay both of them. This is almost (and i say ALMOST) decoding the frame twice. (BTW, we can do that already with libavcodec for MV, so why not for QP) Last summer, an intern from google tried to come up with a metadata structure to store information per block. This would have allow to store per block, the MV, QP, block type, etc.. And it could have work for any codec with any different block size. He was trying to implement what was done for MV and replace the QP with this new metadata. I agree that the current QP code (not feature) should be deprecated as it does not work with newer codec. But before removing the deprecated code, it will be nice to have the same feature available with a newer API, so the features of extracting/analyzing/overlaying QP still work. > > I remember that last year, there was an extractqp for h264 patches from > Google, for example. > > Any other question is basically less important. > > If that is useful, then, we should update the API and remove the old API. > If it is not, then, let's remove everything. > > Best, > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > 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". -- Thierry Foucu ___ 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]lsws/input: Do not change transparency range
Am Sa., 15. Feb. 2020 um 20:21 Uhr schrieb Michael Niedermayer : > > On Sat, Feb 15, 2020 at 10:10:45AM +0100, Carl Eugen Hoyos wrote: > > Hi! > > > > Transparency levels are currently changed when reading bgra and > > friends, this patch changes behaviour and fixes ticket #8509. > > > > Please comment, Carl Eugen > > > libswscale/input.c|6 > > tests/ref/fate/ffmpeg-filter_colorkey | 20 +- > > tests/ref/fate/filter-overlay-dvdsub-2397 | 180 > > +- > > tests/ref/fate/filter-overlay_gbrap_gbrap |2 > > tests/ref/fate/filter-overlay_gbrp_gbrap |2 > > tests/ref/fate/filter-overlay_yuv420_yuva420 |2 > > tests/ref/fate/filter-overlay_yuv422_yuva422 |2 > > tests/ref/fate/filter-overlay_yuv444_yuva444 |2 > > tests/ref/fate/filter-overlay_yuva420_yuva420 |2 > > tests/ref/fate/filter-overlay_yuva422_yuva422 |2 > > tests/ref/fate/filter-overlay_yuva444_yuva444 |2 > > 11 files changed, 111 insertions(+), 111 deletions(-) > > d8ed3bafeca2ed15b41a2fca0dc5600e3aeab671 > > 0001-lsws-input-Do-not-change-transparency-range.patch > > From a71053df9131be803d9a359a7232e5193747f351 Mon Sep 17 00:00:00 2001 > > From: Carl Eugen Hoyos > > Date: Sat, 15 Feb 2020 10:07:51 +0100 > > Subject: [PATCH] lsws/input: Do not change transparency range. > > > > Fixes ticket #8509. > [...] > > > @@ -457,7 +457,7 @@ static void palToA_c(uint8_t *_dst, const uint8_t *src, > > const uint8_t *unused1, > > for (i=0; i > int d= src[i]; > > > > -dst[i]= (pal[d] >> 24)<<6; > > +dst[i]= (pal[d] >> 24)<<6 | pal[d]>>2; > > this looks wrong, theres a 24 missing in some form New patch attached, thank you! Carl Eugen From a71053df9131be803d9a359a7232e5193747f351 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Sat, 15 Feb 2020 10:07:51 +0100 Subject: [PATCH] lsws/input: Do not change transparency range. Fixes ticket #8509. --- libswscale/input.c| 6 +- tests/ref/fate/ffmpeg-filter_colorkey | 20 +- tests/ref/fate/filter-overlay-dvdsub-2397 | 180 +- tests/ref/fate/filter-overlay_gbrap_gbrap | 2 +- tests/ref/fate/filter-overlay_gbrp_gbrap | 2 +- tests/ref/fate/filter-overlay_yuv420_yuva420 | 2 +- tests/ref/fate/filter-overlay_yuv422_yuva422 | 2 +- tests/ref/fate/filter-overlay_yuv444_yuva444 | 2 +- tests/ref/fate/filter-overlay_yuva420_yuva420 | 2 +- tests/ref/fate/filter-overlay_yuva422_yuva422 | 2 +- tests/ref/fate/filter-overlay_yuva444_yuva444 | 2 +- 11 files changed, 111 insertions(+), 111 deletions(-) diff --git a/libswscale/input.c b/libswscale/input.c index 159f70307d..7d7e6b7f36 100644 --- a/libswscale/input.c +++ b/libswscale/input.c @@ -437,7 +437,7 @@ static void abgrToA_c(uint8_t *_dst, const uint8_t *src, const uint8_t *unused1, int16_t *dst = (int16_t *)_dst; int i; for (i=0; i>2; } } @@ -446,7 +446,7 @@ static void rgbaToA_c(uint8_t *_dst, const uint8_t *src, const uint8_t *unused1, int16_t *dst = (int16_t *)_dst; int i; for (i=0; i>2; } } @@ -457,7 +457,7 @@ static void palToA_c(uint8_t *_dst, const uint8_t *src, const uint8_t *unused1, for (i=0; i> 24)<<6; +dst[i]= (pal[d] >> 24)<<6 | pal[d]>>26; } } diff --git a/tests/ref/fate/ffmpeg-filter_colorkey b/tests/ref/fate/ffmpeg-filter_colorkey index effc13b12f..490a0f9aa6 100644 --- a/tests/ref/fate/ffmpeg-filter_colorkey +++ b/tests/ref/fate/ffmpeg-filter_colorkey @@ -3,13 +3,13 @@ #codec_id 0: rawvideo #dimensions 0: 720x576 #sar 0: 0/1 -0, 0, 0,1, 622080, 0x4e30accb -0, 1, 1,1, 622080, 0x7d941c14 -0, 2, 2,1, 622080, 0xf7451c5b -0, 3, 3,1, 622080, 0xb2c74319 -0, 4, 4,1, 622080, 0xc9b80b79 -0, 5, 5,1, 622080, 0x92ce1194 -0, 6, 6,1, 622080, 0x43ae99ac -0, 7, 7,1, 622080, 0x4ec3a554 -0, 8, 8,1, 622080, 0x3200250c -0, 9, 9,1, 622080, 0x94ebb3f3 +0, 0, 0,1, 622080, 0x78efb628 +0, 1, 1,1, 622080, 0x641f2564 +0, 2, 2,1, 622080, 0x348f25c3 +0, 3, 3,1, 622080, 0x6afc485a +0, 4, 4,1, 622080, 0xe949107f +0, 5, 5,1, 622080, 0x171716e5 +0, 6, 6,1, 622080, 0x2985a01f +0, 7, 7,1, 622080, 0xc5ddabd7 +0, 8, 8,1, 622080, 0xb4dd2b7f +0, 9, 9,1, 622080, 0x6e75ba82 diff --git a/tests/ref/fate/filter-overlay-dvdsub-2397 b/tests/ref/fate/filter-overlay-dvdsub-2397 index b86a2184b7..483e5fa4e0 100644 --- a/tests/ref/fate/filter-overlay
[FFmpeg-devel] [PATCH] configure: Remove bitrig support
configure: Remove bitrig support Bitrig was an OpenBSD derivative that has been dead for awhile now. Signed-off-by: Brad Smith --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 06e3a7b2a8..9221621bd1 100755 --- a/configure +++ b/configure @@ -5303,7 +5303,7 @@ case $target_os in oss_outdev_extralibs="-lossaudio" enabled gcc || check_ldflags -Wl,-zmuldefs ;; -openbsd|bitrig) +openbsd) disable symver enable section_data_rel_ro striptype="" -- 2.25.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avdevice/decklink_dec: fix stopping streams in read_close
On Sat, 22 Feb 2020, Marton Balint wrote:
The capture_started variable was never set, it is simpler to call the stop
functions unconditionally if the interface is available.
Applied the series.
Regards,
Marton
Signed-off-by: Marton Balint
---
libavdevice/decklink_common.h | 1 -
libavdevice/decklink_dec.cpp | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 8b3dbce2fb..27ce6a8a40 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -115,7 +115,6 @@ struct decklink_ctx {
/* Status */
int playback_started;
-int capture_started;
int64_t last_pts;
unsigned long frameCount;
unsigned int dropped;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 1fd5adf515..c8d931517e 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -983,7 +983,7 @@ av_cold int ff_decklink_read_close(AVFormatContext *avctx)
struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
struct decklink_ctx *ctx = (struct decklink_ctx *)cctx->ctx;
-if (ctx->capture_started) {
+if (ctx->dli) {
ctx->dli->StopStreams();
ctx->dli->DisableVideoInput();
ctx->dli->DisableAudioInput();
--
2.16.4
___
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] Status and Plans for Subtitle Filters
On Tue, Feb 25, 2020 at 06:40:13PM +0100, Clément Bœsch wrote:
> On Sun, Feb 23, 2020 at 09:59:59PM +0100, Michael Niedermayer wrote:
> [...]
> > > The subtitles refactor requires to see the big picture and all the
> > > problems at
> > > once.
> >
> > really ?
> > just hypothetically, and playing the devils advocat here.
> > what would happen if one problem or set of problems is solved at a time ?
>
> The first requirement of everything following is to define a new
> structure/API for holding the subtitles within the AVFrame (which has to
> live in lavu and not lavc like current API). So you have to address all
> the current limitations in that new API first, unless you're ready to
> change that new API 10x in the near future.
yes i realized this implication when i wrote my mail and while it gave me
pause iam not sure this is a problem. This would not necessarily be public
API for user applications to use. Rather a step toward implementing the
new final API. Done that way to simplify things.
This like other comments is also really just a suggestion to simplify
the work. If it doesnt simplify anything it makes no sense of course.
> And even if you keep most of
> the current design, you still have to at least come up with ways to remove
> all the current hacks that would go away while moving to the new design.
>
> >
> > Maybe the thinking should not be "what are all the things that might need
> > to be considered"
> > but rather "what is the minimum set of things that need to be considered"
> > to make the first step towards a better API/first git push
> >
> >
> >
> > > Since the core change (subtitles in AVFrame) requires the introduction of
> > > a new subtitles structure and API, it also involve addressing the
> > > shortcomings
> > > of the original API (or maybe we could tolerate a new API that actually
> > > looks
> > > like the old?). So even if we ignore the subtitle-in-avframe thing, we
> > > don't
> > > have a clear answer for a sane API that handles everything. Here is a
> > > non-exhaustive list of stuff that we have to take into account while
> > > thinking
> > > about that:
> > >
> > > - text subtitles with and without markup
> >
> > > - sparsity, overlapping
> >
> > heartbeat frames would eliminate sparsity
>
> Yes, and like many aspect of this refactor: we need to come up and
> formalize a convention. Of course I can make a suggestion, but there are
> many other cases and exceptions.
>
> > what happens if you forbid overlapping ?
>
> You can't, it's too common. The classic "Hello, hello" was already
> mentioned, but I could also mention subtitles used to "legend" the
> environment (you know, like, signposts and stuff) in addition to
> dialogues.
I do think i misunderstand something here
because if we have a video with a signpost shown from 0:00 to 1:00
and another shown from 0:30 to 1:30 then the subtitles translating
or commenting that would overlap.
and also the video frames showing these signposts overlap , ehm i mean
they dont overlap. That is what i do not understand.
Video frames dont do that and its fine
and then theres audio
someone playing a note on the trumpet and another a note on the piano
again we have 2 AVFrame overlapp i mean not overlapping.
So why subtitles ?
and one could even argue why it would make sense for audio to be
overlapping with this information about instruments and it is in
midi and mod files. And a filter writing notes for the instruments
would benefit from this and simlar a midi encoder
[...]
> > > - bitmap subtitles and their potential colorspaces (each rectangle as an
> > > AVFrame is way overkill but technically that's exactly what it is)
> >
> > then a AVFrame needs to represent a collection of rectangles.
> > Its either 1 or N for the design i think.
> > Our current subtitle structures already have a similar design so this
> > wouldnt be really different.
>
> Yeah, the new API prototype ended up being:
>
> +#define AV_NUM_DATA_POINTERS 8
> +
> +/**
> + * This structure describes decoded subtitle rectangle
> + */
> +typedef struct AVFrameSubtitleRectangle {
> +int x, y;
> +int w, h;
> +
> +/* image data for bitmap subtitles, in AVFrame.format (AVPixelFormat) */
> +uint8_t *data[AV_NUM_DATA_POINTERS];
> +int linesize[AV_NUM_DATA_POINTERS];
> +
> +/* decoded text for text subtitles, in ASS */
> +char *text;
> +
> +int flags;
is 32bit flags enough ?
just bringing this up as a int64 is less ugly than a flags2
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Elect your leaders based on what they did after the last election, not
based on what they say before an election.
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 "unsu
Re: [FFmpeg-devel] Status and Plans for Subtitle Filters
Michael Niedermayer (12020-02-26): > I do think i misunderstand something here > because if we have a video with a signpost shown from 0:00 to 1:00 > and another shown from 0:30 to 1:30 then the subtitles translating > or commenting that would overlap. The existence of signs implies that overlap does happen frequently and needs to happen gracefully. The idea of speech synthesis implies that splitting and merging cannot be used indiscriminately. Both are true, they do not need to happen at the same time. Yet, they can happen at the same time, if for example spoken dialogue meant for speech synthesis is separate (with a different ASS style or layer) from the signs. Furthermore, speech synthesis was just one example among many to explain why splitting and merging is not acceptable. There are many others. The case of timed animations has been given. > and also the video frames showing these signposts overlap , ehm i mean > they dont overlap. That is what i do not understand. > Video frames dont do that and its fine > and then theres audio > someone playing a note on the trumpet and another a note on the piano > again we have 2 AVFrame overlapp i mean not overlapping. > So why subtitles ? > > and one could even argue why it would make sense for audio to be > overlapping with this information about instruments and it is in > midi and mod files. And a filter writing notes for the instruments > would benefit from this and simlar a midi encoder You're hinting at the answer. If we worked with MIDI and mod files, splitting or merging notes would be unacceptable. Same goes for frames: if we were a vectorial drawing program, rasterizing the graphic objects would be unacceptable. But we're not: we consider audio is just a stream of sample going to the speakers, and if some codec tries to do something fancy with notes, that's its problem and we don't try to help. Same goes for video: it's just pixels going to the screen, we don't try to preserve sprites. But it's not the same with subtitles. Subtitles are not just a bunch of pixels that get overlaid on top of the video. Well, they could be, but it's not what the users expect. Subtitles are often hand-written, partially or completely, and read directly. A tool that mangles it would be useless for most usages. 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] Add .mailmap
On Mon, Feb 24, 2020, at 11:19 AM, Thilo Borgmann wrote: > Am 23.02.20 um 21:40 schrieb Josh de Kock: > > On Sun, Feb 23, 2020, at 4:07 PM, Thilo Borgmann wrote: > >> [...] > >> > >> How is it automatically generated? > > > > I wrote a small script to parse author names/emails and group > > emails together based on names. In the future, additions should > > be added manually. > > Having that script in tools/ shouldn't hurt, manual updates can get out of > sync. > Also authors might be unaware of or forgetting about .mailmap. > > If you scriptify the group of people for a general assembly like > specified during some earlier meeting, that should be committed, > too. > > .mailmap patch itself LGTM. Pushed. I will send a patch to add the script to compute the general assembly soon. -- Josh ___ 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] avcodec/cdtoons: Remove superfluous ;
The second ; in a double ;; is actually a null statement. It triggers
the typical declaration-after-statement compiler-warnings if it occurs
in the middle of several declarations (like here).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cdtoons.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cdtoons.c b/libavcodec/cdtoons.c
index d5dce6351f..13f9a60f0f 100644
--- a/libavcodec/cdtoons.c
+++ b/libavcodec/cdtoons.c
@@ -61,7 +61,7 @@ static int cdtoons_render_sprite(AVCodecContext *avctx, const
uint8_t *data,
{
CDToonsContext *c = avctx->priv_data;
const uint8_t *next_line = data;
-const uint8_t *end = data + data_size;;
+const uint8_t *end = data + data_size;
uint16_t line_size;
uint8_t *dest;
int skip = 0, to_skip, x;
--
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] avformat/ivfenc: Don't use size_t for size of file
Signed-off-by: Andreas Rheinhardt
---
libavformat/ivfenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index eb70421c44..45e5b238dc 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -80,7 +80,7 @@ static int ivf_write_trailer(AVFormatContext *s)
IVFEncContext *ctx = s->priv_data;
if ((pb->seekable & AVIO_SEEKABLE_NORMAL) && ctx->frame_cnt > 1) {
-size_t end = avio_tell(pb);
+int64_t end = avio_tell(pb);
avio_seek(pb, 24, SEEK_SET);
// overwrite the "length" field (duration)
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/cdtoons: Remove superfluous ;
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: Thursday, February 27, 2020 13:34
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt
> Subject: [FFmpeg-devel] [PATCH 2/2] avcodec/cdtoons: Remove
> superfluous ;
>
> The second ; in a double ;; is actually a null statement. It triggers
> the typical declaration-after-statement compiler-warnings if it occurs
> in the middle of several declarations (like here).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/cdtoons.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/cdtoons.c b/libavcodec/cdtoons.c
> index d5dce6351f..13f9a60f0f 100644
> --- a/libavcodec/cdtoons.c
> +++ b/libavcodec/cdtoons.c
> @@ -61,7 +61,7 @@ static int cdtoons_render_sprite(AVCodecContext
> *avctx, const uint8_t *data,
> {
> CDToonsContext *c = avctx->priv_data;
> const uint8_t *next_line = data;
> -const uint8_t *end = data + data_size;;
> +const uint8_t *end = data + data_size;
> uint16_t line_size;
> uint8_t *dest;
> int skip = 0, to_skip, x;
> --
lgtm, same issue exists in vf_cas.c maybe could be fixed in one commit.
libavfilter/vf_cas.c:61:const int w1 = w - 1;;
libavfilter/vf_cas.c:128:const int w1 = w - 1;;
- Linjie
___
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] lavfi/vf_zscale: remove unused code
> -Original Messages-
> From: "Linjie Fu"
> Sent Time: 2019-12-12 17:14:59 (Thursday)
> To: ffmpeg-devel@ffmpeg.org
> Cc: "Linjie Fu"
> Subject: [FFmpeg-devel] [PATCH,v2] lavfi/vf_zscale: remove unused code
>
> Signed-off-by: Linjie Fu
> ---
> libavfilter/vf_zscale.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
> index db2dd17..bd5825f 100644
> --- a/libavfilter/vf_zscale.c
> +++ b/libavfilter/vf_zscale.c
> @@ -287,13 +287,6 @@ static int config_props(AVFilterLink *outlink)
> outlink->w = w;
> outlink->h = h;
>
> -if (inlink->w == outlink->w &&
> -inlink->h == outlink->h &&
> -inlink->format == outlink->format)
> -;
> -else {
> -}
> -
> if (inlink->sample_aspect_ratio.num){
> outlink->sample_aspect_ratio = av_mul_q((AVRational){outlink->h *
> inlink->w, outlink->w * inlink->h}, inlink->sample_aspect_ratio);
> } else
> --
> 2.7.4
Ping.
___
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".
