* commit '8542f9c4':
  replaygain: correctly parse peak values

Conflicts:
	libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '25b6837f':
  replaygain: fix gain sign decoding
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This change make error handling simplier.
av_opt_freep_ranges may be called when some ranges are NULL,
for example after memory allocation fail.
Signed-off-by: Lukasz Marek <lukasz.m.luki@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This reverts part of 41e7e46c

See: http://thread.gmane.org/gmane.comp.video.ffmpeg.user/51229Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

According to the ReplayGain spec, the peak amplitude may overflow and may result
in peak amplitude values greater than 1.0 with psychoacoustically coded audio,
such as MP3. Fully compliant decoders must allow peak overflows.

Additionally, having peak values in the 0<->UINT32_MAX scale makes it more
difficult for applications to actually use the peak values (e.g. when
implementing clipping prevention) since values have to be rescaled down.

This patch corrects the peak parsing by removing the rescaling of the decoded
values between 0 and UINT32_MAX and the 1.0 upper limit.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes ticket #3522.
Signed-off-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The gain sign was incorrectly decoded: since the FFSIGN() macro treats 0 as
negative, gain values starting with "0." were always decoded as negative.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* qatar/master:
  arm: asm decode_block_coeffs_internal is vp8 specific

See: 89f2f5dbMerged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '28743243':
  fate: add a VP7 test
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'ac4b32df':
  On2 VP7 decoder

Conflicts:
	Changelog
	libavcodec/arm/h264pred_init_arm.c
	libavcodec/arm/vp8dsp.h
	libavcodec/arm/vp8dsp_init_arm.c
	libavcodec/arm/vp8dsp_init_armv6.c
	libavcodec/arm/vp8dsp_init_neon.c
	libavcodec/avcodec.h
	libavcodec/h264pred.c
	libavcodec/version.h
	libavcodec/vp8.c
	libavcodec/vp8.h
	libavcodec/vp8data.h
	libavcodec/vp8dsp.c
	libavcodec/vp8dsp.h
	libavcodec/x86/h264_intrapred_init.c
	libavcodec/x86/vp8dsp_init.c

See: 89f2f5db and others
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Unbreaks compilation on arm due to conflicting types for
'ff_decode_block_coeffs_armv6'.

Configure will detect the availability of the Windows' console functions and set
HAVE_SETCONSOLETEXTATTRIBUTE.  Meaning av_log will use those functions to
control colours.  When ffmpeg is run in Cygwin's mintty terminal emulator it
will not use colour highlighting in this case.

Mintty responds to the usual escape code colours (it even supports 256 colours).
Windows' cmd.exe does not.  Fortunately it seems that Cygwin's emulation layer
now translates the basic 16 colours into Windows' Console command functions.

That means that we can have av_log use the standard colour commands and let
ffmpeg print colours in both mintty and cmd.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Further performance improvements and security fixes by
Vittorio Giovara, Luca Barbato and Diego Biurrun.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>

* qatar/master: (31 commits)
  riff: Add an additional AAC TwoCC
  riff: support 0xa100 TwoCC for G723_1
  riff: add 0x594a TwoCC for Xan DPCM
  riff: add 0x64 to g726
  riff: add G723_1 wav tag
  riff: map 0x0038 to amrnb
  riff: Support FLIC FourCC
  riff: add escape130 FourCC
  riff: support 'aas4' FourCC
  riff: add "YUV8" FourCC
  riff: Add "S263" FourCC
  riff: Support XMPG as mpeg1
  riff: support BW10 as mpeg1
  riff: Add SLDV FourCC for dvvideo
  riff: Support NTSC forward dvcpro videos
  riff: add dvis/pdvc FourCCs
  riff: add "GXVE" FourCC for WMV2
  riff: add PLV1 fourcc to mpeg4
  riff: Support decoding ASP variant from QNAP Systems
  riff: add "SM4V" FourCC
  ...

Conflicts:
	libavformat/riff.c

See: various commits, all the merged changes where in ffmpeg already
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '121b5b7e':
  isom: add some BOXX tags
  isom: add 'flic' tag
  isom: add 'm1v ' tag

Conflicts:
	libavformat/isom.c

See: ca8623e1
See: 8a3f9764
See: fca62f05Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'ad8f736b':
  mxf: Remove typo

also See: [FFmpeg-devel] [PATCH 3/3] lavf/mxfdec: delete trailing semi-colon
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '9464b69d':
  log: Unbreak windows support

Conflicts:
	libavutil/log.c

No change as we didnt use print_256color() in our implementation
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Would have shown the trailing semi-colon in lavu/log.c that broke detection of
256 colour capable terminals.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Mentioned on http://msdn.microsoft.com/en-us/library/dd341376%28prot.20%29.aspx

Sample-Id: 4790b7f1c44f98e35f3b806468fa615f5930a5b3.wav

Sample-Id: crusader-no-regret.avi

Sample-Id: g726-test1.wav

Sample-Id: 40709.avi

Sample-Id: MAILTEST.AVI

PAL looks incorrect.

Sample-Id: vivd.avi