Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter
> -Original Message- > From: ffmpeg-devel On Behalf Of Steven > Liu > Sent: Thursday, July 30, 2020 7:04 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter > > Zong, Wei 于2020年7月30日周四 下午6:00写道： > > > > Someone opened an issue https://github.com/intel/libxcam/issues/729 they > want to use a FFmpeg video filter pipeline to do multiple decoder, stitching > and > encoder. > > > > Those 3rd party libs are not necessary for stitching and most image > > processing > functions. By default these 3rd libs are disabled. > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > myp...@gmail.com > > Sent: Thursday, July 30, 2020 5:34 PM > > To: FFmpeg development discussions and patches > > > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video > > filter > > > > On Thu, Jul 30, 2020 at 5:15 PM myp...@gmail.com > wrote: > > > > > > On Thu, Jul 30, 2020 at 5:12 PM Nicolas George wrote: > > > > > > > > zongwave (12020-07-31): > > > > > From: Yinhang Liu > > > > > > > > > > xcam filter is a wrapper of libxcam project which supports 360 > > > > > video stitching, automotive surround view stitching, digital > > > > > video stabilization (DVS), Wide dynamic range (WDR), wavelet noise > reduction, 3D noise reduction, etc. > > > > > > > > Hi. Thanks for the patch. But it seems to have been generated in a > > > > strange way, with double insertion marks. Did you commit your > > > > changes and then use git format-patch or git send-email? > > > > > > > > Regards, > > > > > > > > -- > > > > Nicolas George > > > > > > The other thing is, I found libxcam > > > (https://github.com/intel/libxcam) > > > depend on a lot of 3rd libs > > > " > > > If --enable-gst, need install libgstreamer1.0-dev, > > > libgstreamer-plugins-base1.0-dev If --enable-aiq, need get > > > ia_imaging lib which we don't support If --enable-libcl, need > > > compile or install OpenCL driver If --enable-opencv, suggest OpenCV > > > versions [3.0.0 - > > > 4.0.0) (or: OpenCV Wiki) If --enable-render, need compile > > > OpenSceneGraph library with configure option > > > "-DOSG_WINDOWING_SYSTEM=X11" > > > If --enable-gles, need to install Mesa3D library If --enable-vulkan, > > > need to install Mesa3D library If --enable-avx512, need to install > > > GCC version > 4.9 ( CPUs With > > > AVX-512 required) > > > If --enable-dnn, need to compile OpenVino inference-engine If > > > --enable-json, need to install json.hpp " > > > Is it a good idea to wrap a lib like this in AVFilter? > > > > My confusion is, where is the boundary of FFmpeg？ > > in my personal opinion, libxcam is not a self-contained library. > > ___ > > 1, Wei, DO NOT topic reply email. OK, I will not do this again. Thank you. > 2. after git am your patch, when i use git show, > > the last message bellow: > > > commit 368d43d3537e608904c7793b12cf2f4de0527e7a (HEAD -> master) > Author: Yinhang Liu > Date: Thu Jul 30 13:45:39 2020 +0800 > > avfilter/vf_xcam: add xcam video filter > > xcam filter is a wrapper of libxcam project which supports 360 video > stitching, > automotive surround view stitching, digital video stabilization (DVS), > Wide dynamic range (WDR), wavelet noise reduction, 3D noise reduction, > etc. > > libxcam library optimized algorithms by AVX, GLES and Vulkan depends on > hardware configuration to get good performance. > > libxcam project is hosted at https://github.com/intel/libxcam > please refer to https://github.com/intel/libxcam/wiki/Build to build > libxcam > library. > > To enable xcam video filter, configure FFmpeg with option > --enable-libxcam. > > Here are the features provided by xcam video filter: > - stitch CPU|GLES|Vulkan stitching > - stitchcl OpenCL stitching > - fisheyeFisheye calibration > - 3dnr 3D denoising > - waveletnr Wavelet denoising > - dvsDigital video stabilization > - defog Fog removal > > Use 'ffmpeg -h filter=xcam' to get the common parameters, stitch and > stitchcl have private parameters, use 'params=help=1' to get the private > parameters. For more detailed test cases posted at: > https://github.com/intel/libxcam/wiki/Tests#1-ffmpeg-xcam. > > Reviewed-by: Zong Wei > > diff --git a/patchset/0057-avfilter-vf_xcam-add-xcam-video-filter.patch > b/patchset/0057-avfilter-vf_xcam-add-xcam-video-filter.patch > new file mode 100644 > index 00..0c3b291dfe > --- /dev/null > +++ b/patchset/0057-avfilter-vf_xcam-add-xcam-video-filter.patch > @@ -0,0 +1,543 @@ > +From f35fa5e17a2916e9342b58a989dc94e88906dfca Mon Sep 17 00:00:00 > 2001 > +From: Yinhang Liu > +Date: Thu, 30 Jul 2020 13:33:37 +0800 > +Subject: [PATCH] avfilter/vf_xcam: add xcam video filter > + > (base) liuqi05:ffmpeg liuqi$ ls patchset/ > 0057-avfilter-vf_xcam-add-xcam-video
[FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter
From: Yinhang Liu
xcam filter is a wrapper of libxcam project which supports 360 video stitching,
automotive surround view stitching, digital video stabilization (DVS),
wavelet noise reduction, 3D noise reduction, etc.
libxcam library optimized algorithms by AVX, GLES and Vulkan depends on
hardware configuration to get good performance.
Here are demos of xcam filter
* video stitching:
https://github.com/intel/libxcam/wiki#libxcam-stitch-processing-flow
https://www.youtube.com/watch?v=J2Cr09KfIQ0
https://www.youtube.com/watch?v=z5MvzhRKcE8
* digital video stabilization:
https://www.youtube.com/watch?v=f5JFhZPa4Xc
libxcam project is hosted at: https://github.com/intel/libxcam
Build instruction is at: https://github.com/intel/libxcam/wiki/Build
To enable xcam video filter, configure FFmpeg with option
--enable-libxcam
Here are features provided by xcam video filter:
- stitch CPU|GLES|Vulkan stitching
- stitchcl OpenCL stitching
- fisheyeFisheye calibration
- 3dnr 3D denoising
- waveletnr Wavelet denoising
- dvsDigital video stabilization
- defog Fog removal
Use 'ffmpeg -h filter=xcam' to get the common parameters,
use 'params=help=1' to get the private parameters.
Detailed test cases at:
https://github.com/intel/libxcam/wiki/Tests#1-ffmpeg-xcam
Signed-off-by: Yinhang Liu
Signed-off-by: Zong Wei
Reviewed-by: Zong Wei
---
Changelog| 1 +
configure| 5 +
doc/filters.texi | 79 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_xcam.c| 326 +++
6 files changed, 413 insertions(+)
create mode 100644 libavfilter/vf_xcam.c
diff --git a/Changelog b/Changelog
index 6f648bff2b..1d5872e216 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
- ADPCM IMA Ubisoft APM encoder
- Rayman 2 APM muxer
- AV1 encoding support SVT-AV1
+- xcam filter
version 4.3:
diff --git a/configure b/configure
index 169f23e17f..7664a077b3 100755
--- a/configure
+++ b/configure
@@ -290,6 +290,7 @@ External library support:
--enable-libx265 enable HEVC encoding via x265 [no]
--enable-libxavs enable AVS encoding via xavs [no]
--enable-libxavs2enable AVS2 encoding via xavs2 [no]
+ --enable-libxcam enable image processing via xcam [no]
--enable-libxcb enable X11 grabbing using XCB [autodetect]
--enable-libxcb-shm enable X11 grabbing shm communication [autodetect]
--enable-libxcb-xfixes enable X11 grabbing mouse rendering [autodetect]
@@ -1817,6 +1818,7 @@ EXTERNAL_LIBRARY_LIST="
libvpx
libwavpack
libwebp
+libxcam
libxml2
libzimg
libzmq
@@ -3639,6 +3641,7 @@ scale_vaapi_filter_deps="vaapi"
scale_vulkan_filter_deps="vulkan libglslang"
vpp_qsv_filter_deps="libmfx"
vpp_qsv_filter_select="qsvvpp"
+xcam_filter_deps="libxcam"
xfade_opencl_filter_deps="opencl"
yadif_cuda_filter_deps="ffnvcodec"
yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
@@ -6451,6 +6454,8 @@ enabled libx265 && require_pkg_config libx265
x265 x265.h x265_api_get
require_cpp_condition libx265 x265.h "X265_BUILD
>= 70"
enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
enabled libxavs2 && require_pkg_config libxavs2 "xavs2 >= 1.3.0"
"stdint.h xavs2.h" xavs2_api_get
+enabled libxcam && { check_pkg_config libxcam "libxcam >= 1.4.0"
"capi/xcam_handle.h" xcam_create_handle ||
+ die "ERROR: libXCam must be installed and
version must be >= 1.4.0"; }
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzimg && require_pkg_config libzimg "zimg >= 2.7.0" zimg.h
zimg_get_api_version
enabled libzmq&& require_pkg_config libzmq "libzmq >= 4.2.1" zmq.h
zmq_ctx_new
diff --git a/doc/filters.texi b/doc/filters.texi
index 561aa98a9d..ab6f231025 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20399,6 +20399,85 @@ Set the scaling dimension: @code{2} for @code{2xBR},
@code{3} for
Default is @code{3}.
@end table
+@section xcam
+Image processing supported through libXCam.
+
+libXCam supports automotive surround view stitching, 360 video stitching,
+digital video stabilization, noise reduction and so on. For more information
+about libxcam see @url{https://github.com/intel/libxcam}.
+
+Please refer to @url{https://github.com/intel/libxcam/wiki/Build} to build
+libxcam.
+
+To enable compilation of @var{xcam} video filter you need to configure FFmpeg
+with @code{--enable-libxcam}.
+
+@subsection Options
+
+@table @option
+
+@item inputs
+The number of inputs. Default is @code{1}. @b{stitch} and @b{stitchcl}
+handlers support dynamic inputs, @b{fisheye}, @b{3dnr}, @b{waveletnr},
+@b{dvs} and @b{defog} handlers support one input.
+
+@item w
+Output video width. Def
Re: [FFmpeg-devel] Pull Request - Support Windows Subsystem for Linux
I didn't find any documentation that refers to building with WSL. Can builds with WSL be achieved without any patching? Also, how should I split the patch, if it's only modifying one file? On Thu, Jul 30, 2020 at 11:52 PM Carl Eugen Hoyos wrote: > > > > Am 31.07.2020 um 06:59 schrieb Julio César Rocha >: > > > > Attaching git format-patch change. > > > > Allows building FFmpeg on Windows using bash.exe provided by WSL, as an > > alternative to MSYS. > > The commit message is not ok as many people regularly build with wsl. > And please split the patch. > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [v3] dnn_backend_native_layer_mathunary: add ceil_v2 support
It can be tested with the model generated with below python script:
import tensorflow as tf
import os
import numpy as np
import imageio
from tensorflow.python.framework import graph_util
name = 'ceil'
pb_file_path = os.getcwd()
if not os.path.exists(pb_file_path+'/{}_savemodel/'.format(name)):
os.mkdir(pb_file_path+'/{}_savemodel/'.format(name))
with tf.Session(graph=tf.Graph()) as sess:
in_img = imageio.imread('detection.jpg')
in_img = in_img.astype(np.float32)
in_data = in_img[np.newaxis, :]
input_x = tf.placeholder(tf.float32, shape=[1, None, None, 3],
name='dnn_in')
y = tf.math.ceil( input_x, name='dnn_out')
sess.run(tf.global_variables_initializer())
constant_graph = graph_util.convert_variables_to_constants(sess,
sess.graph_def, ['dnn_out'])
with tf.gfile.FastGFile(pb_file_path+'/{}_savemodel/model.pb'.format(name),
mode='wb') as f:
f.write(constant_graph.SerializeToString())
print("model.pb generated, please in ffmpeg path use\n \n \
python tools/python/convert.py ceil_savemodel/model.pb
--outdir=ceil_savemodel/ \n \n \
to generate model.model\n")
output = sess.run(y, feed_dict={ input_x: in_data})
imageio.imsave("out.jpg", np.squeeze(output))
print("To verify, please ffmpeg path use\n \n \
./ffmpeg -i detection.jpg -vf
format=rgb24,dnn_processing=model=ceil_savemodel/model.pb:input=dnn_in:output=dnn_out:dnn_backend=tensorflow
-f framemd5 ceil_savemodel/tensorflow_out.md5\n \n \
to generate output result of tensorflow model\n")
print("To verify, please ffmpeg path use\n \n \
./ffmpeg -i detection.jpg -vf
format=rgb24,dnn_processing=model=ceil_savemodel/model.model:input=dnn_in:output=dnn_out:dnn_backend=native
-f framemd5 ceil_savemodel/native_out.md5\n \n \
to generate output result of native model\n")
Signed-off-by: Mingyu Yin
---
libavfilter/dnn/dnn_backend_native_layer_mathunary.c | 4
libavfilter/dnn/dnn_backend_native_layer_mathunary.h | 1 +
tests/dnn/dnn-layer-mathunary-test.c | 4
tools/python/convert_from_tensorflow.py | 4 +++-
tools/python/convert_header.py | 2 +-
5 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
b/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
index c5f0f7adec..a62f6ba6f0 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
@@ -130,6 +130,10 @@ int dnn_execute_layer_math_unary(DnnOperand *operands,
const int32_t *input_oper
for (int i = 0; i < dims_count; ++i)
dst[i] = atanh(src[i]);
return 0;
+case DMUO_CEIL:
+for (int i = 0; i < dims_count; ++i)
+dst[i] = ceil(src[i]);
+return 0;
default:
return -1;
}
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
b/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
index 8076356ba4..82b2d7f4ab 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
@@ -43,6 +43,7 @@ typedef enum {
DMUO_ASINH = 10,
DMUO_ACOSH = 11,
DMUO_ATANH = 12,
+DMUO_CEIL = 13,
DMUO_COUNT
} DNNMathUnaryOperation;
diff --git a/tests/dnn/dnn-layer-mathunary-test.c
b/tests/dnn/dnn-layer-mathunary-test.c
index 5afc5c157e..7da3a206ed 100644
--- a/tests/dnn/dnn-layer-mathunary-test.c
+++ b/tests/dnn/dnn-layer-mathunary-test.c
@@ -56,6 +56,8 @@ static float get_expected(float f, DNNMathUnaryOperation op)
return acosh(f);
case DMUO_ATANH:
return atanh(f);
+case DMUO_CEIL:
+return ceil(f);
default:
av_assert0(!"not supported yet");
return 0.f;
@@ -128,5 +130,7 @@ int main(int agrc, char **argv)
return 1;
if (test(DMUO_ATANH))
return 1;
+if (test(DMUO_CEIL))
+return 1;
return 0;
}
diff --git a/tools/python/convert_from_tensorflow.py
b/tools/python/convert_from_tensorflow.py
index 85db7bf710..64b7551314 100644
--- a/tools/python/convert_from_tensorflow.py
+++ b/tools/python/convert_from_tensorflow.py
@@ -72,7 +72,9 @@ class TFConverter:
self.conv2d_scopename_inputname_dict = {}
self.op2code = {'Conv2D':1, 'DepthToSpace':2, 'MirrorPad':3,
'Maximum':4, 'MathBinary':5, 'MathUnary':6}
self.mathbin2code = {'Sub':0, 'Add':1, 'Mul':2, 'RealDiv':3,
'Minimum':4}
-self.mathun2code = {'Abs':0, 'Sin':1, 'Cos':2, 'Tan':3, 'Asin':4,
'Acos':5, 'Atan':6, 'Sinh':7, 'Cosh':8, 'Tanh':9, 'Asinh':10, 'Acosh':11,
'Atanh':12}
+self.mathun2code = {'Abs':0, 'Sin':1, 'Cos':2, 'Tan':3, 'Asin':4,
+'Acos':5, 'Atan':6, 'Sinh':7, 'Cosh':8, 'Tanh':9, 'Asinh':10,
+'Acosh':11, 'Atanh':12, 'Ceil':13}
self.mirrorpad_mode = {'CONSTANT':0, 'REFLECT':1, 'SYMMETRIC':2}
self.name_operand_dict = {}
diff --git a/
[FFmpeg-devel] [v4] dnn_backend_native_layer_mathunary: add ceil support
It can be tested with the model generated with below python script:
import tensorflow as tf
import os
import numpy as np
import imageio
from tensorflow.python.framework import graph_util
name = 'ceil'
pb_file_path = os.getcwd()
if not os.path.exists(pb_file_path+'/{}_savemodel/'.format(name)):
os.mkdir(pb_file_path+'/{}_savemodel/'.format(name))
with tf.Session(graph=tf.Graph()) as sess:
in_img = imageio.imread('detection.jpg')
in_img = in_img.astype(np.float32)
in_data = in_img[np.newaxis, :]
input_x = tf.placeholder(tf.float32, shape=[1, None, None, 3],
name='dnn_in')
y = tf.math.ceil( input_x, name='dnn_out')
sess.run(tf.global_variables_initializer())
constant_graph = graph_util.convert_variables_to_constants(sess,
sess.graph_def, ['dnn_out'])
with tf.gfile.FastGFile(pb_file_path+'/{}_savemodel/model.pb'.format(name),
mode='wb') as f:
f.write(constant_graph.SerializeToString())
print("model.pb generated, please in ffmpeg path use\n \n \
python tools/python/convert.py ceil_savemodel/model.pb
--outdir=ceil_savemodel/ \n \n \
to generate model.model\n")
output = sess.run(y, feed_dict={ input_x: in_data})
imageio.imsave("out.jpg", np.squeeze(output))
print("To verify, please ffmpeg path use\n \n \
./ffmpeg -i detection.jpg -vf
format=rgb24,dnn_processing=model=ceil_savemodel/model.pb:input=dnn_in:output=dnn_out:dnn_backend=tensorflow
-f framemd5 ceil_savemodel/tensorflow_out.md5\n \n \
to generate output result of tensorflow model\n")
print("To verify, please ffmpeg path use\n \n \
./ffmpeg -i detection.jpg -vf
format=rgb24,dnn_processing=model=ceil_savemodel/model.model:input=dnn_in:output=dnn_out:dnn_backend=native
-f framemd5 ceil_savemodel/native_out.md5\n \n \
to generate output result of native model\n")
Signed-off-by: Mingyu Yin
---
libavfilter/dnn/dnn_backend_native_layer_mathunary.c | 4
libavfilter/dnn/dnn_backend_native_layer_mathunary.h | 1 +
tests/dnn/dnn-layer-mathunary-test.c | 4
tools/python/convert_from_tensorflow.py | 4 +++-
tools/python/convert_header.py | 2 +-
5 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
b/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
index c5f0f7adec..a62f6ba6f0 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathunary.c
@@ -130,6 +130,10 @@ int dnn_execute_layer_math_unary(DnnOperand *operands,
const int32_t *input_oper
for (int i = 0; i < dims_count; ++i)
dst[i] = atanh(src[i]);
return 0;
+case DMUO_CEIL:
+for (int i = 0; i < dims_count; ++i)
+dst[i] = ceil(src[i]);
+return 0;
default:
return -1;
}
diff --git a/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
b/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
index 8076356ba4..82b2d7f4ab 100644
--- a/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
+++ b/libavfilter/dnn/dnn_backend_native_layer_mathunary.h
@@ -43,6 +43,7 @@ typedef enum {
DMUO_ASINH = 10,
DMUO_ACOSH = 11,
DMUO_ATANH = 12,
+DMUO_CEIL = 13,
DMUO_COUNT
} DNNMathUnaryOperation;
diff --git a/tests/dnn/dnn-layer-mathunary-test.c
b/tests/dnn/dnn-layer-mathunary-test.c
index 5afc5c157e..7da3a206ed 100644
--- a/tests/dnn/dnn-layer-mathunary-test.c
+++ b/tests/dnn/dnn-layer-mathunary-test.c
@@ -56,6 +56,8 @@ static float get_expected(float f, DNNMathUnaryOperation op)
return acosh(f);
case DMUO_ATANH:
return atanh(f);
+case DMUO_CEIL:
+return ceil(f);
default:
av_assert0(!"not supported yet");
return 0.f;
@@ -128,5 +130,7 @@ int main(int agrc, char **argv)
return 1;
if (test(DMUO_ATANH))
return 1;
+if (test(DMUO_CEIL))
+return 1;
return 0;
}
diff --git a/tools/python/convert_from_tensorflow.py
b/tools/python/convert_from_tensorflow.py
index 85db7bf710..64b7551314 100644
--- a/tools/python/convert_from_tensorflow.py
+++ b/tools/python/convert_from_tensorflow.py
@@ -72,7 +72,9 @@ class TFConverter:
self.conv2d_scopename_inputname_dict = {}
self.op2code = {'Conv2D':1, 'DepthToSpace':2, 'MirrorPad':3,
'Maximum':4, 'MathBinary':5, 'MathUnary':6}
self.mathbin2code = {'Sub':0, 'Add':1, 'Mul':2, 'RealDiv':3,
'Minimum':4}
-self.mathun2code = {'Abs':0, 'Sin':1, 'Cos':2, 'Tan':3, 'Asin':4,
'Acos':5, 'Atan':6, 'Sinh':7, 'Cosh':8, 'Tanh':9, 'Asinh':10, 'Acosh':11,
'Atanh':12}
+self.mathun2code = {'Abs':0, 'Sin':1, 'Cos':2, 'Tan':3, 'Asin':4,
+'Acos':5, 'Atan':6, 'Sinh':7, 'Cosh':8, 'Tanh':9, 'Asinh':10,
+'Acosh':11, 'Atanh':12, 'Ceil':13}
self.mirrorpad_mode = {'CONSTANT':0, 'REFLECT':1, 'SYMMETRIC':2}
self.name_operand_dict = {}
diff --git a/
[FFmpeg-devel] Building with WSL instead of MSYS?
Hi. I recently submitted a patch to enable building the Windows flavor with Windows Subsystem for Linux as an alternative to MSYS / CYGWIN. I got the feedback that people are already able to achieve this. Has anyone achieved this without patching the sources (out of the box)? If so, could you please share your config steps? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] cineform CFHD encoder, and decoder speedup
On 7/30/20, Andreas Rheinhardt wrote:
> Paul B Mahol:
>>
>> +static int cfhd_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
>> + const AVFrame *frame, int *got_packet)
>> +{
>> +CFHDEncContext *s = avctx->priv_data;
>> +PutByteContext *pby = &s->pby;
>> +PutBitContext *pb = &s->pb;
>> +const Codebook *const cb = s->cb;
>> +const Runbook *const rb = s->rb;
>
> Why are these part of the context and not simply on the stack although
> they are reinitialized every time they are used?
Because I'm lazy typing & every single time.
>
>> +unsigned pos;
>> +int ret = 0;
>
>
>
>>
>> +ret = ff_alloc_packet2(avctx, pkt, 6 * avctx->width * avctx->height,
>> 0);
>> +if (ret < 0)
>> +return ret;
>> +
>
> You are writing quite a lot of stuff whose length is independent of the
> dimensions (E.g. you are writing 60 + 4 * s->planes before you enter the
> big for-loop). Is it possible that the allocated size might be
> insufficient for small dimensions (when the allocated packet is small,
> yet the constant part might not be)? (Or is there some check that I
> missed that rules out small dimensions?) And shouldn't you explicitly
> check whether your buffer was too small?
Fixed.
>
>> +bytestream2_init_writer(pby, pkt->data, pkt->size);
>> +
>
>
>>
>> +avpriv_align_put_bits(pb);
>
> Unnecessary, flush_put_bits() already fills the bitstream with zeroes.
Fixed.
>
>> +flush_put_bits(pb);
>> +bytestream2_skip_p(pby, put_bits_count(pb) >> 3);
>> +while (bytestream2_tell_p(pby) & 3)
>> +bytestream2_put_byte(pby, 0);
>
> It seems to me that this loop can be an infinite loop if the buffer
> turned out too small (because you are using the safe version of the
> bytestream2 API and if the packet size is not divisible by four (happens
> if and only if avctx->width and avctx->height are odd), then you will
> not advance to an element whose distance from the beginning is divisible
> by four).
Fixed.
>>
>> +pkt->size = bytestream2_tell_p(pby);
>> +pkt->flags |= AV_PKT_FLAG_KEY;
>> +
>> +bytestream2_seek_p(pby, 8, SEEK_SET);
>> +for (int i = 0; i < s->planes; i++)
>> +bytestream2_put_be32(pby, s->plane[i].size);
>> +
>> +av_assert0((pkt->size & 3) == 0);
>> +
>
> If your buffer turned out to be too small, the above assert might be
> triggered.
Removed. Anyway if buffer is too small it will assert in another code.
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] cineform CFHD encoder, and decoder speedup
On 7/30/20, James Almer wrote:
> On 7/30/2020 1:32 PM, Paul B Mahol wrote:
>> Hi,
>>
>> patches attached.
>>
>> Decoder speedup is approx %20 overall.
>
>> From 9692daafc0c4a69ce3cf7dca5b5aa90b5737e15f Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol
>> Date: Sat, 25 Jul 2020 18:18:18 +0200
>> Subject: [PATCH 1/2] avcodec: add CFHD encoder
>>
>> ---
>> libavcodec/Makefile| 1 +
>> libavcodec/allcodecs.c | 1 +
>> libavcodec/cfhd.c | 28 --
>> libavcodec/cfhd.h | 52 +++
>> libavcodec/cfhdenc.c | 750 +
>> 5 files changed, 804 insertions(+), 28 deletions(-)
>> create mode 100644 libavcodec/cfhdenc.c
>
> [...]
>
>> +static av_cold int cfhd_encode_init(AVCodecContext *avctx)
>> +{
>> +CFHDEncContext *s = avctx->priv_data;
>> +const int sign_mask = 256;
>> +const int twos_complement = -sign_mask;
>> +const int mag_mask = sign_mask - 1;
>> +
>> +s->planes = av_pix_fmt_count_planes(avctx->pix_fmt);
>> +if (avctx->compression_level == FF_COMPRESSION_DEFAULT)
>> +s->compression = 2;
>> +s->compression = av_clip(avctx->compression_level, 0, 9);
>> +
>> +for (int i = 0; i < s->planes; i++) {
>> +int w8, h8, w4, h4, w2, h2;
>> +int width = avctx->width;
>> +int height = avctx->height;
>> +ptrdiff_t stride = FFALIGN(width / 8, 8) * 8;
>> +
>> +s->plane[i].width = width;
>> +s->plane[i].height = height;
>> +s->plane[i].stride = stride;
>
> These three seem unused. For the first two you're always using the
> relevant s->plane[i].band[j][k] fields instead. But for stride, you're
> not even using the band one.
Removed.
>
> [...]
>
>> +
>> +bytestream2_put_be16(pby, GroupTrailer);
>> +bytestream2_put_be16(pby, 0);
>> +
>> +pkt->size = bytestream2_tell_p(pby);
>
> Use av_shrink_packet(), as it also zeroes the padding bytes.
Done.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] cineform CFHD encoder, and decoder speedup
On 7/30/20, Nicolas George wrote:
> Paul B Mahol (12020-07-30):
>> Hi,
>>
>> patches attached.
>>
>> Decoder speedup is approx %20 overall.
>
>> From 9692daafc0c4a69ce3cf7dca5b5aa90b5737e15f Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol
>> Date: Sat, 25 Jul 2020 18:18:18 +0200
>> Subject: [PATCH 1/2] avcodec: add CFHD encoder
>>
>> ---
>> libavcodec/Makefile| 1 +
>> libavcodec/allcodecs.c | 1 +
>> libavcodec/cfhd.c | 28 --
>> libavcodec/cfhd.h | 52 +++
>> libavcodec/cfhdenc.c | 750 +
>> 5 files changed, 804 insertions(+), 28 deletions(-)
>> create mode 100644 libavcodec/cfhdenc.c
>>
>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>> index c48138d0ad..1e7f899855 100644
>> --- a/libavcodec/Makefile
>> +++ b/libavcodec/Makefile
>> @@ -255,6 +255,7 @@ OBJS-$(CONFIG_CDGRAPHICS_DECODER) +=
>> cdgraphics.o
>> OBJS-$(CONFIG_CDTOONS_DECODER) += cdtoons.o
>> OBJS-$(CONFIG_CDXL_DECODER)+= cdxl.o
>> OBJS-$(CONFIG_CFHD_DECODER)+= cfhd.o cfhddata.o
>> +OBJS-$(CONFIG_CFHD_ENCODER)+= cfhdenc.o cfhddata.o
>> OBJS-$(CONFIG_CINEPAK_DECODER) += cinepak.o
>> OBJS-$(CONFIG_CINEPAK_ENCODER) += cinepakenc.o elbg.o
>> OBJS-$(CONFIG_CLEARVIDEO_DECODER) += clearvideo.o
>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
>> index 7a941b257e..c3a1f38db2 100644
>> --- a/libavcodec/allcodecs.c
>> +++ b/libavcodec/allcodecs.c
>> @@ -70,6 +70,7 @@ extern AVCodec ff_cavs_decoder;
>> extern AVCodec ff_cdgraphics_decoder;
>> extern AVCodec ff_cdtoons_decoder;
>> extern AVCodec ff_cdxl_decoder;
>> +extern AVCodec ff_cfhd_encoder;
>> extern AVCodec ff_cfhd_decoder;
>> extern AVCodec ff_cinepak_encoder;
>> extern AVCodec ff_cinepak_decoder;
>> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
>> index 299d98780c..ae7dd8ddbe 100644
>> --- a/libavcodec/cfhd.c
>> +++ b/libavcodec/cfhd.c
>> @@ -40,34 +40,6 @@
>> #define ALPHA_COMPAND_DC_OFFSET 256
>> #define ALPHA_COMPAND_GAIN 9400
>>
>> -enum CFHDParam {
>> -SampleType = 1,
>> -SampleIndexTable = 2,
>> -BitstreamMarker = 4,
>> -TransformType= 10,
>> -ChannelCount = 12,
>> -SubbandCount = 14,
>> -ImageWidth = 20,
>> -ImageHeight = 21,
>> -LowpassWidth = 27,
>> -LowpassHeight= 28,
>> -LowpassPrecision = 35,
>> -HighpassWidth= 41,
>> -HighpassHeight = 42,
>> -SubbandNumber= 48,
>> -Quantization = 53,
>> -BandHeader = 55,
>> -ChannelNumber= 62,
>> -SampleFlags = 68,
>> -EncodedFormat= 84,
>> -BitsPerComponent = 101,
>> -ChannelWidth = 104,
>> -ChannelHeight= 105,
>> -PrescaleShift= 109,
>> -};
>> -
>> -
>> -
>> static av_cold int cfhd_init(AVCodecContext *avctx)
>> {
>> CFHDContext *s = avctx->priv_data;
>> diff --git a/libavcodec/cfhd.h b/libavcodec/cfhd.h
>> index 4f2c82d8bc..0e3155be23 100644
>> --- a/libavcodec/cfhd.h
>> +++ b/libavcodec/cfhd.h
>> @@ -30,6 +30,58 @@
>> #include "get_bits.h"
>> #include "vlc.h"
>>
>> +enum CFHDParam {
>> +SampleType = 1,
>> +SampleIndexTable = 2,
>> +BitstreamMarker = 4,
>> +TransformType= 10,
>> +NumFrames= 11,
>> +ChannelCount = 12,
>> +WaveletCount = 13,
>> +SubbandCount = 14,
>> +NumSpatial = 15,
>> +FirstWavelet = 16,
>> +GroupTrailer = 18,
>> +ImageWidth = 20,
>> +ImageHeight = 21,
>> +LowpassSubband = 25,
>> +NumLevels= 26,
>> +LowpassWidth = 27,
>> +LowpassHeight= 28,
>> +PixelOffset = 33,
>> +LowpassQuantization=34,
>> +LowpassPrecision = 35,
>> +WaveletType = 37,
>> +WaveletNumber= 38,
>> +WaveletLevel = 39,
>> +NumBands = 40,
>> +HighpassWidth= 41,
>> +HighpassHeight = 42,
>> +LowpassBorder= 43,
>> +HighpassBorder = 44,
>> +LowpassScale = 45,
>> +LowpassDivisor = 46,
>> +SubbandNumber= 48,
>> +BandWidth= 49,
>> +BandHeight = 50,
>> +SubbandBand = 51,
>> +BandEncoding = 52,
>> +Quantization = 53,
>> +BandScale= 54,
>> +BandHeader = 55,
>> +BandTrailer = 56,
>> +ChannelNumber= 62,
>> +SampleFlags = 68,
>> +Precision= 70,
>> +BandCodingFlags = 72,
>> +PrescaleTable= 83,
>> +EncodedFormat= 84,
>> +BitsPerComponent = 101,
>> +ChannelWidth = 104,
>> +ChannelHeight= 105,
>> +PrescaleShift= 109,
>> +};
>> +
>> #define VLC_BITS 9
>> #define SUBBAND_COUNT 10
>>
>> diff --git a/libavcodec/cfhdenc.c b/libavcodec/cfhdenc.c
>> new file mode 100644
>> index 00..b2f4b31795
>> --- /dev/null
>> +++ b/libavcodec/cfhdenc.c
>> @@ -0,0 +1,750
Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter
Thank you for the comments on this patch, I want to make some explanation on your comments. 1. the purpose of this patch We got some requirements from users who are trying libxcam stitching or developers who showing interests. Many of them want an easy way to construct an end 2 end pipeline of high quality immersive media application. The key points are high resolution and low latency, FFMpeg provides high quality video codec framework, if we implement video stitching as a video filter in FFMpeg, they will get benefits. 2. 3rd party dependency The functions exposed by xcam filter only depends on essential build tool-chain. According to hardware configuration, user can get performance improvement by install OCL, GLES or Vulkan. These libraries are not necessary for video stitching, user can build a CPU version without these libraries. Beside these, stitching and DVS function depend on feature match algorithm from OpenCV library to get better quality, I posted demo link in commit message. User can run stitching without install OpenCV, the side effect is the quality will decrease. 3. Immersive media standard Normally the camera manufactures provide video stitching software, they defined private camera calibration parameters, these are very critical to stitching quality. I know MPEG is making proposal on transfer these meta-data in video stream, this will help compose immersive media on cloud or edge server. I think it's a good idea to create such a video filter in FFMpeg pipeline. 4. Why not implement stitching inside FFMpeg video filter The algorithms are complexity and the performance are also important, the stitching function manage computing resource for example thread handling, image data block dispatching. Personally I think we don't need to construct a wheel from the beginning. > -Original Message- > From: Zong, Wei > Sent: Friday, July 31, 2020 10:57 PM > To: ffmpeg-devel@ffmpeg.org > Cc: Liu, YinhangX ; Zong, Wei > Subject: [PATCH] avfilter/vf_xcam: add xcam video filter > > From: Yinhang Liu > > xcam filter is a wrapper of libxcam project which supports 360 video > stitching, > automotive surround view stitching, digital video stabilization (DVS), wavelet > noise reduction, 3D noise reduction, etc. > > libxcam library optimized algorithms by AVX, GLES and Vulkan depends on > hardware configuration to get good performance. > > Here are demos of xcam filter > * video stitching: > https://github.com/intel/libxcam/wiki#libxcam-stitch-processing-flow > https://www.youtube.com/watch?v=J2Cr09KfIQ0 > https://www.youtube.com/watch?v=z5MvzhRKcE8 > > * digital video stabilization: > https://www.youtube.com/watch?v=f5JFhZPa4Xc > > libxcam project is hosted at: https://github.com/intel/libxcam > > Build instruction is at: https://github.com/intel/libxcam/wiki/Build > > To enable xcam video filter, configure FFmpeg with option --enable-libxcam > > Here are features provided by xcam video filter: > - stitch CPU|GLES|Vulkan stitching > - stitchcl OpenCL stitching > - fisheyeFisheye calibration > - 3dnr 3D denoising > - waveletnr Wavelet denoising > - dvsDigital video stabilization > - defog Fog removal > > Use 'ffmpeg -h filter=xcam' to get the common parameters, use > 'params=help=1' to get the private parameters. > Detailed test cases at: > https://github.com/intel/libxcam/wiki/Tests#1-ffmpeg-xcam > > Signed-off-by: Yinhang Liu > Signed-off-by: Zong Wei > Reviewed-by: Zong Wei > --- > Changelog| 1 + > configure| 5 + > doc/filters.texi | 79 ++ > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_xcam.c| 326 +++ > 6 files changed, 413 insertions(+) > create mode 100644 libavfilter/vf_xcam.c > > diff --git a/Changelog b/Changelog > index 6f648bff2b..1d5872e216 100644 > --- a/Changelog > +++ b/Changelog > @@ -10,6 +10,7 @@ version : > - ADPCM IMA Ubisoft APM encoder > - Rayman 2 APM muxer > - AV1 encoding support SVT-AV1 > +- xcam filter > > > version 4.3: > diff --git a/configure b/configure > index 169f23e17f..7664a077b3 100755 > --- a/configure > +++ b/configure > @@ -290,6 +290,7 @@ External library support: >--enable-libx265 enable HEVC encoding via x265 [no] >--enable-libxavs enable AVS encoding via xavs [no] >--enable-libxavs2enable AVS2 encoding via xavs2 [no] > + --enable-libxcam enable image processing via xcam [no] >--enable-libxcb enable X11 grabbing using XCB [autodetect] >--enable-libxcb-shm enable X11 grabbing shm communication [autodetect] >--enable-libxcb-xfixes enable X11 grabbing mouse rendering [autodetect] > @@ -1817,6 +1818,7 @@ EXTERNAL_LIBRARY_LIST=" > libvpx > libwavpack > libwebp > +libxcam > libxml2 > libzimg > libzmq > @@ -3639,6 +364
Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter
On 7/31/20, Zong, Wei wrote: > Thank you for the comments on this patch, I want to make some explanation on > your comments. > > 1. the purpose of this patch > We got some requirements from users who are trying libxcam stitching or > developers who showing interests. Many of them want an easy way to construct > an end 2 end pipeline of high quality immersive media application. > The key points are high resolution and low latency, FFMpeg provides high > quality video codec framework, if we implement video stitching as a video > filter in FFMpeg, > they will get benefits. > > 2. 3rd party dependency > The functions exposed by xcam filter only depends on essential build > tool-chain. > According to hardware configuration, user can get performance improvement by > install OCL, GLES or Vulkan. > These libraries are not necessary for video stitching, user can build a CPU > version without these libraries. > Beside these, stitching and DVS function depend on feature match > algorithm from OpenCV library to get better quality, I posted demo link in > commit message. > User can run stitching without install OpenCV, the side effect is the > quality will decrease. > > 3. Immersive media standard > Normally the camera manufactures provide video stitching software, they > defined private camera calibration parameters, these are very critical to > stitching quality. I know MPEG is making proposal on transfer these > meta-data in video stream, this will help compose immersive media on cloud > or edge server. I think it's a good idea to > create such a video filter in FFMpeg pipeline. > > 4. Why not implement stitching inside FFMpeg video filter > The algorithms are complexity and the performance are also important, > the stitching function manage computing resource for example thread > handling, image data block dispatching. Personally I think we don't need to > construct a wheel from the beginning. Number of supported pixel formats are rather very low. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] cineform CFHD encoder, and decoder speedup
Paul B Mahol (12020-07-31): > These are either made up by inspecting numbers from already encoded > files or added new ones from scratch. "Document" means in the source code. And I meant all the numbers, including codebook and runbook, not just quantization_per_subband. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Pull Request - Support Windows Subsystem for Linux
> On Jul 31, 2020, at 3:19 PM, Julio César Rocha wrote: > > I didn't find any documentation that refers to building with WSL. > Can builds with WSL be achieved without any patching? > > Also, how should I split the patch, if it's only modifying one file? Modify a part of the file, git add && git commit, then modify another part. > > On Thu, Jul 30, 2020 at 11:52 PM Carl Eugen Hoyos > wrote: > >> >> >>> Am 31.07.2020 um 06:59 schrieb Julio César Rocha >> : >>> >>> Attaching git format-patch change. >>> >>> Allows building FFmpeg on Windows using bash.exe provided by WSL, as an >>> alternative to MSYS. >> >> The commit message is not ok as many people regularly build with wsl. >> And please split the patch. >> >> Carl Eugen >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] cineform CFHD additions and improvements
Hi, updated patches attached. This work is sponsored by VideoLAN. 0001-avcodec-add-CFHD-encoder.patch Description: Binary data 0002-avcodec-cfhd-move-if-else-out-of-loop-in-inverse-tra.patch Description: Binary data 0003-avcodec-cfhd-fix-non-aligned-to-8-height-decoding.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cineform CFHD additions and improvements
Paul B Mahol (12020-07-31): > From 6ec6fb33ac4a21c602b44efa94ff3246a6ea4342 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Sat, 25 Jul 2020 18:18:18 +0200 > Subject: [PATCH 1/3] avcodec: add CFHD encoder > > --- > libavcodec/Makefile| 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/cfhd.c | 28 -- > libavcodec/cfhd.h | 52 +++ > libavcodec/cfhdenc.c | 746 + > 5 files changed, 800 insertions(+), 28 deletions(-) > create mode 100644 libavcodec/cfhdenc.c The origin of the tables of numbers still need to be documented in the source code. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] cineform CFHD encoder, and decoder speedup
On 7/31/20, Nicolas George wrote: > Paul B Mahol (12020-07-31): >> These are either made up by inspecting numbers from already encoded >> files or added new ones from scratch. > > "Document" means in the source code. And I meant all the numbers, > including codebook and runbook, not just quantization_per_subband. > They are derived from existing decoder code. Also if there is way to use existing VLC table, I'm all ears. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cineform CFHD additions and improvements
On 7/31/20, Nicolas George wrote: > Paul B Mahol (12020-07-31): >> From 6ec6fb33ac4a21c602b44efa94ff3246a6ea4342 Mon Sep 17 00:00:00 2001 >> From: Paul B Mahol >> Date: Sat, 25 Jul 2020 18:18:18 +0200 >> Subject: [PATCH 1/3] avcodec: add CFHD encoder >> >> --- >> libavcodec/Makefile| 1 + >> libavcodec/allcodecs.c | 1 + >> libavcodec/cfhd.c | 28 -- >> libavcodec/cfhd.h | 52 +++ >> libavcodec/cfhdenc.c | 746 + >> 5 files changed, 800 insertions(+), 28 deletions(-) >> create mode 100644 libavcodec/cfhdenc.c > > The origin of the tables of numbers still need to be documented in the > source code. Disagree, no it does not, also only you complained about it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cineform CFHD additions and improvements
Paul B Mahol (12020-07-31): > Disagree, no it does not, also only you complained about it. Do not push this patch unless the origin of all these numbers is properly documented in the source code. I am ready to argue, but I will not spend more text than you on it. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cineform CFHD additions and improvements
On 7/31/20, Nicolas George wrote: > Paul B Mahol (12020-07-31): >> Disagree, no it does not, also only you complained about it. > > Do not push this patch unless the origin of all these numbers is > properly documented in the source code. > > I am ready to argue, but I will not spend more text than you on it. Always when you appear you must evoke your request that must be fulfilled at any costs no matter how useless they are. No existing encoder/decoder document their tables and how they got it, unless they are part of existing specification, which in this case it is not. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cineform CFHD additions and improvements
Paul B Mahol (12020-07-31): > Always when you appear you must evoke your request that must be > fulfilled at any costs no matter how useless they are. I will not answer this personal attack. > No existing encoder/decoder document their tables and how they got it, > unless they are part of existing specification, which in this case it > is not. They should: tables of numbers are not source code, otherwise any blob could be source code by hexdumping it into a C file. As our project is Libre software, it must contain its whole source code, and therefore document where the tables of numbers come from. I have only realized this recently, and will be careful about it from now on. Past wrongs cannot be used as a justification for new wrongs. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter
> -Original Message- > From: ffmpeg-devel On Behalf Of Paul B > Mahol > Sent: Friday, July 31, 2020 3:57 PM > To: FFmpeg development discussions and patches > Cc: Liu, YinhangX > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter > > On 7/31/20, Zong, Wei wrote: > > Thank you for the comments on this patch, I want to make some > > explanation on your comments. > > > > 1. the purpose of this patch > > We got some requirements from users who are trying libxcam > > stitching or developers who showing interests. Many of them want an > > easy way to construct an end 2 end pipeline of high quality immersive media > application. > > The key points are high resolution and low latency, FFMpeg > > provides high quality video codec framework, if we implement video > > stitching as a video filter in FFMpeg, they will get benefits. > > > > 2. 3rd party dependency > > The functions exposed by xcam filter only depends on essential > > build tool-chain. > > According to hardware configuration, user can get performance > > improvement by install OCL, GLES or Vulkan. > > These libraries are not necessary for video stitching, user can build > > a CPU version without these libraries. > > Beside these, stitching and DVS function depend on feature match > > algorithm from OpenCV library to get better quality, I posted demo > > link in commit message. > > User can run stitching without install OpenCV, the side effect is the > > quality will decrease. > > > > 3. Immersive media standard > > Normally the camera manufactures provide video stitching software, > > they defined private camera calibration parameters, these are very > > critical to stitching quality. I know MPEG is making proposal on > > transfer these meta-data in video stream, this will help compose > > immersive media on cloud or edge server. I think it's a good idea to > > create such a video filter in FFMpeg pipeline. > > > > 4. Why not implement stitching inside FFMpeg video filter > > The algorithms are complexity and the performance are also > > important, the stitching function manage computing resource for > > example thread handling, image data block dispatching. Personally I > > think we don't need to construct a wheel from the beginning. > > Number of supported pixel formats are rather very low. Do you mean the pixel format (NV12 & YUV420) that xcam filter supported is not enough? xcam filter works as a post processing component between video decoder and encoder, we suppose the data comes from camera or stored video clips, so it handles YUV format. libxcam algorithm optimization highly depends on pixel layout, to support YUV422 or YUV444 will cost much effort, we do not meet the requirement till now. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org > with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Pull Request - Support Windows Subsystem for Linux
Understood, thanks! Here are the updated patches. On Fri, Jul 31, 2020 at 1:07 AM zhilizhao wrote: > > > > On Jul 31, 2020, at 3:19 PM, Julio César Rocha > wrote: > > > > I didn't find any documentation that refers to building with WSL. > > Can builds with WSL be achieved without any patching? > > > > Also, how should I split the patch, if it's only modifying one file? > > Modify a part of the file, git add && git commit, then modify another part. > > > > > On Thu, Jul 30, 2020 at 11:52 PM Carl Eugen Hoyos > > wrote: > > > >> > >> > >>> Am 31.07.2020 um 06:59 schrieb Julio César Rocha < > ju...@rochsquadron.net > >>> : > >>> > >>> Attaching git format-patch change. > >>> > >>> Allows building FFmpeg on Windows using bash.exe provided by WSL, as an > >>> alternative to MSYS. > >> > >> The commit message is not ok as many people regularly build with wsl. > >> And please split the patch. > >> > >> Carl Eugen > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". 0001-Use-normalized-Linux-paths-on-Windows-WSL.patch Description: Binary data 0002-Use-relative-paths-on-Windows-WSL.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cineform CFHD additions and improvements
On 7/31/20, Nicolas George wrote: > Paul B Mahol (12020-07-31): >> Always when you appear you must evoke your request that must be >> fulfilled at any costs no matter how useless they are. > > I will not answer this personal attack. You think this is some kind of game, that you will reply only if I write enough character in my reply hopefully wasting my precious time to your trolling attempts. > >> No existing encoder/decoder document their tables and how they got it, >> unless they are part of existing specification, which in this case it >> is not. > > They should: tables of numbers are not source code, otherwise any blob > could be source code by hexdumping it into a C file. As our project is > Libre software, it must contain its whole source code, and therefore > document where the tables of numbers come from. > > I have only realized this recently, and will be careful about it from > now on. > > Past wrongs cannot be used as a justification for new wrongs. As already said they are derived from other parts of code or by research, there is no original source that could be used and written as link in source code. For reverse engineered codecs documenting from which binary blob it came from is nonsense. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter
On 7/31/20, Zong, Wei wrote: > > >> -Original Message- >> From: ffmpeg-devel On Behalf Of Paul B >> Mahol >> Sent: Friday, July 31, 2020 3:57 PM >> To: FFmpeg development discussions and patches >> Cc: Liu, YinhangX >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video >> filter >> >> On 7/31/20, Zong, Wei wrote: >> > Thank you for the comments on this patch, I want to make some >> > explanation on your comments. >> > >> > 1. the purpose of this patch >> > We got some requirements from users who are trying libxcam >> > stitching or developers who showing interests. Many of them want an >> > easy way to construct an end 2 end pipeline of high quality immersive >> > media >> application. >> > The key points are high resolution and low latency, FFMpeg >> > provides high quality video codec framework, if we implement video >> > stitching as a video filter in FFMpeg, they will get benefits. >> > >> > 2. 3rd party dependency >> > The functions exposed by xcam filter only depends on essential >> > build tool-chain. >> > According to hardware configuration, user can get performance >> > improvement by install OCL, GLES or Vulkan. >> > These libraries are not necessary for video stitching, user can build >> > a CPU version without these libraries. >> > Beside these, stitching and DVS function depend on feature match >> > algorithm from OpenCV library to get better quality, I posted demo >> > link in commit message. >> > User can run stitching without install OpenCV, the side effect is the >> > quality will decrease. >> > >> > 3. Immersive media standard >> > Normally the camera manufactures provide video stitching software, >> > they defined private camera calibration parameters, these are very >> > critical to stitching quality. I know MPEG is making proposal on >> > transfer these meta-data in video stream, this will help compose >> > immersive media on cloud or edge server. I think it's a good idea to >> > create such a video filter in FFMpeg pipeline. >> > >> > 4. Why not implement stitching inside FFMpeg video filter >> > The algorithms are complexity and the performance are also >> > important, the stitching function manage computing resource for >> > example thread handling, image data block dispatching. Personally I >> > think we don't need to construct a wheel from the beginning. >> >> Number of supported pixel formats are rather very low. > >Do you mean the pixel format (NV12 & YUV420) that xcam filter supported > is not enough? > xcam filter works as a post processing component between video decoder and > encoder, we suppose the data comes from camera or stored video clips, so it > handles YUV format. > libxcam algorithm optimization highly depends on pixel layout, to support > YUV422 or YUV444 will cost much effort, we do not meet the requirement till > now. Ok then, I thought library provided support for it already. Supporting only few pixel formats is very limited functionality IMHO. > > >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org >> with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cineform CFHD additions and improvements
Paul B Mahol (12020-07-31): > As already said they are derived from other parts of code or by research, > there is no original source that could be used and written as link in > source code. > > For reverse engineered codecs documenting from which binary blob it > came from is nonsense. I do not agree. The source code should be as complete as possible, to allow other developers to take over, or to fix a bug, or to adapt to new samples and variations in the codec. I understand nobody can explain their whole know-how, but explaining nothing at all is completely unacceptable. These tables as they are are not source code, and therefore have no place in FFmpeg's source tree. With adequate comments, they would. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.
Tables that were not just written by the code author are not actually source code, otherwise, "recode data..x1 < proprietary.o > source.c" would be enough to launder a proprietary blob into the source code. Documenting the origin of the tables or the methods for their generation is necessary to let other developers take over if the original author is no longer available. Signed-off-by: Nicolas George --- doc/developer.texi | 8 1 file changed, 8 insertions(+) diff --git a/doc/developer.texi b/doc/developer.texi index b33cab0fc7..5c698fe9c5 100644 --- a/doc/developer.texi +++ b/doc/developer.texi @@ -216,6 +216,14 @@ please use av_log() instead. @item Casts should be used only when necessary. Unneeded parentheses should also be avoided if they don't make the code easier to understand. + +@item +If the code contains tables of numbers or other data, their origin should be +documented in a comment, so that other developers can rebuild them if +necessary. If they were taken from a reference, include the URL of that +reference. If they were computed by a tool, include the code of the tool. +If they were reverse-engineerd, include an honest attempt at explaining the +methods used. @end itemize @section Editor configuration -- 2.27.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.
Lynne (12020-07-31):
> I disagree. We don't have any proprietary blobs in our codebase.
> Everything that you think is binary is in fact a well defined VLC
> table that simply describes bit positions and lengths.
Please read my message more carefully (and possibly with less
hostility): I never said that the tables we have right now are
proprietary blobs.
What I am saying is that accepting them in new code creates a loophole
that somebody with bad intentions could exploit in the future. One of my
reasons for insisting on this is to close that loophole.
> Neither are quantization tables. They're again, well defined series of
> lookup tables that always follow a simple pattern, be it linear or
> some exponent.
Then all I am asking is:
/* Geometric progression with ratio 42. */
Or, if you used a one-liner in whatever language of your choice, just
copy-paste it into the comment:
/* Zsh: for i in {0..11}; printf "%8x\\n" $[440*2**(22+i/12.)] */
That is all I am asking. Is it really too much to ask? One line of
comment!
> Forcing developers to meticulously describe standard bitstream readers
> or copying entire chunks of specifications as comments just because
> you don't understand them,
If they are standard, just name them or put a Wikipedia link.
> or want to justify your own personal war, or are paranoid of binary
> blobs is not acceptable.
Please refrain from personal attacks. The only thing I am at "war"
against is bad code by Libre Software standards.
Libre Software is not just about churning out code that does the work;
that's for proprietary software and its poor cousin Open Source. Libre
Software is also about building collective knowledge. Libre Software is
almost as much teaching as it is coding, so that other developers can
extend it rather than just using it.
> In the first place no one would commit actual binary blobs (read:
> CPU-specific bytecode or a series of bytes needed to initialize a
> device) to the codebase.
I hope so. I am not convinced some company would not try to.
> And if developers were forced to copy chunks of spec as comments into
> the codebase you'll end up with licensed content just sitting in the
> codebase, making us liable for lawsuits.
As I said, if the explanations already exist elsewhere, just a link or a
bibliography reference is enough. No need to copy chunks, I never talked
about is and do not know why you think I did.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/mxfdec: Read color metadata from MXF
Hi,
V2 fixes all the fate tests (I didn't know to download the test footage before.
Doh).
The following patch adds reading colour metadata (transfer, primaries and
colour space) from
standard MXF files. I wrote it without seeing the other patch but it turned out
very similar to this
one that was never merged.
https://patchwork.ffmpeg.org/project/ffmpeg/patch/1474694344-31167-1-git-send-email-ste...@strobe.cc/
.
Thanks.
Harry
From d16966e6b0a6367a5e5445987c0449fb1150785a Mon Sep 17 00:00:00 2001
From: Harry Mallon
Date: Mon, 27 Jul 2020 15:52:17 +0100
Subject: [PATCH] avformat/mxfdec: Read color metadata from MXF
Reads color_primaries, color_trc and color_space from mxf
headers. ULs are from https://registry.smpte-ra.org/ site.
Signed-off-by: Harry Mallon
---
libavformat/mxf.c | 49 +
libavformat/mxf.h | 3 ++
libavformat/mxfdec.c| 15
tests/ref/fate/mxf-d10-user-comments| 2 +-
tests/ref/fate/mxf-opatom-user-comments | 2 +-
tests/ref/fate/mxf-probe-d10| 2 +-
tests/ref/fate/mxf-probe-dnxhd | 4 +-
tests/ref/fate/mxf-probe-dv25 | 2 +-
tests/ref/fate/mxf-reel_name| 2 +-
tests/ref/fate/mxf-user-comments| 2 +-
10 files changed, 75 insertions(+), 8 deletions(-)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 7d154ca9d3..e51fc48a84 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -86,6 +86,55 @@ const MXFCodecUL ff_mxf_codec_tag_uls[] = {
{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, 0 },
};
+const MXFCodecUL ff_mxf_color_primaries_uls[] = {
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x03,0x01,0x00,0x00
}, 14, AVCOL_PRI_SMPTE170M }, /* SMPTE 170M */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x03,0x02,0x00,0x00
}, 14, AVCOL_PRI_BT470BG }, /* ITU-R BT.470 PAL */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x03,0x03,0x00,0x00
}, 14, AVCOL_PRI_BT709 }, /* ITU-R BT.709 */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x03,0x04,0x00,0x00
}, 14, AVCOL_PRI_BT2020 }, /* ITU-R BT.2020 */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x03,0x05,0x00,0x00
}, 14, AVCOL_PRI_SMPTE428 }, /* SMPTE-DC28 DCDM */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x03,0x06,0x00,0x00
}, 14, AVCOL_PRI_SMPTE432 }, /* P3D65 */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x03,0x08,0x00,0x00
}, 14, AVCOL_PRI_SMPTE428 }, /* Cinema Mezzanine */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x03,0x0a,0x00,0x00
}, 14, AVCOL_PRI_SMPTE431 }, /* P3DCI */
+/* alternate mappings for encoding */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x03,0x01,0x00,0x00
}, 14, AVCOL_PRI_SMPTE240M }, /* = AVCOL_PRI_SMPTE170M */
+
+{ {
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
}, 0, AVCOL_PRI_UNSPECIFIED },
+};
+
+const MXFCodecUL ff_mxf_color_trc_uls[] = {
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x01,0x00,0x00
}, 14, AVCOL_TRC_GAMMA22 }, /* ITU-R BT.470 */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x02,0x00,0x00
}, 14, AVCOL_TRC_BT709 }, /* ITU-R BT.709 */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x03,0x00,0x00
}, 14, AVCOL_TRC_SMPTE240M }, /* SMPTE 240M */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x04,0x00,0x00
}, 14, AVCOL_TRC_BT709 }, /* SMPTE 274/296M (must appear after ITU-R BT.709) */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x05,0x00,0x00
}, 14, AVCOL_TRC_BT1361_ECG }, /* ITU-R BT.1361 */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x06,0x04,0x01,0x01,0x01,0x01,0x06,0x00,0x00
}, 14, AVCOL_TRC_LINEAR }, /* Linear */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x08,0x04,0x01,0x01,0x01,0x01,0x07,0x00,0x00
}, 14, AVCOL_TRC_SMPTE428 }, /* SMPTE-DC28 DCDM */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x01,0x08,0x00,0x00
}, 14, AVCOL_TRC_IEC61966_2_4 }, /* IEC 61966-2-4 xvYCC */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0E,0x04,0x01,0x01,0x01,0x01,0x09,0x00,0x00
}, 14, AVCOL_TRC_BT2020_10 }, /* ITU-R BT.2020 */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x01,0x0A,0x00,0x00
}, 14, AVCOL_TRC_SMPTE2084 }, /* SMPTE ST 2084 */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x01,0x01,0x01,0x0B,0x00,0x00
}, 14, AVCOL_TRC_ARIB_STD_B67 }, /* Hybrid Log-Gamma OETF */
+/* alternate mappings for encoding */
+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x01,0x00,0x00
}, 14, AVCOL_TRC_GAMMA28 }, /* = AVCOL_TRC_GAMMA22 */
+{ {
0x06,0x0E,0
Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter
The xcam filter is providing high quality stitching, accepting data from the current 360 camera, one example is: https://www.insta360.com/product/insta360-pro2/. Now the current 360 camera output doesn't provide a broad pixel format, only YUV420P and NV12. (For other formats, we can use current FFmpeg filters to handle with a little performance and quality drop.) Beside this, this xcam filter can work with FFmpeg's v360 filter together, one example is transforming the stitching result from ERP (res:7680x3840) to CubeMap (res:5760x3840), this can save 50% bitrate. Paul B Mahol 于2020年7月31日周五 下午4:39写道： > On 7/31/20, Zong, Wei wrote: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of Paul > B > >> Mahol > >> Sent: Friday, July 31, 2020 3:57 PM > >> To: FFmpeg development discussions and patches > > >> Cc: Liu, YinhangX > >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video > >> filter > >> > >> On 7/31/20, Zong, Wei wrote: > >> > Thank you for the comments on this patch, I want to make some > >> > explanation on your comments. > >> > > >> > 1. the purpose of this patch > >> > We got some requirements from users who are trying libxcam > >> > stitching or developers who showing interests. Many of them want an > >> > easy way to construct an end 2 end pipeline of high quality immersive > >> > media > >> application. > >> > The key points are high resolution and low latency, FFMpeg > >> > provides high quality video codec framework, if we implement video > >> > stitching as a video filter in FFMpeg, they will get benefits. > >> > > >> > 2. 3rd party dependency > >> > The functions exposed by xcam filter only depends on essential > >> > build tool-chain. > >> > According to hardware configuration, user can get performance > >> > improvement by install OCL, GLES or Vulkan. > >> > These libraries are not necessary for video stitching, user can build > >> > a CPU version without these libraries. > >> > Beside these, stitching and DVS function depend on feature match > >> > algorithm from OpenCV library to get better quality, I posted demo > >> > link in commit message. > >> > User can run stitching without install OpenCV, the side effect is the > >> > quality will decrease. > >> > > >> > 3. Immersive media standard > >> > Normally the camera manufactures provide video stitching software, > >> > they defined private camera calibration parameters, these are very > >> > critical to stitching quality. I know MPEG is making proposal on > >> > transfer these meta-data in video stream, this will help compose > >> > immersive media on cloud or edge server. I think it's a good idea to > >> > create such a video filter in FFMpeg pipeline. > >> > > >> > 4. Why not implement stitching inside FFMpeg video filter > >> > The algorithms are complexity and the performance are also > >> > important, the stitching function manage computing resource for > >> > example thread handling, image data block dispatching. Personally I > >> > think we don't need to construct a wheel from the beginning. > >> > >> Number of supported pixel formats are rather very low. > > > >Do you mean the pixel format (NV12 & YUV420) that xcam filter > supported > > is not enough? > > xcam filter works as a post processing component between video decoder > and > > encoder, we suppose the data comes from camera or stored video clips, so > it > > handles YUV format. > > libxcam algorithm optimization highly depends on pixel layout, to support > > YUV422 or YUV444 will cost much effort, we do not meet the requirement > till > > now. > > Ok then, I thought library provided support for it already. > > Supporting only few pixel formats is very limited functionality IMHO. > > > > > > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org > >> with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- --- *^_^* Many Thanks & Best Regards! Amy Zhao 赵娟 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/put_bits: Make skip_put_bits() less dangerous
Before c63c303a1f2b58677d480505ec93a90f77dd25b5 (the commit which
introduced a typedef for the type of the buffer of a PutBitContext)
skip_put_bits() was as follows:
static inline void skip_put_bits(PutBitContext *s, int n)
{
s->bit_left -= n;
s->buf_ptr -= 4 * (s->bit_left >> 5);
s->bit_left &= 31;
}
If s->bit_left was negative after the first subtraction, then the next
line will divide this by 32 with rounding towards -inf and multiply by
four; the result will be negative, of course.
The aforementioned commit changed this to:
static inline void skip_put_bits(PutBitContext *s, int n)
{
s->bit_left -= n;
s->buf_ptr -= sizeof(BitBuf) * ((unsigned)s->bit_left / BUF_BITS);
s->bit_left &= (BUF_BITS - 1);
}
Casting s->bit_left to unsigned meant that the rounding is still towards
-inf; yet the right side is now always positive (it transformed the
arithmetic shift into a logical shift), so that s->buf_ptr will always
be decremented (by about UINT_MAX / 8 unless n is huge) which leads to
segfaults on further usage and is already undefined pointer arithmetic
before that. This can be reproduced with the mpeg4 encoder with the
AV_CODEC_FLAG2_NO_OUTPUT flag set.
Furthermore, the earlier version as well as the new version share
another bug: s->bit_left will be in the range of 0..(BUF_BITS - 1)
afterwards, although the assumption throughout the other PutBitContext
functions is that it is in the range of 1..BUF_BITS. This might lead to
a shift by BUF_BITS in little-endian mode. This has been fixed, too.
The new version is furthermore able to skip zero bits, too.
Signed-off-by: Andreas Rheinhardt
---
1. skip_put_bits() is still bad even after this: If one skips so few that
buf_ptr will not change, the non-skipped bits in the buffer will be
wrong in case of a big-endian reader (they would need to be shifted by
the number of bits to be skipped for this to work*). If one skips so much
that buf_ptr does change, all the valid bits in the buffer will not be
output at the place where they should have been output.
2. Since c63c303a1f2b58677d480505ec93a90f77dd25b5 sizeof(BitBuf) is used
in several comparisons like s->buf_end - s->buf_ptr >= sizeof(BitBuf)
where an immediate (of type int) has been used before. This is a
problem if one is already past the end of the buffer, because the left
side will (typically) be converted to size_t. With the current API, this
can only happen when skip_put_bits() and set_put_bits_buffer_size() are
used (or if one modifies the PutBitContext manually). But it would be a
problem if we would add an unchecked version of this API for users that
do their own checks and if said user would want to use padding in a
controlled manner to be able to minimize the amount of checks.
3. Should the "Internal error, put_bits buffer too small" error message
without proper logcontext be removed just like the one in
get_ue_golomb() was in 39c4b788297b7883d833d68fad3707ce50e01472?
(It could of course be used for the av_assert2 message.)
*: For a big-endian writer, the already buffered bits occupy the least
significant bits of the buffer. If they were already put into their
final position, one would need to disallow/special-case writing zero bits
with put_bits() (but it could then automatically be used to write up to
BIT_BUF bits).
libavcodec/put_bits.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index ddd97906b2..3ba9549948 100644
--- a/libavcodec/put_bits.h
+++ b/libavcodec/put_bits.h
@@ -364,13 +364,13 @@ static inline void skip_put_bytes(PutBitContext *s, int n)
/**
* Skip the given number of bits.
* Must only be used if the actual values in the bitstream do not matter.
- * If n is 0 the behavior is undefined.
+ * If n is < 0 the behavior is undefined.
*/
static inline void skip_put_bits(PutBitContext *s, int n)
{
-s->bit_left -= n;
-s->buf_ptr -= sizeof(BitBuf) * ((unsigned)s->bit_left / BUF_BITS);
-s->bit_left &= (BUF_BITS - 1);
+unsigned bits = BUF_BITS - s->bit_left + n;
+s->buf_ptr += sizeof(BitBuf) * (bits / BUF_BITS);
+s->bit_left = BUF_BITS - (bits & (BUF_BITS - 1));
}
/**
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/g723_1enc: Avoid skip_put_bits()
If a bit is reserved, it matters very much what value it has, because
otherwise a decoder conforming to a future version of the standard might
interpret the output file in an unintended manner. This implies that
one must not use skip_put_bits() for it (which does not give any
guarantees wrt what ends up in the output (in case of a little-endian
bitstream writer (as here) it writes a 0 bit)); given that the reference
encoder as well as the earlier code write a zero bit at this place, the
new code does, too.
Signed-off-by: Andreas Rheinhardt
---
The earlier code here was unaffected by any of the bugs of
skip_put_bits, because this code uses a little-endian writer and
the number of bits written so far was always even, so that skipping
a single bit could be done in the buffer itself.
libavcodec/g723_1enc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/g723_1enc.c b/libavcodec/g723_1enc.c
index 592840566e..b2ba3c2230 100644
--- a/libavcodec/g723_1enc.c
+++ b/libavcodec/g723_1enc.c
@@ -1030,7 +1030,7 @@ static int pack_bitstream(G723_1_ChannelContext *p,
AVPacket *avpkt)
put_bits(&pb, 1, p->subframe[3].grid_index);
if (p->cur_rate == RATE_6300) {
-skip_put_bits(&pb, 1); /* reserved bit */
+put_bits(&pb, 1, 0); /* reserved bit */
/* Write 13 bit combined position index */
temp = (p->subframe[0].pulse_pos >> 16) * 810 +
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Building with WSL instead of MSYS?
On 31.07.2020 09:41, Julio César Rocha wrote: Hi. I recently submitted a patch to enable building the Windows flavor with Windows Subsystem for Linux as an alternative to MSYS / CYGWIN. I got the feedback that people are already able to achieve this. Has anyone achieved this without patching the sources (out of the box)? If so, could you please share your config steps? I'm building ffmpeg in WSL for over a year now, if not longer. Never needed any patches or anything. For all that ffmpegs build system is concerned it's a normal cross-compile from Linux to Windows. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Building with WSL instead of MSYS?
Do you use the MSVC compilers? If so, how do you get around compiling linux-type absolute paths with cl.exe? (i.e. /home/user/src/ffmpeg/dir/file.c). Microsoft's CL.EXE does not accept paths beginning with a forward slash. On Fri, Jul 31, 2020 at 4:02 AM Timo Rothenpieler wrote: > On 31.07.2020 09:41, Julio César Rocha wrote: > > Hi. I recently submitted a patch to enable building the Windows flavor > with > > Windows Subsystem for Linux as an alternative to MSYS / CYGWIN. > > > > I got the feedback that people are already able to achieve this. > > > > Has anyone achieved this without patching the sources (out of the box)? > > If so, could you please share your config steps? > > I'm building ffmpeg in WSL for over a year now, if not longer. > Never needed any patches or anything. > For all that ffmpegs build system is concerned it's a normal > cross-compile from Linux to Windows. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/8] avcodec/smacker: Remove write-only and unused variables
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 8
1 file changed, 8 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 9f054f071d..e53183318e 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -59,7 +59,6 @@ typedef struct SmackVContext {
*/
typedef struct HuffContext {
int length;
-int maxlength;
int current;
uint32_t *bits;
int *lengths;
@@ -72,7 +71,6 @@ typedef struct DBCtx {
int *recode1, *recode2;
int escapes[3];
int *last;
-int lcur;
} DBCtx;
/* possible runs of blocks */
@@ -116,8 +114,6 @@ static int smacker_decode_tree(GetBitContext *gb,
HuffContext *hc, uint32_t pref
}
hc->values[hc->current] = get_bits(gb, 8);
hc->current++;
-if(hc->maxlength < length)
-hc->maxlength = length;
return 0;
} else { //Node
int r;
@@ -200,14 +196,12 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
}
tmp1.length = 256;
-tmp1.maxlength = 0;
tmp1.current = 0;
tmp1.bits = av_mallocz(256 * 4);
tmp1.lengths = av_mallocz(256 * sizeof(int));
tmp1.values = av_mallocz(256 * sizeof(int));
tmp2.length = 256;
-tmp2.maxlength = 0;
tmp2.current = 0;
tmp2.bits = av_mallocz(256 * 4);
tmp2.lengths = av_mallocz(256 * sizeof(int));
@@ -277,7 +271,6 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
ctx.last = last;
huff.length = ((size + 3) >> 2) + 4;
-huff.maxlength = 0;
huff.current = 0;
huff.values = av_mallocz_array(huff.length, sizeof(int));
if (!huff.values) {
@@ -690,7 +683,6 @@ static int smka_decode_frame(AVCodecContext *avctx, void
*data,
// Initialize
for(i = 0; i < (1 << (bits + stereo)); i++) {
h[i].length = 256;
-h[i].maxlength = 0;
h[i].current = 0;
h[i].bits = av_mallocz(256 * 4);
h[i].lengths = av_mallocz(256 * sizeof(int));
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/8] avcodec/smacker: Don't warn for Huffmann tables with one element
The Huffmann tables used by Smacker can consist of exactly one leaf only
in which case the length of the corresponding code is zero; there is
then exactly one value encoded. Our VLC can't handle this and therefore
this case needs to be treated separately; it has been implemented in
commit 48cbdaea157671d456750e00fde37c6d7595fad6. Yet said commit also
made the decoder emit an error message (despite not erroring out) in this
case, although it seems that this is rather a limitation of our VLC API.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index e53183318e..3c9f118fb7 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -229,8 +229,7 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
goto error;
}
}
-}
-if (!vlc[0].table) {
+} else {
av_log(smk->avctx, AV_LOG_ERROR, "Skipping low bytes tree\n");
}
if(get_bits1(gb)){
@@ -250,8 +249,7 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
goto error;
}
}
-}
-if (!vlc[1].table) {
+} else {
av_log(smk->avctx, AV_LOG_ERROR, "Skipping high bytes tree\n");
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/8] avcodec/smacker: Improve header table error checks
The extradata for Smacker video contains Huffman trees as well as a
field containing the size (in bytes) of said Huffman tree when stored
as a table. Due to three special values the decoder allocates more than
the size field indicates; yet when it parses the table it only errors
out if the number of elements exceeds the number of allocated elements
and not the number of elements as indicated by the size field. As a
consequence, there might be less than three elements available at the
end, so that another check for this is necessary.
This commit changes this: It is always made sure that the three elements
reserved to (potentially) use them to store the special values are not
used to store ordinary tree entries. This allows to remove the extra
check at the end.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index b6245a0ce1..8a4d88cfed 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -137,7 +137,7 @@ static int smacker_decode_bigtree(GetBitContext *gb,
HuffContext *hc,
return AVERROR_INVALIDDATA;
}
-if (hc->current + 1 >= hc->length) {
+if (hc->current >= hc->length) {
av_log(NULL, AV_LOG_ERROR, "Tree size exceeded!\n");
return AVERROR_INVALIDDATA;
}
@@ -244,9 +244,9 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
ctx.recode2 = h[1].values;
ctx.last = last;
-huff.length = ((size + 3) >> 2) + 4;
+huff.length = (size + 3) >> 2;
huff.current = 0;
-huff.values = av_mallocz_array(huff.length, sizeof(int));
+huff.values = av_mallocz_array(huff.length + 3, sizeof(huff.values[0]));
if (!huff.values) {
err = AVERROR(ENOMEM);
goto error;
@@ -259,12 +259,6 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
if(ctx.last[0] == -1) ctx.last[0] = huff.current++;
if(ctx.last[1] == -1) ctx.last[1] = huff.current++;
if(ctx.last[2] == -1) ctx.last[2] = huff.current++;
-if (ctx.last[0] >= huff.length ||
-ctx.last[1] >= huff.length ||
-ctx.last[2] >= huff.length) {
-av_log(smk->avctx, AV_LOG_ERROR, "Huffman codes out of range\n");
-err = AVERROR_INVALIDDATA;
-}
*recodes = huff.values;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/8] avcodec/smacker: Remove code duplication when decoding header trees
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 83 +++-
1 file changed, 28 insertions(+), 55 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 3c9f118fb7..b6245a0ce1 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -184,7 +184,7 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
{
int res;
HuffContext huff;
-HuffContext tmp1, tmp2;
+HuffContext h[2] = { 0 };
VLC vlc[2] = { { 0 } };
int escapes[3];
DBCtx ctx;
@@ -195,62 +195,38 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
return AVERROR_INVALIDDATA;
}
-tmp1.length = 256;
-tmp1.current = 0;
-tmp1.bits = av_mallocz(256 * 4);
-tmp1.lengths = av_mallocz(256 * sizeof(int));
-tmp1.values = av_mallocz(256 * sizeof(int));
-
-tmp2.length = 256;
-tmp2.current = 0;
-tmp2.bits = av_mallocz(256 * 4);
-tmp2.lengths = av_mallocz(256 * sizeof(int));
-tmp2.values = av_mallocz(256 * sizeof(int));
-if (!tmp1.bits || !tmp1.lengths || !tmp1.values ||
-!tmp2.bits || !tmp2.lengths || !tmp2.values) {
-err = AVERROR(ENOMEM);
-goto error;
-}
-
-if(get_bits1(gb)) {
-res = smacker_decode_tree(gb, &tmp1, 0, 0);
-if (res < 0) {
-err = res;
+for (int i = 0; i < 2; i++) {
+h[i].length = 256;
+h[i].current = 0;
+h[i].bits= av_mallocz(256 * sizeof(h[i].bits[0]));
+h[i].lengths = av_mallocz(256 * sizeof(h[i].lengths[0]));
+h[i].values = av_mallocz(256 * sizeof(h[i].values[0]));
+if (!h[i].bits || !h[i].lengths || !h[i].values) {
+err = AVERROR(ENOMEM);
goto error;
}
-skip_bits1(gb);
-if(tmp1.current > 1) {
-res = init_vlc(&vlc[0], SMKTREE_BITS, tmp1.length,
-tmp1.lengths, sizeof(int), sizeof(int),
-tmp1.bits, sizeof(uint32_t), sizeof(uint32_t),
INIT_VLC_LE);
-if(res < 0) {
-av_log(smk->avctx, AV_LOG_ERROR, "Cannot build VLC table\n");
-err = res;
-goto error;
-}
+if (!get_bits1(gb)) {
+av_log(smk->avctx, AV_LOG_ERROR, "Skipping %s bytes tree\n",
+ i ? "high" : "low");
+continue;
}
-} else {
-av_log(smk->avctx, AV_LOG_ERROR, "Skipping low bytes tree\n");
-}
-if(get_bits1(gb)){
-res = smacker_decode_tree(gb, &tmp2, 0, 0);
+res = smacker_decode_tree(gb, &h[i], 0, 0);
if (res < 0) {
err = res;
goto error;
}
skip_bits1(gb);
-if(tmp2.current > 1) {
-res = init_vlc(&vlc[1], SMKTREE_BITS, tmp2.length,
-tmp2.lengths, sizeof(int), sizeof(int),
-tmp2.bits, sizeof(uint32_t), sizeof(uint32_t),
INIT_VLC_LE);
+if (h[i].current > 1) {
+res = init_vlc(&vlc[i], SMKTREE_BITS, h[i].length,
+ INIT_VLC_DEFAULT_SIZES(h[i].lengths),
+ INIT_VLC_DEFAULT_SIZES(h[i].bits),
+ INIT_VLC_LE);
if(res < 0) {
av_log(smk->avctx, AV_LOG_ERROR, "Cannot build VLC table\n");
err = res;
goto error;
}
}
-} else {
-av_log(smk->avctx, AV_LOG_ERROR, "Skipping high bytes tree\n");
}
escapes[0] = get_bits(gb, 16);
@@ -264,8 +240,8 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
ctx.escapes[2] = escapes[2];
ctx.v1 = &vlc[0];
ctx.v2 = &vlc[1];
-ctx.recode1 = tmp1.values;
-ctx.recode2 = tmp2.values;
+ctx.recode1 = h[0].values;
+ctx.recode2 = h[1].values;
ctx.last = last;
huff.length = ((size + 3) >> 2) + 4;
@@ -293,16 +269,13 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
*recodes = huff.values;
error:
-if(vlc[0].table)
-ff_free_vlc(&vlc[0]);
-if(vlc[1].table)
-ff_free_vlc(&vlc[1]);
-av_free(tmp1.bits);
-av_free(tmp1.lengths);
-av_free(tmp1.values);
-av_free(tmp2.bits);
-av_free(tmp2.lengths);
-av_free(tmp2.values);
+for (int i = 0; i < 2; i++) {
+if (vlc[i].table)
+ff_free_vlc(&vlc[i]);
+av_free(h[i].bits);
+av_free(h[i].lengths);
+av_free(h[i].values);
+}
return err;
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/8] avcodec/vlc: Add macro for ff_init_vlc_sparse()
ff_init_vlc_sparse() supports arrays of uint8_t, uint16_t and uint32_t
as input (and it also supports padding/other elements in between the
elements). This makes the typical case in which the input is a simple
array more cumbersome. E.g. for an array of uint8_t one would either
need to call the function with arguments like "array, sizeof(array[0]),
sizeof(array[0])" or with "array, 1, 1". The former is nicer, but
longer, so that the latter is mostly used. Therefore this commit adds a
macro that expands to the sizeof() construct.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vlc.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vlc.h b/libavcodec/vlc.h
index 42ccddf3fc..7cb323b62c 100644
--- a/libavcodec/vlc.h
+++ b/libavcodec/vlc.h
@@ -35,7 +35,12 @@ typedef struct RL_VLC_ELEM {
uint8_t run;
} RL_VLC_ELEM;
-#define init_vlc(vlc, nb_bits, nb_codes,\
+#define INIT_VLC_DEFAULT_SIZES(ptr) \
+(ptr), sizeof((ptr)[0]), sizeof((ptr)[0])
+
+#define init_vlc(...) init_vlc2(__VA_ARGS__)
+
+#define init_vlc2(vlc, nb_bits, nb_codes, \
bits, bits_wrap, bits_size,\
codes, codes_wrap, codes_size, \
flags) \
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/8] avcodec/smacker: Directly goto error in case of error
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 8a4d88cfed..4b1f0f1b7c 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -251,17 +251,18 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
err = AVERROR(ENOMEM);
goto error;
}
+*recodes = huff.values;
res = smacker_decode_bigtree(gb, &huff, &ctx, 0);
-if (res < 0)
+if (res < 0) {
err = res;
+goto error;
+}
skip_bits1(gb);
if(ctx.last[0] == -1) ctx.last[0] = huff.current++;
if(ctx.last[1] == -1) ctx.last[1] = huff.current++;
if(ctx.last[2] == -1) ctx.last[2] = huff.current++;
-*recodes = huff.values;
-
error:
for (int i = 0; i < 2; i++) {
if (vlc[i].table)
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 7/8] avcodec/smacker: Use same variable for return values and errors
smacker_decode_header_tree() uses different variables for return values
(res) and for errors (err) leading to code like
res = foo(bar);
if (res < 0) {
err = res;
goto error;
}
Given that no positive return value is ever used at all one can simplify
the above by removing the intermediate res.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 4b1f0f1b7c..07fa8887d8 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -182,13 +182,12 @@ static int smacker_decode_bigtree(GetBitContext *gb,
HuffContext *hc,
*/
static int smacker_decode_header_tree(SmackVContext *smk, GetBitContext *gb,
int **recodes, int *last, int size)
{
-int res;
HuffContext huff;
HuffContext h[2] = { 0 };
VLC vlc[2] = { { 0 } };
int escapes[3];
DBCtx ctx;
-int err = 0;
+int err;
if(size >= UINT_MAX>>4){ // (((size + 3) >> 2) + 3) << 2 must not overflow
av_log(smk->avctx, AV_LOG_ERROR, "size too large\n");
@@ -210,20 +209,17 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
i ? "high" : "low");
continue;
}
-res = smacker_decode_tree(gb, &h[i], 0, 0);
-if (res < 0) {
-err = res;
+err = smacker_decode_tree(gb, &h[i], 0, 0);
+if (err < 0)
goto error;
-}
skip_bits1(gb);
if (h[i].current > 1) {
-res = init_vlc(&vlc[i], SMKTREE_BITS, h[i].length,
+err = init_vlc(&vlc[i], SMKTREE_BITS, h[i].length,
INIT_VLC_DEFAULT_SIZES(h[i].lengths),
INIT_VLC_DEFAULT_SIZES(h[i].bits),
INIT_VLC_LE);
-if(res < 0) {
+if (err < 0) {
av_log(smk->avctx, AV_LOG_ERROR, "Cannot build VLC table\n");
-err = res;
goto error;
}
}
@@ -253,16 +249,15 @@ static int smacker_decode_header_tree(SmackVContext *smk,
GetBitContext *gb, int
}
*recodes = huff.values;
-res = smacker_decode_bigtree(gb, &huff, &ctx, 0);
-if (res < 0) {
-err = res;
+err = smacker_decode_bigtree(gb, &huff, &ctx, 0);
+if (err < 0)
goto error;
-}
skip_bits1(gb);
if(ctx.last[0] == -1) ctx.last[0] = huff.current++;
if(ctx.last[1] == -1) ctx.last[1] = huff.current++;
if(ctx.last[2] == -1) ctx.last[2] = huff.current++;
+err = 0;
error:
for (int i = 0; i < 2; i++) {
if (vlc[i].table)
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 8/8] avcodec/smacker: Forward error codes
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 07fa8887d8..9ba70af6f7 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -653,18 +653,15 @@ static int smka_decode_frame(AVCodecContext *avctx, void
*data,
goto error;
}
skip_bits1(&gb);
-if (smacker_decode_tree(&gb, &h[i], 0, 0) < 0) {
-ret = AVERROR_INVALIDDATA;
+if ((ret = smacker_decode_tree(&gb, &h[i], 0, 0)) < 0)
goto error;
-}
skip_bits1(&gb);
if(h[i].current > 1) {
-res = init_vlc(&vlc[i], SMKTREE_BITS, h[i].length,
+ret = init_vlc(&vlc[i], SMKTREE_BITS, h[i].length,
h[i].lengths, sizeof(int), sizeof(int),
h[i].bits, sizeof(uint32_t), sizeof(uint32_t),
INIT_VLC_LE);
-if(res < 0) {
+if (ret < 0) {
av_log(avctx, AV_LOG_ERROR, "Cannot build VLC table\n");
-ret = AVERROR_INVALIDDATA;
goto error;
}
}
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Building with WSL instead of MSYS?
On 31.07.2020 13:17, Julio César Rocha wrote: Do you use the MSVC compilers? If so, how do you get around compiling linux-type absolute paths with cl.exe? (i.e. /home/user/src/ffmpeg/dir/file.c). Microsoft's CL.EXE does not accept paths beginning with a forward slash. I don't, why would I? I just installed mingw via Ubuntu repos. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: Remove unnecessary initializations
Please help review the patch, thanks! > On Jul 26, 2020, at 1:30 PM, Zhao Zhili wrote: > > pre_tag_size is always reset by avio_rb32(). For AVFormatContext > start_time, as the document says, "NEVER set this value directly: > It is deduced from the AVStream values." > --- > fix commit subject > libavformat/flvdec.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c > index 08622739f3..31bdbbd5e9 100644 > --- a/libavformat/flvdec.c > +++ b/libavformat/flvdec.c > @@ -747,7 +747,7 @@ static int flv_read_header(AVFormatContext *s) > int flags; > FLVContext *flv = s->priv_data; > int offset; > -int pre_tag_size = 0; > +int pre_tag_size; > > /* Actual FLV data at 0xe4 in KUX file */ > if(!strcmp(s->iformat->name, "kux")) > @@ -773,7 +773,6 @@ static int flv_read_header(AVFormatContext *s) > av_log(s, AV_LOG_WARNING, "Read FLV header error, input file is not a > standard flv format, first PreviousTagSize0 always is 0\n"); > } > > -s->start_time = 0; > flv->sum_flv_tag_size = 0; > flv->last_keyframe_stream_index = -1; > > -- > 2.25.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Project orientation
On Sun, Jul 5, 2020 at 5:26 AM Jean-Baptiste Kempf wrote:
> On Sat, Jul 4, 2020, at 19:44, Michael Niedermayer wrote:
> > Another area as we are already on the subject is stuff falling a little
> > outside what FFmpeg covers.
> > Not every filter that anyone wants to write should have to be in FFmpeg
>
> Thank $deity that you are saying this!
>
> FFmpeg is used more and more and numerous people want to put everything in
> it.
>
> The project needs to learn to say no to features and define the scope of
> each library.
>
> For libavcodec, the scope is quite clear, even if there are some debates
> about experimental codecs.
>
> But for the other libraries, including avformat and avfilter, there are
> dubious things in.
>
> For example and in my opinion, I don't see why there is support in
> avformat for things that are not standards, like AMQP/ZMQ, who are neither
> a multimedia format nor a multimedia protocol.
> In the same way, if you start to need tensorflow or openvinno for a
> filter, the code has no place in FFmpeg: you can use the api and use that
> externally. Importing tensorflow is probably more lines of code, than
> FFMpeg.
> Or speech-recognition (sphinx) or OCR (tesseract)...
> And now comes the debate with synthesizers or complex filters that are
> almost reinventing GStreamer inside libavfilter ("let's use libavcodec as a
> filter, since everything is a filter")...
>
> When you look at the FFmpeg dependency graph on distributions like Debian,
> this is getting scrary, and this increases a lot the binary size and
> resources usage.
>
> At some point, the project needs to decide what is in and what is out, and
> since FFmpeg has numerous APIs, people can plug them externally. It's not a
> problem to say "No" to a feature, especially when, the number of people
> using that feature is under 0,01% of FFmpeg users, and when people can
> build that externally anyway.
>
It's a good point, looking forward to the "plugin" mechanism.
Frankly speaking, some of the filters don't have to be upstreamed to
FFmpeg, but cloud service providers are using FFmpeg to build the media
pipeline. So the filters may receive some requirements to provide the
functionality through FFmpeg.
If developers can provide a standalone plugin to FFmpeg, and host them by
their own, that's something good, and reduce the complexity of FFmpeg.
But for now, developers can only maintain a patchset which may not be able
to upstream for many reasons.
Thanks,
Juan
>
>
> --
> Jean-Baptiste Kempf - President
> +33 672 704 734
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Building with WSL instead of MSYS?
You would, if you had to or wanted to use the Microsoft compilers, as in my case. So, in summary, your use case is different to what I’m trying to do. On Fri, Jul 31, 2020 at 04:26 Timo Rothenpieler wrote: > On 31.07.2020 13:17, Julio César Rocha wrote: > > Do you use the MSVC compilers? > > If so, how do you get around compiling linux-type absolute paths with > > cl.exe? (i.e. /home/user/src/ffmpeg/dir/file.c). > > Microsoft's CL.EXE does not accept paths beginning with a forward slash. > > > > I don't, why would I? > I just installed mingw via Ubuntu repos. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.
Jul 31, 2020, 10:48 by geo...@nsup.org: > Tables that were not just written by the code author are > not actually source code, otherwise, > "recode data..x1 < proprietary.o > source.c" > would be enough to launder a proprietary blob into > the source code. > > Documenting the origin of the tables or the methods > for their generation is necessary to let other developers > take over if the original author is no longer available. > I disagree. We don't have any proprietary blobs in our codebase. Everything that you think is binary is in fact a well defined VLC table that simply describes bit positions and lengths. Neither are quantization tables. They're again, well defined series of lookup tables that always follow a simple pattern, be it linear or some exponent. Forcing developers to meticulously describe standard bitstream readers or copying entire chunks of specifications as comments just because you don't understand them, or want to justify your own personal war, or are paranoid of binary blobs is not acceptable. In the first place no one would commit actual binary blobs (read: CPU-specific bytecode or a series of bytes needed to initialize a device) to the codebase. And if developers were forced to copy chunks of spec as comments into the codebase you'll end up with licensed content just sitting in the codebase, making us liable for lawsuits. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Building with WSL instead of MSYS?
On Fri, 31 Jul 2020 at 13:26, Timo Rothenpieler wrote: > On 31.07.2020 13:17, Julio César Rocha wrote: > > Do you use the MSVC compilers? > > If so, how do you get around compiling linux-type absolute paths with > > cl.exe? (i.e. /home/user/src/ffmpeg/dir/file.c). > > Microsoft's CL.EXE does not accept paths beginning with a forward slash. > > > > I don't, why would I? > I just installed mingw via Ubuntu repos. > You would want to use MSVC if you want to build shared libs and use them with any other application that is compiled using MSVC or Intel C++. struct layout is in C is compiler implementation specific (without programmer intervention). And many functions use structs as for parameters making ffmpeg shared libs compiled by GCC unusable in an application compiled with MSVC ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.
> /* Geometric progression with ratio 42. */
>
> Or, if you used a one-liner in whatever language of your choice, just
> copy-paste it into the comment:
>
> /* Zsh: for i in {0..11}; printf "%8x\\n" $[440*2**(22+i/12.)] */
>
This is completely unrealistic for reverse engineered tables such as VLCs
which have no mathematical basis.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Building with WSL instead of MSYS?
On 31.07.2020 14:11, Julio César Rocha wrote: You would, if you had to or wanted to use the Microsoft compilers, as in my case. Just tested with msvc in WSL(i.e. launch wsl.exe from within a x64 native tools cmd), and it works just fine as well without any modifications made. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/developer: origin of tables should be documented.
Kieran Kunhya (12020-07-31):
> > /* Geometric progression with ratio 42. */
> >
> > Or, if you used a one-liner in whatever language of your choice, just
> > copy-paste it into the comment:
> >
> > /* Zsh: for i in {0..11}; printf "%8x\\n" $[440*2**(22+i/12.)] */
>
> This is completely unrealistic for reverse engineered tables such as VLCs
> which have no mathematical basis.
Duh. For reverse-engineered codecs, I expect a comment with at least the
word "reverse-engineered".
Something like this would be acceptable:
/* Reverse-engineered by encoding various files with the reference
encoder. */
Reluctance to give this little information is baffling to me.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/mxfdec: Read color metadata from MXF
On 7/31/20, Harry Mallon wrote: > Hi, > > V2 fixes all the fate tests (I didn't know to download the test footage > before. Doh). > > The following patch adds reading colour metadata (transfer, primaries and > colour space) from > standard MXF files. I wrote it without seeing the other patch but it turned > out very similar to this > one that was never merged. > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/1474694344-31167-1-git-send-email-ste...@strobe.cc/ > . > > Thanks. > Harry > > From d16966e6b0a6367a5e5445987c0449fb1150785a Mon Sep 17 00:00:00 2001 > > From: Harry Mallon > Date: Mon, 27 Jul 2020 15:52:17 +0100 > Subject: [PATCH] avformat/mxfdec: Read color metadata from MXF > > Reads color_primaries, color_trc and color_space from mxf > headers. ULs are from https://registry.smpte-ra.org/ site. > > Signed-off-by: Harry Mallon > --- > libavformat/mxf.c | 49 + > libavformat/mxf.h | 3 ++ > libavformat/mxfdec.c| 15 > tests/ref/fate/mxf-d10-user-comments| 2 +- > tests/ref/fate/mxf-opatom-user-comments | 2 +- > tests/ref/fate/mxf-probe-d10| 2 +- > tests/ref/fate/mxf-probe-dnxhd | 4 +- > tests/ref/fate/mxf-probe-dv25 | 2 +- > tests/ref/fate/mxf-reel_name| 2 +- > tests/ref/fate/mxf-user-comments| 2 +- > 10 files changed, 75 insertions(+), 8 deletions(-) > LGTM, but better wait for actual maintainer(s). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/8] avcodec/smacker: Remove write-only and unused variables
probably ok
On 7/31/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/smacker.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
> index 9f054f071d..e53183318e 100644
> --- a/libavcodec/smacker.c
> +++ b/libavcodec/smacker.c
> @@ -59,7 +59,6 @@ typedef struct SmackVContext {
> */
> typedef struct HuffContext {
> int length;
> -int maxlength;
> int current;
> uint32_t *bits;
> int *lengths;
> @@ -72,7 +71,6 @@ typedef struct DBCtx {
> int *recode1, *recode2;
> int escapes[3];
> int *last;
> -int lcur;
> } DBCtx;
>
> /* possible runs of blocks */
> @@ -116,8 +114,6 @@ static int smacker_decode_tree(GetBitContext *gb,
> HuffContext *hc, uint32_t pref
> }
> hc->values[hc->current] = get_bits(gb, 8);
> hc->current++;
> -if(hc->maxlength < length)
> -hc->maxlength = length;
> return 0;
> } else { //Node
> int r;
> @@ -200,14 +196,12 @@ static int smacker_decode_header_tree(SmackVContext
> *smk, GetBitContext *gb, int
> }
>
> tmp1.length = 256;
> -tmp1.maxlength = 0;
> tmp1.current = 0;
> tmp1.bits = av_mallocz(256 * 4);
> tmp1.lengths = av_mallocz(256 * sizeof(int));
> tmp1.values = av_mallocz(256 * sizeof(int));
>
> tmp2.length = 256;
> -tmp2.maxlength = 0;
> tmp2.current = 0;
> tmp2.bits = av_mallocz(256 * 4);
> tmp2.lengths = av_mallocz(256 * sizeof(int));
> @@ -277,7 +271,6 @@ static int smacker_decode_header_tree(SmackVContext
> *smk, GetBitContext *gb, int
> ctx.last = last;
>
> huff.length = ((size + 3) >> 2) + 4;
> -huff.maxlength = 0;
> huff.current = 0;
> huff.values = av_mallocz_array(huff.length, sizeof(int));
> if (!huff.values) {
> @@ -690,7 +683,6 @@ static int smka_decode_frame(AVCodecContext *avctx, void
> *data,
> // Initialize
> for(i = 0; i < (1 << (bits + stereo)); i++) {
> h[i].length = 256;
> -h[i].maxlength = 0;
> h[i].current = 0;
> h[i].bits = av_mallocz(256 * 4);
> h[i].lengths = av_mallocz(256 * sizeof(int));
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/ratecontrol: Fix error logging for parsing and evaluation of rc_eq
On Thu, Jul 30, 2020 at 02:42:30PM +0200, Alexander Strasser wrote: > Don't pass a potential NULL pointer to av_log, instead use a default > in the rc_eq AVOption definitions. Now the context variable always > holds a string; even if it's the default expression. > > Note this also fixes the evaluation error path, where a similar > av_log references the rc_eq string from the context too. > --- > libavcodec/mpegvideo.h | 2 +- > libavcodec/ratecontrol.c | 3 +-- > 2 files changed, 2 insertions(+), 3 deletions(-) crashes with: ./ffmpeg -i matrixbench_mpeg2.mpg -vcodec snow -y file.avi ==22043== Invalid read of size 1 ==22043==at 0x4C32CF2: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==22043==by 0x10A83AD: av_expr_parse (in ffmpeg-git/ffmpeg/ffmpeg_g) ==22043==by 0x2858ED: ff_rate_control_init (in ffmpeg-git/ffmpeg/ffmpeg_g) ==22043==by 0x28A668: encode_init (in ffmpeg-git/ffmpeg/ffmpeg_g) ==22043==by 0xA7E2D0: avcodec_open2 (in ffmpeg-git/ffmpeg/ffmpeg_g) ==22043==by 0x2F196A: init_output_stream.constprop.24 (in ffmpeg-git/ffmpeg/ffmpeg_g) ==22043==by 0x2F383A: reap_filters (in ffmpeg-git/ffmpeg/ffmpeg_g) ==22043==by 0x2F78D7: transcode (in ffmpeg-git/ffmpeg/ffmpeg_g) ==22043==by 0x2D093B: main (in ffmpeg-git/ffmpeg/ffmpeg_g) ==22043== Address 0x0 is not stack'd, malloc'd or (recently) free'd if you cannot reproduce, say so and ill make a more detailed backtrace thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [aarch64] improve hscale by 50% with multi-threading
On Thu, Jul 30, 2020 at 01:32:47AM -0500, Sebastian Pop wrote: > On Sat, Jul 18, 2020 at 1:35 AM Michael Niedermayer > wrote: > > > Multithreading support should be added in a architecture independant way > > > > > Attached patch moves helper threads up from hscale to > chr_h_scale and lum_h_scale in an architecture independent way. > This new version of the patch improves performance > by up to 135% on Graviton2 Arm64 and by up to 95% on Intel. > Compared to the previous version of the patch, > there is more uninterrupted work per thread that results > in better performance. > > Please let me know how I can improve the patch. the thread code is duplicated between chr_h_scale & lum_h_scale, this would become messy if its done with more functions. HT_NUM seems always 0 indention is inconsistent also i see a sched_yield() in there, some other form of thread sync is probably better The HT_NUM sized arrays might have their elements moved into a struct so its a single array of structs. Just thinking that might look neater > > There are other functions (lum_convert and chr_convert) > that may benefit from multi-threading. > I have not seen these functions appearing on a hot profile. > Is there a benchmark for those functions? you can just put a abort() in the function you are interrested to test then run make fate -k the failing tests are potential testcases Also this swscale MT work is quite welcome, the benefit speedwise should be substantial Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] RTSP - Increasing the buffer size of control URI to 2048 chars
Attached patch increases the max length of control URI to 2048 characters, as urls of some RTSP streams do exceed this limit. 0001-Increasing-the-max-length-of-control-URI-to-2048-cha.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Commit a500b975 removed NULL input handling from this function,
moving the check higher up the call tree in one branch. However,
there is another call to set_string_video_rate() which may pass
NULL, and future users of the function may not be clear that
a NULL check is required. This patch restores the NULL check to
avoid these problems.
---
libavutil/opt.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c8413fa5e1..9f36dc89a9 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -333,7 +333,13 @@ static int set_string_image_size(void *obj, const AVOption
*o, const char *val,
static int set_string_video_rate(void *obj, const AVOption *o, const char
*val, AVRational *dst)
{
-int ret = av_parse_video_rate(dst, val);
+int ret;
+
+if (!val) {
+av_log(obj, AV_LOG_ERROR, "NULL passed as video rate\n");
+return AVERROR(EINVAL);
+}
+ret = av_parse_video_rate(dst, val);
if (ret < 0)
av_log(obj, AV_LOG_ERROR, "Unable to parse option value \"%s\" as
video rate\n", val);
return ret;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/opt: Restore NULL input handling to set_string_video_rate()
Hi On Fri, Jul 31, 2020 at 03:53:56PM +0100, Jack Haughton wrote: > Commit a500b975 removed NULL input handling from this function, > moving the check higher up the call tree in one branch. However, > there is another call to set_string_video_rate() which may pass > NULL, and future users of the function may not be clear that > a NULL check is required. This patch restores the NULL check to > avoid these problems. Does this affect something else than the seting based on defaults ? because the defaults should probably be valid values or if you disagree, iam curious where the default would be intentionally invalid thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/g723_1enc: Avoid skip_put_bits()
On Fri, Jul 31, 2020 at 12:39:46PM +0200, Andreas Rheinhardt wrote: > If a bit is reserved, it matters very much what value it has, because > otherwise a decoder conforming to a future version of the standard might > interpret the output file in an unintended manner. This implies that > one must not use skip_put_bits() for it (which does not give any > guarantees wrt what ends up in the output (in case of a little-endian > bitstream writer (as here) it writes a 0 bit)); given that the reference > encoder as well as the earlier code write a zero bit at this place, the > new code does, too. > > Signed-off-by: Andreas Rheinhardt > --- > The earlier code here was unaffected by any of the bugs of > skip_put_bits, because this code uses a little-endian writer and > the number of bits written so far was always even, so that skipping > a single bit could be done in the buffer itself. > > libavcodec/g723_1enc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] libsvtav1: Rename without a -
On 31/07/2020 00:59, James Almer wrote:
On 7/30/2020 6:31 PM, Mark Thompson wrote:
The external library is called libsvtav1, so use this name everywhere.
---
configure| 2 +-
libavcodec/Makefile | 2 +-
libavcodec/allcodecs.c | 2 +-
libavcodec/{libsvt_av1.c => libsvtav1.c} | 8
4 files changed, 7 insertions(+), 7 deletions(-)
rename libavcodec/{libsvt_av1.c => libsvtav1.c} (99%)
...
@@ -543,7 +543,7 @@ static const AVOption options[] = {
};
static const AVClass class = {
-.class_name = "libsvt_av1",
+.class_name = "libsvtav1",
.item_name = av_default_item_name,
.option = options,
.version= LIBAVUTIL_VERSION_INT,
@@ -557,8 +557,8 @@ static const AVCodecDefault eb_enc_defaults[] = {
{ NULL },
};
-AVCodec ff_libsvt_av1_encoder = {
-.name = "libsvt_av1",
Subject mentions - (dash) but you're removing underscores.
Oops, fixed.
+AVCodec ff_libsvtav1_encoder = {
+.name = "libsvtav1",
.long_name = NULL_IF_CONFIG_SMALL("SVT-AV1(Scalable Video Technology for
AV1) encoder"),
.priv_data_size = sizeof(SvtContext),
.type = AVMEDIA_TYPE_VIDEO,
@@ -573,5 +573,5 @@ AVCodec ff_libsvt_av1_encoder = {
.priv_class = &class,
.defaults = eb_enc_defaults,
.caps_internal = FF_CODEC_CAP_INIT_CLEANUP,
-.wrapper_name = "libsvt_av1",
+.wrapper_name = "libsvtav1",
};
LGTM with the subject fixed.
Applied.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/dv: allow returning damaged audio
Fixes: Ticket8762
Signed-off-by: Michael Niedermayer
---
libavformat/dv.c | 49 +---
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/libavformat/dv.c b/libavformat/dv.c
index e99422d4b5..7ebe1815b3 100644
--- a/libavformat/dv.c
+++ b/libavformat/dv.c
@@ -34,12 +34,18 @@
#include "libavcodec/dv_profile.h"
#include "libavcodec/dv.h"
#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/mathematics.h"
#include "libavutil/timecode.h"
#include "dv.h"
#include "libavutil/avassert.h"
+enum AudioConceal {
+AUDIO_CONCEAL_PASS = 1,
+AUDIO_CONCEAL_DROP = 0,
+};
+
struct DVDemuxContext {
const AVDVProfile* sys;/* Current DV profile. E.g.: 525/60, 625/50 */
AVFormatContext* fctx;
@@ -50,6 +56,8 @@ struct DVDemuxContext {
int ach;
int frames;
uint64_t abytes;
+uint8_t as_pack[5];
+int dvaudio_concealment;
};
static inline uint16_t dv_audio_12to16(uint16_t sample)
@@ -72,7 +80,7 @@ static inline uint16_t dv_audio_12to16(uint16_t sample)
return result;
}
-static const uint8_t *dv_extract_pack(const uint8_t *frame, enum dv_pack_type
t)
+static const uint8_t *dv_extract_pack(DVDemuxContext *d, const uint8_t *frame,
enum dv_pack_type t)
{
int offs;
int c;
@@ -101,6 +109,13 @@ static const uint8_t *dv_extract_pack(const uint8_t
*frame, enum dv_pack_type t)
break;
}
+if (t == dv_audio_source || t == dv_audio_control) {
+if (frame[offs] == t) {
+memcpy(d->as_pack, &frame[offs], sizeof(d->as_pack));
+} else if (d->as_pack[0] && d->dvaudio_concealment ==
AUDIO_CONCEAL_PASS)
+return d->as_pack;
+}
+
return frame[offs] == t ? &frame[offs] : NULL;
}
@@ -116,7 +131,7 @@ static const int dv_audio_frequency[3] = {
* 3. Audio is always returned as 16-bit linear samples: 12-bit nonlinear
samples
*are converted into 16-bit linear ones.
*/
-static int dv_extract_audio(const uint8_t *frame, uint8_t **ppcm,
+static int dv_extract_audio(DVDemuxContext *c, const uint8_t *frame, uint8_t
**ppcm,
const AVDVProfile *sys)
{
int size, chan, i, j, d, of, smpls, freq, quant, half_ch;
@@ -124,7 +139,7 @@ static int dv_extract_audio(const uint8_t *frame, uint8_t
**ppcm,
const uint8_t *as_pack;
uint8_t *pcm, ipcm;
-as_pack = dv_extract_pack(frame, dv_audio_source);
+as_pack = dv_extract_pack(c, frame, dv_audio_source);
if (!as_pack)/* No audio ? */
return 0;
@@ -224,7 +239,7 @@ static int dv_extract_audio_info(DVDemuxContext *c, const
uint8_t *frame)
const uint8_t *as_pack;
int freq, stype, smpls, quant, i, ach;
-as_pack = dv_extract_pack(frame, dv_audio_source);
+as_pack = dv_extract_pack(c, frame, dv_audio_source);
if (!as_pack || !c->sys) {/* No audio ? */
c->ach = 0;
return 0;
@@ -292,7 +307,7 @@ static int dv_extract_video_info(DVDemuxContext *c, const
uint8_t *frame)
c->vst->avg_frame_rate = av_inv_q(c->vst->time_base);
/* finding out SAR is a little bit messy */
-vsc_pack = dv_extract_pack(frame, dv_video_control);
+vsc_pack = dv_extract_pack(c, frame, dv_video_control);
apt = frame[4] & 0x07;
is16_9 = (vsc_pack && ((vsc_pack[2] & 0x07) == 0x02 ||
(!apt && (vsc_pack[2] & 0x07) == 0x07)));
@@ -312,7 +327,7 @@ static int dv_extract_timecode(DVDemuxContext* c, const
uint8_t* frame, char *tc
// is only relevant for NTSC systems.
int prevent_df = c->sys->ltc_divisor == 25 || c->sys->ltc_divisor == 50;
-tc_pack = dv_extract_pack(frame, dv_timecode);
+tc_pack = dv_extract_pack(c, frame, dv_timecode);
if (!tc_pack)
return 0;
av_timecode_make_smpte_tc_string(tc, AV_RB32(tc_pack + 1), prevent_df);
@@ -384,7 +399,7 @@ int avpriv_dv_produce_packet(DVDemuxContext *c, AVPacket
*pkt,
ppcm[i] = c->audio_buf[i];
}
if (c->ach)
-dv_extract_audio(buf, ppcm, c->sys);
+dv_extract_audio(c, buf, ppcm, c->sys);
/* We work with 720p frames split in half, thus even frames have
* channels 0,1 and odd 2,3. */
@@ -452,8 +467,10 @@ void ff_dv_offset_reset(DVDemuxContext *c, int64_t
frame_offset)
/
typedef struct RawDVContext {
+const AVClass *class;
DVDemuxContext *dv_demux;
uint8_t buf[DV_MAX_FRAME_SIZE];
+int dvaudio_concealment;
} RawDVContext;
static int dv_read_timecode(AVFormatContext *s) {
@@ -500,6 +517,7 @@ static int dv_read_header(AVFormatContext *s)
c->dv_demux = avpriv_dv_init_demux(s);
if (!c->dv_demux)
return AVERROR(ENOMEM);
+c->dv_demux->dvaudio_concealment = c->dvaudio_concealment;
state = av
[FFmpeg-devel] [PATCH 2/2] avformat/dv: Change default dvaudio_concealment to PASS
With this change the AV sync issues should be fixed without manually
setting the dvaudio_concealment
Signed-off-by: Michael Niedermayer
---
libavformat/dv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dv.c b/libavformat/dv.c
index 7ebe1815b3..aea68d40fc 100644
--- a/libavformat/dv.c
+++ b/libavformat/dv.c
@@ -660,7 +660,7 @@ static int dv_probe(const AVProbeData *p)
#define OFFSET(x) offsetof(RawDVContext, x)
#define DEC AV_OPT_FLAG_DECODING_PARAM
static const AVOption dv_options[] = {
-{ "dvaudio_concealment", "", OFFSET(dvaudio_concealment), AV_OPT_TYPE_INT
, {.i64 = AUDIO_CONCEAL_DROP}, 0, INT_MAX, DEC, "dvaudio_concealment"},
+{ "dvaudio_concealment", "", OFFSET(dvaudio_concealment), AV_OPT_TYPE_INT
, {.i64 = AUDIO_CONCEAL_PASS}, 0, INT_MAX, DEC, "dvaudio_concealment"},
{ "drop","", 0 ,
AV_OPT_TYPE_CONST, {.i64 = AUDIO_CONCEAL_DROP}, 0, INT_MAX, DEC,
"dvaudio_concealment"},
{ "pass","", 0 ,
AV_OPT_TYPE_CONST, {.i64 = AUDIO_CONCEAL_PASS}, 0, INT_MAX, DEC,
"dvaudio_concealment"},
{ NULL },
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Pull Request - Support Windows Subsystem for Linux
Friendly ping. Are these changes acceptable now? On Fri, Jul 31, 2020 at 1:35 AM Julio César Rocha wrote: > Understood, thanks! > > Here are the updated patches. > > On Fri, Jul 31, 2020 at 1:07 AM zhilizhao wrote: > >> >> >> > On Jul 31, 2020, at 3:19 PM, Julio César Rocha >> wrote: >> > >> > I didn't find any documentation that refers to building with WSL. >> > Can builds with WSL be achieved without any patching? >> > >> > Also, how should I split the patch, if it's only modifying one file? >> >> Modify a part of the file, git add && git commit, then modify another >> part. >> >> > >> > On Thu, Jul 30, 2020 at 11:52 PM Carl Eugen Hoyos >> > wrote: >> > >> >> >> >> >> >>> Am 31.07.2020 um 06:59 schrieb Julio César Rocha < >> ju...@rochsquadron.net >> >>> : >> >>> >> >>> Attaching git format-patch change. >> >>> >> >>> Allows building FFmpeg on Windows using bash.exe provided by WSL, as >> an >> >>> alternative to MSYS. >> >> >> >> The commit message is not ok as many people regularly build with wsl. >> >> And please split the patch. >> >> >> >> Carl Eugen >> >> ___ >> >> ffmpeg-devel mailing list >> >> ffmpeg-devel@ffmpeg.org >> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> >> >> To unsubscribe, visit link above, or email >> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> > ___ >> > ffmpeg-devel mailing list >> > ffmpeg-devel@ffmpeg.org >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > >> > To unsubscribe, visit link above, or email >> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
