If _FieldBased, _Matrix, _ColorRange, or _ChromaLocation haven't
been set, that absence would be interpreted as 0, leading to those
being set to case 0 instead of default. There is no case 0 for
_Primaries and _Transfer, so those were correctly falling back
to the default case.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
Since the check got simplified and stdbool was no longer necessary
to include, neither is that variable. Silences a warning.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
Trying to be clever about determining between interface version 8
and 8.1 ended up with pre-8.1 versions of AviSynth+ segfaulting.
The amount of time between interface version 8.1 and 9 is small,
so just restrict the frameprop awareness to version 9 and call it
a day.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
* Field Order
* Chroma Location
* Color Transfer Characteristics
* Color Range
* Color Primaries
* Matrix Coefficients
The existing TFF/BFF detection is retained as a fallback for
older versions of AviSynth that can't access frame properties.
The other properties have no legacy equivalent to detect them.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
AviSynth works on frame-based video by default, which can
be either progressive or interlaced. Some filters can break
frames into half-height fields, at which point it considers
the clip to be field-based (avs_is_field_based can be used
to check for this situation).
To properly detect the field order of a typical video clip,
the frame needs to have been weaved back together already,
so avs_is_field_based should actually report 'false' when
checked.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
AviSynth+ outputs audio in the same format as the
OS, so assuming little endian formats as input
on big endian OSes results in nothing but static.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
avs_is_color_space provides a generic way of checking whether the
video is RGB, and has been available through AVSC_API since 2.6.
This means that GetProcAddress doesn't have to run on every frame.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
AviSynth+ now supports non-Windows OSes, making AvxSynth
obsolete. Since we no longer support AviSynth 2.5 (which is
essentially what AvxSynth is), remove AvxSynth support and
replace it with AviSynth+.
As a result, the USING_AVISYNTH defines can be switched back
to generic _WIN32.
It is not uncommon to find code where the caller thinks to know better
what the return value should be than the callee. E.g. something like
"if (av_new_packet(pkt, size) < 0) return AVERROR(ENOMEM);". This commit
changes several instances of this to instead forward the actual error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit was merged in a couple years ago as a no-op because we
had already switched from GetProcAddress to dlsym some time before
that. However, not applying the actual cast causes warnings about
FARPROC and when attempting to build FFmpeg in MSVC with AviSynth-GCC
32-bit compatibility, those FARPROC warnings turn into FARPROC errors.
These pix_fmts have been added to FFmpeg in the 31 months since
commit 92916e8542 added support for
the larger number of pix_fmts that AviSynth+ can use. They were
present in AviSynth+ even then, just not in libavutil.
It's completely absurd that libavcodec would care about libavformat
locking, but it was there because the lock manager was in libavcodec.
This is more stright forward. Changes ABI, but we don't require ABI
compatibility currently.
* commit '3cc3463f306f425f76bd962755df1132eeac6dfa':
avisynth: Support pix_fmts added to AviSynth+
This commit is mostly a noop, see
92916e8542.
Cosmetics and a small fix are merged.
Merged-by: Clément Bœsch <u@pkh.me>
A number of new pix_fmts* have been added to AviSynth+:
16-bit packed RGB and RGBA
10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
8-, 10-, 12-, 14-, and 16-bit Planar RGB
8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA
10-, 12-, 14-, and 16-bit GRAY variants
32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY
*some of which are not currently available pix_fmts here and were
not added to the demuxer due to this
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Stream timebase should be set using avpriv_set_pts_info, otherwise
avctx->pkt_timebase is not correct, leading to A/V desync.
Signed-off-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Stephen Hutchinson <qyot27@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
A number of new pix_fmts have been added to AviSynth+:
16-bit packed RGB and RGBA
10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
8-, 10-, 12-, 14-, and 16-bit Planar RGB
8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA*
10-, 12-, 14-, and 16-bit GRAY variants*
32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY*
*some of which are not currently available pix_fmts here and were
not added to the demuxer due to this
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The values don't need to be hardcoded since the correct values are
returned by avs_bits_per_pixel.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
Stream timebase should be set using avpriv_set_pts_info, otherwise
avctx->pkt_timebase is not correct.
This should fix ticket #4766.
Patch is only compile tested.
Signed-off-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Stephen Hutchinson <qyot27@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '247aa7af7d8197247c181e3fbfe8d93d75e41b29':
avisynth: Simplify shared library name construction
Conflicts:
libavformat/avisynth.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
In order to safely exit when the user tries to use AviSynth 2.5, the
continue_on_fail value for 2.6's functions need to be set to 1.
Otherwise, the library loader fails before the 'upgrade to 2.6'
log message appears.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The AVSC_API changes in the new headers mean that the 2.6 alphas
are just as incompatible as 2.5 is.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In order to safely exit when the user tries to use AviSynth 2.5,
the continue_on_fail value for 2.6's functions need to be set to
1. Otherwise, the library loader fails before the 'upgrade to
2.6' log message appears.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If the user attempts to use AviSynth 2.5, an error message will
now tell them they need to upgrade.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a8c99205ca8703bd849efae13fcf844315c7147d':
avisynth: Fix compilation against current 2.6 header(s).
Merged-by: Michael Niedermayer <michaelni@gmx.at>
AviSynth 2.6 (and by extension, AviSynth+) moves these functions
into AVSC_API. This requires both adjusting their normal use,
and for AvxSynth, adjusting the position/use of the USING_AVISYNTH
ifdefs.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Reviewed-by: Stephen Hutchinson <qyot27@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
If the audio changes from 9eac7c4 were merged as they were, this
would cause scripts with both video+audio to fail with a lot of
audio decoding errors (the video would be fine). Scripts with
only one of either video or audio were unaffected. Additionally,
the av_packet changes in general caused seeking to break.
Using av_packet_from_data allows video+audio scripts to work as
expected, without audio decoding errors. It also fixes seeking.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
These are the remaining av_packet-related bits from 9eac7c4
that didn't get merged at that time.
Changes authored by Anton Khirnov <anton@khirnov.net>, split out
from 9eac7c4 by Stephen Hutchinson <qyot27@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
