FATE refs changed to accomodate for the new default behavior of the function.
Numbers are now interpreted as a channel layout, instead of a number of channels.
* commit '58c3720a3cc71142b5d48d8ccdc9213f9a66cd33':
fate: Make sure a corner-case for ASF is covered
Adjusted fate ref to match the different timebase of the ffasf demuxer
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
As suggested, posting the combined patch with the fate changes.
The patch sets the default style in ASS from the default style
information present in the movtext header.
Signed-off-by: Niklesh <niklesh.lalwani@iitb.ac.in>
Compute individual stream durations in matroska muxer.
Write them as string tags in the same format as mkvmerge tool does.
Signed-off-by: Sasi Inguva <isasi@google.com>
Also replace custom tests for MD5 with those published in RFC 2202
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes Ticket4664
The changed fate tests lack red/blue shades and thus look correct
either way
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* 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>
* commit 'f91fe24e9bd6912c29bbb03d8afe878e045f9721':
g2meet: force simple idct for identical results over all fate configs
Conflicts:
tests/ref/fate/g2m3
tests/ref/fate/g2m4
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4d1229dabf7a7e3b6a7b326afd79102256c3b008':
g2meet: Add FATE tests for all three G2M variants
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Most of the fate-dds-* and fate-txd-* tests already
output into the same pixel format regardless of
platform endianness, so there's no need to force
conversion to another format.
This fixes the tests fate-txd-16bpp, fate-txd-odd,
fate-dds-rgb16, fate-dds-rgb24 and fate-dds-xrgb on
big endian, where the tests seem to fail due to issues
with certain conversion codepaths in swscale.
Those conversion codepaths should of course be fixed, but
the individual decoder tests should use as little extra
conversion steps as possible.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'd3ea79e8a65ddad4da11813bb43c46701295f68c':
FATE: drop the last truncated frame from the wma lossless test
Conflicts:
tests/fate/lossless-audio.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The old one is the result of the reverse engineering and guesswork.
The new one has been written following the now-available specification.
This work is part of Outreach Program for Women Summer 2014 activities
for the Libav project.
The fate references had to be changed because the old demuxer truncates
the last frame in some cases, the new one handles it properly.
The seek-test reference is changed because seeking works differently
in the new demuxer. When seeking, the packet is not read from the stream
directly, but it is rather constructed by the demuxer. That is why
position is -1 now in the reference.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Result differs in pkt_duration and time_base.den for some reason.
Right now it tests only one example (adjusted to match the output).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Ideally this should be discarded by the demuxer but this is not
possible without fully parsing which would be then very similar
to this. The current ID3v1 discard code in the demuxer does not work
and will be removed in a subsequent commit
The discard code could be adjusted if needed to also discard tags at
other locations than the end or to limit this possibly to input
from the mp3 demuxer or even to move the discarding to the
decoder.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c0b105756f61d253bdabcc2bb49453a2557e7c3b':
txd: Use the TextureDSP module for decoding
Conflicts:
configure
libavcodec/s3tc.c
libavcodec/s3tc.h
libavcodec/txd.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Using the internal DXTC routines brings support for non multiple of 4
textures. A new test is added to cover this feature. Hashes differ
since the decoding algorithm is different, though no visual changes
have been spotted.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
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>
This is almost certainly closer to how the actual Nintendo players work,
and fixes some output pops in files with blank ADPC/SEEK tables (like
those from brawlcustommusic).
* commit '063f7467e4d14ab7fe01b2845dab60cc75df8b53':
rtmpdh: Add fate test for the DH handshake routine
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Previous version Reviewed-by: tim nicholson <nichot20@yahoo.com>
Previous version Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The positioning was completely wrong. First, the coordinates are
expressed in ASS playback resolution (which is by default 384x288).
Secondly, the coordinates define a drawing rectangle, not a moving area.
The previous code was making subtitles move from a random position to
another random position.
Here we rescale assuming the video resolution is a DVD one (720x480). We
can't really do anything better so far, but since this positioning
information is often from a DVD rip we can consider them relatively
safe.
