C++ doesn't support designated initializers until C++20. We have
a bunch of pre-defined channel layouts, the gains to make them
usable in C++ exceed the losses.
Bump minor version so C++ project can check before use these defines.
Also initialize .opaque field explicitly to reduce warning in C++.
Signed-off-by: James Almer <jamrial@gmail.com>
if !ph_deblocking_params_present_flag is true, ph_deblocking_filter_disabled_flag infered from pps
if !sh_deblocking_params_present_flag is true, sh_deblocking_filter_disabled_flag infered from ph
Failed clips:
ENT444MAINTIER_C_Sony_3.bit
ENT444HIGHTIER_D_Sony_3.bit
Signed-off-by: James Almer <jamrial@gmail.com>
if pps_alf_info_in_ph_flag is true
sh_alf_enabled_flag infered from ph
Failed clip:
LTRP_A_ERICSSON_3.bit
Signed-off-by: James Almer <jamrial@gmail.com>
if sh_picture_header_in_slice_header_flag is true
sh_lmcs_used_flag and sh_explicit_scaling_list_used_flag are infered from ph
Failed clips:
LMCS: CLM_A_KDDI_2.bit STILL444_A_KDDI_1.bit
Scaling: SCALING_B_InterDigital_1.bit SCALING_A_InterDigital_1.bit
Signed-off-by: James Almer <jamrial@gmail.com>
By default the OpenEXR decoder outputs linear light pixel data by
applying a gamma=1.0 transfer (i.e. a no-op). When it does so, it
should tag the data as linear so color-managed filters or other tools
can work with it correctly.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
If user doesn't set framerate when he creates a filter, the filter uses
default framerate {0, 1}. This causes error when setting timebase to
1/framerate. Now change it to pass inlink->time_base to outlink when
framerate is not set.
This patch fixes ticket: #10476#10468
Signed-off-by: Wenbin Chen <wenbin.chen@intel.com>
Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause
bzlib.h to parse as nonsense, due to an instance of #define char small
in rpcndr.h.
See:
https://stackoverflow.com/a/27794577
Signed-off-by: L. E. Segovia <amy@amyspark.me>
Signed-off-by: Martin Storsjö <martin@martin.st>
because the flv specification said the video frametype
should use value range from 0x00 to 0x70,
so use 0xF0 have no problem before support enhanced flv,
but the 0xF0 will get incorrect result after support enhanced flv,
so should set the video frametype mask 0x70 to make it correct now.
Reported-By: flvAnalyser <hybase@qq.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Writing the duration SimpleTag is special: It's size is
reserved in advance via an EBML Void element (if seekable)
and this reserved space is overwritten when writing the trailer;
it does not use put_ebml_string().
The string to write is created via snprintf on a buffer
of size 20; this buffer is then written via put_ebml_binary()
with a size of 20.
EBML strings need not be zero-terminated; if not, they
are implicitly terminated by the element's length field.
snprintf() always zero-terminates the buffer, i.e.
the last byte can be discarded when using an EBML string.
This patch does this.
The FATE changes are as expected: One byte saved for every
track; the only exception is the matroska-qt-mode test:
An additional byte is saved because an additional byte
could be saved from the enclosing Tags length field.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do it only for video (the only thing for type for which HDR10+
makes sense).
This effectively reverts changes to several FATE ref-files
made in bda44f0f39.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Pass it as void* instead. While just at it, also constify
the pointee of AVDOVIDecoderConfigurationRecord* in
ff_isom_put_dvcc_dvvc().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Zhao Zhili
Nuo Mi
Leo Izen
Wenbin Chen
Haihao Xiang
David Rosca
Paul B Mahol
L. E. Segovia
Steven Liu
Random Joe
Andreas Rheinhardt