Re: [FFmpeg-devel] [PATCH] kmsgrab: add category for kmsgrab

[Jun Zhao]

On 2018/3/27 6:01, Mark Thompson wrote:
> On 26/03/18 01:22, Jun Zhao wrote:
>> From fc9b04d95b1e21fa9985dc611fcf43d2a4c635c0 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Fri, 23 Mar 2018 21:32:03 +0800
>> Subject: [PATCH] kmsgrab: add category for kmsgrab
>>
>> add category for kmsgrab, then we can display kmsgrab in
>> "ffmpeg -devices".
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavdevice/kmsgrab.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
>> index 6a6de09c37..d0de774871 100644
>> --- a/libavdevice/kmsgrab.c
>> +++ b/libavdevice/kmsgrab.c
>> @@ -451,6 +451,7 @@ static const AVClass kmsgrab_class = {
>>  .item_name  = av_default_item_name,
>>  .option = options,
>>  .version= LIBAVUTIL_VERSION_INT,
>> +.category   = AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT,
>>  };
>>  
>>  AVInputFormat ff_kmsgrab_demuxer = {
>> -- 
>> 2.14.1
>>
> Sure, will apply soon.
>
> Thanks,
Tks the appled, Mark
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add OpenCL scale filter

[Gabriel Machado]

From: Gabriel Machado 

Some scaling filters implemented as OpenCL kernels. Can be used as:

scale_opencl=::flags=
where  can be `neighbor', `bilinear', `bicubic' or `fast_bicubic'

This is an initial draft, there's still a long way to go in terms of
completeness, configurability and performance.

---
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/opencl/scale.cl   | 165 
 libavfilter/opencl_source.h   |   1 +
 libavfilter/vf_scale_opencl.c | 289 ++
 6 files changed, 458 insertions(+)
 create mode 100644 libavfilter/opencl/scale.cl
 create mode 100644 libavfilter/vf_scale_opencl.c

diff --git a/configure b/configure
index 5ccf3ce..4007ee8 100755
--- a/configure
+++ b/configure
@@ -2821,6 +2821,7 @@ v4l2_m2m_deps_any="linux_videodev2_h"
 
 hwupload_cuda_filter_deps="ffnvcodec"
 scale_npp_filter_deps="ffnvcodec libnpp"
+scale_opencl_filter_deps="opencl"
 scale_cuda_filter_deps="cuda_sdk"
 thumbnail_cuda_filter_deps="cuda_sdk"
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a90ca30..6303cbd 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -302,6 +302,7 @@ OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
 OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
+OBJS-$(CONFIG_SCALE_OPENCL_FILTER)   += vf_scale_opencl.o opencl.o 
opencl/scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 1cf1340..3185b17 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -309,6 +309,7 @@ static void register_all(void)
 REGISTER_FILTER(SCALE,  scale,  vf);
 REGISTER_FILTER(SCALE_CUDA, scale_cuda, vf);
 REGISTER_FILTER(SCALE_NPP,  scale_npp,  vf);
+REGISTER_FILTER(SCALE_OPENCL,   scale_opencl,   vf);
 REGISTER_FILTER(SCALE_QSV,  scale_qsv,  vf);
 REGISTER_FILTER(SCALE_VAAPI,scale_vaapi,vf);
 REGISTER_FILTER(SCALE2REF,  scale2ref,  vf);
diff --git a/libavfilter/opencl/scale.cl b/libavfilter/opencl/scale.cl
new file mode 100644
index 000..b0e6cb2
--- /dev/null
+++ b/libavfilter/opencl/scale.cl
@@ -0,0 +1,165 @@
+/*
+ * Copyright (c) 2018 Gabriel Machado
+ *
+ * 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
+ */
+
+__kernel void neighbor(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_NEAREST);
+
+int2 coord = {get_global_id(0), get_global_id(1)};
+int2 size = {get_global_size(0), get_global_size(1)};
+
+float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
+
+float4 c = read_imagef(src, sampler, pos);
+write_imagef(dst, coord, c);
+}
+
+__kernel void bilinear(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_LINEAR);
+
+int2 coord = {get_global_id(0), get_global_id(1)};
+int2 size = {get_global_size(0), get_global_size(1)};
+
+float2 pos = (convert_float2(coord) + 0.5) / convert_float2(size);
+
+float4 c = read_imagef(src, sampler, pos);
+write_imagef(dst, coord, c);
+}
+
+// https://developer.nvidia.com/gpugems/GPUGems/gpugems_ch24.html
+float MitchellNetravali(float x, float B, float C)
+{
+float t = fabs(x);
+float tt = t*t;
+float ttt = tt*t;
+
+if (t < 1) {
+return ((12 - 9 * B - 6 * C) * ttt +
+(-18 + 12 * B + 6 * C) * tt + (6 - 2 * B)) / 6;
+} else if ((t >= 1) && (t < 2)) {
+return ((-B - 6 * C) 

Re: [FFmpeg-devel] [PATCH v2] avformat/dashdec: Support signaling of last segment number

[Steven Liu]

> On 26 Mar 2018, at 04:01, sanilraut  wrote:
> 
> Last segment indicated by mpd is not parsed.
> Example stream: 
> http://dash.akamaized.net/dash264/TestCasesIOP41/LastSegmentNumber/1/manifest_last_segment_num.mpd
> 
> This patch supports parsing of Supplemental Descriptor with @schemeIdUri set 
> to http://dashif.org/guide-
> lines/last-segment-number with the @value set to the last segment number.
> 
> ---
> libavformat/dashdec.c | 22 +++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 7b79b93..db63a99 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -805,7 +805,8 @@ static int parse_manifest_representation(AVFormatContext 
> *s, const char *url,
>  xmlNodePtr fragment_template_node,
>  xmlNodePtr content_component_node,
>  xmlNodePtr adaptionset_baseurl_node,
> - xmlNodePtr 
> adaptionset_segmentlist_node)
> + xmlNodePtr 
> adaptionset_segmentlist_node,
> + xmlNodePtr 
> adaptionset_supplementalproperty_node)
> {
> int32_t ret = 0;
> int32_t audio_rep_idx = 0;
> @@ -825,6 +826,7 @@ static int parse_manifest_representation(AVFormatContext 
> *s, const char *url,
> char *timescale_val = NULL;
> char *initialization_val = NULL;
> char *media_val = NULL;
> +char *val = NULL;
> xmlNodePtr baseurl_nodes[4];
> xmlNodePtr representation_node = node;
> char *rep_id_val = xmlGetProp(representation_node, "id");
> @@ -920,6 +922,13 @@ static int parse_manifest_representation(AVFormatContext 
> *s, const char *url,
> rep->first_seq_no = (int64_t) strtoll(startnumber_val, NULL, 
> 10);
> xmlFree(startnumber_val);
> }
> +if (adaptionset_supplementalproperty_node) {
> +if 
> (!strcmp(xmlGetProp(adaptionset_supplementalproperty_node,"schemeIdUri"), 
> "http://dashif.org/guidelines/last-segment-number;)) {
av_strcasecmp
> +val = 
> xmlGetProp(adaptionset_supplementalproperty_node,"value”);
val need be checked if xmlGetProp will be failed
> +rep->last_seq_no =(int64_t) strtoll(val, NULL, 10) - 1;
> +xmlFree(val);
> + }
> +}
> 
> fragment_timeline_node = 
> find_child_node_by_name(representation_segmenttemplate_node, 
> "SegmentTimeline");
> 
> @@ -1054,6 +1063,7 @@ static int parse_manifest_adaptationset(AVFormatContext 
> *s, const char *url,
> xmlNodePtr content_component_node = NULL;
> xmlNodePtr adaptionset_baseurl_node = NULL;
> xmlNodePtr adaptionset_segmentlist_node = NULL;
> +xmlNodePtr adaptionset_supplementalproperty_node = NULL;
> xmlNodePtr node = NULL;
> 
> node = xmlFirstElementChild(adaptionset_node);
> @@ -1066,6 +1076,8 @@ static int parse_manifest_adaptationset(AVFormatContext 
> *s, const char *url,
> adaptionset_baseurl_node = node;
> } else if (!av_strcasecmp(node->name, (const char *)"SegmentList")) {
> adaptionset_segmentlist_node = node;
> +} else if (!av_strcasecmp(node->name, (const char 
> *)"SupplementalProperty")) {
> +adaptionset_supplementalproperty_node = node;
> } else if (!av_strcasecmp(node->name, (const char 
> *)"Representation")) {
> ret = parse_manifest_representation(s, url, node,
> adaptionset_node,
> @@ -1076,7 +1088,8 @@ static int parse_manifest_adaptationset(AVFormatContext 
> *s, const char *url,
> fragment_template_node,
> content_component_node,
> adaptionset_baseurl_node,
> -
> adaptionset_segmentlist_node);
> +adaptionset_segmentlist_node,
> +
> adaptionset_supplementalproperty_node);
> if (ret < 0) {
> return ret;
> }
> @@ -1819,7 +1832,10 @@ static int open_demux_for_component(AVFormatContext 
> *s, struct representation *p
> 
> pls->parent = s;
> pls->cur_seq_no  = calc_cur_seg_no(s, pls);
> -pls->last_seq_no = calc_max_seg_no(pls, s->priv_data);
> +
> +if (!pls->last_seq_no) {
> +pls->last_seq_no = calc_max_seg_no(pls, s->priv_data);
> +}
> 
> ret = reopen_demux_for_component(s, pls);
> if (ret < 0) {
> -- 
> 
> Thanks
> 
> 2.7.4
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] h264_metadata: Add support for A/53 closed captions

[James Almer]

On 3/26/2018 9:31 PM, Mark Thompson wrote:
> On 27/03/18 01:20, Michael Niedermayer wrote:
>> On Sun, Mar 25, 2018 at 06:41:34PM +0100, Mark Thompson wrote:
>>> Allows insertion (from side data), extraction (to side data), and removal
>>> of closed captions in SEI messages.
>>> ---
>>>  libavcodec/Makefile|   2 +-
>>>  libavcodec/h264_metadata_bsf.c | 138 
>>> +
>>>  2 files changed, 139 insertions(+), 1 deletion(-)
>>
>> This breaks build on mips-linux-gnu-gcc-4.4 (Debian 4.4.5-8) 4.4.5
>>
>>
>> In file included from src/libavcodec/cbs_misc.c:25:
>> src/libavcodec/cbs_misc.h:73: warning: declaration does not declare anything
>> src/libavcodec/cbs_misc.h:86: warning: declaration does not declare anything
>> In file included from src/libavcodec/cbs_misc.c:57:
>> src/libavcodec/cbs_misc_syntax_template.c: In function 
>> ‘cbs_misc_read_a53_atsc_user_data’:
>> src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has 
>> no member named ‘cc_data’
>> src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has 
>> no member named ‘bar_data’
>> src/libavcodec/cbs_misc_syntax_template.c: In function 
>> ‘cbs_misc_read_a53_user_data’:
>> src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
>> member named ‘atsc’
>> src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
>> member named ‘afd’
>> In file included from src/libavcodec/cbs_misc.c:82:
>> src/libavcodec/cbs_misc_syntax_template.c: In function 
>> ‘cbs_misc_write_a53_atsc_user_data’:
>> src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has 
>> no member named ‘cc_data’
>> src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has 
>> no member named ‘bar_data’
>> src/libavcodec/cbs_misc_syntax_template.c: In function 
>> ‘cbs_misc_write_a53_user_data’:
>> src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
>> member named ‘atsc’
>> src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
>> member named ‘afd’
>> src/libavcodec/cbs_misc.c: In function ‘ff_cbs_read_a53_cc_side_data’:
>> src/libavcodec/cbs_misc.c:153: error: unknown field ‘atsc’ specified in 
>> initializer
>> src/libavcodec/cbs_misc.c:153: error: extra brace group at end of initializer
>> src/libavcodec/cbs_misc.c:153: error: (near initialization for ‘(anonymous)’)
>> src/libavcodec/cbs_misc.c:156: error: extra brace group at end of initializer
>> src/libavcodec/cbs_misc.c:156: error: (near initialization for ‘(anonymous)’)
>> src/libavcodec/cbs_misc.c:165: warning: excess elements in struct initializer
>> src/libavcodec/cbs_misc.c:165: warning: (near initialization for 
>> ‘(anonymous)’)
>> src/libavcodec/cbs_misc.c:167: error: ‘A53UserData’ has no member named 
>> ‘atsc’
>> src/libavcodec/cbs_misc.c: In function ‘ff_cbs_write_a53_cc_side_data’:
>> src/libavcodec/cbs_misc.c:193: error: ‘A53UserData’ has no member named 
>> ‘atsc’
>> src/libavcodec/cbs_misc.c:196: error: ‘A53UserData’ has no member named 
>> ‘atsc’
>> CC   libavcodec/dpxenc.o
>> CC   libavcodec/dpx_parser.o
>> make: *** [libavcodec/cbs_misc.o] Error 1
>> make: *** Waiting for unfinished jobs
>> src/libavcodec/dnxhddec.c:146: warning: ‘dnxhd_decode_init_thread_copy’ 
>> defined but not used
>> src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_init’:
>> src/libavcodec/dnxhdenc.c:518: warning: ‘coded_frame’ is deprecated 
>> (declared at src/libavcodec/avcodec.h:2760)
>> src/libavcodec/dnxhdenc.c:519: warning: ‘coded_frame’ is deprecated 
>> (declared at src/libavcodec/avcodec.h:2760)
>> src/libavcodec/dnxhdenc.c: In function ‘dnxhd_load_picture’:
>> src/libavcodec/dnxhdenc.c:1272: warning: ‘coded_frame’ is deprecated 
>> (declared at src/libavcodec/avcodec.h:2760)
>> src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_picture’:
>> src/libavcodec/dnxhdenc.c:1337: warning: ‘coded_frame’ is deprecated 
>> (declared at src/libavcodec/avcodec.h:2760)
>> src/libavcodec/dpxenc.c: In function ‘encode_frame’:
>> src/libavcodec/dpxenc.c:180: warning: ‘need_align’ may be used uninitialized 
>> in this function
>> src/libavcodec/dpxenc.c:180: warning: ‘len’ may be used uninitialized in 
>> this function
>>
>>
>> [...]
> 
> Do you happen to know what set of compilers lack anonymous union support like 
> this?  It's quite tempting to add a configure option to just not build it for 
> them.

Apparently, GCC prior to 4.6
See commit b93d96a07be40f8e5d267d55fe961285586c0fd7
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] h264_metadata: Add support for A/53 closed captions

[Mark Thompson]

On 27/03/18 01:20, Michael Niedermayer wrote:
> On Sun, Mar 25, 2018 at 06:41:34PM +0100, Mark Thompson wrote:
>> Allows insertion (from side data), extraction (to side data), and removal
>> of closed captions in SEI messages.
>> ---
>>  libavcodec/Makefile|   2 +-
>>  libavcodec/h264_metadata_bsf.c | 138 
>> +
>>  2 files changed, 139 insertions(+), 1 deletion(-)
> 
> This breaks build on mips-linux-gnu-gcc-4.4 (Debian 4.4.5-8) 4.4.5
> 
> 
> In file included from src/libavcodec/cbs_misc.c:25:
> src/libavcodec/cbs_misc.h:73: warning: declaration does not declare anything
> src/libavcodec/cbs_misc.h:86: warning: declaration does not declare anything
> In file included from src/libavcodec/cbs_misc.c:57:
> src/libavcodec/cbs_misc_syntax_template.c: In function 
> ‘cbs_misc_read_a53_atsc_user_data’:
> src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has 
> no member named ‘cc_data’
> src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has 
> no member named ‘bar_data’
> src/libavcodec/cbs_misc_syntax_template.c: In function 
> ‘cbs_misc_read_a53_user_data’:
> src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
> member named ‘atsc’
> src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
> member named ‘afd’
> In file included from src/libavcodec/cbs_misc.c:82:
> src/libavcodec/cbs_misc_syntax_template.c: In function 
> ‘cbs_misc_write_a53_atsc_user_data’:
> src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has 
> no member named ‘cc_data’
> src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has 
> no member named ‘bar_data’
> src/libavcodec/cbs_misc_syntax_template.c: In function 
> ‘cbs_misc_write_a53_user_data’:
> src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
> member named ‘atsc’
> src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
> member named ‘afd’
> src/libavcodec/cbs_misc.c: In function ‘ff_cbs_read_a53_cc_side_data’:
> src/libavcodec/cbs_misc.c:153: error: unknown field ‘atsc’ specified in 
> initializer
> src/libavcodec/cbs_misc.c:153: error: extra brace group at end of initializer
> src/libavcodec/cbs_misc.c:153: error: (near initialization for ‘(anonymous)’)
> src/libavcodec/cbs_misc.c:156: error: extra brace group at end of initializer
> src/libavcodec/cbs_misc.c:156: error: (near initialization for ‘(anonymous)’)
> src/libavcodec/cbs_misc.c:165: warning: excess elements in struct initializer
> src/libavcodec/cbs_misc.c:165: warning: (near initialization for 
> ‘(anonymous)’)
> src/libavcodec/cbs_misc.c:167: error: ‘A53UserData’ has no member named ‘atsc’
> src/libavcodec/cbs_misc.c: In function ‘ff_cbs_write_a53_cc_side_data’:
> src/libavcodec/cbs_misc.c:193: error: ‘A53UserData’ has no member named ‘atsc’
> src/libavcodec/cbs_misc.c:196: error: ‘A53UserData’ has no member named ‘atsc’
> CClibavcodec/dpxenc.o
> CClibavcodec/dpx_parser.o
> make: *** [libavcodec/cbs_misc.o] Error 1
> make: *** Waiting for unfinished jobs
> src/libavcodec/dnxhddec.c:146: warning: ‘dnxhd_decode_init_thread_copy’ 
> defined but not used
> src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_init’:
> src/libavcodec/dnxhdenc.c:518: warning: ‘coded_frame’ is deprecated (declared 
> at src/libavcodec/avcodec.h:2760)
> src/libavcodec/dnxhdenc.c:519: warning: ‘coded_frame’ is deprecated (declared 
> at src/libavcodec/avcodec.h:2760)
> src/libavcodec/dnxhdenc.c: In function ‘dnxhd_load_picture’:
> src/libavcodec/dnxhdenc.c:1272: warning: ‘coded_frame’ is deprecated 
> (declared at src/libavcodec/avcodec.h:2760)
> src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_picture’:
> src/libavcodec/dnxhdenc.c:1337: warning: ‘coded_frame’ is deprecated 
> (declared at src/libavcodec/avcodec.h:2760)
> src/libavcodec/dpxenc.c: In function ‘encode_frame’:
> src/libavcodec/dpxenc.c:180: warning: ‘need_align’ may be used uninitialized 
> in this function
> src/libavcodec/dpxenc.c:180: warning: ‘len’ may be used uninitialized in this 
> function
> 
> 
> [...]

Do you happen to know what set of compilers lack anonymous union support like 
this?  It's quite tempting to add a configure option to just not build it for 
them.

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] hwcontext_d3d11: Fix crash with valid adapter but no device

[Mark Thompson]

This crash was introduced by 8bbf2dacbfb4ead1535dea411035994f507f517d,
which could incorrectly overwrite the failure result from creating the
device.

Fixes ticket #7108.
---
 libavutil/hwcontext_d3d11va.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 960883c9d8..d39fdd3fc8 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -556,8 +556,6 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx, 
const char *device,
 }
 }
 
-hr = mD3D11CreateDevice(pAdapter, pAdapter ? D3D_DRIVER_TYPE_UNKNOWN : 
D3D_DRIVER_TYPE_HARDWARE, NULL, creationFlags, NULL, 0,
-   D3D11_SDK_VERSION, _hwctx->device, NULL, NULL);
 if (pAdapter) {
 DXGI_ADAPTER_DESC2 desc;
 hr = IDXGIAdapter2_GetDesc(pAdapter, );
@@ -565,8 +563,12 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx, 
const char *device,
 av_log(ctx, AV_LOG_INFO, "Using device %04x:%04x (%ls).\n",
desc.VendorId, desc.DeviceId, desc.Description);
 }
-IDXGIAdapter_Release(pAdapter);
 }
+
+hr = mD3D11CreateDevice(pAdapter, pAdapter ? D3D_DRIVER_TYPE_UNKNOWN : 
D3D_DRIVER_TYPE_HARDWARE, NULL, creationFlags, NULL, 0,
+   D3D11_SDK_VERSION, _hwctx->device, NULL, NULL);
+if (pAdapter)
+IDXGIAdapter_Release(pAdapter);
 if (FAILED(hr)) {
 av_log(ctx, AV_LOG_ERROR, "Failed to create Direct3D device (%lx)\n", 
(long)hr);
 return AVERROR_UNKNOWN;
-- 
2.16.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] h264_metadata: Add support for A/53 closed captions

[Michael Niedermayer]

On Sun, Mar 25, 2018 at 06:41:34PM +0100, Mark Thompson wrote:
> Allows insertion (from side data), extraction (to side data), and removal
> of closed captions in SEI messages.
> ---
>  libavcodec/Makefile|   2 +-
>  libavcodec/h264_metadata_bsf.c | 138 
> +
>  2 files changed, 139 insertions(+), 1 deletion(-)

This breaks build on mips-linux-gnu-gcc-4.4 (Debian 4.4.5-8) 4.4.5


In file included from src/libavcodec/cbs_misc.c:25:
src/libavcodec/cbs_misc.h:73: warning: declaration does not declare anything
src/libavcodec/cbs_misc.h:86: warning: declaration does not declare anything
In file included from src/libavcodec/cbs_misc.c:57:
src/libavcodec/cbs_misc_syntax_template.c: In function 
‘cbs_misc_read_a53_atsc_user_data’:
src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has no 
member named ‘cc_data’
src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has no 
member named ‘bar_data’
src/libavcodec/cbs_misc_syntax_template.c: In function 
‘cbs_misc_read_a53_user_data’:
src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
member named ‘atsc’
src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
member named ‘afd’
In file included from src/libavcodec/cbs_misc.c:82:
src/libavcodec/cbs_misc_syntax_template.c: In function 
‘cbs_misc_write_a53_atsc_user_data’:
src/libavcodec/cbs_misc_syntax_template.c:102: error: ‘A53ATSCUserData’ has no 
member named ‘cc_data’
src/libavcodec/cbs_misc_syntax_template.c:104: error: ‘A53ATSCUserData’ has no 
member named ‘bar_data’
src/libavcodec/cbs_misc_syntax_template.c: In function 
‘cbs_misc_write_a53_user_data’:
src/libavcodec/cbs_misc_syntax_template.c:140: error: ‘A53UserData’ has no 
member named ‘atsc’
src/libavcodec/cbs_misc_syntax_template.c:142: error: ‘A53UserData’ has no 
member named ‘afd’
src/libavcodec/cbs_misc.c: In function ‘ff_cbs_read_a53_cc_side_data’:
src/libavcodec/cbs_misc.c:153: error: unknown field ‘atsc’ specified in 
initializer
src/libavcodec/cbs_misc.c:153: error: extra brace group at end of initializer
src/libavcodec/cbs_misc.c:153: error: (near initialization for ‘(anonymous)’)
src/libavcodec/cbs_misc.c:156: error: extra brace group at end of initializer
src/libavcodec/cbs_misc.c:156: error: (near initialization for ‘(anonymous)’)
src/libavcodec/cbs_misc.c:165: warning: excess elements in struct initializer
src/libavcodec/cbs_misc.c:165: warning: (near initialization for ‘(anonymous)’)
src/libavcodec/cbs_misc.c:167: error: ‘A53UserData’ has no member named ‘atsc’
src/libavcodec/cbs_misc.c: In function ‘ff_cbs_write_a53_cc_side_data’:
src/libavcodec/cbs_misc.c:193: error: ‘A53UserData’ has no member named ‘atsc’
src/libavcodec/cbs_misc.c:196: error: ‘A53UserData’ has no member named ‘atsc’
CC  libavcodec/dpxenc.o
CC  libavcodec/dpx_parser.o
make: *** [libavcodec/cbs_misc.o] Error 1
make: *** Waiting for unfinished jobs
src/libavcodec/dnxhddec.c:146: warning: ‘dnxhd_decode_init_thread_copy’ defined 
but not used
src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_init’:
src/libavcodec/dnxhdenc.c:518: warning: ‘coded_frame’ is deprecated (declared 
at src/libavcodec/avcodec.h:2760)
src/libavcodec/dnxhdenc.c:519: warning: ‘coded_frame’ is deprecated (declared 
at src/libavcodec/avcodec.h:2760)
src/libavcodec/dnxhdenc.c: In function ‘dnxhd_load_picture’:
src/libavcodec/dnxhdenc.c:1272: warning: ‘coded_frame’ is deprecated (declared 
at src/libavcodec/avcodec.h:2760)
src/libavcodec/dnxhdenc.c: In function ‘dnxhd_encode_picture’:
src/libavcodec/dnxhdenc.c:1337: warning: ‘coded_frame’ is deprecated (declared 
at src/libavcodec/avcodec.h:2760)
src/libavcodec/dpxenc.c: In function ‘encode_frame’:
src/libavcodec/dpxenc.c:180: warning: ‘need_align’ may be used uninitialized in 
this function
src/libavcodec/dpxenc.c:180: warning: ‘len’ may be used uninitialized in this 
function


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dcaenc: Use aac psychoacoustic model for dcaenc

[Даниил Чередник]

Now it should be fine. Second patch has been fixed.

On Mon, Mar 26, 2018 at 3:59 PM, Даниил Чередник 
wrote:

> Hi.
> Yes, I reproduced it on mac. A bit strange, I run fate with valgrind
> during patch preparation, it was ok.
> I will fix it, and send updated patch.
>
> Thank you!
>
> On Sun, Mar 25, 2018 at 5:57 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Sun, Mar 25, 2018 at 01:55:42PM +0300, Даниил Чередник wrote:
>> [...]
>>
>> >  libavcodec/dcaenc.c   |  369 --
>> 
>> >  libavcodec/psymodel.c |1
>> >  tests/fate/acodec.mak |4
>> >  3 files changed, 156 insertions(+), 218 deletions(-)
>> > fd146632a7f29530a59d35abd63149c81b4dfcc6
>> 0002-avcodec-dcaenc-Use-aac-psychoacoustic-model-for-DCA-.patch
>> > From 99d937a0828bbd60aef52d7979c75f8c21989145 Mon Sep 17 00:00:00 2001
>> > From: Daniil Cherednik 
>> > Date: Sun, 4 Mar 2018 13:14:17 +
>> > Subject: [PATCH 2/2] avcodec/dcaenc: Use aac psychoacoustic model for
>> DCA
>> >  encoder
>> >
>> > There are several reasons to replace dca psychoacoustic to common model:
>> >  - dca psychoacoustic has some quality problems especially at high
>> frequency bands
>> >  - unclear implementation
>> >  - aac implementation allows to use tonality measurement for future
>> improvements
>> >  - a bit faster
>>
>> This breaks
>> make -j12 fate-acodec-dca
>> (segfaults)
>>
>> tell me if you can reproduce? If not ill rebuild with debug symbols and
>> get a
>> backtrace
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> If you drop bombs on a foreign country and kill a hundred thousand
>> innocent people, expect your government to call the consequence
>> "unprovoked inhuman terrorist attacks" and use it to justify dropping
>> more bombs and killing more people. The technology changed, the idea is
>> old.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>
>
> --
> Daniil Cherednik
>



-- 
Daniil Cherednik


0001-avcodec-dcaenc-Use-planar-float-frame-format.patch
Description: Binary data


0002-avcodec-dcaenc-Use-aac-psychoacoustic-model-for-DCA-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/amfenc: Reference to input AVFrame (hwaccel) is retained during the encoding process

[Alexander Kravchenko]

Fixed issues of previous patch

---
 libavcodec/amfenc.c | 82 ++---
 1 file changed, 78 insertions(+), 4 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 89a10ff253..5f3440a9f3 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -443,6 +443,48 @@ int ff_amf_encode_init(AVCodecContext *avctx)
 return ret;
 }
 
+#define AMF_AV_QUERY_INTERFACE(res, from, InterfaceTypeTo, to) \
+{ \
+AMFGuid guid_##InterfaceTypeTo = IID_##InterfaceTypeTo(); \
+res = from->pVtbl->QueryInterface(from, _##InterfaceTypeTo, 
(void**)); \
+}
+
+#define AMF_AV_ASSIGN_PROPERTY_INTERFACE(res, pThis, name, val) \
+{ \
+AMFInterface *amf_interface; \
+AMFVariantStruct var; \
+res = AMFVariantInit(); \
+if (res != AMF_OK) \
+return res; \
+if (res == AMF_OK) { \
+AMF_AV_QUERY_INTERFACE(res, val, AMFInterface, amf_interface)\
+} \
+if (res == AMF_OK) { \
+res = AMFVariantAssignInterface(, amf_interface); \
+amf_interface->pVtbl->Release(amf_interface); \
+} \
+if (res == AMF_OK) { \
+res = pThis->pVtbl->SetProperty(pThis, name, var); \
+} \
+res = AMFVariantClear(); \
+}
+
+#define AMF_AV_GET_PROPERTY_INTERFACE(res, pThis, name, TargetType, val) \
+{ \
+AMFVariantStruct var; \
+res = AMFVariantInit(); \
+if (res != AMF_OK) \
+return res; \
+res = pThis->pVtbl->GetProperty(pThis, name, ); \
+if (res == AMF_OK) { \
+if (var.type == AMF_VARIANT_INTERFACE && 
AMFVariantInterface()) { \
+AMF_AV_QUERY_INTERFACE(res, AMFVariantInterface(), 
TargetType, val); \
+} else { \
+res = AMF_INVALID_DATA_TYPE; \
+} \
+} \
+AMFVariantClear(); \
+}
 
 int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame)
 {
@@ -484,6 +526,8 @@ int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame 
*frame)
 (ctx->hw_device_ctx && 
((AVHWFramesContext*)frame->hw_frames_ctx->data)->device_ctx ==
 (AVHWDeviceContext*)ctx->hw_device_ctx->data)
 )) {
+AVFrame *frame_ref;
+AMFBuffer *frame_ref_storage_buffer;
 #if CONFIG_D3D11VA
 static const GUID AMFTextureArrayIndexGUID = { 0x28115527, 0xe7c3, 
0x4b66, { 0x99, 0xd3, 0x4f, 0x2a, 0xe6, 0xb4, 0x7f, 0xaf } };
 ID3D11Texture2D *texture = (ID3D11Texture2D*)frame->data[0]; // 
actual texture
@@ -496,6 +540,21 @@ int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame 
*frame)
 // input HW surfaces can be vertically aligned by 16; tell AMF the 
real size
 surface->pVtbl->SetCrop(surface, 0, 0, frame->width, 
frame->height);
 #endif
+res = ctx->context->pVtbl->AllocBuffer(ctx->context, 
AMF_MEMORY_HOST, sizeof(frame_ref), _ref_storage_buffer);
+AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR(ENOMEM), 
"AllocBuffer() failed  with error %d\n", res);
+frame_ref = av_frame_clone(frame);
+AMF_RETURN_IF_FALSE(ctx, frame_ref != NULL, AVERROR(ENOMEM), 
"av_frame_clone() returned NULL\n");
+
memcpy(frame_ref_storage_buffer->pVtbl->GetNative(frame_ref_storage_buffer), 
_ref, sizeof(frame_ref));
+AMF_AV_ASSIGN_PROPERTY_INTERFACE(res, surface, L"av_frame_ref", 
frame_ref_storage_buffer);
+if (res != AMF_OK)
+{
+av_frame_free(_ref);
+surface->pVtbl->Release(surface);
+av_log(avctx, AV_LOG_WARNING, "failed to attach av_frame_ref 
to surface\n");
+return AVERROR(ENOMEM);
+}
+frame_ref_storage_buffer->pVtbl->Release(frame_ref_storage_buffer);
+AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR(ENOMEM), 
"SetProperty failed for \"frame_ref\" with error %d\n", res);
 } else {
 res = ctx->context->pVtbl->AllocSurface(ctx->context, 
AMF_MEMORY_HOST, ctx->format, avctx->width, avctx->height, );
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR(ENOMEM), 
"AllocSurface() failed  with error %d\n", res);
@@ -554,12 +613,27 @@ int ff_amf_receive_packet(AVCodecContext *avctx, AVPacket 
*avpkt)
 res_query = ctx->encoder->pVtbl->QueryOutput(ctx->encoder, );
 if (data) {
 // copy data to packet
-AMFBuffer* buffer;
-AMFGuid guid = IID_AMFBuffer();
-data->pVtbl->QueryInterface(data, , (void**)); // 
query for buffer interface
+AMFBuffer *buffer;
+AMF_AV_QUERY_INTERFACE(res, data, AMFBuffer, buffer);
+AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "Invalid 
data type from encoder->QueryOutput, should be AMFBuffer, error %d\n", res);
 ret = amf_copy_buffer(avctx, avpkt, buffer);
-
 

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Reference to input AVFrame (hwaccel) is retained during the encoding process

[Kravchenko, Alexander]

>
> Put email comments on a patch below the "---" line (otherwise they end up in 
> the commit message when applied).
>
Sorry, I am not sure I understand you correctly here


> > +#define AMF_AV_GET_PROPERTY_INTERFACE(res, pThis, name, TargetType, val) \
> > +{ \
> > +AMFVariantStruct var; \
> > +res = AMFVariantInit(); \
> > +if (res != AMF_OK) \
> > +return res; \
> > +res = pThis->pVtbl->GetProperty(pThis, name, ); \
> > +if (res == AMF_OK) { \
> > +if (var.type == AMF_VARIANT_INTERFACE && 
> > AMFVariantInterface()) { \
> > +AMF_AV_QUERY_INTERFACE(res, AMFVariantInterface(), 
> > TargetType, val); \
> > +} else { \
> > +res = AMF_INVALID_DATA_TYPE; \
> > +} \
> > +} \
> > +AMFVariantClear(); \
> > +}
>
> These look even more like they should be functions rather than macros now?  
> In particular, the returns in them interact badly with the
> code below.

I'd also prefer function here, but it works with different types (TargetType 
parameter is type name)
I am going to discuss propose such macros to AMF headers near future.


> > +if (res != AMF_OK)
> > +{
>
> { on the previous line.
>
> > +av_log(avctx, AV_LOG_WARNING, "failed to attach 
> > av_frame_ref to surface\n");
>
> And keep going anyway, corrupting the output?
>
Ok, agree, I will return error here



Thanks,
Alexander



This e-mail and any attachment(s) are intended only for the recipient(s) named 
above and others who have been specifically authorized to receive them. They 
may contain confidential information. If you are not the intended recipient, 
please do not read this email or its attachment(s). Furthermore, you are hereby 
notified that any dissemination, distribution or copying of this e-mail and any 
attachment(s) is strictly prohibited. If you have received this e-mail in 
error, please immediately notify the sender by replying to this e-mail and then 
delete this e-mail and any attachment(s) or copies thereof from your system. 
Thank you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2] ffmpeg_filter: enable stream_loop in HWAccel transcoding.

[Mark Thompson]

On 26/03/18 02:25, Jun Zhao wrote:
> V2: simplified the logic as Michael's review.
> 
> From 6c332c65d64977c4d6220acfb7e9db3505281f87 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Wed, 14 Mar 2018 16:13:39 +0800
> Subject: [PATCH V2] ffmpeg_filter: enable stream_loop in HWAccel transcoding.
> 
> use the cmd: ffmpeg -y -stream_loop 1 -hwaccel vaapi -hwaccel_device
> /dev/dri/renderD128 -hwaccel_output_format vaapi -i
> input.mp4 -c:v h264_vaapi output.mp4 can get the error like:
> 
> Error while decoding stream #0:1: Invalid data found when processing
> input
> Impossible to convert between the formats supported by the filter
> 'Parsed_null_0' and the filter 'auto_scaler_0'
> Error reinitializing filters!
> Failed to inject frame into filter network: Function not implemented
> 
> the root cause is can't insert software scale filter in the hwaccel
> transcoding pipeline.
> 
> Signed-off-by: Jun Zhao 
> ---
>  fftools/ffmpeg_filter.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 877fd670e6..4e5d8fa24e 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -452,6 +452,7 @@ static int configure_output_video_filter(FilterGraph *fg, 
> OutputFilter *ofilter,
>  int pad_idx = out->pad_idx;
>  int ret;
>  char name[255];
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(ofilter->format);
>  
>  snprintf(name, sizeof(name), "out_%d_%d", ost->file_index, ost->index);
>  ret = avfilter_graph_create_filter(>filter,
> @@ -461,7 +462,8 @@ static int configure_output_video_filter(FilterGraph *fg, 
> OutputFilter *ofilter,
>  if (ret < 0)
>  return ret;
>  
> -if (ofilter->width || ofilter->height) {
> +if ((ofilter->width || ofilter->height) &&
> +(!desc || !(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))) {
>  char args[255];
>  AVFilterContext *filter;
>  AVDictionaryEntry *e = NULL;
> -- 
> 2.14.1
> 

This is doing something kindof subtle, in that this check was previously 
blocking changes to the hw_frames_ctx input to the encoder.  While that works 
in some cases, it is pretty clearly documented that it isn't allowed by the 
API.  Do all existing encoders work ok with that, such that the restriction 
might be relaxed?  It's not obvious to me that QSV will work at all (though I 
haven't actually checked), and others might do something nasty if any property 
changes because they don't currently expect it.

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[Michael Niedermayer]

On Mon, Mar 26, 2018 at 10:56:47PM +0100, Mark Thompson wrote:
> On 26/03/18 22:44, Michael Niedermayer wrote:
> > On Mon, Mar 26, 2018 at 08:34:06AM +0200, Paul B Mahol wrote:
> >> On 3/26/18, Michael Niedermayer  wrote:
> >>> On Wed, Mar 21, 2018 at 09:18:21AM +0100, Paul B Mahol wrote:
>  On 3/20/18, Michael Niedermayer  wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavfilter/vf_scale.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > index 9f45032e85..2f6fa4791d 100644
> > --- a/libavfilter/vf_scale.c
> > +++ b/libavfilter/vf_scale.c
> > @@ -407,6 +407,7 @@ static int filter_frame(AVFilterLink *link, AVFrame
> > *in)
> >  AVFilterLink *outlink = link->dst->outputs[0];
> >  AVFrame *out;
> >  const AVPixFmtDescriptor *desc =
> > av_pix_fmt_desc_get(link->format);
> > +const AVPixFmtDescriptor *out_desc =
> > av_pix_fmt_desc_get(outlink->format);
> >  char buf[32];
> >  int in_range;
> >
> > @@ -497,7 +498,11 @@ static int filter_frame(AVFilterLink *link,
> > AVFrame
> > *in)
> >   table, out_full,
> >   brightness, contrast,
> > saturation);
> >
> > -out->color_range = out_full ? AVCOL_RANGE_JPEG :
> > AVCOL_RANGE_MPEG;
> > +// color_range describes YUV, it is undefined for RGB
> > +if ((out_desc->flags & AV_PIX_FMT_FLAG_RGB) &&
> > out_desc->nb_components != 1) {
> > +out->color_range = AVCOL_RANGE_UNSPECIFIED;
> > +} else
> > +out->color_range = out_full ? AVCOL_RANGE_JPEG :
> > AVCOL_RANGE_MPEG;
> >  }
> >
> >  av_reduce(>sample_aspect_ratio.num,
> > >sample_aspect_ratio.den,
> > --
> > 2.16.2
> >
> 
>  This is not optimal, as full color_range should remain full when not
>  changed.
> >>>
> >>> there is no range for rgb formats. The range is specific to YUV based
> >>> formats.
> >>> Thats, if iam guessing correctly what you meant. You did not really say
> >>> which case you meant here. So maybe there is an issue and i misunderstand
> >>> what you refer to
> >>
> >> Maybe not for swscale here but does exist otherwise.
> > 
> > It has no meaning for RGB. There is no limited range RGB
> > also, the API defines it only for YUV. So if it had meaning for RGB its not 
> > defined
> > what meaning that would be. The ranges for luma and chroma differ so its not
> > natural or obvious how to extend it to RGB.
> > Iam also not aware of any specification that defines limited range RGB
> See HDMI, HD-SDI, CEA-861, pretty much anything related to sending RGB over 
> wires in a non-PC context.
> 
> (No comment on whether it is useful to include it, but dismissing limited 
> range RGB as not a thing is probably not a good idea.  I would kindof expect 
> things like DeckLink to be using limited-range RGB everywhere, but I'm not 
> familiar with the details there.)

interresting, i was unaware of this
are these specs publically available ? i could find CEA-861 but not the others
quickly

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_avgblur_opencl: fix error when clSetKernelArg fails

[Mark Thompson]

On 26/03/18 01:08, dylanf...@gmail.com wrote:
> From: drfer3 
> 
> Fixes Coverity CID 1430382
> ---
>  libavfilter/vf_avgblur_opencl.c | 6 ++
>  1 file changed, 6 insertions(+)

LGTM, applied this along with the image size one.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/1] libavfilter: Add OpenCL convolution filter v0.2

[Mark Thompson]

On 24/03/18 15:57, Danil Iashchenko wrote:
> Behaves like existing convolution filter.
> 
> Patch uses global kernel.
> 
> ---
>  configure   |   1 +
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/opencl/convolution.cl   |  42 
>  libavfilter/opencl_source.h |   1 +
>  libavfilter/vf_convolution_opencl.c | 368 
> 
>  6 files changed, 414 insertions(+)
>  create mode 100644 libavfilter/opencl/convolution.cl
>  create mode 100644 libavfilter/vf_convolution_opencl.c

I fixed some minor formatting issues locally (overlong lines), and applied.

(For future reference, look at the "-v" option to format-patch - that includes 
the patch version number inside the [PATCH] block in the title subject, where 
it won't leak into the commit message.)

Thanks!

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Reference to input AVFrame (hwaccel) is retained during the encoding process

[Mark Thompson]

On 26/03/18 11:41, Alexander Kravchenko wrote:

Put email comments on a patch below the "---" line (otherwise they end up in 
the commit message when applied).

> Hello,
> I have fixed issues listed in previous patch.
> 
> 
>> Say what the change is in the title.  Something like "amfenc: Retain a 
>> reference to D3D11 frames used as input during the encoding
>> process", maybe?
> Sure, but I am preparing next patch adding DX9 support, so probably better to 
> write D3D instead D3D11

Well, it currently means D3D11 only, unless you are posting a D3D9 patch ahead 
of it?  Doesn't really matter, though.

>>
>> How many frames can end up queued inside the encoder here?
> 16

So a transcode from a file with a lot of references will fall over without 
extra_hw_frames being set on the decoder?  That probably wants more 
documentation somewhere, but it shouldn't block this patch.

>>
>> Is there always an exact 1->1 correspondence between input frames and output 
>> packets?  That is, is it guaranteed that no frames are
>> ever dropped, even in the low-latency modes?
> yes

Ok, good.

>> Put the * in the right place - it's part of the declarator, not the 
>> declaration-specifiers.
>> "if (", and in all places below too.
> I have fixed these issues in whole file (Hopefully you don’t mind if it put 
> to same commit. There aren't many pf them)

I was meaning only in the code you are adding.  The others should be fixed, but 
it should be separate patch with no functional content (saying something like 
"fix cosmetic issues").

> 
> From: Alexander Kravchenko 
> ---
>  libavcodec/amfenc.c | 89 
> -
>  1 file changed, 81 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> index 89a10ff253..f532a32b7b 100644
> --- a/libavcodec/amfenc.c
> +++ b/libavcodec/amfenc.c
> @@ -188,7 +188,7 @@ static int amf_init_context(AVCodecContext *avctx)
>  return AVERROR(ENOMEM);
>  }
>  } else {
> -if(res == AMF_NOT_SUPPORTED)
> +if (res == AMF_NOT_SUPPORTED)
>  av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
> has D3D11 device which doesn't have D3D11VA interface, switching to 
> default\n");
>  else
>  av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
> has non-AMD device, switching to default\n");
> @@ -298,7 +298,7 @@ int av_cold ff_amf_encode_close(AVCodecContext *avctx)
>  }
>  
>  static int amf_copy_surface(AVCodecContext *avctx, const AVFrame *frame,
> -AMFSurface* surface)
> +AMFSurface *surface)
>  {
>  AVFrame*sw_frame = NULL;
>  AMFPlane   *plane = NULL;
> @@ -371,7 +371,7 @@ static int amf_copy_buffer(AVCodecContext *avctx, 
> AVPacket *pkt, AMFBuffer *buff
>  switch (avctx->codec->id) {
>  case AV_CODEC_ID_H264:
>  buffer->pVtbl->GetProperty(buffer, 
> AMF_VIDEO_ENCODER_OUTPUT_DATA_TYPE, );
> -if(var.int64Value == AMF_VIDEO_ENCODER_OUTPUT_DATA_TYPE_IDR) {
> +if (var.int64Value == AMF_VIDEO_ENCODER_OUTPUT_DATA_TYPE_IDR) {
>  pkt->flags = AV_PKT_FLAG_KEY;
>  }
>  break;
> @@ -443,6 +443,48 @@ int ff_amf_encode_init(AVCodecContext *avctx)
>  return ret;
>  }
>  
> +#define AMF_AV_QUERY_INTERFACE(res, from, InterfaceTypeTo, to) \
> +{ \
> +AMFGuid guid_##InterfaceTypeTo = IID_##InterfaceTypeTo(); \
> +res = from->pVtbl->QueryInterface(from, _##InterfaceTypeTo, 
> (void**)); \
> +}
> +
> +#define AMF_AV_ASSIGN_PROPERTY_INTERFACE(res, pThis, name, val) \
> +{ \
> +AMFInterface *amf_interface; \
> +AMFVariantStruct var; \
> +res = AMFVariantInit(); \
> +if (res != AMF_OK) \
> +return res; \
> +if (res == AMF_OK) { \
> +AMF_AV_QUERY_INTERFACE(res, val, AMFInterface, amf_interface)\
> +} \
> +if (res == AMF_OK) { \
> +res = AMFVariantAssignInterface(, amf_interface); \
> +amf_interface->pVtbl->Release(amf_interface); \
> +} \
> +if (res == AMF_OK) { \
> +res = pThis->pVtbl->SetProperty(pThis, name, var); \
> +} \
> +res = AMFVariantClear(); \
> +}
> +
> +#define AMF_AV_GET_PROPERTY_INTERFACE(res, pThis, name, TargetType, val) \
> +{ \
> +AMFVariantStruct var; \
> +res = AMFVariantInit(); \
> +if (res != AMF_OK) \
> +return res; \
> +res = pThis->pVtbl->GetProperty(pThis, name, ); \
> +if (res == AMF_OK) { \
> +if (var.type == AMF_VARIANT_INTERFACE && 
> AMFVariantInterface()) { \
> +AMF_AV_QUERY_INTERFACE(res, AMFVariantInterface(), 
> TargetType, val); \
> +} else { \
> +res = AMF_INVALID_DATA_TYPE; \
> +  

Re: [FFmpeg-devel] Moving enum AVFieldOrder to libavutil?

[Michael Niedermayer]

On Mon, Mar 26, 2018 at 11:48:01AM -0400, Devin Heitmueller wrote:
> Hello all,
> 
> > On Mar 24, 2018, at 6:37 AM, Michael Niedermayer  
> > wrote:
> > 
> > On Sat, Mar 24, 2018 at 01:07:48AM +0100, Marton Balint wrote:
> >> 
> >> 
> >> On Fri, 23 Mar 2018, Devin Heitmueller wrote:
> >> 
> >>> Hello,
> >>> 
> >>> I am in the process of reworking libavfilter to pass along the field order
> >>> across links.  For the moment I followed the model found in AVFrame where
> >>> there are two int fields: “interlaced_frame” and “top_field_first”.
> >>> However it seems like it would be more appropriate to use the enum
> >>> AVFieldOrder, which is a single field and provides more flexibility
> >>> (including being able to be set to “unknown” if appropriate).
> >>> 
> >>> Does anyone have an objection to moving the definition of AVFieldOrder to
> >>> libavutil, so it can be taken advantage of by libavfilter?  Right now it’s
> >>> in libavcodec, and from what I understand libavfilter does not depend on
> >>> libavcodec.
> >> 
> > 
> >> AVFieldOrder is already a mess, 
> > 
> > +1
> 
> Well, I really opened up a can of worms, eh?
> 
> As someone who used to work on Linux video capture drivers in a former life, 
> I can appreciate how confusing interlaced formats can be, perhaps even among 
> some of the ffmpeg developers.  It gets even worse when you have to deal with 
> the buffers delivered directly from embedded hardware such as SOCs, where the 
> formats can be even more esoteric than what you might find in various codecs 
> (most of which make at least some effort to normalize down to only a few 
> formats).
> 
> For what it’s worth, there were similar such debates years ago on what sort 
> of definitions are necessary to specify interlaced formats, and this is what 
> we arrived at (and have been using for many years):
> 
> https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/field-order.html 
> 
> 
> The enum values described on that page cover pretty much all the cases you 
> can come across, including buffers organized as interleaved versus separate 
> fields, etc.
> 
> The above page is nice because it has some pictures/diagrams which allow you 
> to visualize the actual differences between the different modes.  It also 
> gives a good summary of the differences between spatial ordering and temporal 
> ordering (which I suspect is a cause of much of the confusing).
> 
> My goal was to solve an immediate business problem - making sure that when 
> playing a 1080i H.264 or MPEG-2 video that the decklink output gets properly 
> configured to 1080i59.  The scope creep came in after I realized this data 
> had no means of being propagated through the filter framework.  Now it’s 
> being suggested that we would have to redesign the whole way AVFieldOrder is 
> done, presumably including some sort of backward compatibility with the 
> existing system and API deprecation path for what is already there.
> 
> I’m not confident I have the time required to achieve such a goal.  This 
> presents several options:
> 
> 1.  Do nothing.  I’ll maintain my patch out-of-tree and Decklink will 
> continue to make bad choices on setting the output format.
> 
> 2.  Somebody else create a replacement for AVFieldOrder, go through all the 
> rounds of feedback/debate, merge the functionality and fix all the various 
> codecs/demuxers/etc which would need to use the new framework.  I’m happy to 
> rework my patch to use such replacement, but given ffmpeg has gone for many 
> years with AVFieldOrder in the state it’s in, I’m not confident there are 
> many volunteers willing to take on such an endeavor.
> 
> 3.  Try to get some variant of my patch upstream which leverages either the 
> existing AVFieldOrder or the AVFrame approach (i.e. 
> interlaced_frame/top_field_first struct members), and continue to live with 
> the deficiencies in the API.  I don’t think this makes the situation any 
> worse, it lays the groundwork for propagating this data through pipelines 
> (which can be converted to use some other struct member at a later date), and 
> it solves all the use cases that I care about.
> 
> I’m happy to contribute where I can, but part of me feels like let’s not let 
> “perfect be the enemy of good”.

I would say, use the existing API or design a new/better one (which may be 
substantial work)
but first wait for others to have a chance to comment

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] kmsgrab: add category for kmsgrab

[Mark Thompson]

On 26/03/18 01:22, Jun Zhao wrote:
> 
> From fc9b04d95b1e21fa9985dc611fcf43d2a4c635c0 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 23 Mar 2018 21:32:03 +0800
> Subject: [PATCH] kmsgrab: add category for kmsgrab
> 
> add category for kmsgrab, then we can display kmsgrab in
> "ffmpeg -devices".
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavdevice/kmsgrab.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavdevice/kmsgrab.c b/libavdevice/kmsgrab.c
> index 6a6de09c37..d0de774871 100644
> --- a/libavdevice/kmsgrab.c
> +++ b/libavdevice/kmsgrab.c
> @@ -451,6 +451,7 @@ static const AVClass kmsgrab_class = {
>  .item_name  = av_default_item_name,
>  .option = options,
>  .version= LIBAVUTIL_VERSION_INT,
> +.category   = AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT,
>  };
>  
>  AVInputFormat ff_kmsgrab_demuxer = {
> -- 
> 2.14.1
> 

Sure, will apply soon.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] h264_metadata: Add support for A/53 closed captions

[Mark Thompson]

On 26/03/18 01:18, James Almer wrote:
> On 3/25/2018 2:41 PM, Mark Thompson wrote:
>> Allows insertion (from side data), extraction (to side data), and removal
>> of closed captions in SEI messages.
>> ---
>>  libavcodec/Makefile|   2 +-
>>  libavcodec/h264_metadata_bsf.c | 138 
>> +
>>  2 files changed, 139 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index aaef6c3ab8..cfde104055 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -1044,7 +1044,7 @@ OBJS-$(CONFIG_DCA_CORE_BSF)   += 
>> dca_core_bsf.o
>>  OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF)  += extract_extradata_bsf.o\
>>   h2645_parse.o
>>  OBJS-$(CONFIG_FILTER_UNITS_BSF)   += filter_units_bsf.o
>> -OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_metadata_bsf.o
>> +OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_metadata_bsf.o cbs_misc.o
>>  OBJS-$(CONFIG_H264_MP4TOANNEXB_BSF)   += h264_mp4toannexb_bsf.o
>>  OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) += h264_redundant_pps_bsf.o
>>  OBJS-$(CONFIG_HAPQA_EXTRACT_BSF)  += hapqa_extract_bsf.o hap.o
>> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
>> index 27053dbdcf..d79e6c0c87 100644
>> --- a/libavcodec/h264_metadata_bsf.c
>> +++ b/libavcodec/h264_metadata_bsf.c
>> @@ -24,6 +24,7 @@
>>  #include "bsf.h"
>>  #include "cbs.h"
>>  #include "cbs_h264.h"
>> +#include "cbs_misc.h"
>>  #include "h264.h"
>>  #include "h264_sei.h"
>>  
>> @@ -74,6 +75,8 @@ typedef struct H264MetadataContext {
>>  int display_orientation;
>>  double rotate;
>>  int flip;
>> +
>> +int a53_cc;
>>  } H264MetadataContext;
>>  
>>  
>> @@ -222,6 +225,8 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
>> AVPacket *out)
>>  int err, i, j, has_sps;
>>  uint8_t *displaymatrix_side_data = NULL;
>>  size_t displaymatrix_side_data_size = 0;
>> +uint8_t *a53_side_data = NULL;
>> +size_t a53_side_data_size = 0;
>>  
>>  err = ff_bsf_get_packet(bsf, );
>>  if (err < 0)
>> @@ -516,6 +521,116 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
>> AVPacket *out)
>>  }
>>  }
>>  
>> +if (ctx->a53_cc == INSERT) {
> 
> This function is becoming pretty big. Could you split it, either before
> or after this patch, for readability sake? One function per each
> AVOption with pass/insert/remove, basically.

Not very fun because they all interact to some degree (the easily-splittable 
SPS update is already a separate function).  I might look at this later.

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/5] h264_metadata: Add support for A/53 closed captions

[Mark Thompson]

On 26/03/18 14:33, Alex Giladi wrote:
> Is there any documentation on the side data file format?

The format for the side data is the existing one used in AV_PKT_DATA_A53_CC.

The documentation for that could probably be improved - basically it's just a 
sequence of the 3-byte CC data packets as defined by CEA-708.

> On Sun, Mar 25, 2018 at 6:18 PM, James Almer  wrote:
>> On 3/25/2018 2:41 PM, Mark Thompson wrote:
>>> Allows insertion (from side data), extraction (to side data), and removal
>>> of closed captions in SEI messages.
>>> ---
>>>  libavcodec/Makefile|   2 +-
>>>  libavcodec/h264_metadata_bsf.c | 138 ++
>> +++
>>>  2 files changed, 139 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>>> index aaef6c3ab8..cfde104055 100644
>>> --- a/libavcodec/Makefile
>>> +++ b/libavcodec/Makefile
>>> @@ -1044,7 +1044,7 @@ OBJS-$(CONFIG_DCA_CORE_BSF)   +=
>> dca_core_bsf.o
>>>  OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF)  += extract_extradata_bsf.o
>>   \
>>>   h2645_parse.o
>>>  OBJS-$(CONFIG_FILTER_UNITS_BSF)   += filter_units_bsf.o
>>> -OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_metadata_bsf.o
>>> +OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_metadata_bsf.o
>> cbs_misc.o
>>>  OBJS-$(CONFIG_H264_MP4TOANNEXB_BSF)   += h264_mp4toannexb_bsf.o
>>>  OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) += h264_redundant_pps_bsf.o
>>>  OBJS-$(CONFIG_HAPQA_EXTRACT_BSF)  += hapqa_extract_bsf.o hap.o
>>> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_
>> bsf.c
>>> index 27053dbdcf..d79e6c0c87 100644
>>> --- a/libavcodec/h264_metadata_bsf.c
>>> +++ b/libavcodec/h264_metadata_bsf.c
>>> @@ -24,6 +24,7 @@
>>>  #include "bsf.h"
>>>  #include "cbs.h"
>>>  #include "cbs_h264.h"
>>> +#include "cbs_misc.h"
>>>  #include "h264.h"
>>>  #include "h264_sei.h"
>>>
>>> @@ -74,6 +75,8 @@ typedef struct H264MetadataContext {
>>>  int display_orientation;
>>>  double rotate;
>>>  int flip;
>>> +
>>> +int a53_cc;
>>>  } H264MetadataContext;
>>>
>>>
>>> @@ -222,6 +225,8 @@ static int h264_metadata_filter(AVBSFContext *bsf,
>> AVPacket *out)
>>>  int err, i, j, has_sps;
>>>  uint8_t *displaymatrix_side_data = NULL;
>>>  size_t displaymatrix_side_data_size = 0;
>>> +uint8_t *a53_side_data = NULL;
>>> +size_t a53_side_data_size = 0;
>>>
>>>  err = ff_bsf_get_packet(bsf, );
>>>  if (err < 0)
>>> @@ -516,6 +521,116 @@ static int h264_metadata_filter(AVBSFContext
>> *bsf, AVPacket *out)
>>>  }
>>>  }
>>>
>>> +if (ctx->a53_cc == INSERT) {
>>
>> This function is becoming pretty big. Could you split it, either before
>> or after this patch, for readability sake? One function per each
>> AVOption with pass/insert/remove, basically.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[Mark Thompson]

On 26/03/18 22:44, Michael Niedermayer wrote:
> On Mon, Mar 26, 2018 at 08:34:06AM +0200, Paul B Mahol wrote:
>> On 3/26/18, Michael Niedermayer  wrote:
>>> On Wed, Mar 21, 2018 at 09:18:21AM +0100, Paul B Mahol wrote:
 On 3/20/18, Michael Niedermayer  wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/vf_scale.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index 9f45032e85..2f6fa4791d 100644
> --- a/libavfilter/vf_scale.c
> +++ b/libavfilter/vf_scale.c
> @@ -407,6 +407,7 @@ static int filter_frame(AVFilterLink *link, AVFrame
> *in)
>  AVFilterLink *outlink = link->dst->outputs[0];
>  AVFrame *out;
>  const AVPixFmtDescriptor *desc =
> av_pix_fmt_desc_get(link->format);
> +const AVPixFmtDescriptor *out_desc =
> av_pix_fmt_desc_get(outlink->format);
>  char buf[32];
>  int in_range;
>
> @@ -497,7 +498,11 @@ static int filter_frame(AVFilterLink *link,
> AVFrame
> *in)
>   table, out_full,
>   brightness, contrast,
> saturation);
>
> -out->color_range = out_full ? AVCOL_RANGE_JPEG :
> AVCOL_RANGE_MPEG;
> +// color_range describes YUV, it is undefined for RGB
> +if ((out_desc->flags & AV_PIX_FMT_FLAG_RGB) &&
> out_desc->nb_components != 1) {
> +out->color_range = AVCOL_RANGE_UNSPECIFIED;
> +} else
> +out->color_range = out_full ? AVCOL_RANGE_JPEG :
> AVCOL_RANGE_MPEG;
>  }
>
>  av_reduce(>sample_aspect_ratio.num,
> >sample_aspect_ratio.den,
> --
> 2.16.2
>

 This is not optimal, as full color_range should remain full when not
 changed.
>>>
>>> there is no range for rgb formats. The range is specific to YUV based
>>> formats.
>>> Thats, if iam guessing correctly what you meant. You did not really say
>>> which case you meant here. So maybe there is an issue and i misunderstand
>>> what you refer to
>>
>> Maybe not for swscale here but does exist otherwise.
> 
> It has no meaning for RGB. There is no limited range RGB
> also, the API defines it only for YUV. So if it had meaning for RGB its not 
> defined
> what meaning that would be. The ranges for luma and chroma differ so its not
> natural or obvious how to extend it to RGB.
> Iam also not aware of any specification that defines limited range RGB
See HDMI, HD-SDI, CEA-861, pretty much anything related to sending RGB over 
wires in a non-PC context.

(No comment on whether it is useful to include it, but dismissing limited range 
RGB as not a thing is probably not a good idea.  I would kindof expect things 
like DeckLink to be using limited-range RGB everywhere, but I'm not familiar 
with the details there.)

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Reference to input AVFrame (hwaccel) is retained during the encoding process

[James Almer]

On 3/26/2018 7:41 AM, Alexander Kravchenko wrote:
> Hello,
> I have fixed issues listed in previous patch.
> 
> 
>> Say what the change is in the title.  Something like "amfenc: Retain a 
>> reference to D3D11 frames used as input during the encoding
>> process", maybe?
> Sure, but I am preparing next patch adding DX9 support, so probably better to 
> write D3D instead D3D11
> 
>>
>> How many frames can end up queued inside the encoder here?
> 16
> 
>>
>> Is there always an exact 1->1 correspondence between input frames and output 
>> packets?  That is, is it guaranteed that no frames are
>> ever dropped, even in the low-latency modes?
> yes
> 
>> Put the * in the right place - it's part of the declarator, not the 
>> declaration-specifiers.
>> "if (", and in all places below too.
> I have fixed these issues in whole file (Hopefully you don’t mind if it put 
> to same commit. There aren't many pf them)

Usually no, cosmetic changes on existing code go in their own separate
commits.

Also, if this is fixing the issue described in
https://trac.ffmpeg.org/ticket/6990 then please add a "Fixes ticket
#6990" to the commit message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: Reference to input AVFrame (hwaccel) is retained during the encoding process

[Michael Niedermayer]

On Mon, Mar 26, 2018 at 01:41:20PM +0300, Alexander Kravchenko wrote:
> Hello,
> I have fixed issues listed in previous patch.
> 
> 
> > Say what the change is in the title.  Something like "amfenc: Retain a 
> > reference to D3D11 frames used as input during the encoding
> > process", maybe?
> Sure, but I am preparing next patch adding DX9 support, so probably better to 
> write D3D instead D3D11
> 
> > 
> > How many frames can end up queued inside the encoder here?
> 16
> 
> > 
> > Is there always an exact 1->1 correspondence between input frames and 
> > output packets?  That is, is it guaranteed that no frames are
> > ever dropped, even in the low-latency modes?
> yes
> 
> > Put the * in the right place - it's part of the declarator, not the 
> > declaration-specifiers.
> > "if (", and in all places below too.
> I have fixed these issues in whole file (Hopefully you don’t mind if it put 
> to same commit. There aren't many pf them)
> 
> 

> From: Alexander Kravchenko 
> ---
>  libavcodec/amfenc.c | 89 
> -
>  1 file changed, 81 insertions(+), 8 deletions(-)
> 
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> index 89a10ff253..f532a32b7b 100644
> --- a/libavcodec/amfenc.c
> +++ b/libavcodec/amfenc.c
> @@ -188,7 +188,7 @@ static int amf_init_context(AVCodecContext *avctx)
>  return AVERROR(ENOMEM);
>  }
>  } else {
> -if(res == AMF_NOT_SUPPORTED)
> +if (res == AMF_NOT_SUPPORTED)
>  av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
> has D3D11 device which doesn't have D3D11VA interface, switching to 
> default\n");
>  else
>  av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
> has non-AMD device, switching to default\n");
> @@ -298,7 +298,7 @@ int av_cold ff_amf_encode_close(AVCodecContext *avctx)
>  }
>  
>  static int amf_copy_surface(AVCodecContext *avctx, const AVFrame *frame,
> -AMFSurface* surface)
> +AMFSurface *surface)
>  {
>  AVFrame*sw_frame = NULL;
>  AMFPlane   *plane = NULL;

These changes are unrelated and should not be in this patch


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[Michael Niedermayer]

On Mon, Mar 26, 2018 at 12:50:41PM +0200, Paul B Mahol wrote:
> On 3/26/18, Martin Vignali  wrote:
> >> >> This is not optimal, as full color_range should remain full when not
> >> >> changed.
> >> >
> >> > there is no range for rgb formats. The range is specific to YUV based
> >> > formats.
> >> > Thats, if iam guessing correctly what you meant. You did not really say
> >> > which case you meant here. So maybe there is an issue and i
> >> > misunderstand
> >> > what you refer to
> >>
> >> Maybe not for swscale here but does exist otherwise.
> >>
> >> What software use limited for rgb ?
> >
> > I understand for gray (it can be gray of yuv data (limited or full) or gray
> > for RGB data)),
> > but for RGB/RGBA, never see limited (and doesn't see the interest :-)
> >
> > Martin
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 

> OK then, just apply patch.

ok, will apply

thanks!

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[Michael Niedermayer]

On Mon, Mar 26, 2018 at 08:34:06AM +0200, Paul B Mahol wrote:
> On 3/26/18, Michael Niedermayer  wrote:
> > On Wed, Mar 21, 2018 at 09:18:21AM +0100, Paul B Mahol wrote:
> >> On 3/20/18, Michael Niedermayer  wrote:
> >> > Signed-off-by: Michael Niedermayer 
> >> > ---
> >> >  libavfilter/vf_scale.c | 7 ++-
> >> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> >> > index 9f45032e85..2f6fa4791d 100644
> >> > --- a/libavfilter/vf_scale.c
> >> > +++ b/libavfilter/vf_scale.c
> >> > @@ -407,6 +407,7 @@ static int filter_frame(AVFilterLink *link, AVFrame
> >> > *in)
> >> >  AVFilterLink *outlink = link->dst->outputs[0];
> >> >  AVFrame *out;
> >> >  const AVPixFmtDescriptor *desc =
> >> > av_pix_fmt_desc_get(link->format);
> >> > +const AVPixFmtDescriptor *out_desc =
> >> > av_pix_fmt_desc_get(outlink->format);
> >> >  char buf[32];
> >> >  int in_range;
> >> >
> >> > @@ -497,7 +498,11 @@ static int filter_frame(AVFilterLink *link,
> >> > AVFrame
> >> > *in)
> >> >   table, out_full,
> >> >   brightness, contrast,
> >> > saturation);
> >> >
> >> > -out->color_range = out_full ? AVCOL_RANGE_JPEG :
> >> > AVCOL_RANGE_MPEG;
> >> > +// color_range describes YUV, it is undefined for RGB
> >> > +if ((out_desc->flags & AV_PIX_FMT_FLAG_RGB) &&
> >> > out_desc->nb_components != 1) {
> >> > +out->color_range = AVCOL_RANGE_UNSPECIFIED;
> >> > +} else
> >> > +out->color_range = out_full ? AVCOL_RANGE_JPEG :
> >> > AVCOL_RANGE_MPEG;
> >> >  }
> >> >
> >> >  av_reduce(>sample_aspect_ratio.num,
> >> > >sample_aspect_ratio.den,
> >> > --
> >> > 2.16.2
> >> >
> >> > ___
> >> > ffmpeg-devel mailing list
> >> > ffmpeg-devel@ffmpeg.org
> >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >
> >>
> >> This is not optimal, as full color_range should remain full when not
> >> changed.
> >
> > there is no range for rgb formats. The range is specific to YUV based
> > formats.
> > Thats, if iam guessing correctly what you meant. You did not really say
> > which case you meant here. So maybe there is an issue and i misunderstand
> > what you refer to
> 
> Maybe not for swscale here but does exist otherwise.

It has no meaning for RGB. There is no limited range RGB
also, the API defines it only for YUV. So if it had meaning for RGB its not 
defined
what meaning that would be. The ranges for luma and chroma differ so its not
natural or obvious how to extend it to RGB.
Iam also not aware of any specification that defines limited range RGB

also please be a little more verbose about what you speak of. That should
speed up resolving this

/**
 * MPEG vs JPEG YUV range.
 */
enum AVColorRange {
AVCOL_RANGE_UNSPECIFIED = 0,
AVCOL_RANGE_MPEG= 1, ///< the normal 219*2^(n-8) "MPEG" YUV ranges
AVCOL_RANGE_JPEG= 2, ///< the normal 2^n-1   "JPEG" YUV ranges
AVCOL_RANGE_NB   ///< Not part of ABI


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] doc/examples/hw_decode: Remove logically dead code in decode_write()

[Michael Niedermayer]

On Mon, Mar 26, 2018 at 08:15:49AM +0800, Jun Zhao wrote:
> 
> 
> On 2018/3/26 2:21, Michael Niedermayer wrote:
> > Fixes CID1415951
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  doc/examples/hw_decode.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/doc/examples/hw_decode.c b/doc/examples/hw_decode.c
> > index 74a0ca32db..77ae8df35b 100644
> > --- a/doc/examples/hw_decode.c
> > +++ b/doc/examples/hw_decode.c
> > @@ -86,7 +86,7 @@ static int decode_write(AVCodecContext *avctx, AVPacket 
> > *packet)
> >  return ret;
> >  }
> >  
> > -while (ret >= 0) {
> > +while (1) {
> >  if (!(frame = av_frame_alloc()) || !(sw_frame = av_frame_alloc())) 
> > {
> >  fprintf(stderr, "Can not alloc frame\n");
> >  ret = AVERROR(ENOMEM);
> > @@ -142,8 +142,6 @@ static int decode_write(AVCodecContext *avctx, AVPacket 
> > *packet)
> >  if (ret < 0)
> >  return ret;
> >  }
> > -
> > -return 0;
> >  }
> >  
> >  int main(int argc, char *argv[])
> LGTM both patches

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [DEMO][PATCH] avcodec/eac3: add support for dependent stream

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---

Need proper channel mapping support.

 libavcodec/aac_ac3_parser.c |  7 ++--
 libavcodec/aac_ac3_parser.h |  2 ++
 libavcodec/ac3_parser.c | 29 +--
 libavcodec/ac3dec.c | 88 ++---
 libavcodec/ac3dec.h |  8 +++--
 libavcodec/eac3dec.c| 10 ++
 6 files changed, 101 insertions(+), 43 deletions(-)

diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
index 4e834b4424..6f8d4b3b78 100644
--- a/libavcodec/aac_ac3_parser.c
+++ b/libavcodec/aac_ac3_parser.c
@@ -24,6 +24,7 @@
 #include "libavutil/common.h"
 #include "parser.h"
 #include "aac_ac3_parser.h"
+#include "ac3.h"
 
 int ff_aac_ac3_parse(AVCodecParserContext *s1,
  AVCodecContext *avctx,
@@ -86,8 +87,10 @@ get_next:
the frame). */
 if (avctx->codec_id != AV_CODEC_ID_AAC) {
 avctx->sample_rate = s->sample_rate;
-avctx->channels = s->channels;
-avctx->channel_layout = s->channel_layout;
+if (avctx->codec_id != AV_CODEC_ID_EAC3 || s->frame_type != 
EAC3_FRAME_TYPE_DEPENDENT) {
+avctx->channels = s->channels;
+avctx->channel_layout = s->channel_layout;
+}
 s1->duration = s->samples;
 avctx->audio_service_type = s->service_type;
 }
diff --git a/libavcodec/aac_ac3_parser.h b/libavcodec/aac_ac3_parser.h
index c2506a5bfd..445ce0b9b2 100644
--- a/libavcodec/aac_ac3_parser.h
+++ b/libavcodec/aac_ac3_parser.h
@@ -44,6 +44,7 @@ typedef struct AACAC3ParseContext {
 int (*sync)(uint64_t state, struct AACAC3ParseContext *hdr_info,
 int *need_next_header, int *new_frame_start);
 
+int frame_type;
 int channels;
 int sample_rate;
 int bit_rate;
@@ -54,6 +55,7 @@ typedef struct AACAC3ParseContext {
 int remaining_size;
 uint64_t state;
 
+int queued_headers;
 int need_next_header;
 enum AVCodecID codec_id;
 } AACAC3ParseContext;
diff --git a/libavcodec/ac3_parser.c b/libavcodec/ac3_parser.c
index 1015245a90..694b38c3b1 100644
--- a/libavcodec/ac3_parser.c
+++ b/libavcodec/ac3_parser.c
@@ -53,10 +53,12 @@ static const uint8_t surround_levels[4] = { 4, 6, 7, 6 };
 
 int ff_ac3_parse_header(GetBitContext *gbc, AC3HeaderInfo *hdr)
 {
-int frame_size_code;
+int frame_size_code, i;
 
 memset(hdr, 0, sizeof(*hdr));
 
+hdr->channel_map = -1;
+
 hdr->sync_word = get_bits(gbc, 16);
 if(hdr->sync_word != 0x0B77)
 return AAC_AC3_PARSE_ERROR_SYNC;
@@ -109,6 +111,8 @@ int ff_ac3_parse_header(GetBitContext *gbc, AC3HeaderInfo 
*hdr)
 hdr->frame_type = EAC3_FRAME_TYPE_AC3_CONVERT; 
//EAC3_FRAME_TYPE_INDEPENDENT;
 hdr->substreamid = 0;
 } else {
+int skipped_bits = 0;
+
 /* Enhanced AC-3 */
 hdr->crc1 = 0;
 hdr->frame_type = get_bits(gbc, 2);
@@ -140,6 +144,27 @@ int ff_ac3_parse_header(GetBitContext *gbc, AC3HeaderInfo 
*hdr)
 hdr->bit_rate = 8LL * hdr->frame_size * hdr->sample_rate /
 (hdr->num_blocks * 256);
 hdr->channels = ff_ac3_channels_tab[hdr->channel_mode] + hdr->lfe_on;
+
+skip_bits(gbc, 5);
+skipped_bits += 5;
+for (i = 0; i < (hdr->channel_mode ? 1 : 2); i++) {
+skip_bits(gbc, 5);
+skipped_bits += 6;
+if (get_bits1(gbc)) {
+skip_bits(gbc, 8);
+skipped_bits += 8;
+}
+}
+
+if (hdr->frame_type == EAC3_FRAME_TYPE_DEPENDENT) {
+skipped_bits += 1;
+if (get_bits1(gbc)) {
+hdr->channel_map = get_bits(gbc, 16);
+skipped_bits += 16;
+}
+}
+
+skip_bits_long(gbc, -skipped_bits);
 }
 hdr->channel_layout = avpriv_ac3_channel_layout_tab[hdr->channel_mode];
 if (hdr->lfe_on)
@@ -218,8 +243,8 @@ static int ac3_sync(uint64_t state, AACAC3ParseContext 
*hdr_info,
 else if (hdr_info->codec_id == AV_CODEC_ID_NONE)
 hdr_info->codec_id = AV_CODEC_ID_AC3;
 
-*need_next_header = (hdr.frame_type != EAC3_FRAME_TYPE_AC3_CONVERT);
 *new_frame_start  = (hdr.frame_type != EAC3_FRAME_TYPE_DEPENDENT);
+*need_next_header = *new_frame_start || (hdr.frame_type != 
EAC3_FRAME_TYPE_AC3_CONVERT);
 return hdr.frame_size;
 }
 
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 244a18323f..58db1c5045 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -309,6 +309,7 @@ static int parse_frame_header(AC3DecodeContext *s)
 s->bitstream_id = hdr.bitstream_id;
 s->bitstream_mode   = hdr.bitstream_mode;
 s->channel_mode = hdr.channel_mode;
+s->channel_map  = hdr.channel_map;
 s->lfe_on   = hdr.lfe_on;
 s->bit_alloc_params.sr_shift= hdr.sr_shift;
 s->sample_rate  

[FFmpeg-devel] [GSoC] proposal idea: Color Constancy using Machine Learning

[Mina]

Hi,

  I'm proposing a Color Constancy filter as a project idea for GSoC and 
was asking for any remarks about that idea.


  Color constancy is the ability of the human visual system that 
ensures the perception of the color of objects to remain relatively 
constant under varying illumination conditions. A color constancy filter 
would basically be applied on images with various degrees of damage to 
restore original colors as close as possible.


This  is a simple example of a low-statistics 
filter output I've implemented as an academic project along with the 
original damaged image. The filter is an implementation of a 
mathematical equation presented with some parameters that's used to 
introduce variations to the filter.


  Use cases: despite being an end-result filter that helps retrieving 
damaged images original colors it's very helpful as a pre-processing 
utility for many computer vision algorithms. A simple example would be a 
classifier that identifies an object utilizing its color.


Implementation: this is still a research filed where last paper I've 
read was out earlier this year and still more and more papers are being 
published introducing various learning-methods to improve accuracy 
including unsupervised and supervised methods and even new 
learning-based algorithms to improve low-statistics light-computational 
ones. Variations of this filter and their accuracies will also prove to 
be a very appropriate project for GSoC since there is many factors 
affecting the choice of filter such as real-time need, filed of 
application, available dataset, ..etc. So, it's more like a group of 
filters.


  Impact: introduction of machine learning to this filed is quiet 
recent so enhancing FFmpeg with this technology and possibly adding to 
it will prove entrepreneurship. Photography, Computer Vision and many 
other fields that performs fine image processing would make good use of 
this filter.


Best regards,
Mina Sami.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/segafilm - fix keyframe detection and set packet, flags

[James Almer]

On 3/26/2018 3:27 PM, Gyan Doshi wrote:
> On 3/24/2018 7:39 AM, Michael Niedermayer wrote:
>> On Thu, Mar 22, 2018 at 11:04:21PM +0530, Gyan Doshi wrote:
> 
>>>
>>> Fixes #7091
>>> ---
>>>   libavformat/segafilm.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> should be ok
> 
> 
> Ping for push. There's a pending patch by another user blocked by this one.
> 
> Thanks,
> Gyan

Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/segafilm - fix keyframe detection and set packet, flags

[Gyan Doshi]

On 3/24/2018 7:39 AM, Michael Niedermayer wrote:

On Thu, Mar 22, 2018 at 11:04:21PM +0530, Gyan Doshi wrote:




Fixes #7091
---
  libavformat/segafilm.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)


should be ok



Ping for push. There's a pending patch by another user blocked by this one.

Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 5/5] avformat/mp3enc: use AVPacketList helper functions to queue packets

[James Almer]

Simplifies code.

Signed-off-by: James Almer 
---
 libavformat/mp3enc.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index 8479e2485b..78e231fbfd 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -369,20 +369,18 @@ static int mp3_write_audio_packet(AVFormatContext *s, 
AVPacket *pkt)
 static int mp3_queue_flush(AVFormatContext *s)
 {
 MP3Context *mp3 = s->priv_data;
-AVPacketList *pktl;
+AVPacket pkt;
 int ret = 0, write = 1;
 
 ff_id3v2_finish(>id3, s->pb, s->metadata_header_padding);
 mp3_write_xing(s);
 
-while ((pktl = mp3->queue)) {
-if (write && (ret = mp3_write_audio_packet(s, >pkt)) < 0)
+while (mp3->queue) {
+ff_packet_list_get(>queue, >queue_end, );
+if (write && (ret = mp3_write_audio_packet(s, )) < 0)
 write = 0;
-av_packet_unref(>pkt);
-mp3->queue = pktl->next;
-av_freep();
+av_packet_unref();
 }
-mp3->queue_end = NULL;
 return ret;
 }
 
@@ -514,21 +512,14 @@ static int mp3_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (pkt->stream_index == mp3->audio_stream_idx) {
 if (mp3->pics_to_write) {
 /* buffer audio packets until we get all the pictures */
-AVPacketList *pktl = av_mallocz(sizeof(*pktl));
+int ret = ff_packet_list_put(>queue, >queue_end, pkt, 1);
 
-if (!pktl || av_packet_ref(>pkt, pkt) < 0) {
-av_freep();
+if (ret < 0) {
 av_log(s, AV_LOG_WARNING, "Not enough memory to buffer audio. 
Skipping picture streams\n");
 mp3->pics_to_write = 0;
 mp3_queue_flush(s);
 return mp3_write_audio_packet(s, pkt);
 }
-
-if (mp3->queue_end)
-mp3->queue_end->next = pktl;
-else
-mp3->queue = pktl;
-mp3->queue_end = pktl;
 } else
 return mp3_write_audio_packet(s, pkt);
 } else {
-- 
2.16.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/5] avformat/ttaenc: use AVPacketList helper functions to queue packets

[James Almer]

Simplifies code.

Signed-off-by: James Almer 
---
 libavformat/ttaenc.c | 27 +++
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/libavformat/ttaenc.c b/libavformat/ttaenc.c
index add15873d0..8a8b565871 100644
--- a/libavformat/ttaenc.c
+++ b/libavformat/ttaenc.c
@@ -91,22 +91,12 @@ static int tta_write_header(AVFormatContext *s)
 static int tta_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 TTAMuxContext *tta = s->priv_data;
-AVPacketList *pktl = av_mallocz(sizeof(*pktl));
 int ret;
 
-if (!pktl)
-return AVERROR(ENOMEM);
-
-ret = av_packet_ref(>pkt, pkt);
+ret = ff_packet_list_put(>queue, >queue_end, pkt, 1);
 if (ret < 0) {
-av_free(pktl);
 return ret;
 }
-if (tta->queue_end)
-tta->queue_end->next = pktl;
-else
-tta->queue = pktl;
-tta->queue_end = pktl;
 
 avio_wl32(tta->seek_table, pkt->size);
 tta->nb_samples += pkt->duration;
@@ -131,16 +121,13 @@ static int tta_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 static void tta_queue_flush(AVFormatContext *s)
 {
 TTAMuxContext *tta = s->priv_data;
-AVPacketList *pktl;
-
-while (pktl = tta->queue) {
-AVPacket *pkt = >pkt;
-avio_write(s->pb, pkt->data, pkt->size);
-av_packet_unref(pkt);
-tta->queue = pktl->next;
-av_free(pktl);
+AVPacket pkt;
+
+while (tta->queue) {
+ff_packet_list_get(>queue, >queue_end, );
+avio_write(s->pb, pkt.data, pkt.size);
+av_packet_unref();
 }
-tta->queue_end = NULL;
 }
 
 static int tta_write_trailer(AVFormatContext *s)
-- 
2.16.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/5] avformat/utils: optimize ff_packet_list_free()

[James Almer]

Don't contantly overwrite the list's head pointer.

Signed-off-by: James Almer 
---
 libavformat/utils.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index cb1ea5b386..9faffa03a3 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1416,12 +1416,15 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 void ff_packet_list_free(AVPacketList **pkt_buf, AVPacketList **pkt_buf_end)
 {
-while (*pkt_buf) {
-AVPacketList *pktl = *pkt_buf;
-*pkt_buf = pktl->next;
+AVPacketList *tmp = *pkt_buf;
+
+while (tmp) {
+AVPacketList *pktl = tmp;
+tmp = pktl->next;
 av_packet_unref(>pkt);
 av_freep();
 }
+*pkt_buf = NULL;
 *pkt_buf_end = NULL;
 }
 
-- 
2.16.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/5] avformat/matroskadec: use AVPacketList to queue packets

[James Almer]

It's more robust and efficient.

Signed-off-by: James Almer 
---
 libavformat/matroskadec.c | 62 ++-
 1 file changed, 23 insertions(+), 39 deletions(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 2faaf9dfb8..3e5b537ac4 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -338,9 +338,8 @@ typedef struct MatroskaDemuxContext {
 int64_t segment_start;
 
 /* the packet queue */
-AVPacket **packets;
-int num_packets;
-AVPacket *prev_pkt;
+AVPacketList *queue;
+AVPacketList *queue_end;
 
 int done;
 
@@ -2722,11 +2721,11 @@ fail:
 static int matroska_deliver_packet(MatroskaDemuxContext *matroska,
AVPacket *pkt)
 {
-if (matroska->num_packets > 0) {
+if (matroska->queue) {
 MatroskaTrack *tracks = matroska->tracks.elem;
 MatroskaTrack *track;
-memcpy(pkt, matroska->packets[0], sizeof(AVPacket));
-av_freep(>packets[0]);
+
+ff_packet_list_get(>queue, >queue_end, pkt);
 track = [pkt->stream_index];
 if (track->has_palette) {
 uint8_t *pal = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE, 
AVPALETTE_SIZE);
@@ -2737,20 +2736,6 @@ static int matroska_deliver_packet(MatroskaDemuxContext 
*matroska,
 }
 track->has_palette = 0;
 }
-if (matroska->num_packets > 1) {
-void *newpackets;
-memmove(>packets[0], >packets[1],
-(matroska->num_packets - 1) * sizeof(AVPacket *));
-newpackets = av_realloc(matroska->packets,
-(matroska->num_packets - 1) *
-sizeof(AVPacket *));
-if (newpackets)
-matroska->packets = newpackets;
-} else {
-av_freep(>packets);
-matroska->prev_pkt = NULL;
-}
-matroska->num_packets--;
 return 0;
 }
 
@@ -2762,16 +2747,7 @@ static int matroska_deliver_packet(MatroskaDemuxContext 
*matroska,
  */
 static void matroska_clear_queue(MatroskaDemuxContext *matroska)
 {
-matroska->prev_pkt = NULL;
-if (matroska->packets) {
-int n;
-for (n = 0; n < matroska->num_packets; n++) {
-av_packet_unref(matroska->packets[n]);
-av_freep(>packets[n]);
-}
-av_freep(>packets);
-matroska->num_packets = 0;
-}
+ff_packet_list_free(>queue, >queue_end);
 }
 
 static int matroska_parse_laces(MatroskaDemuxContext *matroska, uint8_t **buf,
@@ -2953,7 +2929,11 @@ static int matroska_parse_rm_audio(MatroskaDemuxContext 
*matroska,
 track->audio.buf_timecode = AV_NOPTS_VALUE;
 pkt->pos  = pos;
 pkt->stream_index = st->index;
-dynarray_add(>packets, >num_packets, pkt);
+ret = ff_packet_list_put(>queue, >queue_end, pkt, 
0);
+if (ret < 0) {
+av_packet_free();
+return AVERROR(ENOMEM);
+}
 }
 
 return 0;
@@ -3152,8 +3132,11 @@ static int matroska_parse_webvtt(MatroskaDemuxContext 
*matroska,
 pkt->duration = duration;
 pkt->pos = pos;
 
-dynarray_add(>packets, >num_packets, pkt);
-matroska->prev_pkt = pkt;
+err = ff_packet_list_put(>queue, >queue_end, pkt, 0);
+if (err < 0) {
+av_packet_free();
+return AVERROR(ENOMEM);
+}
 
 return 0;
 }
@@ -3268,8 +3251,11 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
-dynarray_add(>packets, >num_packets, pkt);
-matroska->prev_pkt = pkt;
+res = ff_packet_list_put(>queue, >queue_end, pkt, 0);
+if (res < 0) {
+av_packet_free();
+return AVERROR(ENOMEM);
+}
 
 return 0;
 
@@ -3433,7 +3419,6 @@ static int 
matroska_parse_cluster_incremental(MatroskaDemuxContext *matroska)
 memset(>current_cluster, 0, sizeof(MatroskaCluster));
 matroska->current_cluster_num_blocks = 0;
 matroska->current_cluster_pos= avio_tell(matroska->ctx->pb);
-matroska->prev_pkt   = NULL;
 /* sizeof the ID which was already read */
 if (matroska->current_id)
 matroska->current_cluster_pos -= 4;
@@ -3486,7 +3471,6 @@ static int matroska_parse_cluster(MatroskaDemuxContext 
*matroska)
 if (!matroska->contains_ssa)
 return matroska_parse_cluster_incremental(matroska);
 pos = avio_tell(matroska->ctx->pb);
-matroska->prev_pkt = NULL;
 if (matroska->current_id)
 pos -= 4;  /* sizeof the ID which was already read */
 res = ebml_parse(matroska, matroska_clusters, );
@@ -3671,10 +3655,10 @@ static int 
webm_clusters_start_with_keyframe(AVFormatContext *s)
 matroska->current_id = 0;
 matroska_clear_queue(matroska);
 if (matroska_parse_cluster(matroska) < 0 ||
-matroska->num_packets <= 

[FFmpeg-devel] [PATCH 1/5] avformat/utils: make AVPacketList helper functions shared

[James Almer]

Based on a patch by Luca Barbato.

Signed-off-by: James Almer 
---
 libavformat/internal.h | 35 ++
 libavformat/utils.c| 51 +++---
 2 files changed, 63 insertions(+), 23 deletions(-)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index a020b1b417..7e1b24ebe6 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -731,6 +731,41 @@ int ff_unlock_avformat(void);
  */
 void ff_format_set_url(AVFormatContext *s, char *url);
 
+/**
+ * Append an AVPacket to the list.
+ *
+ * @param head List head
+ * @param tail List tail
+ * @param pkt  The packet being appended
+ * @param ref  Create a new reference for the packet instead of
+   transferring the ownership of the existing one to the
+ * list.
+ * @return < 0 on failure and 0 on success
+ */
+int ff_packet_list_put(AVPacketList **head, AVPacketList **tail,
+   AVPacket *pkt, int ref);
+
+/**
+ * Remove the oldest AVPacket in the list and return it.
+ *
+ * @note The pkt will be overwritten completely. The caller owns the
+ *   packet and must unref it by itself.
+ *
+ * @param head List head.
+ * @param tail List tail.
+ * @param pkt  Pointer to an initialized AVPacket struct
+ */
+int ff_packet_list_get(AVPacketList **head, AVPacketList **tail,
+   AVPacket *pkt);
+
+/**
+ * Wipe the list and unref all the packets in it.
+ *
+ * @param head List head.
+ * @param tail List tail
+ */
+void ff_packet_list_free(AVPacketList **head, AVPacketList **tail);
+
 #if FF_API_NEXT
 /**
   * Register devices in deprecated format linked list.
diff --git a/libavformat/utils.c b/libavformat/utils.c
index f13c8208b1..cb1ea5b386 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -444,8 +444,9 @@ static int init_input(AVFormatContext *s, const char 
*filename,
  s, 0, s->format_probesize);
 }
 
-static int add_to_pktbuf(AVPacketList **packet_buffer, AVPacket *pkt,
- AVPacketList **plast_pktl, int ref)
+int ff_packet_list_put(AVPacketList **packet_buffer,
+   AVPacketList **plast_pktl,
+   AVPacket  *pkt, int ref)
 {
 AVPacketList *pktl = av_mallocz(sizeof(AVPacketList));
 int ret;
@@ -485,9 +486,9 @@ int avformat_queue_attached_pictures(AVFormatContext *s)
 continue;
 }
 
-ret = add_to_pktbuf(>internal->raw_packet_buffer,
->streams[i]->attached_pic,
->internal->raw_packet_buffer_end, 1);
+ret = ff_packet_list_put(>internal->raw_packet_buffer,
+ >internal->raw_packet_buffer_end,
+ >streams[i]->attached_pic, 1);
 if (ret < 0)
 return ret;
 }
@@ -913,8 +914,9 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
 if (!pktl && st->request_probe <= 0)
 return ret;
 
-err = add_to_pktbuf(>internal->raw_packet_buffer, pkt,
->internal->raw_packet_buffer_end, 0);
+err = ff_packet_list_put(>internal->raw_packet_buffer,
+ >internal->raw_packet_buffer_end,
+ pkt, 0);
 if (err)
 return err;
 s->internal->raw_packet_buffer_remaining_size -= pkt->size;
@@ -1412,7 +1414,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 }
 
-static void free_packet_buffer(AVPacketList **pkt_buf, AVPacketList 
**pkt_buf_end)
+void ff_packet_list_free(AVPacketList **pkt_buf, AVPacketList **pkt_buf_end)
 {
 while (*pkt_buf) {
 AVPacketList *pktl = *pkt_buf;
@@ -1504,8 +1506,9 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt, int stream_index)
 
 compute_pkt_fields(s, st, st->parser, _pkt, next_dts, next_pts);
 
-ret = add_to_pktbuf(>internal->parse_queue, _pkt,
->internal->parse_queue_end, 1);
+ret = ff_packet_list_put(>internal->parse_queue,
+ >internal->parse_queue_end,
+ _pkt, 1);
 av_packet_unref(_pkt);
 if (ret < 0)
 goto fail;
@@ -1522,9 +1525,9 @@ fail:
 return ret;
 }
 
-static int read_from_packet_buffer(AVPacketList **pkt_buffer,
-   AVPacketList **pkt_buffer_end,
-   AVPacket  *pkt)
+int ff_packet_list_get(AVPacketList **pkt_buffer,
+   AVPacketList **pkt_buffer_end,
+   AVPacket  *pkt)
 {
 AVPacketList *pktl;
 av_assert0(*pkt_buffer);
@@ -1670,7 +1673,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 
 if (!got_packet && s->internal->parse_queue)
-ret = read_from_packet_buffer(>internal->parse_queue, 
>internal->parse_queue_end, 

Re: [FFmpeg-devel] Moving enum AVFieldOrder to libavutil?

[Devin Heitmueller]

Hello all,

> On Mar 24, 2018, at 6:37 AM, Michael Niedermayer  
> wrote:
> 
> On Sat, Mar 24, 2018 at 01:07:48AM +0100, Marton Balint wrote:
>> 
>> 
>> On Fri, 23 Mar 2018, Devin Heitmueller wrote:
>> 
>>> Hello,
>>> 
>>> I am in the process of reworking libavfilter to pass along the field order
>>> across links.  For the moment I followed the model found in AVFrame where
>>> there are two int fields: “interlaced_frame” and “top_field_first”.
>>> However it seems like it would be more appropriate to use the enum
>>> AVFieldOrder, which is a single field and provides more flexibility
>>> (including being able to be set to “unknown” if appropriate).
>>> 
>>> Does anyone have an objection to moving the definition of AVFieldOrder to
>>> libavutil, so it can be taken advantage of by libavfilter?  Right now it’s
>>> in libavcodec, and from what I understand libavfilter does not depend on
>>> libavcodec.
>> 
> 
>> AVFieldOrder is already a mess, 
> 
> +1

Well, I really opened up a can of worms, eh?

As someone who used to work on Linux video capture drivers in a former life, I 
can appreciate how confusing interlaced formats can be, perhaps even among some 
of the ffmpeg developers.  It gets even worse when you have to deal with the 
buffers delivered directly from embedded hardware such as SOCs, where the 
formats can be even more esoteric than what you might find in various codecs 
(most of which make at least some effort to normalize down to only a few 
formats).

For what it’s worth, there were similar such debates years ago on what sort of 
definitions are necessary to specify interlaced formats, and this is what we 
arrived at (and have been using for many years):

https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/field-order.html 


The enum values described on that page cover pretty much all the cases you can 
come across, including buffers organized as interleaved versus separate fields, 
etc.

The above page is nice because it has some pictures/diagrams which allow you to 
visualize the actual differences between the different modes.  It also gives a 
good summary of the differences between spatial ordering and temporal ordering 
(which I suspect is a cause of much of the confusing).

My goal was to solve an immediate business problem - making sure that when 
playing a 1080i H.264 or MPEG-2 video that the decklink output gets properly 
configured to 1080i59.  The scope creep came in after I realized this data had 
no means of being propagated through the filter framework.  Now it’s being 
suggested that we would have to redesign the whole way AVFieldOrder is done, 
presumably including some sort of backward compatibility with the existing 
system and API deprecation path for what is already there.

I’m not confident I have the time required to achieve such a goal.  This 
presents several options:

1.  Do nothing.  I’ll maintain my patch out-of-tree and Decklink will continue 
to make bad choices on setting the output format.

2.  Somebody else create a replacement for AVFieldOrder, go through all the 
rounds of feedback/debate, merge the functionality and fix all the various 
codecs/demuxers/etc which would need to use the new framework.  I’m happy to 
rework my patch to use such replacement, but given ffmpeg has gone for many 
years with AVFieldOrder in the state it’s in, I’m not confident there are many 
volunteers willing to take on such an endeavor.

3.  Try to get some variant of my patch upstream which leverages either the 
existing AVFieldOrder or the AVFrame approach (i.e. 
interlaced_frame/top_field_first struct members), and continue to live with the 
deficiencies in the API.  I don’t think this makes the situation any worse, it 
lays the groundwork for propagating this data through pipelines (which can be 
converted to use some other struct member at a later date), and it solves all 
the use cases that I care about.

I’m happy to contribute where I can, but part of me feels like let’s not let 
“perfect be the enemy of good”.

Devin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/1] re: Add Sega FILM muxer

[misty]

From: Misty De Meo 

I reviewed the contributing guide one more time, and noticed I'd missed two
items from the new muxer list. Updated the patch with:

* Marked Sega FILM as having a muxer in general.texi
* Bumped the minor version of libavformat

Misty De Meo (1):
  Add Sega FILM muxer

 Changelog |   1 +
 doc/general.texi  |   2 +-
 libavformat/Makefile  |   1 +
 libavformat/allformats.c  |   1 +
 libavformat/segafilmenc.c | 377 ++
 libavformat/version.h |   2 +-
 6 files changed, 382 insertions(+), 2 deletions(-)
 create mode 100644 libavformat/segafilmenc.c

-- 
2.16.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/1] Add Sega FILM muxer

[misty]

From: Misty De Meo 

---
 Changelog |   1 +
 doc/general.texi  |   2 +-
 libavformat/Makefile  |   1 +
 libavformat/allformats.c  |   1 +
 libavformat/segafilmenc.c | 377 ++
 libavformat/version.h |   2 +-
 6 files changed, 382 insertions(+), 2 deletions(-)
 create mode 100644 libavformat/segafilmenc.c

diff --git a/Changelog b/Changelog
index 30a8978db4..0ff62ff69d 100644
--- a/Changelog
+++ b/Changelog
@@ -48,6 +48,7 @@ version :
 - drmeter audio filter
 - hapqa_extract bitstream filter
 - filter_units bitstream filter
+- segafilm muxer
 
 
 version 3.4:
diff --git a/doc/general.texi b/doc/general.texi
index c5d46d3404..b5b7695bd4 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -551,7 +551,7 @@ library:
 @item SAP   @tab X @tab X
 @item SBG   @tab   @tab X
 @item SDP   @tab   @tab X
-@item Sega FILM/CPK @tab   @tab X
+@item Sega FILM/CPK @tab X @tab X
 @tab Used in many Sega Saturn console games.
 @item Silicon Graphics Movie@tab   @tab X
 @item Sierra SOL@tab   @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 39ec68c28b..4abb992b14 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -462,6 +462,7 @@ OBJS-$(CONFIG_SDR2_DEMUXER)  += sdr2.o
 OBJS-$(CONFIG_SDS_DEMUXER)   += sdsdec.o
 OBJS-$(CONFIG_SDX_DEMUXER)   += sdxdec.o
 OBJS-$(CONFIG_SEGAFILM_DEMUXER)  += segafilm.o
+OBJS-$(CONFIG_SEGAFILM_MUXER)+= segafilmenc.o
 OBJS-$(CONFIG_SEGMENT_MUXER) += segment.o
 OBJS-$(CONFIG_SHORTEN_DEMUXER)   += shortendec.o rawdec.o
 OBJS-$(CONFIG_SIFF_DEMUXER)  += siff.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 9dc5ce8a76..dfd964f07a 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -364,6 +364,7 @@ extern AVInputFormat  ff_sdr2_demuxer;
 extern AVInputFormat  ff_sds_demuxer;
 extern AVInputFormat  ff_sdx_demuxer;
 extern AVInputFormat  ff_segafilm_demuxer;
+extern AVOutputFormat ff_segafilm_muxer;
 extern AVOutputFormat ff_segment_muxer;
 extern AVOutputFormat ff_stream_segment_muxer;
 extern AVInputFormat  ff_shorten_demuxer;
diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
new file mode 100644
index 00..453eb7d6ba
--- /dev/null
+++ b/libavformat/segafilmenc.c
@@ -0,0 +1,377 @@
+/*
+ * Sega FILM Format (CPK) Muxer
+ * Copyright (C) 2003 The FFmpeg project
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Sega FILM (.cpk) file muxer
+ * @author Misty De Meo 
+ *
+ * @see For more information regarding the Sega FILM file format, visit:
+ *   http://wiki.multimedia.cx/index.php?title=Sega_FILM
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "avformat.h"
+#include "internal.h"
+#include "avio_internal.h"
+
+typedef struct FILMPacket {
+int audio;
+int keyframe;
+int32_t pts;
+int32_t duration;
+int32_t size;
+int32_t index;
+struct FILMPacket *next;
+} FILMPacket;
+
+typedef struct FILMOutputContext {
+const AVClass *class;
+int audio_index;
+int video_index;
+int64_t stab_pos;
+FILMPacket *start;
+FILMPacket *last;
+int64_t packet_count;
+} FILMOutputContext;
+
+static int film_write_packet_to_header(AVFormatContext *format_context, 
FILMPacket *pkt)
+{
+AVIOContext *pb = format_context->pb;
+// The bits in these two 32-bit integers contain info about the contents 
of this sample
+int32_t info1 = 0;
+int32_t info2 = 0;
+
+if (pkt->audio) {
+// Always the same, carries no more information than "this is audio"
+info1 = 0x;
+info2 = 1;
+} else {
+info1 = pkt->pts;
+info2 = pkt->duration;
+// The top bit being set indicates a key frame
+if (pkt->keyframe)
+info1 |= (1 << 31);
+}
+
+// Write the 16-byte sample info packet to the STAB chunk in the header
+avio_wb32(pb, pkt->index);
+avio_wb32(pb, pkt->size);
+avio_wb32(pb, info1);
+avio_wb32(pb, info2);
+
+return 0;
+}
+
+static int 

Re: [FFmpeg-devel] [PATCH 2/5] h264_metadata: Add support for A/53 closed captions

[Alex Giladi]

Is there any documentation on the side data file format?

On Sun, Mar 25, 2018 at 6:18 PM, James Almer  wrote:

> On 3/25/2018 2:41 PM, Mark Thompson wrote:
> > Allows insertion (from side data), extraction (to side data), and removal
> > of closed captions in SEI messages.
> > ---
> >  libavcodec/Makefile|   2 +-
> >  libavcodec/h264_metadata_bsf.c | 138 ++
> +++
> >  2 files changed, 139 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index aaef6c3ab8..cfde104055 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -1044,7 +1044,7 @@ OBJS-$(CONFIG_DCA_CORE_BSF)   +=
> dca_core_bsf.o
> >  OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF)  += extract_extradata_bsf.o
>   \
> >   h2645_parse.o
> >  OBJS-$(CONFIG_FILTER_UNITS_BSF)   += filter_units_bsf.o
> > -OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_metadata_bsf.o
> > +OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_metadata_bsf.o
> cbs_misc.o
> >  OBJS-$(CONFIG_H264_MP4TOANNEXB_BSF)   += h264_mp4toannexb_bsf.o
> >  OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) += h264_redundant_pps_bsf.o
> >  OBJS-$(CONFIG_HAPQA_EXTRACT_BSF)  += hapqa_extract_bsf.o hap.o
> > diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_
> bsf.c
> > index 27053dbdcf..d79e6c0c87 100644
> > --- a/libavcodec/h264_metadata_bsf.c
> > +++ b/libavcodec/h264_metadata_bsf.c
> > @@ -24,6 +24,7 @@
> >  #include "bsf.h"
> >  #include "cbs.h"
> >  #include "cbs_h264.h"
> > +#include "cbs_misc.h"
> >  #include "h264.h"
> >  #include "h264_sei.h"
> >
> > @@ -74,6 +75,8 @@ typedef struct H264MetadataContext {
> >  int display_orientation;
> >  double rotate;
> >  int flip;
> > +
> > +int a53_cc;
> >  } H264MetadataContext;
> >
> >
> > @@ -222,6 +225,8 @@ static int h264_metadata_filter(AVBSFContext *bsf,
> AVPacket *out)
> >  int err, i, j, has_sps;
> >  uint8_t *displaymatrix_side_data = NULL;
> >  size_t displaymatrix_side_data_size = 0;
> > +uint8_t *a53_side_data = NULL;
> > +size_t a53_side_data_size = 0;
> >
> >  err = ff_bsf_get_packet(bsf, );
> >  if (err < 0)
> > @@ -516,6 +521,116 @@ static int h264_metadata_filter(AVBSFContext
> *bsf, AVPacket *out)
> >  }
> >  }
> >
> > +if (ctx->a53_cc == INSERT) {
>
> This function is becoming pretty big. Could you split it, either before
> or after this patch, for readability sake? One function per each
> AVOption with pass/insert/remove, basically.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: Add OpenCL avgblur filter

[Dylan Fernando]

On Fri, Mar 23, 2018 at 9:10 PM, Carl Eugen Hoyos 
wrote:

> 2018-03-21 14:09 GMT+01:00, Dylan Fernando :
>
> > What information should I put in my GSoC application? How should I
> > structure it? Should I give a rough timeline detailing exactly which
> color
> > conversion and scaling algorithms I’ll be implementing? If so, which
> files
> > should I look at to see the current colour conversion code?
>
> Two blogposts that are meant to help you:
> https://medium.com/@owtf/google-summer-of-code-writing-
> a-good-proposal-141b1376f076
> http://mirca.fun/gsoc-application/
>
> But please remember that in this project, the qualification task
> is more important than the form of the application.
> You of course absolutely have to finish an application, without
> it you cannot be chosen as student.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Thanks,

I have the project timeline part of my application below. Feel free to
comment any suggestions:

Proposal
Video filtering with OpenCL

Currently, FFmpeg has good support for offloading decoding and encoding
from the CPU, but not such good support for doing anything else with that
video without using the CPU. There is interop support for mapping between
APIs so that generic methods like OpenCL which can be run on any GPU can be
used together with specific video APIs for decoding and encoding, but
currently there are only a few operations which can actually use this so
many use-cases require expensive additional steps to download frames from
the GPU and then upload them again later after performing some processing
on the CPU. Therefore, we would like to add more OpenCL filter support to
libavfilter so that more operations can be offloaded. This includes
implementing a scaler, supporting a choice of scaling algorithms, a
deinterlacer and color conversion.

Timeline
I have a report due for uni in June. This should only take a day or two.
Other than that, I have no commitments. All tasks below include writing
documentation.

Week 1-2:
Implement OpenCL deinterlacer based on yadif

Week 3-6:
Implement OpenCL YUV-to-YUV color conversion based on vf_colorspace

Week 7-9:
Implement OpenCL rgb colorspace conversion

Week 10-14:
Implement scaling algorithms with OpenCL including bilinear, bicubic, and
averaging area
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/dcaenc: Use aac psychoacoustic model for dcaenc

[Даниил Чередник]

Hi.
Yes, I reproduced it on mac. A bit strange, I run fate with valgrind during
patch preparation, it was ok.
I will fix it, and send updated patch.

Thank you!

On Sun, Mar 25, 2018 at 5:57 PM, Michael Niedermayer  wrote:

> On Sun, Mar 25, 2018 at 01:55:42PM +0300, Даниил Чередник wrote:
> [...]
>
> >  libavcodec/dcaenc.c   |  369 --
> 
> >  libavcodec/psymodel.c |1
> >  tests/fate/acodec.mak |4
> >  3 files changed, 156 insertions(+), 218 deletions(-)
> > fd146632a7f29530a59d35abd63149c81b4dfcc6  0002-avcodec-dcaenc-Use-aac-
> psychoacoustic-model-for-DCA-.patch
> > From 99d937a0828bbd60aef52d7979c75f8c21989145 Mon Sep 17 00:00:00 2001
> > From: Daniil Cherednik 
> > Date: Sun, 4 Mar 2018 13:14:17 +
> > Subject: [PATCH 2/2] avcodec/dcaenc: Use aac psychoacoustic model for DCA
> >  encoder
> >
> > There are several reasons to replace dca psychoacoustic to common model:
> >  - dca psychoacoustic has some quality problems especially at high
> frequency bands
> >  - unclear implementation
> >  - aac implementation allows to use tonality measurement for future
> improvements
> >  - a bit faster
>
> This breaks
> make -j12 fate-acodec-dca
> (segfaults)
>
> tell me if you can reproduce? If not ill rebuild with debug symbols and
> get a
> backtrace
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If you drop bombs on a foreign country and kill a hundred thousand
> innocent people, expect your government to call the consequence
> "unprovoked inhuman terrorist attacks" and use it to justify dropping
> more bombs and killing more people. The technology changed, the idea is
> old.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>


-- 
Daniil Cherednik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: initialize saveptrs

[Liu Steven]

> 在 2018年3月26日，上午11:49，Jeyapal, Karthick  写道：
> 
> 
> 
> On 3/25/18 1:43 PM, Timo Rothenpieler wrote:
>> Am 21.03.2018 um 20:37 schrieb Timo Rothenpieler:
>>> Am 21.03.2018 um 20:33 schrieb Timo Rothenpieler:
 av_strtok calls strspn on a non-NULL *saveptr, so not NULL 
 initializing it is an issue.
 
 Fixes CID #1428568
 ---
  libavformat/hlsenc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
 index b7c6fbde6a..fa17776efe 100644
 --- a/libavformat/hlsenc.c
 +++ b/libavformat/hlsenc.c
 @@ -1873,7 +1873,8 @@ static int 
 parse_cc_stream_mapstring(AVFormatContext *s)
  {
  HLSContext *hls = s->priv_data;
  int nb_ccstreams;
 -char *p, *q, *saveptr1, *saveptr2, *ccstr, *keyval;
 +char *p, *q, *ccstr, *keyval;
 +char *saveptr1 = NULL, *saveptr2 = NULL;
  const char *val;
  ClosedCaptionsStream *ccs;
>>> 
>>> Just realized, the more correct approach is probably to check the 
>>> av_strdup below this for ENOMEM. Not sure about the exact semantics 
>>> there, initializing these still seems like a good safety measure.
>>> 
> I agree with you that checking the return value of av_strdup for NULL is a 
> better approach.
> But I am fine with this initialization fix as well.

Pushed


Thanks
Steven

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[Paul B Mahol]

On 3/26/18, Martin Vignali  wrote:
>> >> This is not optimal, as full color_range should remain full when not
>> >> changed.
>> >
>> > there is no range for rgb formats. The range is specific to YUV based
>> > formats.
>> > Thats, if iam guessing correctly what you meant. You did not really say
>> > which case you meant here. So maybe there is an issue and i
>> > misunderstand
>> > what you refer to
>>
>> Maybe not for swscale here but does exist otherwise.
>>
>> What software use limited for rgb ?
>
> I understand for gray (it can be gray of yuv data (limited or full) or gray
> for RGB data)),
> but for RGB/RGBA, never see limited (and doesn't see the interest :-)
>
> Martin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

OK then, just apply patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/amfenc: Reference to input AVFrame (hwaccel) is retained during the encoding process

[Alexander Kravchenko]

Hello,
I have fixed issues listed in previous patch.


> Say what the change is in the title.  Something like "amfenc: Retain a 
> reference to D3D11 frames used as input during the encoding
> process", maybe?
Sure, but I am preparing next patch adding DX9 support, so probably better to 
write D3D instead D3D11

> 
> How many frames can end up queued inside the encoder here?
16

> 
> Is there always an exact 1->1 correspondence between input frames and output 
> packets?  That is, is it guaranteed that no frames are
> ever dropped, even in the low-latency modes?
yes

> Put the * in the right place - it's part of the declarator, not the 
> declaration-specifiers.
> "if (", and in all places below too.
I have fixed these issues in whole file (Hopefully you don’t mind if it put to 
same commit. There aren't many pf them)


From: Alexander Kravchenko 
---
 libavcodec/amfenc.c | 89 -
 1 file changed, 81 insertions(+), 8 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 89a10ff253..f532a32b7b 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -188,7 +188,7 @@ static int amf_init_context(AVCodecContext *avctx)
 return AVERROR(ENOMEM);
 }
 } else {
-if(res == AMF_NOT_SUPPORTED)
+if (res == AMF_NOT_SUPPORTED)
 av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
has D3D11 device which doesn't have D3D11VA interface, switching to default\n");
 else
 av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
has non-AMD device, switching to default\n");
@@ -298,7 +298,7 @@ int av_cold ff_amf_encode_close(AVCodecContext *avctx)
 }
 
 static int amf_copy_surface(AVCodecContext *avctx, const AVFrame *frame,
-AMFSurface* surface)
+AMFSurface *surface)
 {
 AVFrame*sw_frame = NULL;
 AMFPlane   *plane = NULL;
@@ -371,7 +371,7 @@ static int amf_copy_buffer(AVCodecContext *avctx, AVPacket 
*pkt, AMFBuffer *buff
 switch (avctx->codec->id) {
 case AV_CODEC_ID_H264:
 buffer->pVtbl->GetProperty(buffer, 
AMF_VIDEO_ENCODER_OUTPUT_DATA_TYPE, );
-if(var.int64Value == AMF_VIDEO_ENCODER_OUTPUT_DATA_TYPE_IDR) {
+if (var.int64Value == AMF_VIDEO_ENCODER_OUTPUT_DATA_TYPE_IDR) {
 pkt->flags = AV_PKT_FLAG_KEY;
 }
 break;
@@ -443,6 +443,48 @@ int ff_amf_encode_init(AVCodecContext *avctx)
 return ret;
 }
 
+#define AMF_AV_QUERY_INTERFACE(res, from, InterfaceTypeTo, to) \
+{ \
+AMFGuid guid_##InterfaceTypeTo = IID_##InterfaceTypeTo(); \
+res = from->pVtbl->QueryInterface(from, _##InterfaceTypeTo, 
(void**)); \
+}
+
+#define AMF_AV_ASSIGN_PROPERTY_INTERFACE(res, pThis, name, val) \
+{ \
+AMFInterface *amf_interface; \
+AMFVariantStruct var; \
+res = AMFVariantInit(); \
+if (res != AMF_OK) \
+return res; \
+if (res == AMF_OK) { \
+AMF_AV_QUERY_INTERFACE(res, val, AMFInterface, amf_interface)\
+} \
+if (res == AMF_OK) { \
+res = AMFVariantAssignInterface(, amf_interface); \
+amf_interface->pVtbl->Release(amf_interface); \
+} \
+if (res == AMF_OK) { \
+res = pThis->pVtbl->SetProperty(pThis, name, var); \
+} \
+res = AMFVariantClear(); \
+}
+
+#define AMF_AV_GET_PROPERTY_INTERFACE(res, pThis, name, TargetType, val) \
+{ \
+AMFVariantStruct var; \
+res = AMFVariantInit(); \
+if (res != AMF_OK) \
+return res; \
+res = pThis->pVtbl->GetProperty(pThis, name, ); \
+if (res == AMF_OK) { \
+if (var.type == AMF_VARIANT_INTERFACE && 
AMFVariantInterface()) { \
+AMF_AV_QUERY_INTERFACE(res, AMFVariantInterface(), 
TargetType, val); \
+} else { \
+res = AMF_INVALID_DATA_TYPE; \
+} \
+} \
+AMFVariantClear(); \
+}
 
 int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame *frame)
 {
@@ -458,7 +500,7 @@ int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame 
*frame)
 if (!ctx->eof) { // submit drain one time only
 if (ctx->delayed_surface != NULL) {
 ctx->delayed_drain = 1; // input queue is full: resubmit 
Drain() in ff_amf_receive_packet
-} else if(!ctx->delayed_drain) {
+} else if (!ctx->delayed_drain) {
 res = ctx->encoder->pVtbl->Drain(ctx->encoder);
 if (res == AMF_INPUT_FULL) {
 ctx->delayed_drain = 1; // input queue is full: resubmit 
Drain() in ff_amf_receive_packet
@@ -484,6 +526,8 @@ int ff_amf_send_frame(AVCodecContext *avctx, const AVFrame 
*frame)
 (ctx->hw_device_ctx && 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[Martin Vignali]

> >> This is not optimal, as full color_range should remain full when not
> >> changed.
> >
> > there is no range for rgb formats. The range is specific to YUV based
> > formats.
> > Thats, if iam guessing correctly what you meant. You did not really say
> > which case you meant here. So maybe there is an issue and i misunderstand
> > what you refer to
>
> Maybe not for swscale here but does exist otherwise.
>
> What software use limited for rgb ?

I understand for gray (it can be gray of yuv data (limited or full) or gray
for RGB data)),
but for RGB/RGBA, never see limited (and doesn't see the interest :-)

Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/get_bits: Document skip_bits_long()

[Michael Niedermayer]

On Fri, Mar 23, 2018 at 10:02:39PM +0100, Thilo Borgmann wrote:
> Am 23.03.18 um 20:20 schrieb Michael Niedermayer:
> > Found-by: Kieran
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/get_bits.h | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
> > index 0c7f5ff0c6..3ec45e7ab6 100644
> > --- a/libavcodec/get_bits.h
> > +++ b/libavcodec/get_bits.h
> > @@ -201,6 +201,13 @@ static inline int get_bits_count(const GetBitContext 
> > *s)
> >  return s->index;
> >  }
> >  
> > +/**
> > + * Skips the specified number of bits.
> > + * @param n the number of bits to skip,
> > + *  For the UNCHECKED_BITSTREAM_READER this must not cause the 
> > distance
> > + *  from the start to overflow int32_t. Staying within the 
> > bitstream + padding
> > + *  is sufficient too.
>   ^^
> Shouldn't this be "required" or "necessary"?

The bitstream reader must be able to index the whole bitstream and the padding
otherwise it would have some issues, actually it possibly does have a bug there
i need to double check this

currently it uses int32, so if the input is bigger the reader will reject this
so just staying within that size should be fine
that is unless iam missing something

[...]


> And nit: "something, too."

will fix

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [V2 1/2] lavc/vaapi_encode: fix the caculation overflow

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Pengfei Qu
> Sent: Monday, March 26, 2018 1:51 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Qu, Pengfei 
> Subject: [FFmpeg-devel] [V2 1/2] lavc/vaapi_encode: fix the caculation
> overflow
> 
> this fix the overflow during the caculation before value assignment.
> 
> Signed-off-by: Pengfei Qu 
> ---
>  libavcodec/vaapi_encode.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c index
> 36c85a3..78347d4 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1168,9 +1168,9 @@ static av_cold int
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  rc_target_percentage = 100;
>  } else {
>  rc_bits_per_second   = avctx->rc_max_rate;
> -rc_target_percentage = (avctx->bit_rate * 100) /
> rc_bits_per_second;
> +rc_target_percentage = (unsigned long)(avctx->bit_rate *
> + 100) / rc_bits_per_second;
>  }
> -rc_window_size = (hrd_buffer_size * 1000) / avctx->bit_rate;
> +rc_window_size = (unsigned long)(hrd_buffer_size * 1000) /
> + avctx->bit_rate;

Should better to use " uint64_t".

>  }
> 
>  ctx->rc_params.misc.type = VAEncMiscParameterTypeRateControl;
> --
> 2.9.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame in response to I frame pict_type

[Valery Kot]

On Tue, Mar 20, 2018 at 9:21 AM, Valery Kot  wrote:
> On Fri, Mar 16, 2018 at 3:04 PM, Valery Kot  wrote:
>>
>> Attached is an updated patch incorporating all feedback - only
>> formatting for now.
>>
>> Friendly ping to maintainers to review and pull the patch.
>>
>> Valery
>
> Another ping.
Just wondering: is there an active maintainer for avcodec/libopenh264?
If yes - can he or she please review my patch. If no - how does
maintenance works for "orphaned" modules?
I really need my patch in.
PLEASE!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Do not set YUV color range for RGB formats

[Paul B Mahol]

On 3/26/18, Michael Niedermayer  wrote:
> On Wed, Mar 21, 2018 at 09:18:21AM +0100, Paul B Mahol wrote:
>> On 3/20/18, Michael Niedermayer  wrote:
>> > Signed-off-by: Michael Niedermayer 
>> > ---
>> >  libavfilter/vf_scale.c | 7 ++-
>> >  1 file changed, 6 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
>> > index 9f45032e85..2f6fa4791d 100644
>> > --- a/libavfilter/vf_scale.c
>> > +++ b/libavfilter/vf_scale.c
>> > @@ -407,6 +407,7 @@ static int filter_frame(AVFilterLink *link, AVFrame
>> > *in)
>> >  AVFilterLink *outlink = link->dst->outputs[0];
>> >  AVFrame *out;
>> >  const AVPixFmtDescriptor *desc =
>> > av_pix_fmt_desc_get(link->format);
>> > +const AVPixFmtDescriptor *out_desc =
>> > av_pix_fmt_desc_get(outlink->format);
>> >  char buf[32];
>> >  int in_range;
>> >
>> > @@ -497,7 +498,11 @@ static int filter_frame(AVFilterLink *link,
>> > AVFrame
>> > *in)
>> >   table, out_full,
>> >   brightness, contrast,
>> > saturation);
>> >
>> > -out->color_range = out_full ? AVCOL_RANGE_JPEG :
>> > AVCOL_RANGE_MPEG;
>> > +// color_range describes YUV, it is undefined for RGB
>> > +if ((out_desc->flags & AV_PIX_FMT_FLAG_RGB) &&
>> > out_desc->nb_components != 1) {
>> > +out->color_range = AVCOL_RANGE_UNSPECIFIED;
>> > +} else
>> > +out->color_range = out_full ? AVCOL_RANGE_JPEG :
>> > AVCOL_RANGE_MPEG;
>> >  }
>> >
>> >  av_reduce(>sample_aspect_ratio.num,
>> > >sample_aspect_ratio.den,
>> > --
>> > 2.16.2
>> >
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>>
>> This is not optimal, as full color_range should remain full when not
>> changed.
>
> there is no range for rgb formats. The range is specific to YUV based
> formats.
> Thats, if iam guessing correctly what you meant. You did not really say
> which case you meant here. So maybe there is an issue and i misunderstand
> what you refer to

Maybe not for swscale here but does exist otherwise.

>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel