It caused a segfault when channel reordering was in use and the last chunk
of data was not silent.
Spotted and diagnosed by Carl Eugen Hoyos.

* newdev/master:
  rtsp: Use GET_PARAMETER for keep-alive for generic RTSP servers
  mlp_parse.c: set AVCodecContext channel_layout
  APIChanges: mark the place where 0.6 was branched.
  avio: make get_checksum() internal.
  avio: move ff_crc04C11DB7_update() from avio.h -> avio_internal.h
  avio: make init_checksum() internal.
NOT MERGED  Add MxPEG decoder
NOT MERGED  Add support for picture_ptr field in MJpegDecodeContext
NOT MERGED  Move MJPEG's input buffer preprocessing in separate public function
NOT MERGED  Support reference picture defined by bitmask in MJPEG's SOS decoder
  sndio bug fix
Merged-by: Michael Niedermayer <michaelni@gmx.at>

This reverts commit cb48e245.

Reason being we like pressing "q" to quit ffmpeg.

Conflicts:

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

ipod shuffle doesn't support anything else.

According to the RFC, GET_PARAMETER should be used for
this, and according to a report from Tim Ouellette,
OPTIONS doesn't work for keeping the connection alive for some
servers. Also, live555 uses GET_PARAMETER for this purpose.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Add notice telling that the filter is designed for playback only.

Fix crash in create_filter() which occurrs if a scale filter with no
args is provided.

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

The channel layout isn't getting set for mlp and truehd audio.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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

Heres a benchmark

VOFW 5120  VOFW 21504    Note
10438.8    10344.2       timex ffmpeg -y -i tulip2.mp4 tulip2.yuv
25611.9    24256.9       timex ffmpeg -y -itulip2.mp4 -s 1272x724 tulip2.yuv
24485.7    26006.6
28573.1    24291.3
24069.1    26995.9
25684.95   25387.675     average

This is on a Nehalem i7.  Despite being a 500 frame, 720p video, the numbers
fluctuate, so I took an average of 4 runs.

Another reason I'd like this change is youtube accepts videos with higher
resolutions than 5120.
16384 is vp8's maximum resolution, so that should keep us amused for a
little longer.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Since the code already supports both little- and big-endian
audio for recording, do not fail just because the endianness is not
what we expect.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

* newdev/master:
  ac3enc: move compute_mantissa_size() to ac3dsp
  ac3enc: move mant*_cnt and qmant*_ptr out of AC3EncodeContext
  Remove support for stripping executables
  ac3enc: NEON optimised float_to_fixed24
  ac3: move ff_ac3_bit_alloc_calc_bap to ac3dsp
  dfa: protect pointer range checks against overflows.
Duplicate:  mimic: implement multithreading.
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* ffmpeg-mt/master:
  Update todo. More items appeared...
  Fix mdec
Duplicate:  id3v1: change filesize to int64_t.
Duplicate:  id3v1: Seek back to old position after reading.

Conflicts:
    libavcodec/mpegvideo.c
    libavcodec/snow.c
    libavformat/id3v1.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Mans Rullgard <mans@mansr.com>

These fields are only used in quantize_mantissas() and reset
on each call, no need to store them in the main context.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Stripping is generally best left to package management tools, and
since unstripped copies are kept in the build tree, any arguments
about saving space (no matter how insignificant) are void.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>

Since the code already supports both little- and big-endian
audio for recording, do not fail just because the endianness is not
what we expect.
It is possible that 8-bit recording would not have worked at all on
some systems without that change.