mpegaudiodec_template.c uses stuff from mpegaudiodata directly,
yet this dependency was only indirectly fulfilled via mpegaudio-headers
before 33e6d57f01. Since this commit,
the latter only needs (and therefore provides) mpegaudiotabs,
leading to compilation failures.
This commit adds this missing direct dependency directly.
(Sorry for not having checked indirect dependencies.)
Found-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to remove the spurious dependencies of mpegvideo encoders
on error_resilience; some other components that do not use mpegvideo
to its fullest turned out to not need it either.
Adding a new CONFIG_EXTRA needs a reconfigure to take effect.
In order to force this a few unnecessary headers from lavfi/allfilters.c
have been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This function is quite small (96B with GCC 11.2 on x64 Ubuntu 21.10
at -O3), making it more economical to duplicate it into libavformat
instead of exporting it as avpriv: Doing so saves 2x24B in .dynsim,
2x16B in .dynstr, 2x2B .gnu.version, 24B in .rela.plt, 16B in .plt,
16B in .plt.sec (if enabled), 4B .gnu.hash; besides the actual
duplicated code this also adds 2x8B .eh_frame_hdr and 24B .eh_frame.
In other words: Duplicating is neutral size-wise (it is also presumed
neutral for other systems). Given that it avoids the runtime
overhead of dynamic symbols, it is advantageouos to duplicate the
function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These arrays have a size of 180 resp. six bytes. This does not
make it worthwhile to export them due to the overhead this occurs;
for x64 Elf/Linux/GNU: 2x2B version, 2x24B .dynsym, 24B .rela.dyn,
8B .got, 4B hash + twice the size of the name (here 20+23B).
Therefore these symbols are unavprived and duplicated for shared
builds.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avpriv_mpeg4audio_sample_rates has a size of 64B and it is currently
avpriv; a clone of it exists in aacenctab.h and from there it is inlined
in aacenc.c (which also uses the avpriv version) and in the FLV muxer.
This means that despite it being avpriv both libavformat as well as
libavcodec have copies already.
This situation is clearly suboptimal. Given the overhead of exporting
symbols (for x64 Elf/Linux/GNU: 2x2B version, 2x24B .dynsym, 24B .rela.dyn,
8B .got, 4B hash + twice the size of the name (here 31B)) the object is
unavprived, i.e. duplicated into libavformat when creating a shared
build; but the duplicates in the AAC encoder and FLV muxer are removed.
This involves splitting of the sample rate table into a file of its own;
this allowed to break some spurious dependencies (e.g. both the AAC
encoder as well as the Matroska demuxer actually don't need the
mpeg4audio_get_config stuff).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This group is mainly for the users of *_mpeg4audio_get_config2();
it is not for those who only use avpriv_mpeg4audio_sample_rates.
This is in preparation for splitting the latter into a file of its own;
if there were no CONFIG_EXTRA group for *_mpeg4audio_get_config2()
users, one would have to add a dependency to the new file for all
these users on top of the existing dependency on mpeg4audio.o.
Adding a new CONFIG_EXTRA group only takes effect after a reconfigure;
so in order to force a reconfigure some unnecessary headers from
libavdevice/alldevices.c have been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are seven MJPEG-tables, five small (1x12, 4x17) and two
not small (2x162). These are all avpriv, despite this not being
worthwhile due to the overhead of exporting a symbol: The total
overhead for each symbol consists of two entries in .dynsym (24B each),
one entry in the importing library's .rela.dyn (24B) and one in .got
(8B) as well as 2x2B for symbol versions and 4B for symbol hashes
in the exporting library; in addition to that, the name of the symbol
is included in both exporting and importing libraries, using 2x210 bytes
in this case.
(The above numbers are for a x64 Elf/Linux/GNU system. Other platforms
will give different numbers.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Said table is 64 bytes long and exported so that it can be used both
in libavcodec and libavformat. This commit stops doing so and instead
duplicates it for shared builds, because the overhead of exporting the
symbol is bigger than 64 bytes. It consists of the length of the name of
the symbol (2x24 bytes), two entries in .dynsym (2x24 bytes), two
entries for symbol version (2x2 bytes), one hash value in the exporting
library (4 bytes) in addition to one entry in the importing library's
.got and .rela.dyn (8 + 24 bytes).
(The above numbers are for a Linux/GNU/Elf system; the numbers for other
platforms may be different.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is small (16 B) and therefore the overhead of exporting it more
than outweighs the size savings from not having duplicated symbols:
When the symbol is no longer avpriv, one saves twice the size of
the string containing the symbols name (2x30 byte), two entries
in .dynsym (24 bytes each on x64), one entry in the importing libraries
.got and .rela.dyn (8 + 24 bytes on x64) and two entries for the
symbol version (2 bytes each) and one hash value in the exporting
library (4 bytes).
(The exact numbers are of course different for other platforms
(e.g. when using dlls), but given that the strings saved alone
more than outweigh the array size it can be presumed that this
is beneficial for all platforms.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.
Contains some annoying machinery to persist these values in between
frames, which is needed in theory even though I've never actually seen a
sample that relies on it in practice. May or may not work.
Since the distinction matters greatly for parsing the color matrix
values, this includes a small helper function to guess the right profile
from the RPU itself in case the user has forgotten to forward the dovi
configuration record to the decoder. (Which in practice, only ffmpeg.c
and ffplay do..)
Notable omissions / deviations:
- CRC32 verification. This is based on the MPEG2 CRC32 type, which is
similar to IEEE CRC32 but apparently different in subtle enough ways
that I could not get it to pass verification no matter what parameters
I fed to av_crc. It's possible the code needs some changes.
- Linear interpolation support. Nothing documents this (beyond its
existence) and no samples use it, so impossible to implement.
- All of the extension metadata blocks, but these contain values that
seem largely congruent with ST2094, HDR10, or other existing forms of
side data, so I will defer parsing/attaching them to a future commit.
- The patent describes a mechanism for predicting coefficients from
previous RPUs, but the bit for the flag whether to use the
prediction deltas or signal entirely new coefficients does not seem to
be present in actual RPUs, so we ignore this subsystem entirely.
- In the patent's spec, the NLQ subsystem also loops over
num_nlq_pivots, but even in the patent the number is hard-coded to one
iteration rather than signalled. So we only store one set of coefs.
Heavily influenced by https://github.com/quietvoid/dovi_tool
Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In case of shared builds, some object files containing tables
are currently duplicated into other libraries: log2_tab.c,
golomb.c, reverse.c. The check for whether this is duplicated
is simply whether CONFIG_SHARED is true. Yet this is crude:
E.g. libavdevice includes reverse.c for shared builds, but only
needs it for the decklink input device, which given that decklink
is not enabled by default will be unused in most libavdevice.so.
This commit changes this by making it more explicit about what
to duplicate from other libraries. To do this, two new Makefile
variables were added: SHLIBOBJS and STLIBOBJS. SHLIBOBJS contains
the objects that are duplicated from other libraries in case of
shared builds; STLIBOBJS contains stuff that a library has to
provide for other libraries in case of static builds. These new
variables provide a way to enable/disable with a finer granularity
than just whether shared builds are enabled or not. E.g. lavd's
Makefile now contains: SHLIBOBJS-$(CONFIG_DECKLINK_INDEV) += reverse.o
Another example is provided by the golomb tables. These are provided
by lavc for static builds, even if one uses a build configuration
that makes only lavf use them. Therefore lavc's Makefile contains
STLIBOBJS-$(CONFIG_MXF_MUXER) += golomb.o, whereas lavf's Makefile
has a corresponding SHLIBOBJS-$(CONFIG_MXF_MUXER) += golomb_tab.o.
E.g. in case the MXF muxer is the only component needing these tables
only libavformat.so will contain them for shared builds; currently
libavcodec.so does so, too.
(There is currently a CONFIG_EXTRA group for golomb. But actually
one would need two groups (golomb_avcodec and golomb_avformat) in
order to know when and where to include these tables. Therefore
this commit uses a Makefile-based approach for this and stops
using these groups for the users in libavformat.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is no mxfenc dependency any more since commit
b9a26b9d55.
Also remove a dnxhddata.h inclusion in mxfenc that was forgotten
in the very same commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current name comes from a time in which libavcodec/utils.c
contained the whole core of libavcodec.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This could arguably also be a vf, but I decided to put it here since
decoders are technically required to apply film grain during the output
step, and I would rather want to avoid requiring users insert the
correct film grain synthesis filter on their own.
The code, while in C, is written in a way that unrolls/vectorizes fairly
well under -O3, and is reasonably cache friendly. On my CPU, a single
thread pushes about 400 FPS at 1080p.
Apart from hand-written assembly, one possible avenue of improvement
would be to change the access order to compute the grain row-by-row
rather than in 8x8 blocks. This requires some redundant PRNG calls, but
would make the algorithm more cache-oblivious.
The implementation has been written to the wording of SMPTE RDD 5-2006
as faithfully as I can manage. However, apart from passing a visual
inspection, no guarantee of correctness can be made due to the lack of
any publicly available reference implementation against which to
compare it.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>
Said encoder uses a function in adpcm.c and while it does not use
anything from adpcm_data.c, other parts of both adpcm.c and adpcmenc.c
need it, so adpcm_data.c needs to be enabled anyway.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The remove_extradata bsf is the only user of these functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Using optimal Huffman tables is not supported for AMV and always
disabled by ff_mpv_encode_init(); therefore one can build
the AMV encoder without mjpegenc_huffman if one adds the necessary
compile-time checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Forgotten after d78ecf10bd.
(Also mark some AVPackets as const.)
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
tiff.c is the only user of the data from tiff_data.c (the dependency of
the tiff encoder of it is spurious). Therefore this commit moves all the
data from tiff_data.c to tiff_data.h (which is only included by tiff.c)
and makes the objects declared therein static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The NUT and avi demuxers only need ff_codec_movvideo_tags and so this
removes a dependency on the rest of isom.c as well as on mpeg4audio.c
(which isom depends on); it is similar for the Matroska demuxer and
muxers, except that the mpeg4audio.c dependency can't be avoided.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
While just at it, remove the nb_codes parameter: It is redundant
(the number of codes is implicitly contained in the array containing how
many entries of a specific size there are) and for this reason it might
even be wrong, so it is better to check what is actually used instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MJPEG decoder is already activated by configure whenever the tiff
decoder is selected; ergo it is unnecessary to add a dependency in the
Makefile.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The avrn decoder actually only needs one thing: The MJPEG decoder.
Instead the Makefile made it compile mjpegdec and configure required
some of the prerequisites of the MJPEG decoder (exif and jpegtables).
Even if all the prerequisites of the MJPEG decoder were required, it
would still not make the MJPEG decoder usable, because for that
the MJPEG decoder needs to be in the list of codecs in codec_list.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The fixed-point AAC decoder is the only user of the fixed-point sinewin
tables from sinewin; and it only uses a few of them (about 10% when
counting by size). This means that guarding initializing these tables by
an AVOnce (as done in 3719122065) is
unnecessary for them. Furthermore the array of pointers to the
individual arrays is also unneeded.
Therefore this commit moves these tables directly into aacdec_fixed.c;
this is done by ridding the original sinewin.h and sinewin_tablegen.h
headers completely of any fixed-point code at the cost of a bit of
duplicated code (the alternative is an ugly ifdef-mess).
This saves about 58KB from the binary when using hardcoded tables (as
these tables are hardcoded in this scenario); when not using hardcoded
tables, most of these savings only affect the .bss segment, but the rest
(< 1KB) contains relocations (i.e. savings in .data.rel.ro).
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Neither module should depend on the other.
Move shared functions to its own file for this purpose, and ensure
source files are compiled only when the required modules are enabled.
Signed-off-by: James Almer <jamrial@gmail.com>
The only call to ff_intel_h263_decode_picture_header() is already behind
"if (CONFIG_H263I_DECODER)".
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
2ef2496cd1 used ff_vorbis_channel_layouts
in flac.c, but added a dependency to the FLAC decoder only; lateron
aba0278e9f added the dependency of the
FLAC parser and encoder on vorbis_data.o. Yet when the original commit
was reverted in aba0278e9f, the two other
dependencies were not removed. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
No longer used by anything.
Unfortunately the old FFT_FLOAT/FFT_FIXED_32 is left as-is. It's
simply too much work for code meant to be all removed anyway.
The AC3 encoder used to be a separate library called "Aften", which
got merged into libavcodec (literally, SVN commits and all).
The merge preserved as much features from the library as possible.
The code had two versions - a fixed point version and a floating
point version. FFmpeg had floating point DSP code used by other
codecs, the AC3 decoder including, so the floating-point DSP was
simply replaced with FFmpeg's own functions.
However, FFmpeg had no fixed-point audio code at that point. So
the encoder brought along its own fixed-point DSP functions,
including a fixed-point MDCT.
The fixed-point MDCT itself is trivially just a float MDCT with a
different type and each multiply being a fixed-point multiply.
So over time, it got refactored, and the FFT used for all other codecs
was templated.
Due to design decisions at the time, the fixed-point version of the
encoder operates at 16-bits of precision. Although convenient, this,
even at the time, was inadequate and inefficient. The encoder is noisy,
does not produce output comparable to the float encoder, and even
rings at higher frequencies due to the badly approximated winow function.
Enter MIPS (owned by Imagination Technologies at the time). They wanted
quick fixed-point decoding on their FPUless cores. So they contributed
patches to template the AC3 decoder so it had both a fixed-point
and a floating-point version. They also did the same for the AAC decoder.
They however, used 32-bit samples. Not 16-bits. And we did not have
32-bit fixed-point DSP functions, including an MDCT. But instead of
templating our MDCT to output 3 versions (float, 32-bit fixed and 16-bit fixed),
they simply copy-pasted their own MDCT into ours, and completely
ifdeffed our own MDCT code out if a 32-bit fixed point MDCT was selected.
This is also the status quo nowadays - 2 separate MDCTs, one which
produces floating point and 16-bit fixed point versions, and one
sort-of integrated which produces 32-bit MDCT.
MIPS weren't all that interested in encoding, so they left the encoder
as-is, and they didn't care much about the ifdeffery, mess or quality - it's
not their problem.
So the MDCT/FFT code has always been a thorn in anyone looking to clean up
code's eye.
Backstory over. Internally AC3 operates on 25-bit fixed-point coefficients.
So for the floating point version, the encoder simply runs the float MDCT,
and converts the resulting coefficients to 25-bit fixed-point, as AC3 is inherently
a fixed-point codec. For the fixed-point version, the input is 16-bit samples,
so to maximize precision the frame samples are analyzed and the highest set
bit is detected via ac3_max_msb_abs_int16(), and the coefficients are then
scaled up via ac3_lshift_int16(), so the input for the FFT is always at least 14 bits,
computed in normalize_samples(). After FFT, the coefficients are scaled up to 25 bits.
This patch simply changes the encoder to accept 32-bit samples, reusing
the already well-optimized 32-bit MDCT code, allowing us to clean up and drop
a large part of a very messy code of ours, as well as prepare for the future lavu/tx
conversion. The coefficients are simply scaled down to 25 bits during windowing,
skipping 2 separate scalings, as the hacks to extend precision are simply no longer
necessary. There's no point in running the MDCT always at 32 bits when you're
going to drop 6 bits off anyway, the headroom is plenty, and the MDCT rounds
properly.
This also makes the encoder even slightly more accurate over the float version,
as there's no coefficient conversion step necessary.
SIZE SAVINGS:
ARM32:
HARDCODED TABLES:
BASE - 10709590
DROP DSP - 10702872 - diff: -6.56KiB
DROP MDCT - 10667932 - diff: -34.12KiB - both: -40.68KiB
DROP FFT - 10336652 - diff: -323.52KiB - all: -364.20KiB
SOFTCODED TABLES:
BASE - 9685096
DROP DSP - 9678378 - diff: -6.56KiB
DROP MDCT - 9643466 - diff: -34.09KiB - both: -40.65KiB
DROP FFT - 9573918 - diff: -67.92KiB - all: -108.57KiB
ARM64:
HARDCODED TABLES:
BASE - 14641112
DROP DSP - 14633806 - diff: -7.13KiB
DROP MDCT - 14604812 - diff: -28.31KiB - both: -35.45KiB
DROP FFT - 14286826 - diff: -310.53KiB - all: -345.98KiB
SOFTCODED TABLES:
BASE - 13636238
DROP DSP - 13628932 - diff: -7.13KiB
DROP MDCT - 13599866 - diff: -28.38KiB - both: -35.52KiB
DROP FFT - 13542080 - diff: -56.43KiB - all: -91.95KiB
x86:
HARDCODED TABLES:
BASE - 12367336
DROP DSP - 12354698 - diff: -12.34KiB
DROP MDCT - 12331024 - diff: -23.12KiB - both: -35.46KiB
DROP FFT - 12029788 - diff: -294.18KiB - all: -329.64KiB
SOFTCODED TABLES:
BASE - 11358094
DROP DSP - 11345456 - diff: -12.34KiB
DROP MDCT - 11321742 - diff: -23.16KiB - both: -35.50KiB
DROP FFT - 11276946 - diff: -43.75KiB - all: -79.25KiB
PERFORMANCE (10min random s32le):
ARM32 - before - 39.9x - 0m15.046s
ARM32 - after - 28.2x - 0m21.525s
Speed: -30%
ARM64 - before - 36.1x - 0m16.637s
ARM64 - after - 36.0x - 0m16.727s
Speed: -0.5%
x86 - before - 184x - 0m3.277s
x86 - after - 190x - 0m3.187s
Speed: +3%
Up until now, the SpeedHQ encoder called a wrong function for init:
void ff_init_uni_ac_vlc(const uint8_t huff_size_ac[256],
uint8_t *uni_ac_vlc_len);
Yet the first argument actually used is of type RLTable; the size of
said struct is less than 256 if the size of a pointer is four, leading
to an access beyond the end of the RLTable.
This commit fixes this by calling the actually intended function:
init_uni_ac_vlc() from mpeg12enc.c. It was intended to use this
function [1], yet doing so was forgotten when the patch was actually
applied.
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-July/266187.html
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
SMVJPEG stores frames as slices of a big JPEG image. The decoder is
implemented as a wrapper that instantiates a full internal MJPEG
decoder, then forwards the decoded frames with offset data pointers.
This is unnecessarily complex and fragile, not supporting useful decoder
capabilities like direct rendering.
Re-implement the decoder inside the MJPEG decoder, which is accomplished
by returning each decoded frame multiple times, setting cropping
information appropriately on each instance.
One peculiar aspect of the previous design is that since
- the smvjpeg decoder returns one frame per input packet
- there are multiple frames in each packets (the aformentioned slices)
the demuxer needs to return each packet multiple times.
This is now also eliminated - the demuxer now returns each packet
exactly once, with the duration set to the number of frames it decodes
to.
This also removes one of the last remaining internal uses of the old
video decoding API.
Both the fixed as well as the floating point mpegaudio decoders use
LUTs of type int8_t and uint32_t with 32K entries each; these tables
are completely the same, yet they are not shared. This commit makes
them shared. When both fixed as well as floating point decoders are
enabled, this saves 160KiB from the bss segment for a normal build
(translating into 160KiB less memory usage if both a shared as well as
a floating point decoder have actually been used) and 160KiB from the
binary for a build with hardcoded tables.
It also means that the code to create said LUTs is no longer duplicated
(for a normal build).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The manual states "there is virtually no reason to use that encoder.".
It supports less sample formats than the native encoder, is less efficient
than the native encoder and is also slower and pretty much remains untested.
libwavpack also isn't being fuzzed, which given that we plug the parameters
without any sanitizing them looks concerning.
This AV1 decoder is currently only used for hardware accelerated decoding.
It can be extended into a native decoder in the future, so set its name to
"av1" and temporarily give it the lowest priority in the codec list.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Add vdpau_parse_rext_profile and use profile constraint flags to
determine the exact vdp_profile for HEVC_REXT.
If profile mismatch is allowed, select Main profile by default.
Add build object in Makefile for h265_profile_level dependency.
Signed-off-by: Philip Langdale <philipl@overt.org>
I have attempted to write a JPEG2000 Parser. Have tested
by generating a file containing 14 frames, as mentioned
by Micheal. Have also tried testing with various packet
sizes by setting -frame_size option. Additionally,
fixed a few formatting issues as pointed out by Micheal.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This contains encoder wrappers for H264, HEVC, AAC, AC3 and MP3.
This is based on top of an original patch by wm4
<nfxjfg@googlemail.com>. The original patch supported both encoding
and decoding, but this patch only includes encoding.
The patch contains further changes by Paweł Wegner
<pawel.wegner95@gmail.com> (primarily for splitting out the encoding
parts of the original patch) and further cleanup, build compatibility
fixes and tweaks for use with Qualcomm encoders by Martin Storsjö.
Signed-off-by: Martin Storsjö <martin@martin.st>
Add support for WavPack DSD files to the existing WavPack decoder using
avcodec/dsd to perform the 8:1 decimation to 32-bit float samples. We must
serialize the dsd2pcm operation (cross-boundary filtering) but would like
to use frame-level multithreading for the CPU-intensive DSD decompression,
and this is accomplished with ff_thread_report/await_progress(). Because
the dsd2pcm operation is independent across channels we use slice-based
multithreading for that part.
Also a few things were removed from the existing WavPack decoder that
weren't being used (primarily the SavedContext stuff) and the WavPack
demuxer was enhanced to correctly determine the sampling rate of DSD
files (and of course to no longer reject them).
Signed-off-by: David Bryant <david@wavpack.com>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add vaapi_parse_rext_profile and use profile constraint flags to
determine the exact va_profile for HEVC_REXT.
If profile mismatch is allowed, select Main profile by default.
Add build object in Makefile for h265_profile_level dependency.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
This adds a decoder for Broderbund's sprite-based QuickTime CDToons
codec, based on the decoder I wrote for ScummVM.
Signed-off-by: Alyssa Milburn <amilburn@zall.org>
Adds support for the ADPCM variant used by some Simon & Schuster
Interactive games such as Real War, and Real War: Rogue States.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously, the default palette would always be used.
Now, we can accept a custom palette, just like dvdsubdec does.
Signed-off-by: Michael Kuron <michael.kuron@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
