* shariman/wmall:
Fix lms_update()
Move num_lms reading out of a loop
Use correct value for range
Fix some int / int16_t / int32_t confusion
Implement revert_mclms() and associated functions
Fix two more int16_t vs. int confusion
Init s->cdlms[][].recent to order - 1
Add a size argument to dump_int_buffer()
Get rid of logging that are not required anymore
Fix some int vs. int16_t confusion
Conflicts:
libavcodec/wmalosslessdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The default of 9 gives different results on different FATE systems.
However the zlib test using compression level 6 works, so
try this instead.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Its checked a few lines below too.
The only difference is that empty atoms with size=0 will now get parsed too.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The computed size doesn't contain the header size because it's already
skipped by incrementing total_size, but then it's skipped again in the
last line. The atom comes out 8 bytes short and the function
mov_read_chan() aborts the whole parsing process. I think the computed
size should be atom.size - total_size + 8.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
mov: Don't av_malloc(0).
avconv: only allocate 1 AVFrame per input stream
avconv: fix memleaks due to not freeing the AVFrame for audio
h264-fate: remove -strict 1 except where necessary (mr4/5-tandberg).
misc Doxygen markup improvements
doxygen: eliminate Qt-style doxygen syntax
g722: Add a regression test for muxing/demuxing in wav
g722: Change bits per sample to 4
g722dec: Signal skipping the lower bits via AVOptions instead of bits_per_coded_sample
api-example: update to use avcodec_decode_audio4()
avplay: use avcodec_decode_audio4()
avplay: use a separate buffer for playing silence
avformat: use avcodec_decode_audio4() in avformat_find_stream_info()
avconv: use avcodec_decode_audio4() instead of avcodec_decode_audio3()
mov: Allow empty stts atom.
doc: document preferred Doxygen syntax and make patcheck detect it
Conflicts:
avconv.c
ffplay.c
libavcodec/mlpdec.c
libavcodec/version.h
libavformat/mov.c
tests/codec-regression.sh
tests/fate/h264.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
More specifically, PNG, v210, zlib and zmbv codecs.
zmbv needs vf_scale to be able to produce PAL8.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
While quality is bad, PAL8 support is needed to allow testing some
encoders that only support PAL8 input.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
For some of the code e.g. doing timing measurements there is no
real point in running regression testing on it, thus it should
not be counted against coverage.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Adds --enable-coverage to configure and a "coverage-html" make target.
The dependency stuff in the Makefile is a bit questionable, but the
best I could think of so far.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
malloc() is allowed to return NULL when zero is the argument. This
causes us to think malloc has failed and return AVERROR(ENOMEM). In
addition OS X malloc() returns an unfreeable non-NULL pointer for size
zero when alignment is greater than 16.
Earlier, bits per sample was defined as 8, since
bits_per_coded_sample was used to indicate whether to ignore
the lower bits of the codeword, having values 6, 7 or 8.
g722 encodes 2 samples into one byte codeword, therefore the
bits per sample is 4. By changing this, the generated timestamps
for streams encoded with g722 become correct.
This makes timestamp generation for g722 data correct (both when
encoding and when demuxing from raw g722 files).
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids using bits_per_coded_sample for this information.
bits_per_coded_sample should be 4 for this codec normally,
since two samples are encoded into one 8 bit codeword.
In principle, this might be info that needs to be passed from
a demuxer, and in that case, a private AVOption isn't the best
choice, but no such samples are available at the moment, so
that use case is purely theoretical at the moment.
Signed-off-by: Martin Storsjö <martin@martin.st>
