"int" is useful in testing because provides accurate results across
different plaftforms, so remove it from the scheduled FF_API_UNUSED_MEMBERS
deprecation.
Deprecate the now unused option, but temporarily retain the capability
to disable the now default behaviour.
Mention this change in the AVPacket documentation.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This also drops setting the frame->pts field. This is usually not set by
decoders, so this would be an inconsistency that's at worst a danger to
the API user.
It appears the buffer->dts field is normally not set by the MMAL
decoder, so don't use it. If it's ever going to be set by MMAL, we
don't know whether the value will be what we want.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The generic code in utils.c sets the AVFrame.pkt_dts field from the
packet it was supposedly decoded. This does not have to be true for a
fully asynchronous decoder like mmaldec. It could be overwritten with an
incorrect value. Even if the decoder doesn't determine the DTS (but sets
it to AV_NOPTS_VALUE), it's impossible to determine a correct value in
utils.c.
Decoders can now be marked with FF_CODEC_CAP_SETS_PKT_DTS, in which case
utils.c won't overwrite the field. The decoders are expected to set this
field (even if they only set it to AV_NOPTS_VALUE).
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This MMAL feature fills in missing timestamps from the framerate set on
the input port. This is generally unwanted, since libavcodec decoders
merely pass through timestamps without ever "fixing" them. The framerate
is also unknown, and even the timebase doesn't have to be set.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Don't try to do a blocking wait for MMAL output if we haven't even sent
a single real packet, but only flush packets. Obviously we can't expect
to get anything back.
Additionally, don't send a flush packet to MMAL in the same case. It
appears the MMAL decoder will sometimes hang in mmal_vc_port_disable()
(called from ffmmal_close_decoder()), waiting for a reply from the GPU
which never arrives. Either MMAL disallows sending flush packets without
preceding real data, or it's a MMAL bug.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
I can't come up with a nice way to handle this. It's hard to keep the
lock-stepped input/output in this case. You can't predict whether the
MMAL decoder will output a picture (because it's asynchronous), so
you have to assume in general that any packet could produce 0 or 1
frames. You can't continue to write input packets to the decoder,
because then you might get too many output frames, which you can't
get rid of because the lavc decoding API does not allow the decoder
to return an output frame without consuming an input frame (except
when flushing).
The ideal fix is a M:N decoding API (preferably asynchronous), which
would make this code potentially much cleaner. For now, this hack
will do.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Do not make many assumption on the dimension of the slices and just
try to decode additional lines if there is enough data left.
Decodes all the samples kindly provided by ultramage.
Despite '417792' being reported in the binary decoder, the buffer at
encoding time needs to be bigger to avoid running out of space due to
interlace handling.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Use a comment to list the reused tables, since it's more flexible than a
table name to keep information like this. The list will expand in later
commits.
Previously most of the error paths leaked.
Also add FF_CODEC_CAP_INIT_THREADSAFE while adding caps_internal;
this decoder wrapper doesn't have any static data that is initialized.
Signed-off-by: Martin Storsjö <martin@martin.st>
For ADTS streams, the output format (number of channels, frame size)
can change at any point (with the latest version of fdk-aac, the decoder
seems to change format after a handful of frames, not outputting the
right format immediately, for cases that worked fine with the earlier
version of the lib).
Previously, the decoder decoded straight into the output frame once the
number of channels and frame size was known. This obviously does not
work if the number of channels or frame size changes.
The alternative would be to allocate the AVFrame with the maximum number
of channels and frame size, and change them afterward decoding into it,
but that may cause confusion to users e.g. of the get_buffer callback.
This solution should be more robust.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
In the latest version of fdk-aac, the decoder can output up to 8
channels; take this into account when preallocating buffers that
need to fit the output from any packet.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
The .text section is already 16-byte aligned by default on all supported
platforms so `SECTION_TEXT` isn't any different from `SECTION .text`.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Change ALLOC_STACK to always align the stack before allocating stack space for
consistency. Previously alignment would occur either before or after allocating
stack space depending on whether manual alignment was required or not.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
There is an SSE2 implementation so the SSE version is never used. The "SSE"
version also happens to contain SSE2 instructions on x86-64.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Extract two methods from decode_registered_user_data in order to improve
code readability. Also make the constant holding the allocation size a
64-bit unsigned integer so that the size comparison against INT_MAX makes
sense.
Bug-Id: CID1312090
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
If _WIN32_WINNT is unset, we force it to a new enough value to
make sure the necessary definitions are visible.
When targeting Windows Phone or Windows RT, _WIN32_WINNT should
be at least 0x0602 - otherwise the windows headers themselves
can cause errors (which technically are bugs in the headers).
Raising this value here shouldn't hurt; the alternative would
be to not touch it at all if WINAPI_FAMILY is set to phone/app,
or to force setting it to 0x0602 in configure if unset (for phone/app).
Signed-off-by: Martin Storsjö <martin@martin.st>
When skip_frame is set to _NONKEY the decoder skips everything except intra
slices, which breaks frames that consist of an intra field together with any
other field type; half the frame becomes garbage. This patch fixes the issue by
letting non-intra slices through if they're part of a keyframe.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This change will reject frames with a texture type which does not match
the stream description.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This option is extremely codec specific and only a few codecs employ it.
Move it to codec private options instead: mpegenc family supports only 3
values, xavs and x264 use 5, and xvid has a different metric entirely.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The struct definitions in dxva.h, which are necessary in order to
actually use d3d11va, are hidden when WINAPI_FAMILY targets Windows Phone
or WindowsRT.
Building with WINAPI_FAMILY=WINAPI_FAMILY_DESKTOP_APP is disallowed
when targeting ARM. ("Compiling Desktop applications for the ARM
platform is not supported.") So we set _CRT_BUILD_DESKTOP_APP to 0
to tell the runtime not to detect some issues with this mismatching.
The same tweaks to detect if the API is available is done in dxva2_internal.h
when compiling each DXVA2/D3D11VA decoders.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is triggerable with the HEVC decoder. It is unclear yet whether the
bug is in the calling code or the MSDK, but it seems better to check for
this in any case.
A bug was introduced in 977105407c whereby when
frame height wasn't divisible by the number of threads, pixels would be omitted
from the bottom rows during decode.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
A bug was introduced in 6b2b26e7af whereby when
frame height wasn't divisible by the number of threads, pixels would be omitted
from the bottom rows during decode.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Enjoy some cache locality and use less threads.
About 5x speedup (from 60ms to 12ms to decode a 4k frame).
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The rationale is that coded_frame was only used to communicate key_frame,
pict_type and quality to the caller, as well as a few other random fields,
in a non predictable, let alone consistent way.
There was agreement that there was no use case for coded_frame, as it is
a full-sized AVFrame container used for just 2-3 int-sized properties,
which shouldn't even belong into the AVCodecContext in the first place.
The appropriate AVPacket flag can be used instead of key_frame, while
quality is exported with the new AVPacketSideData quality factor.
There is no replacement for the other fields as they were unreliable,
mishandled or just not used at all.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This is necessary to preserve the quality information currently exported
with coded_frame. Add the new side data to every encoder that needs it,
and use it in avconv.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Allocating coded_frame is what most encoders do anyway, so it makes
sense to always allocate and free it in a single place. Moreover a lot
of encoders freed the frame with av_freep() instead of the correct API
av_frame_free().
This bring uniformity to encoder behaviour and prevents applications
from erroneusly accessing this field when not allocated. Additionally
this helps isolating encoders that export information with coded_frame,
and heavily simplifies its deprecation.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This change (and the following ones of the same kind) is mainly to
simplify wrapping this section with an #if FF_API block later on.
No functional changes are applied, the fields of the context coded_frame
fields are directly initialized, instead of keeping a reference to the
coded_frame itself.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The upper halves are not guaranteed to be zero in x86-64.
Also use `test` instead of `and` when the result isn't used for anything other
than as a branch condition, this allows some register moves to be eliminated.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
