For example, given TensorFlow model file espcn.pb,
to generate native model file espcn.model, just run:
python convert.py espcn.pb
In current implementation, the native model file is generated for
specific dnn network with hard-code python scripts maintained out of ffmpeg.
For example, srcnn network used by vf_sr is generated with
https://github.com/HighVoltageRocknRoll/sr/blob/master/generate_header_and_model.py#L85
In this patch, the script is designed as a general solution which
converts general TensorFlow model .pb file into .model file. The script
now has some tricky to be compatible with current implemention, will
be refined step by step.
The script is also added into ffmpeg source tree. It is expected there
will be many more patches and community needs the ownership of it.
Another technical direction is to do the conversion in c/c++ code within
ffmpeg source tree. While .pb file is organized with protocol buffers,
it is not easy to do such work with tiny c/c++ code, see more discussion
at http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/244496.html. So,
choose the python script.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
If links don't work, fall back to using the full source path as was
previously done.
This should fix build failures with MSVC.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
During a build, a lot of *.o.-hash files are created - had not noticed
this as they are usually dumped in tmpfs on Linux. However, they
sometimes are present during a long build in the project directory, making it
annoying to commit while the project is being built.
These have been observed with Clang, -fsanitize-undefined on Arch Linux,
though other configurations may also generate such temporaries.
The solution here is on lines with the Linux kernel's .gitignore:
https://github.com/torvalds/linux/blob/master/.gitignore.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It provides the following features:
* verify correctness by comparing output to the C version.
* detect failure to save and restore clobbered callee-saved registers.
* detect 32-bit parameters being used as if they were 64-bit in x86-64
(the upper halves are not guaranteed to be zero - but in practice
they very often are, which makes those bugs hard to spot otherwise).
* easy benchmarking.
Compile by running 'make checkasm'.
Execute by running 'tests/checkasm/checkasm'.
Optional arguments are '--bench' to run benchmarks for all functions,
'--bench=<pattern>' to run benchmarks for all functions that starts with
<pattern>, and '<integer>' to seed the PRNG for reproducible results.
Contains unit tests for most h264pred functions to get started, more tests
can be added afterwards using those as a reference.
Loosely based on code from x264. Currently only supports x86 and x86-64,
but additional architectures shouldn't be too much of an obstacle to add.
Note that functions with floating point parameters or floating point
return values are not supported. Some compiler-specific features or
preprocessor hacks would likely be required to add support for that.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
This returns something like "v12_dev0-1332-g333a27c". This is much more
useful than the individual library versions, of which there are too
many, and which are very hard to map back to releases or git commits.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
The reasoning behind this addition is that various third party
applications are interested in getting some motion information out of a
video "for free" when it is available.
It was considered to export other information as well (such as the intra
information about the block, or the quantization) but the structure
might have ended up into a half full-generic, half full of codec
specific cruft. If more information is necessary, it should either be
added in the "flags" field of the AVMotionVector structure, or in
another side-data.
This commit also includes an example exporting them in a CSV stream.
It has not been properly maintained for years and there is little hope
of that changing in the future.
It appears simpler to write a new replacement from scratch than
unbreaking it.
Also the libavutil/ffversion.h will be installed.
Rationale:
* Applications might want to know FFmpeg's version besides the individual
libraries'.
* Avoids file name clash between FFmpeg's ./version.h and lib*/version.h when
a library source file includes both and is compiled on an out-of-tree build.
Fixes#1769.
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The benchmark tests the speed of the following algorithms:
MD5, SHA-1, SHA-256, SHA-512, RIPEMD-160, AES-128.
It can optionally be built to perform the same benchmark on
other crypto libraries, for comparison purposes.
The supported libraries are:
- crypto: OpenSSL's libcrypto;
- gcrypt: GnuTLS's libgcrypt;
- tomcrypt: LibTomCrypt
To enable them, use this syntax:
make VERSUS=crypto+gcrypt+tomcrypt tools/crypto_bench
They do not need to have been enabled in configure.
The gcov/lcov are a common toolchain for visualizing code coverage with
the GNU/Toolchain. The documentation and implementation of this
integration was heavily inspired from the blog entry by Mike Melanson:
http://multimedia.cx/eggs/using-lcov-with-ffmpeg/
James Almer
Martin Storsjö
Aman Karmani
Timo Rothenpieler
Guo, Yejun
Rostislav Pehlivanov
Diego Biurrun
Anton Khirnov
Michael Niedermayer
Andreas Cadhalpun
Ganesh Ajjanagadde
Harshit Mittal
Mariusz Szczepańczyk
Henrik Gramner
wm4
Lukasz Marek
Benoit Fouet
Clément Bœsch
Vittorio Giovara
Stefano Sabatini
Timothy Gu
Nicolas George
Reinhard Tartler
Loren Merritt
Paul B Mahol
Clément Bœsch