RA288Context.pr{1,2}. Note that the pr{1,2} buffers are one unity smaller
than the st{1,2} buffers. My guess is that the original coder decided to
add one to the array sizes "just to be sure".

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

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

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

allows to remove two intermediary buffers and avoid a few
memcpy's.

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

patch by tripp, eliared yahoo com

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

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

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

Fixes issue 560

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

This patch changes the left_block initialisation code in the fill_caches
function from individual array element setters to a simple pointer to a
pre-initialised array.
Patch by (Paul Kendall ! paul X kcbbs knodel gen knodel nz)
Date: Sun, 27 Jul 2008 11:40:18 +1200
Subject: [FFmpeg-devel] [PATCH] h264 fill_caches left_block intialisation optimisation

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

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

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

Fixes maybeH264_dumpvideo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Can be disabled by removing #define ALLOW_NOCHROMA in case the extra if()
slow the code down measurably.
Fixes at least
FRExt/HPCAMOLQ_BRCM_B.264
FRExt/HPCVMOLQ_BRCM_B.264

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

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

	Remove another 2 incorrect checks.
	These would ignore fields of different parity.
I was wrong, i thought pic_stricture is the current pic structure.
But it does not make a difference either way on the reference bitstreams.

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

These would ignore fields of different parity.

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

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

What the standard calls non-existent is not related to the
value of the data[0] pointer.

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

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

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

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

repair with hacks.
new code is ~60lines old was ~200
Fixes at least:
FRExt/HCHP2_HHI_A.264
one sample also get decoded much better:
FRExt/FRExt1_Panasonic.avc (PSNR 11 -> 80)
(no i do not know why, the old code was too a big mess to figure out
 what it did)

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

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

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