in this case current MB size is forced to 16x16 (AVS standard section 9.9.1)
Signed-off-by: Yao Wang <jiayaowang@gmail.com>
Fixes Ticket 1901
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* commit '593d2326':
  dv: Replace a magic number by sizeof()

Conflicts:
	libavcodec/dv.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '5ab03e41':
  x86: h264dsp: Fix link failure with optimizations disabled
Merged-by: Michael Niedermayer <michaelni@gmx.at>

There are interoperability issues with D-10 related to the channelcount property in the generic sound essence descriptor.

On one side, SMPTE 386M requires channel count to be 4 or 8, other values being prohibited.
The most widespread value is 8, which seems straightforward as it is the actual size of the allocated structure/disk space.
At the end, it appears that some vendors or workflows do require this descriptor to be 8, and otherwise just "fail".

On the other side, at least AVID and ffmpeg do write/set the channel count to the exact number of channels really "used",
usually 2 or 4, or any other value. And on the decoding side, ffmpeg (for example) make use of the channel count for probing
and only expose this limited number of audio streams
(which make sense but has strong impact on ffmpeg command line usage, output, and downstream workflow).

At the end, I find it pretty usefull to simply give ffmpeg the ability to force/set the channel count to any value the user wants.
(there are turnaround using complex filters, pans, amerge etc., but it is quite boring and requires the command line to be adapted to the input file properties)
Reviewed-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

With optimzations disabled compilers have trouble doing dead code
elimination on 'if (foo && 0)' expressions, while 'if (0 && foo)'
still works, so use the latter to avoid problems.

Bug-Id: 707

This makes C and MMX match, no change to fate as the differences where
apparently not sufficient to show up in fate
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This should avoid issues on x86_64
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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

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

Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* cus/stable:
  ffplay: decrease audio_diff_threshold
  ffplay: decrease max audio callbacks per second
  ffplay: calculate SDL audio buffer size based on sample rate
  ffplay: pass simple integers to calculate_display_rect and set_default_window_size
  ffplay: eliminate pictq_prev_picture
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '2deb6142':
  mjpegdec: Properly set the context colorspace info

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

Since audio clock calculations are more accurate now, it is safe to decrease
the sync treshold to compensate the larger buffers caused by less frequent
audio callbacks.
Signed-off-by: Marton Balint <cus@passwd.hu>

Too many audio callbacks per second can cause buffer underruns especially under
load. As now we take into accound the elapsed time after an audio callback when
determining current audio clock, it is not that important to use small buffer
sizes and frequent audio callbacks, so lets remove the comment.
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

No change in functionality.
Signed-off-by: Marton Balint <cus@passwd.hu>

Instead of directly rolling back the frame queue, keep the last displayed
picture in the queue and use a boolean variable to keep track if it is
displayed or not. This makes the code cleaner because it removes the
complicated logic in pictq_prev_picture.

There should be no change in functionality.
Signed-off-by: Marton Balint <cus@passwd.hu>

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

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

The JPEG spec requires it to be this.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

The JPEG spec requires it to be this.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

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

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

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

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

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

reduce computation too
(cherry picked from commit 39c4d45c7788081c45c7fae51b7c5d0bcbaece9d)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

(cherry picked from commit ff7926d5092f9d4158108963e977e8c992322ba4)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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

5389024880 -> 1389386610 dezicycles

This surely can be optimized more, i just didnt want to cause a slowdown
when trying to make the fate test bitexact.
Further optimization left to ubitux
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

this likely fixes fate failures

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

somehow old llvm-gcc manages to ignore the alignment from ff_pb_0 causing a crash on freebsd
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

* commit '772d150a':
  h264: error out from decode_nal_units() when AV_EF_EXPLODE is set
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '10306e9c':
  jpeg2000: fix dereferencing invalid pointers during cleanup

Conflicts:
	libavcodec/jpeg2000.c

See: 09927f3e
See: 912ce9dd
See: 9e477a37Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'ab72eda1':
  pixfmt: mark the reserved values

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

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>