Will remove native backend, so change the default backend in filters,
and also remove the python scripts which generate native model file.
Signed-off-by: Ting Fu <ting.fu@intel.com>
Native backend will be removed in following commits, so change the
dnn interface and modify the error message in it first.
Signed-off-by: Ting Fu <ting.fu@intel.com>
Not doing so is an obvious oversight - the ICC profile is tied to the
original colorspace, so if we change it, we should definitely strip this
information.
We should probably also have an extra option to control whether the ICC
profile should be stripped, ignored, or applied, but for now this fixes
an existing bug.
Some testing revealed this to be a very efficient and reliable method of
ingesting GPU frames into libplacebo, so it's a good idea to give as an
example.
This example being first is now misleading because round-tripping
through hwdownload/hwupload is neither required nor recommended. Also,
the comment about avoiding format conversion is unnecessary because
`libplacebo` will now inherit the input frame format by default.
This was a bug/mistake in dae3679a9b.
use_mfra_for by defintion only has an effect on fragmented MP4 files,
making the check not only redundant, but also broken if a user used
the option globally (i.e. set on non-fragmented MP4s).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Also make duration check for mvhd more consistent with the others, write
version 1 of mvhd if duration is at least INT32_MAX instead of UINT32_MAX.
Signed-off-by: Marton Balint <cus@passwd.hu>
Commit 23eeffcd48 added a hack to support invalid
files where the creation date was encoded as a classic unix timestamp. Let's
reduce the scope of the hack by only applying it to version 0 mdhd/mvhd atoms.
Also warn the user of such possibly broken files.
Signed-off-by: Marton Balint <cus@passwd.hu>
Support pixel formats 0x11412100, 0x11311100, and 0x41211100, and add
logic to perform 4x horizontal upsampling. This should fix various JPEG
files found in Ticket #8930.
Co-authored-by: <leo.izen@gmail.com>
The previous name is misleading, because the function does not actually
initialize any filters - it creates a new output stream and binds a
filtergraph output to it.
Their only function is checking that encoding was not specified for
data/unknown-type streams, but the check is broken because enc_ctx will
not be created in ost_add() unless a valid encoder can be found.
Add an actually working check for all types for which encoding is not
supported in choose_encoder().
ts_discontinuity_detect() is applied right after demuxing, while
InputStream.pts is a post-decoding timestamp, which may be delayed with
respect to demuxing by an arbitrary amount (e.g. depending on the thread
count when frame threading is used).
The name is misleading, because it is not a picture in the sense of MPEG
terminology (which define "picture" as "frame or field"), but always a
full frame. 'next' is also redundant and/or misleading, because it is
the _current_ frame to be encoded.
Previously they would only be used with trivial filtergraphs, because
filters did not handle frame durations. That is no longer true - most
filters process frame durations properly (there may still be some that
don't - this change will help finding and fixing them).
Improves output video frame durations in a number of FATE tests.
When an encoder exports sum-of-squared-differences information in
encoded packets, print_report() will print PSNR information in the
status line. However,
* the code computing PSNR assumes 8bit 420 video and prints incorrect
values otherwise; there are no issues on trac about this
* only a few encoders (namely aom, vpx, mpegvideo, snow) export this
information; other often-used encoders such as libx26[45] do not
export this, even though they could
This suggests that this feature is not useful and it is better to remove
it rather than spend effort on fixing it.
Otherwise main and overlay videos share the same input region. Note NULL
pointer imples the whole overlay video will be processed.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
