Originally committed as revision 26353 to svn://svn.ffmpeg.org/ffmpeg/trunk

channel first, then by block.

Originally committed as revision 26352 to svn://svn.ffmpeg.org/ffmpeg/trunk

This will allow for faster and simpler processing of all blocks at once.

Originally committed as revision 26351 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26350 to svn://svn.ffmpeg.org/ffmpeg/trunk

No speed improvement, but necessary for some future stuff.
Also opens up the possibility of asm chroma dc idct/dequant.

Originally committed as revision 26349 to svn://svn.ffmpeg.org/ffmpeg/trunk

Doesn't help speed as there isn't an asm implementation yet, but consistency
is a good thing.

Originally committed as revision 26348 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26347 to svn://svn.ffmpeg.org/ffmpeg/trunk

fixes issue 2539

Originally committed as revision 26346 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26345 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26344 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26343 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26342 to svn://svn.ffmpeg.org/ffmpeg/trunk

Regression in r26336-7.

Originally committed as revision 26341 to svn://svn.ffmpeg.org/ffmpeg/trunk

This should avoid non monotone timestamps for video streams with vfr.

Originally committed as revision 26340 to svn://svn.ffmpeg.org/ffmpeg/trunk

Since we no longer have non-transposed scantables, the problem it warns about
no longer exists.

Originally committed as revision 26339 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26338 to svn://svn.ffmpeg.org/ffmpeg/trunk

Useful so that we don't have to run the hierarchical DC iDCT if there aren't
any coefficients.  Opens up some future opportunities for optimization as well.

Originally committed as revision 26337 to svn://svn.ffmpeg.org/ffmpeg/trunk

About 2.5x the speed.

NOTE: the way that the asm code handles large qmuls is a bit suboptimal.
If x264-style dequant was used (separate shift and qmul values), it might
be possible to get some extra speed.

Originally committed as revision 26336 to svn://svn.ffmpeg.org/ffmpeg/trunk

name.

Originally committed as revision 26335 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26334 to svn://svn.ffmpeg.org/ffmpeg/trunk

Avoid the need to manually include the avcore.h header, less
error-prone.

Originally committed as revision 26333 to svn://svn.ffmpeg.org/ffmpeg/trunk

so that applications can read it also.

Originally committed as revision 26332 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26331 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26330 to svn://svn.ffmpeg.org/ffmpeg/trunk

It was an ugly hack to begin with and didn't give any performance.

NOTE: this patch opens up some future simplifications to be made (such as
removing some of the scantables from H264Context) but doesn't take advantage
of them yet.

Originally committed as revision 26329 to svn://svn.ffmpeg.org/ffmpeg/trunk

fixes issue 2537 and 2538

Originally committed as revision 26328 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26327 to svn://svn.ffmpeg.org/ffmpeg/trunk

This reverts SVN commit 26318, which broke MS-RTSP playback.

Originally committed as revision 26326 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26325 to svn://svn.ffmpeg.org/ffmpeg/trunk

was not provided.

Originally committed as revision 26324 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26323 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26322 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26321 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26320 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26319 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26318 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26317 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 26316 to svn://svn.ffmpeg.org/ffmpeg/trunk

Previously the pad filter just drawed borders in the surrounding of the input
without checking if this area was allocated or writeable. Now we check and
allocate a new buffer if the input is unsuitable.

Originally committed as revision 26315 to svn://svn.ffmpeg.org/ffmpeg/trunk

These fields are needed to be able to know which area of memory is allocated and
which is off limits.
This reverts 24291 and parts of r24424.

Originally committed as revision 26314 to svn://svn.ffmpeg.org/ffmpeg/trunk