From
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
"If biCompression equals BI_RGB and the bitmap uses 8 bpp or less, the
bitmap has a color table immediatelly following the BITMAPINFOHEADER
structure. The color table consists of an array of RGBQUAD values. The
size of the array is given by the biClrUsed member. If biClrUsed is
zero, the array contains the maximum number of colors for the given
bitdepth; that is, 2^biBitCount colors."
Nothing about "monochrome" here. Unfortunately, pal8 to monow conversion
seems a bit flaky, but that's another story.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It was useful to (accidentally?) spot an overflow in the column pass
of the x86 simple_idct10 implementation.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
omse goes from 0.03060703 (which fails for dct-test) to 0.01663750.
This also actually improve the error of decoding the sample generated
by fate-vsynth3-dnxhd1080i-10bit using simple_idct10 to FAANI, which
goes (when resampled to yuv422p) from:
stddev: 0.06 PSNR: 72.28 MAXDIFF: 1
to identical.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
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>
* commit '02b7c630875c0bc63cee5ec597aa33baf9bf4e20':
h261: Signal freeze picture release for intra frames
Conflicts:
tests/ref/vsynth/vsynth1-h261
tests/ref/vsynth/vsynth2-h261
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Freeze picture release should be set to 1 when we're responding to a
fast update request. For simplicity we set it for all intra frames,
including those that starts a GOP.
Fixes issue where Tandberg MXP1700 does not recover from packet loss
state since it's waiting for the freeze picture relase indication.
Bug-Id: 873
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Ref H.261 recommendation section 4.2.1.3, setting the still image flag
to 1 disables still image mode. Some decoders require this in order to
decode the bitstream as normal video.
Fixes H.261 calls to Cisco E20.
Also, reserved (aka spare) bits should be set to 1 unless specified
otherwise.
Bug-Id: 872
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
thats how the specification defines it, this also improves numerical
accuracy of the integer wavelet implementation. It otherwise should
be equivalent, in case of overflows this can be reverted.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Even if the jpeg2000 spec uses a wrong value this does not
make mathematics work this way, also this has been corrected in the 2004
version AFAIK
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
No real difference in quality, its a bit slower for the same dia_size as more
vectors are searched for the same dia_size
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd
ffmpeg and qtdump could not decode pasp/colr atoms in the files made by ffmpeg,
when outputting DNxHD due to the incorrect padding placement. Now we add the
padding in the correct place
Tidy up FATE changes due to padding changes.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Avid prefers mpeg range [16-235] by default this change brings
ffmpeg into line with that. To obtain the old behaviour use
'-color_range jpeg' on the command line prior to the ouput
filename.
Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The file is already present in git and by using it we can perform more tests
without the need of fate samples
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The new reference.pnm is a freely licensed replacement. The photo has
been taken by Reinhard Tartler on August 28 2014, and is licensed under
the expat license as stated at http://www.jclark.com/xml/copying.txt
It is derived from the actual equations of the specs. In
particular, it is closer to the inverse of what the encoder uses.
fate tests accordingly updated.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Normally, a Laplace distribution is more typical of the residuals
encoded, but for noisy input, it's both better and simpler to be
safe and use a 1/d^2 distribution. Second hunk could use some
renormalization but it has effectively little impact.
Output size of ffvhuff on various 4:2:0 sequences:
context=0,1/d: 851974 27226 1137281
context=0,1/d²: 619081 25069 1051500
context=0,1/d³: 501983 30454 1290561
context=0,lapl: 500650 31754 1304082
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Improves compatibility with XDCAM HD formats. It has been set for a long time
in ffmbc.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Marton Balint <cus@passwd.hu>
no changes in either standard deviation or PSNR is seen in any of the changed fate
cases
MSE changes from 0.05012422 to 0.04890000
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The encoder uses almost none of the mpegvideo infrastructure, only some
fields from MpegEncContext.
The FATE results change because now an all-zero quant matrix is written
into the file. Since it is not used for anything for ljpeg, this should
not be a problem.
This may improve compatibility of lgpegs generated by libavcodec
also encoded ljpegs become slightly smaller
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The fate tests change as they used 1.2 previously
The increased size is due to:
32bit CRCs per slice by default (can be disabled),
it adds slice headers to allow decoding one slice without the others
an additional slice size field is added to make it possible to find
slices within corrupted surroundings.
these add up to about 57bit per slice more
at 50 frames and 4 slices thats 1425 byte
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
QuickTime will play multiple audio tracks concurrently if this flag is
set for multiple audio tracks. And if no subtitle track has this flag
set, QuickTime will show no subtitles in the subtitle menu.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Tha fate tests change because the edge mirroring was wrong before this commit
Reviewed-by: Nicolas BERTRAND <nicoinattendu@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The quantization code needs more work, not so much work
merging but more work investigating what is correct.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Using the first names of authors sounds somewhat unprofessional
and might be considered offensive which is not intended.
The new names use the initials of the authors due to simplicity
and the possibility to apply it consistently without the need
to find political correct names for each future case where
alternative codecs might exist. Also its shorter ...
If someone has a better idea, like maybe 2 random letters
and people prefer it then iam happy to switch to that ...
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3e2f200237af977b9253b0aff121eee27bcedb44':
roqvideodec: fix a potential infinite loop in roqvideo_decode_frame().
xxan: fix invalid memory access in xan_decode_frame_type0()
tty: set avg_frame_rate.
FATE: enable multiple slices in the ffv1 vsynth test
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Other software does not store it in this case, and the information
is provided by the codec stream
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The QuickTime specification does not contain any hint that the atom
must not be written in some cases and both the QuickTime and the
AVID decoders do not fail if the atom is present.
This change allows to signal (visually) interlaced streams with
a codec different from uncompressed video.
As a side-effect, this fixes ticket #2202
* commit '69c25c9284645cf5189af2ede42d6f53828f3b45':
dnxhdenc: fix invalid reads in dnxhd_mb_var_thread().
x86: h264qpel: Move stray comment to the right spot and clarify it
atrac3: use correct loop variable in add_tonal_components()
Conflicts:
tests/ref/vsynth/vsynth1-dnxhd-1080i
tests/ref/vsynth/vsynth2-dnxhd-1080i
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e6bc38fd49c94726b45d5d5cc2b756ad8ec49ee0':
wmv2: move IDCT to its own DSP context.
Conflicts:
libavcodec/dsputil.h
tests/ref/seek/vsynth2-wmv2
tests/ref/vsynth/vsynth1-wmv2
tests/ref/vsynth/vsynth2-wmv2
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This allows us to remove FF_IDCT_WMV2, which serves no practical purpose
other than to be able to select the WMV2 IDCT for MPEG (or vice versa)
and get corrupt output.
Fate tests for all wmv2-related tests change, because (for some obscure
reason) they forced use of the MPEG IDCT. You would get the same changes
previously by not using -idct simple in the fate test (or replacing it
with -idct auto).
