This allows us to be more selective about the streams we derive durations from
(specifically, ignoring text streams with outlier end times) in the common case
This way, Doxygen is happier as aliases are now grouped together, and
it never handled #define's in an enum well in the first place.
Y400A already exists as an enum assignment.
As all known valid HDCD sample formats and sample rates are now handled
by the filter, remove the scan that "invades the privacy" of the filter graph
and turn off autoconvert by default as requested by Nicolas George.
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197571.html
Signed-off-by: Burt P <pburt0@gmail.com>
I don't have any legitimate 20 or 24-bit HDCD to test. It is known
that the PM Model Two would insert packets into 20 and 24-bit output,
but I have no idea what differences in behavior existed when decoding
20 or 24-bit. For now, as with 16-bit, PE (if enabled) will expand the
top 3dB into 9dB and LLE (gain adjust) will be applied if signaled.
Signed-off-by: Burt P <pburt0@gmail.com>
New versions of hdcd_scan() and hdcd_integrate() that also do the
work of hdcd_scan_stereo() and hdcd_integrate_stereo().
Some code split into previously separate functions to remove
duplication is now merged back into each function in the single
place where it is used.
Signed-off-by: Burt P <pburt0@gmail.com>
The buffer is already being copied anyway, so interlace the planar
format during the copy and remove one use of auto-convert.
Signed-off-by: Burt P <pburt0@gmail.com>
The PM Model Two could output HDCD-encoded audio in CD and all
DVD-Audio sample rates. (44100, 48000, 88200, 96000, 176400, and
192000 Hz)
Signed-off-by: Burt P <pburt0@gmail.com>
Fixes regression as of ee72b6d1
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: James Almer <jamrial@gmail.com>
The durations are never written in that situation.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Explicitly state that FATE should pass, and code should work
for all reviewers who tested.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Josh de Kock <josh@itanimul.li>
This isn't a "version script" in the usual sense, since it doesn't set symbol
versions directly. Instead, the version for the whole .dylib is set in the
linker flags, and we generate a list of symbol patterns to export. This allows
us to keep our local symbols (e.g. ff_*) local on the platform.
The Darwin linker's exported_symbols_list format is a bit different than the
one used by the GNU linker. It doesn't handle local symbols at all, since when
a list is provided, all unlisted symbols are local by default; thus, we remove
local sections. It doesn't handle per-version sections, so we remove the
headers and brackets. It expects symbols to be prefixed with an underscore.
It errors if a listed symbol with no wildcards is not present in the output,
so we append an asterisk to any symbol that doesn't already end in one.
Full width text is really difficult to read, this makes it more
more legible on larger (widescreen) screens. It also means we aren't
inventing our own container instead of using the bootstrap one.
Signed-off-by: Josh de Kock <josh@itanimul.li>
There is really no need for two aac wrappers, we already have
libfdk-aac which is better. Not to mention that faac doesn't
even support HEv1, or HEv2. It's also under a license which is
unusable for distribution, so it would only be useful to people
who will compile their own ffmpeg, only use it themselves (which
at that point should just use fdk-aac).
Signed-off-by: Josh de Kock <josh@itanimul.li>
This is a bit messy, mainly due to timestamp handling.
decode_video() relied on the fact that it could set dts on a flush/drain
packet. This is not possible with the old API, and won't be. (I think
doing this was very questionable with the old API. Flush packets should
not contain any information; they just cause a FIFO to be emptied.) This
is replaced with checking the best_effort_timestamp for AV_NOPTS_VALUE,
and using the suggested DTS in the drain case.
The modified tests (fate-cavs and others) still fails due to dropping
the last frame. This happens because the timestamp of the last frame
goes backwards (ffprobe -show_frames shows the same thing). I suspect
that this "worked" due to the best effort timestamp logic picking the
DTS over the decreasing PTS. Since this logic is in libavcodec (where
it probably shouldn't be), this can't be easily fixed. The timestamps
of the cavs samples are weird anyway, so I chose not to fix it.
Another strange thing is the timestamp handling in the video path of
process_input_packet (after the decode_video() call). It looks like
the code to increase next_dts and next_pts should be run every time
a frame is decoded - but it's needed even if output is skipped.
