| Age | Commit message (Collapse) | Author |
|---|
|
Express bitfields more simply.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
Convert doxygen to multiline and express bitfields more simply.
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>
|
|
|
|
For audio encoders, delay has no effect, use the appropriate one,
initial_padding (see 2df0c32).
|
|
|
|
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>
|
|
|
|
|
|
|
|
It will be shared with the upcoming mpeg2 and hevc decoders.
|
|
Declare a named enum, not a variable with anonymous enum type.
|
|
init() is called whenever format changes, so current code would leak the
fifo in this case.
|
|
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.
|
|
This fixes the palette on big endian, broken (or, differing from
little endian) since 57214b2f7.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
Some uses of Snappy require uncompressing to positions within
an existing buffer. Also adds a function to get the uncompressed
length of Snappy data.
|
|
A bug was introduced in 977105407cae55876041dddbf4ce0934cdd4cd6c 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 6b2b26e7af3ede0abfb46eb5725c26d1083f50bc 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>
|
|
|
|
Found-By: ami_stuff
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
|
|
Red and blue channels were decoded in the wrong order.
Found-By: ami_stuff
|
|
Drop the global variables with anonymous enum type.
|
|
|
|
Enjoy some cache locality and use less threads.
About the same speedup provided to HAP.
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>
|
|
Avoids a relocation which might end out of range for thumb2.
Reported-By: Ludovic Fauvet <etix@videolan.org>
Bug-Id: https://bugs.webkit.org/show_bug.cgi?id=137022
CC: libav-stable@libav.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>
|
|
|
|
|
|
|
|
|
|
|
|
Keep coded_frame.key_frame a write-only variable.
|
|
|
|
|
|
|
|
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>
|
|
Its fields are never initialized to begin with.
|
|
coded_frame is already initialized where needed.
|
|
Wait for async_depth frames before syncing.
|
|
Wait for async_depth frames before syncing.
|
|
|
|
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>
|
|
|
|
|
|
|
