TensorFlow C library accepts config for session options to
set different parameters for the inference. This patch exports
this interface.
The config is a serialized tensorflow.ConfigProto proto, so we need
two steps to use it:
1. generate the serialized proto with python (see script example below)
the output looks like: 0xab...cd
where 0xcd is the least significant byte and 0xab is the most significant byte.
2. pass the python script output into ffmpeg with
dnn_processing=options=sess_config=0xab...cd
The following script is an example to specify one GPU. If the system contains
3 GPU cards, the visible_device_list could be '0', '1', '2', '0,1' etc.
'0' does not mean physical GPU card 0, we need to try and see.
And we can also add more opitions here to generate more serialized proto.
script example to generate serialized proto which specifies one GPU:
import tensorflow as tf
gpu_options = tf.GPUOptions(visible_device_list='0')
config = tf.ConfigProto(gpu_options=gpu_options)
s = config.SerializeToString()
b = ''.join("%02x" % int(ord(b)) for b in s[::-1])
print('0x%s' % b)
ad73b32d2922f4237405043d19763229aee0e59e added some code for freeing in
the input's config_props function, yet this is unnecessary as uninit is
called anyway if config_props fails.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This has happened when initializing the motion estimation context if
width or height of the video was smaller than the block size used
for motion estimation and if the motion interpolation mode indicates
not to use motion estimation.
The solution is of course to only initialize the motion estimation
context if the interpolation mode uses motion estimation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The latter code relies upon the dimensions to be not too small;
otherwise one will call av_clip() with min > max lateron which aborts
in case ASSERT_LEVEL is >= 2 or one will get a nonsense result that may
lead to a heap-buffer-overflow/underflow. The latter has happened in
ticket #8248 which this commit fixes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This reverts commit 5bbf58ab876279ca1a5a2f30563f271c99b93e62.
The setparams filters are not hwframe aware, so the default context
passthrough behaviour is needed to allow using them with hardware frames.
This patch adds the coefficients for the linear gamma function (1,0,1,0)
to the colorspace filter.
Signed-off-by: Andrew Klaassen <clawsoon@yahoo.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
for some cases (for example, super resolution), the DNN model changes
the frame size which impacts the filter behavior, so the filter needs
to know the out frame size at very beginning.
Currently, the filter reuses DNNModule.execute_model to query the
out frame size, it is not clear from interface perspective, so add
a new explict interface DNNModel.get_output for such query.
suppose we have a detect and classify filter in the future, the
detect filter generates some bounding boxes (BBox) as AVFrame sidedata,
and the classify filter executes DNN model for each BBox. For each
BBox, we need to crop the AVFrame, copy data to DNN model input and do
the model execution. So we have to save the in_frame at DNNModel.set_input
and use it at DNNModule.execute_model, such saving is not feasible
when we support async execute_model.
This patch sets the in_frame as execution_model parameter, and so
all the information are put together within the same function for
each inference. It also makes easy to support BBox async inference.
Currently, every filter needs to provide code to transfer data from
AVFrame* to model input (DNNData*), and also from model output
(DNNData*) to AVFrame*. Actually, such transfer can be implemented
within DNN module, and so filter can focus on its own business logic.
DNN module also exports the function pointer pre_proc and post_proc
in struct DNNModel, just in case that a filter has its special logic
to transfer data between AVFrame* and DNNData*. The default implementation
within DNN module is used if the filter does not set pre/post_proc.
Before patch, fate test for dnn may fail in some Windows environment
while succeed in my Linux. The bug was caused by a wrong loop boundary.
After patch, fate test succeed in my windows mingw 64-bit.
Signed-off-by: Xu Jun <xujunzz@sjtu.edu.cn>
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Before patch, memory was allocated in each thread functions,
which may cause more than one time of memory allocation and
cause crash.
After patch, memory is allocated in the main thread once,
an index was parsed into thread functions. Bug fixed.
Signed-off-by: Xu Jun <xujunzz@sjtu.edu.cn>
Also check that segment delta pts is always bigger than input pts.
There is nothing much currently that can be done to recover from
this situation so just return AVERROR_INVALIDDATA error code.
