Not sure if returning -1 is the best possible solution but at least avoids the crash.
Originally committed as revision 17520 to svn://svn.ffmpeg.org/ffmpeg/trunk
ff_h264_decode_sei, ff_h264_decode_seq_parameter_set,
ff_h264_decode_picture_parameter_set, ff_h264_decode_nal,
ff_h264_decode_rbsp_trailing
Patch by Ivan Schreter, schreter gmx net
Originally committed as revision 17487 to svn://svn.ffmpeg.org/ffmpeg/trunk
correctly. This works around an apparent H.264 standard deficiency.
Patch by Ivan Schreter, schreter gmx net
Originally committed as revision 17471 to svn://svn.ffmpeg.org/ffmpeg/trunk
cast discards qualifiers from pointer target type
Patch by Ivan Schreter, schreter gmx net
Originally committed as revision 17463 to svn://svn.ffmpeg.org/ffmpeg/trunk
to make sure they are always initialized.
Patch by Gwenole Beauchesne g${name} splitted-desktop com
Originally committed as revision 17393 to svn://svn.ffmpeg.org/ffmpeg/trunk
Otherwise doxygen complains about ambiguous filenames when files exist
under the same name in different subdirectories.
Originally committed as revision 16912 to svn://svn.ffmpeg.org/ffmpeg/trunk
to be avoided and the function is pretty small.
3% speedup, though this is probably due to changed inlining and not directly
this change.
Originally committed as revision 16301 to svn://svn.ffmpeg.org/ffmpeg/trunk
Sadly only 5 cycles faster here on pentium dual. So maybe the
complexity is not worth it and this should be reverted ...
Originally committed as revision 16295 to svn://svn.ffmpeg.org/ffmpeg/trunk
It contains optimizations that are not specific to i386 and
libavutil uses this naming scheme already.
Originally committed as revision 16270 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes valgrind uninitialized value warnings at the end of decoding H.264
frames.
Originally committed as revision 16230 to svn://svn.ffmpeg.org/ffmpeg/trunk
The case for 16x16 blocks becomes 10 cpu cycles faster on pentium dual,
i could not find a speed difference in the case of subblocks though.
Originally committed as revision 16226 to svn://svn.ffmpeg.org/ffmpeg/trunk
No speed change meassureable with START/STOP_TIMER, but this is needed
for future optimizations.
Originally committed as revision 16218 to svn://svn.ffmpeg.org/ffmpeg/trunk
cathedral +0.5% speed
aladin +0.6% speed [note aladin has been cat-ed 10 times to reduce the influence
of init time]
Speedup also verified via START/STOP_TIMER (difference was very significant
for the changed parts)
Originally committed as revision 16207 to svn://svn.ffmpeg.org/ffmpeg/trunk
1% overall decoding speed up for cathedral-beta2-400extra-crop-avc.mp4
no speed change for Aladin.mpg
Benchmarks done on Pentium dual
Originally committed as revision 16182 to svn://svn.ffmpeg.org/ffmpeg/trunk
Now correct values are propagated to interlaced_frame, top_field_first
and repeat_pict in AVFrame structure.
patch by ffdshow tryouts
Originally committed as revision 15773 to svn://svn.ffmpeg.org/ffmpeg/trunk
in the reference list. Follow the spec and no comment on the sanity of this
design ...
Fixes HPCAMAPALQ_BRCM_B
Originally committed as revision 15407 to svn://svn.ffmpeg.org/ffmpeg/trunk
(note, yes this is unrelated to the previous simplification, the
code always behaved like it is documented now.)
Originally committed as revision 15378 to svn://svn.ffmpeg.org/ffmpeg/trunk
because this mode does not exist, H.264-2007 says "When frame_mbs_only_flag is
equal to 0, direct_8x8_inference_flag shall be equal to 1."
Originally committed as revision 15369 to svn://svn.ffmpeg.org/ffmpeg/trunk
(no i would not have tried to implement this had i known what mess it is)
fixes at least:
CAMACI3_Sony_C
Originally committed as revision 14687 to svn://svn.ffmpeg.org/ffmpeg/trunk
each other.
Fixes at least:
CAMA1_TOSHIBA_B
cama1_vtc_c
CAMA3_Sand_E
cama3_vtc_b
CAMASL3_Sony_B
CVMA1_TOSHIBA_B
CVMAQP3_Sony_D
cvmp_mot_mbaff0_full_B
FRExt/HCAMFF1_HHI
FRExt/HCHP3_HHI_A
FRExt/HVLCMFF0_Sony_B
Originally committed as revision 14683 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes at least:
CAMANL3_Sand_E.264
camp_mot_picaff0_full.26l
CAPA1_TOSHIBA_B.264
CVPA1_TOSHIBA_B.264
Originally committed as revision 14546 to svn://svn.ffmpeg.org/ffmpeg/trunk
mode MBs, this seems to work better with field/frame mixes. POC of both
can be the same and can be different that makes its use tricky.
Originally committed as revision 14545 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes at least:
FRExt/HPCAFL_BRCM_C.264
FRExt/HPCAFLNL_BRCM_C.264
FRExt/HPCVFL_BRCM_A.264
FRExt/HPCVFLNL_BRCM_A.264
Originally committed as revision 14529 to svn://svn.ffmpeg.org/ffmpeg/trunk
slice but thats a seperate bug)
Fixes at least:
CABREF3_Sand_D.264
camp_mot_fld0_full.26l
CVFI2_Sony_H.jsv
CVNLFI2_Sony_H.jsv
Originally committed as revision 14511 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
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
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
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
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
instead of the fragile first_field check to determine if we have
2 fields at the end.
Originally committed as revision 14380 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes at least:
FRExt/HPCV_BRCM_A.264
FRExt/HVLCFI0_Sony_B.264
FRExt/HVLCPFF0_Sony_B.264
H264_artifacts_motion.h264
Originally committed as revision 14373 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes at least:
src19td.IBP.264
CVWP3_TOSHIBA_E.264
cvmp_mot_picaff0_full_B.26l
CVMP_MOT_FRM_L31_B.26l
cvmp_mot_frm0_full_B.26l
CVMP_MOT_FLD_L30_B.26l
cvmp_mot_fld0_full_B.26l
Originally committed as revision 14337 to svn://svn.ffmpeg.org/ffmpeg/trunk
optimization, more interresting would it have been had the author
thought about what value chroma_qp would have for the following MB.
Or failing that, had actually tested the code.
So this reverts this non-functional optimization, and makes the code work.
Fixes at least CAPM3_Sony_D.jsv
Originally committed as revision 14335 to svn://svn.ffmpeg.org/ffmpeg/trunk
Fixes at least:
CABAST3_Sony_E.jsv
CABASTBR3_Sony_A.jsv
CABASTBR3_Sony_B.jsv
Originally committed as revision 14331 to svn://svn.ffmpeg.org/ffmpeg/trunk
This way we use slice_type_nos almost everywhere which means 1 variable less
for gcc to put in a register.
Originally committed as revision 14326 to svn://svn.ffmpeg.org/ffmpeg/trunk
Disable filter_mb_fast() as it optimized the incorrect code.
Fixes at least:
BA3_SVA_C.264
CABA3_SVA_B.264
CABACI3_Sony_B.jsv
CAFI1_SVA_C.264
camp_mot_frm0_full.26l
CAWP5_TOSHIBA_E.264
CVFI2_SVA_C.264
CVSE3_Sony_H.jsv
CVWP2_TOSHIBA_E.264
CVWP5_TOSHIBA_E.264
SL1_SVA_B.264
Originally committed as revision 14315 to svn://svn.ffmpeg.org/ffmpeg/trunk
That is, add 16 frames delay, cache trashing and av desync.
fixes at least the following reference bitstreams:
CABA3_Sony_C.jsv
CACQP3_Sony_D.jsv
CAMANL1_TOSHIBA_B.264
CANL3_Sony_C.jsv
CVBS3_Sony_C.jsv
CVMANL1_TOSHIBA_B.264
Originally committed as revision 14308 to svn://svn.ffmpeg.org/ffmpeg/trunk
same maximum that can be achieved by specifying the value in the bitstream.
Originally committed as revision 14302 to svn://svn.ffmpeg.org/ffmpeg/trunk
in MPV_frame_start() if we break out due to an error at a random place.
Fixes issue334
Originally committed as revision 14283 to svn://svn.ffmpeg.org/ffmpeg/trunk
Move decode_significance_x86() and decode_significance_8x8_x86() to
i386-specific file from cabac.h.
New file is h264-oriented and only included from h264.c
Resolves compilation when configured with --disable-optimizations due to
decode_significance_8x8_x86 using last_coeff_flag_offset_8x8, which is
only defined in h264.c
Originally committed as revision 12846 to svn://svn.ffmpeg.org/ffmpeg/trunk
i386-specific file from cabac.h.
New file is h264-oriented and only included from h264.c
Resolves compilation when configured with --disable-optimizations due to
decode_significance_8x8_x86 using last_coeff_flag_offset_8x8, which is
only defined in h264.c
Originally committed as revision 12838 to svn://svn.ffmpeg.org/ffmpeg/trunk
h264.c:2093: warning: unused variable 's'
h264.c:2406: warning: suggest parentheses around arithmetic in operand of ^
h264.c:2412: warning: suggest parentheses around arithmetic in operand of ^
Originally committed as revision 11680 to svn://svn.ffmpeg.org/ffmpeg/trunk
in both mpegvideo and h264 decoder. Fixed by allowing all (master and duplicate)
contexts to fully initialize in MPV_frame_start and copying these into
H264Contexts.
Mailing list discussion:
[FFmpeg-devel] Memory leak in h264
Tue, 22 Jan 2008 15:22:55
Originally committed as revision 11657 to svn://svn.ffmpeg.org/ffmpeg/trunk
(iam not sure if this might have been exploitable)
fixes issue332 / CVCANLMA2_Sony_C.jsv
Other solutions which waste a few bytes less are welcome ...
Originally committed as revision 11605 to svn://svn.ffmpeg.org/ffmpeg/trunk
Actually unreference removed pics
And check for too many reference frames as originally intended, not equal
to max reference frames.
Originally committed as revision 11218 to svn://svn.ffmpeg.org/ffmpeg/trunk
max frame count, which is limited to less than the size of the
reference buffers, thereby preventing overflow.
Part of fix for issue 281.
Originally committed as revision 11216 to svn://svn.ffmpeg.org/ffmpeg/trunk
many reference frames. Also check max num ref frames against our internal
ref buffer sizes.
Part of fix for roundup issue 281
Originally committed as revision 11215 to svn://svn.ffmpeg.org/ffmpeg/trunk
Namely, that it should not be called if you are starting to decode a B
frame without any reference pictures.
Prevents an endless allocation cycle in MPV_frame_start that will end in
picture buffer overflow and abort.
Fixes roundup issue 216.
Originally committed as revision 11214 to svn://svn.ffmpeg.org/ffmpeg/trunk
Based on original patch by Martin Zlomek martin.zlomek a email D cz
ffmpeg-devel thread: H264: Fix non_zero_count_cache for deblocking in fields
Fri, 30 Nov 2007 9:58:23
Originally committed as revision 11212 to svn://svn.ffmpeg.org/ffmpeg/trunk
to clear last_picture_ptr, next_picture_ptr for proper picture
management. Prevents crashes in error concealer following seeks.
Fixes Roundup issue 189.
Originally committed as revision 11049 to svn://svn.ffmpeg.org/ffmpeg/trunk
in decoding order would always be assigned to a field pair's poc.
Original thread: H.264: Fix poc for field pairs, 6 Nov 2007 17:41:02
Originally committed as revision 10937 to svn://svn.ffmpeg.org/ffmpeg/trunk
in display order, based on decoding information in decoding order. Now
set properly, immediately upon completion of decode.
Based on original patch from Reinhard Nissl, rnisssl % gmx , de
Original Thread: [FFmpeg-devel] H.264 + PAFF: BBC HD recording shows
extreme interlacing artefacts, Thu, 01 Nov 2007 22:43:09
Originally committed as revision 10931 to svn://svn.ffmpeg.org/ffmpeg/trunk
setting Picture.reference to indicate parity for all Pictures in
reference list.
Patch by Jeff Downs, heydowns T borg O com
Originally committed as revision 10744 to svn://svn.ffmpeg.org/ffmpeg/trunk
implemented.
Patch by Jeff Downs, heydowns . borg @ com
Original thread: Enable PAFF decoding, 2007-10-09 11:04
Originally committed as revision 10714 to svn://svn.ffmpeg.org/ffmpeg/trunk
Part of PAFF implementation.
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10691 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10679 to svn://svn.ffmpeg.org/ffmpeg/trunk
implementation.
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10678 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10676 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10675 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10674 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10673 to svn://svn.ffmpeg.org/ffmpeg/trunk
Adds convenience definition for pictures that are field or mbaff based. Part of PAFF implementation.
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10672 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10671 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10670 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10669 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10665 to svn://svn.ffmpeg.org/ffmpeg/trunk
Contributed in part by Neil Brown.
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10664 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10663 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10662 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10661 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10660 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10659 to svn://svn.ffmpeg.org/ffmpeg/trunk
PAFF support disabled until implementation complete.
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10658 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10646 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Jeff Downs, heydowns a borg d com
original thread:
Subject: [FFmpeg-devel] [PATCH] Implement PAFF in H.264
Date: 18/09/07 20:30
Originally committed as revision 10592 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Andreas Öman %andreas A olebyn P nu%
original thread:
Date: Sep 24, 2007 12:59 PM
Subject: [FFmpeg-devel] [PATCH] h264: factor out dequant table lookup outside loops
Originally committed as revision 10564 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Andreas Öman, andreas olebyn nu
Date: Thu, 20 Sep 2007 12:59:19 +0200
Subject: [FFmpeg-devel] [PATCH] simplify h264's decode_cabac_mb_cbp_luma()
Originally committed as revision 10537 to svn://svn.ffmpeg.org/ffmpeg/trunk
dequant-tables were not correctly reinitialized in the slave
contexts when a PPS came with updated matrices.
Patch by Andreas Öman %andreas A olebyn P nu%
Original thread:
date: Sep 16, 2007 6:14 AM
subject: [FFmpeg-devel] Parallelized h264 image corruption bug
Originally committed as revision 10505 to svn://svn.ffmpeg.org/ffmpeg/trunk
if running with multiple threads and CODEC_FLAGS2_FAST is set.
Thus, it may decode the slices in parallel to gain speed.
Patch by Andreas Öman: [andreas olebyn nu]
Originally committed as revision 10431 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Andreas Öman % andreas A olebyn P nu %
NB: depends on having a thread library activated at config time, and on
having a source encoded with multiple slices
Original threads:
date: May 18, 2007 11:00 PM
subject: [FFmpeg-devel] Parallelized h264 proof-of-concept
date: Jun 15, 2007 10:10 PM
subject: [FFmpeg-devel] [PATCH] h264 parallelized, (was: Parallelized h264 proof-of-concept)
date: Jun 25, 2007 7:02 PM
subject: Re: [FFmpeg-devel] [PATCH] h264 parallelized
Originally committed as revision 10407 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Carl Eugen Hoyos: [cehoyos ag or at]
original thread:
[FFmpeg-devel] [PATCH] Don't let ctx->skip_frame>0 produce errors
date: 08/30/2007 01:30 PM
Originally committed as revision 10286 to svn://svn.ffmpeg.org/ffmpeg/trunk
you write them in the right order it comes out backwards.
This removes them from fill_rectangle().
patch by Alexander Strange %astrange A ithinksw P com%
Original thread:
Date: Aug 14, 2007 5:36 AM
Subject: [FFmpeg-devel] [PATCH] two small h264 optimizations
Originally committed as revision 10118 to svn://svn.ffmpeg.org/ffmpeg/trunk
returns 0. This leads to a 0.4% speed-up.
Patch by Alexander Strange astrange at_ ithinksw dot com
Original thread:
Date: Aug 11, 2007 11:44 PM
Subject: [FFmpeg-devel] [PATCH] h264: don't check decode_cabac_residual return
Originally committed as revision 10084 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Andreas Öman %andreas A olebyn P nu%
Original thread:
Date: Jul 7, 2007 1:23 AM
Subject: [FFmpeg-devel] Corrupted blocks and seeking issues in H264 disc sources
Originally committed as revision 9836 to svn://svn.ffmpeg.org/ffmpeg/trunk
since the MVs are in qpel res.
Patch by Andreas Öman % andreas A olebyn P nu %
Date: Jul 14, 2007 12:40 PM
Subject: [FFmpeg-devel] [PATCH] h264 mv visualization
Originally committed as revision 9688 to svn://svn.ffmpeg.org/ffmpeg/trunk
for Cr and Cb
Patch by Andreas Öman % andreas A olebyn P nu %
Original thread:
Date: Jun 26, 2007 8:48 PM
subject: [FFmpeg-devel] Color corruption and seeking errors with H264 disc sources
Originally committed as revision 9505 to svn://svn.ffmpeg.org/ffmpeg/trunk
this saves speed for the upcoming secondqp fix.
Patch by Andreas Öman % andreas A olebyn P nu %
Original thread:
Date: Jun 26, 2007 8:48 PM
subject: [FFmpeg-devel] Color corruption and seeking errors with H264 disc sources
Originally committed as revision 9498 to svn://svn.ffmpeg.org/ffmpeg/trunk
this saves speed for the upcoming secondqp fix.
Patch by Andreas Öman % andreas A olebyn P nu %
Original thread:
Date: Jun 26, 2007 8:48 PM
subject: [FFmpeg-devel] Color corruption and seeking errors with H264 disc sources
Originally committed as revision 9497 to svn://svn.ffmpeg.org/ffmpeg/trunk
at slice boundaries for deblocking-type 2 content.
This is needed for slice based threading only and doesn't do much
good or bad otherwise.
Patch by Andreas Oman %andreas A olebyn P nu%
Original thread:
date: Jun 18, 2007 1:21 PM
subject: Re: [FFmpeg-devel] [PATCH] h264 parallelized,
Originally committed as revision 9380 to svn://svn.ffmpeg.org/ffmpeg/trunk
the intra and inter -nal units are escaped
patch by Andreas Öman: \andreas olebyn nu/
original thread:
[FFmpeg-devel] [PATCH] h264: rbsp de-escape and data partitioning..
date: 06/20/2007 09:32 AM
Originally committed as revision 9374 to svn://svn.ffmpeg.org/ffmpeg/trunk
(done in order to implement slice-level parallel decoding)
Patch by Andreas Öman % andreas olebyn nu %
Original thread:
Date: Jun 15, 2007 10:10 PM
Subject: [FFmpeg-devel] [PATCH] h264 parallelized, (was: Parallelized h264 proof-of-concept)
Originally committed as revision 9371 to svn://svn.ffmpeg.org/ffmpeg/trunk
original thread:
Date: Jun 15, 2007 10:10 PM
Subject: [FFmpeg-devel] [PATCH] h264 parallelized, (was: Parallelized h264 proof-of-concept)
Originally committed as revision 9341 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Andreas Öman: [andreas olebyn nu]
original thread:
subject: [FFmpeg-devel] [patch] h264: use 'simple' in border backup / xchg
date: 06/07/2007 03:24 PM
Originally committed as revision 9237 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Carl Eugen Hoyos cehoyos chez ag or at
original thread: [FFmpeg-devel] [PATCH] attribute_unused -> av_unused
date: 05/29/2007 01:23 PM
Originally committed as revision 9155 to svn://svn.ffmpeg.org/ffmpeg/trunk
patch by Andreas Öman andreas ta olebyn tod nu
reference thread:
subject: [FFmpeg-devel] [PATCH] h264: allocate PPS and SPS dynamically
date: 05/28/2007 03:00 PM
Originally committed as revision 9148 to svn://svn.ffmpeg.org/ffmpeg/trunk
the H.264 encoder. These functions are: pred8x8_left_dc_c, pred8x8_top_dc_c,
pred16x16_left_dc_c and pred16x16_top_dc_c.
Originally committed as revision 9107 to svn://svn.ffmpeg.org/ffmpeg/trunk
attribute_unused and attribute_used respectively to ease compiling on non-gcc.
Originally committed as revision 9024 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Mean % fixounet A free P fr %
Original thread:
Date: Apr 29, 2007 2:00 PM
Subject: Re: [Ffmpeg-devel] [patch] h264.c, dont go beyond buffer in h264_decode_nal_unit
Originally committed as revision 8858 to svn://svn.ffmpeg.org/ffmpeg/trunk
This allows building shared libraries on AMD64 again.
based on a patch by Diego 'Flameeyes' Pettenò and suggestions by Michael
original thread:
Date: Wed, 18 Apr 2007 11:26:12 +0200
Subject: [Ffmpeg-devel] [PATCH] (try 2) Build shared libraries on AMD64 again
Originally committed as revision 8849 to svn://svn.ffmpeg.org/ffmpeg/trunk
Patch by Limin Wang % lance P lmwang A gmail P com %
Original thread:
date: 04/09/2007 03:54 PM
subject: [Ffmpeg-devel] [PATCH] fix segment fault in h264_parse if buf_size is zero
Originally committed as revision 8714 to svn://svn.ffmpeg.org/ffmpeg/trunk
calls decode_rbsp_trailing() and therefore bit_length might get negative.
Although the remaining code is able to handle a negative bit_length, avoid
the calculation at all by setting bit_length to 0 for dst_length == 0.
patch by Reinhard Nissl, rnissl gmx de
Originally committed as revision 8690 to svn://svn.ffmpeg.org/ffmpeg/trunk
Consider the following byte sequence
00 00 01 0a 00 00 00 01 09 ...
^ ^
A B
decode_nal() determines dst_length to be 1 (i. e. the byte between label
A and B above). However, this byte is a trailing zero byte as the spec
says the the current NAL unit is terminated by a byte sequence 00 00 00.
The current code used a loop to decrement dst_length accordingly. But the
loop doesn't start as the loop condition checks for dst_length > 1, which
should read dst_length > 0.
patch by Reinhard Nissl, rnissl gmx de
Originally committed as revision 8689 to svn://svn.ffmpeg.org/ffmpeg/trunk
i.e. the four bytes 00 00 01 0a.
When decode_nal() decodes the end of sequence NAL unit, it returns with
dst_length == 0. The original code leads to a return -1 which discards
the current properly decoded frame.
patch by Reinhard Nissl, rnissl gmx de
Originally committed as revision 8688 to svn://svn.ffmpeg.org/ffmpeg/trunk
interested in using a debugger to debug FFmpeg.
Original thread:
Subject: [PATCH] Fix compilation when using --disable-opts
Date: 2007-03-15 16:58:35 GMT
Originally committed as revision 8549 to svn://svn.ffmpeg.org/ffmpeg/trunk
144095->142319 dezicycles for hl_decode_mb() on duron
trailing whitespace removed by me
Originally committed as revision 8106 to svn://svn.ffmpeg.org/ffmpeg/trunk
