These are DNxHR profiles with the following properties:
- Variable size in a profile (property added in a previous commit),
requiring variable-sized macroblock table;
- Variable bitdepth, up to 12 bits.
- Better validation of buffer sizes and positions
Signed-off-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This a 4:4:4 10 bits profile, where image size is not fixed by the
profile, and which strays a bit outside the old frame header parsing
code.
Fixes ticket #4581 (DNxHR is not stricly supported, but that sequence is).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently not used, but will be used to indicate that a CIDEntry field
is not set, because it is variable, and that checks should be adapted.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Move the 'interlaced' flag to this element (arbitrarily set to 16bits).
This should allow better detection/selection of profiles.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '39f01e346cab464ef6c0d4ec58cc13b7123e60d8':
mmaldec: be more tolerant against MMAL not returning decoded output
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '65db4899fa8790049bec3af16ecdb75dd81051fd':
mmaldec: refactor to have more context per MMAL input buffer
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'abe9adfb31566c415fd830a8d4977c79512d4385':
rangecoder: Use AV_RB16 instead of bytestream_get_be16
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '4628443ca3534060888dd0015b229337eac13fd2':
h263: Drop uninitialized variable use from log message
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'bb198c4997d5036f3bf91de51e44f807115677d0':
d3d11va: make av_d3d11va_alloc_context() available at all times
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
In some situations, MMAL won't return a decoded frame for certain input
frames. This can happen if a frame fails to decode, or if a packet does
not actually contain a complete frame. In these situations, we would
deadlock (or actually timeout) waiting for an expected output frame,
which is not ideal. On the other hand, there are situations where we
definitely have to block to avoid deadlocks. (This mess is a
consequence of trying to map MMAL's asynchronous and flexible
dataflow to libavcodec, which is more static and rigid.)
Solve this by doing a blocking wait only if the amount of buffered data
is too big. The whole purpose of the blocking wait is to avoid excessive
buffering of input data, so we can skip it if it appears to be low. The
consequence is that libavcodec can gracefully return no frame to the
API user.
We want to track the number of full packets to make our heuristic work.
But MMAL buffers are fixed-size, requiring splitting large packets. This
is why the previous commit is needed. We use the ..._FRAME_END flag to
remember packet boundaries, but MMAL does not preserve these buffer
flags when returning buffers to the user.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The next commit needs 1 bit of additional information per MMAL buffer
sent to the MMAL input port. This information will be needed when the
buffer is recycled (i.e. returned by the input port's callback).
Normally, we could use MMAL_BUFFER_HEADER_FLAG_USER0, but that is
unexpectedly not preserved.
Do this by storing a pointer to FFBufferEntry in the MMAL buffer's
user data, instead of an AVBufferRef. This also changes the lifetime
of FFBufferEntry.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
When compiled with --disable-pthreads, e.g
http://fate.ffmpeg.org/report.cgi?time=20150917015044&slot=alpha-debian-qemu-gcc-4.7,
a bunch of -Wunused-functions are reported due to missing header guards
around threading related functions.
This patch should silence such warnings.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The intended meaning is "if this block is the first block in a slice then
its left boundary is a slice boundary". Silence a logical-not-parentheses
warning from gcc.
Silence a warning due to frame assignment in dvenc. All uses of the
reference in dvdec are read only, except the ones in the main decoding
function, so use the frame pointer directly there.
Assumes 'GA94' format (ATSC standard)
Signed-off-by: DHE <git@dehacked.net>
Tested-by: Anshul <anshul.ffmpeg@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'd0a3e89d41b05f9ed0e7401c352b60ed4f4d1ed5':
dcadec: make a number of samples per subband per subsubframe a named constant
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Fixes: https://trac.ffmpeg.org/attachment/ticket/685/movie.264
In the available testcase the actual PPS only uses a few bits
while there are 7kbyte of apparently random data after it
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This affects Annex B streams (such as demuxed from .ts and others). It
also handles the format change in reinit-large_420_8-to-small_420_8.h264
correctly.
Instead of passing through the extradata, create it on the fly it from
the currently active SPS and PPS. Since reconstructing the PPS and SPS
NALs would be very complicated and verbose, we use the NALs as they
originally appeared in the bitstream.
The code for writing the extradata is somewhat derived from
libavformat/avc.c, but it's small and different enough that sharing it
is not really worth it.
We assume an upper bound of 4096 bytes for each raw SPS/PPS. It's hard
to determine an exact maximum size, but this value was was considered
high enough and safe.
Needed for the following VideotoolBox commit.
The current one, while correct, does not yield the best possible
results. The specificiations suggest another formula, which results
in quality gains in the decoded output from fate tests. This
justifies changing said formula.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
CID 1256 is specified as using the same table for luma and chroma,
which is the same as CID 1235 luma table. This is consistent with
the format supposedly being RGB, although most sequences seem to
actually be YCbCr-encoded.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Tables 1258 and 1259 were not zigzagged when added, so it was not
possible to notice the equivalence.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Convert them to zigzag order, as the rest of them are.
When I was adding support for 10-bit DNxHD, I just copy-pasted the
missing quant matrices from the spec. Now it turns out the existing
matrices in dnxhddata.c were in zigzag order. This resulted in wrong
quantization for 10-bit DNxHD. The attached patch fixes the problem by
converting 10-bit quant matrices to zigzag order.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It is only (mis-)used to set the dsp fucntions clear_block(s). But
these functions always work on 16bits-wide elements, which make
the parameter useless and actually harmful, as it causes all content
on more than 8-bits to not use accelerated functions.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When forwarding the frame type information, by default x264 can
decide which kind of keyframe output, add an option to force it
to output IDR frames in to support use-cases such as preparing
the content for segmented streams formats.
x264 build 147 adds the native support for NV21.
Useful to avoid additional pixel format conversion when encoding
from a wide range of capture devices, Android among those.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Fixes deadlock with threads
Found-by: Paul B Mahol
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The variable is not a constant and can lead to race conditions
Fixes: repro.webm (not reproducable with FFmpeg alone)
Found-by: Dale Curtis <dalecurtis@google.com>
Tested-by: Dale Curtis <dalecurtis@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These field are difficult to interpret, and are provided by a single
encoder (mpegvideoenc). In general they do not belong to a structure
containing raw data only, so remove them from AVFrame.
Mpegvideoenc now uses a private field in Picture for its internal
computations.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Commits 43bc5cf9 and c5371f77 add code for skipping initial zeros in mp3
packets. This code forgot to report to the user that data was skipped at
all.
Since audio codecs allow partial packet decoding, the user application
has to rely on the return value. It will remove the data reported as
consumed by the decoder, and feed it to the decoder again. This resulted
in the mp3 frame after the zero region to be decoded over and over
again, until the zero region was finally skipped by the application.
Fix this by including the amount of skipped bytes to the number of
consumed bytes returned by the decode call.
Fixes trac ticket #4890.
CID 1256 is specified as using the same table for luma and chroma,
which is the same as CID 1235 luma table. This is consistent with
the format supposedly being RGB, although most sequences seem to
actually be YCbCr-encoded.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
VideoToolbox also implements a software decoder for h264, and will fallback to
using it if the file cannot be decoded on the GPU. In these cases though,
we want the hwaccel to fail so that we can use the libavcodec software decoder
instead of the Apple one.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
* commit '4885bde3187a2bb0cae85b67796e07db233bf77f':
motion_est_template: Fix undefined left shift of negative number
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '948f3c19a8bd069768ca411212aaf8c1ed96b10d':
lavc: Make AVPacket.duration int64, and deprecate convergence_duration
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This bit is 1 in some samples, and seems to coincide with interlaced
mbs and CID1260. 2008 specs do not know about it, and maintain qscale
is 11 bits. This looks oversized, but may help larger bitdepths.
Currently, it leads to an obviously incorrect qscale value, meaning
its syntax is shifted by 1. However, reading 11 bits also leads to
obviously incorrect decoding: qscale seems to be 10 bits.
However, as most profiles still have 11bits qscale, the feature is
restricted to the CID1260 profile (this flag is dependent on
a higher-level flag located in the header).
The encoder writes 12 bits of syntax, last and first bits always 0,
which is now somewhat inconsistent with the decoder, but ends up with
the same effect (progressive + reserved bit).
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Note that convergence_duration had another meaning, one which was in
practice never used. The only real use for it was a 64 bit replacement
for the duration field. It's better just to make duration 64 bits, and
to get rid of it.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '83847cc8fa97e0fc637a0962bafb837acdb6eacc':
qsvenc: do not try to close the encoder if the session is NULL
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
File libopenh264enc.c has been modified so that the encoder uses av_log()
to log messages (error, warning, info, etc.) instead of logging them
directly to stderr. At the time the encoder is created, the current
libav log level is mapped to an equivalent libopenh264 log level. This
log level, and a message logging function that invokes av_log() to
actually log messages, are then set on the encoder.
This contains further changes and simplifications by Michael Niedermayer
and Martin Storsjö.
Signed-off-by: Martin Storsjö <martin@martin.st>
pix_fmt was declared presumably to shorten the argument passed to the function.
However, it is currently not being used for such a purpose.
This patch simply removes it instead.
This fixes -Wunused-but-set-variable reported at e.g:
http://fate.ffmpeg.org/log.cgi?time=20150919194249&log=compile&slot=x86_64-darwin-gcc-4.9.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It appears vdpau drivers can return constrained baseline as unsupported,
even if libvdpau knows about the symbol, and the main profile is
supported.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This function can intrinsically not deal with codec profile fallback
(for H.264 Constrained Baseline especially), and was made redundant
by av_vdpau_bind_context().
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Each line is padded by the format, and errors are now reported and
stop the decoding. Around 5% speedup.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Default field order to top field first when interlaced frame is detected and pic_struct_present_flag is not set.
Since bottom field first comes from the old NTSC standard and is not used with HD anymore I think it´s straight forward to favor the majority.
Signed-off-by: Thomas Mundt <loudmax@yahoo.de>
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Around 3x speedup with 4 threads. Maybe more mb lines should be
batched per thread, but that's good enough for a first try.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Indicates a YCbCr->RGB transform at the block level. Although nothing
explicitly states it, this would assume the actual content is planar
RGB.
Currently unsupported, but the one sequence I found using it flagged
every mb that way, actually meaning the content was YCbCr, and thus
best left to the output format to decide what to do of it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It currently only applies to CID 1260, but this flag is dependent on
a higher-level flag located in the header.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'bbf71d46db3417b43bcbd745cbf235e8e2ff69ae':
dxv: Print texture information after header parsing
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
CID 1260 (as evidenced by incorrect decoding of a sample from ticket
4876) seems to use incorrect weight tables. It appears those tables
were not zigzag-scanned.
Apply zigzag on weight tables for new CIDs 1258, 1259, and 1260, and
fix an incorrect chroma table for CID 1256.
Fixes last issue from ticket #4876.
Found-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This bit is 1 in some samples, and seems to coincide with interlaced
mbs and CID1260. 2008 specs do not know about it, and maintain qscale
is 11 bits. This looks oversized, but may help larger bitdepths.
Currently, it leads to an obviously incorrect qscale value, meaning
its syntax is shifted by 1. However, reading 11 bits also leads to
obviously incorrect decoding: qscale seems to be 10 bits.
However, as most profiles still have 11bits qscale, the feature is
restricted to the CID1260 profile.
The encoder writes 12 bits of syntax, last and first bits always 0,
which is now somewhat inconsistent with the decoder, but ends up with
the same effect (progressive + reserved bit).
Partially fixes ticket #4876.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch tweaks search_for_pns to be both more
aggressive and more careful when applying PNS. On
the one side, it will again try to use PNS on zero
(or effectively zero) bands. For this, both zeroes
and band_type have to be checked (some ZERO bands
aren't marked in zeroes). On the other side, a more
accurate rate-distortion measure avoids using PNS
where it would cause audible distortion.
Also fixed a small bug in the computation of freq
that caused PNS usage on low-frequency bands during
8-short windows. This allows re-enabling PNS during
8-short.
AVBufferRef.data and AVPacket.data don't need to have the same value.
AVPacket could point anywhere into the buffer. Likewise, the sizes
don't need to be the same.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This works only for extradata sizes up to 128 bytes. Additionally, I
could never actually see it doing anything. The new code using
MMAL_BUFFER_HEADER_FLAG_CONFIG now takes care of this.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
We can send mp4-style data directly. But for some reason, this requires
sending the extradata as buffer with MMAL_BUFFER_HEADER_FLAG_CONFIG
set. Reuse the infrastructure for sending AVPackets to do this.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Commit 7404f3bdb switched bitrate to 64 bits.
This triggers -Wabsolute-value on clang, e.g
http://fate.ffmpeg.org/log.cgi?time=20150917122742&log=compile&slot=x86_64-darwin-clang-3.7-O3.
Therefore, usage of abs is changed to llabs, which is available on all of the platforms.
Unfortunately, LLONG_MAX is not always available, so INT64_MAX is used instead.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch modifies the encode frame function to
retry encoding the frame when the resulting bit count
is too far off target, but only adjusting lambda
in small, incremental step. It also makes the logic
more conservative - otherwise it will contend with
bit reservoir-related variations in bit allocation,
and result in artifacts when frame have to be truncated
(usually at high bit rates transitioning from low
complexity to high complexity).
