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>
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>
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>
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>
Christophe Gisquet
Stefano Pigozzi
Ganesh Ajjanagadde
Vittorio Giovara
wm4
Michael Niedermayer
Gregory J. Wolfe
Paul B Mahol
Anton Khirnov
Rémi Denis-Courmont
Thomas Mundt
Claudio Freire
Jeremy James
wm4