* qatar/master:
lavc: add opt_find to AVCodecContext class.
h264: Complexify frame num gap shortening code
intreadwrite.h: fix AV_RL32/AV_RB32 signedness.
Fix decoding of mpegts streams with h264 video that does *NOT* have b frames
Add minor bumps and APIChanges entries for lavf private options.
ffmpeg: deprecate -vc and -tvstd
ffmpeg: use new avformat_open_* API.
ffserver: use new avformat_open_* API.
ffprobe: use new avformat_open_* API.
ffplay: use new avformat_open_* API.
cmdutils: add opt_default2().
dict: add AV_DICT_APPEND flag.
lavf: add avformat_write_header() as a replacement for av_write_header().
Deprecate av_open_input_* and remove their uses.
lavf: add avformat_open_input() as a replacement for av_open_input_*
AVOptions: add av_opt_find() as a replacement for av_find_opt.
AVOptions: add av_opt_set_dict() mapping a dictionary struct to a context.
ffmpeg: don't abuse a global for passing frame size from input to output
ffmpeg: don't abuse a global for passing pixel format from input to output
ffmpeg: initialise encoders earlier.
Conflicts:
cmdutils.c
doc/APIchanges
ffmpeg.c
ffplay.c
ffprobe.c
libavcodec/h264.c
libavformat/avformat.h
libavformat/utils.c
libavformat/version.h
libavutil/avutil.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
By observation it did not seem to handle prev_frame_num > frame_num.
This does not affect any files I have.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
One of the causes of this bug is that the h264 parser defaults low_delay
to 1, but the h264 codec defaults low_delay to 0. Really Ugly.
After many hours of looking at this, I'm still not sure how has_b_frames
is *intended* to behave, but to me the implementation appears way more
complicated than it ought to be.
My patch relies on the encoder to set an optional field in the SPS. This
works for libx264 streams, but I'm not sure that all h264 encoders will
set it.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* qatar/master:
swscale: remove misplaced comment.
ffmpeg: fix streaming to ffserver.
swscale: split out RGB48 output functions from yuv2packed[12X]_c().
build: move vpath directives to main Makefile
swscale: fix JPEG-range YUV scaling artifacts.
build: move ALLFFLIBS to a more logical place
ARM: factor some repetitive code into macros
Fix SVQ3 after adding 4:4:4 H.264 support
H.264: fix CODEC_FLAG_GRAY
4:4:4 H.264 decoding support
ac3enc: fix allocation of floating point samples.
Conflicts:
ffmpeg.c
libavcodec/dsputil_template.c
libavcodec/h264.c
libavcodec/mpegvideo.c
libavcodec/snow.c
libswscale/swscale.c
libswscale/swscale_internal.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master: (24 commits)
utils: Drop pointless '#if 1' preprocessor directive.
ac3enc: remove empty ac3_float function that is never called
ac3enc: split templated float vs. fixed functions into a separate file.
ac3enc: dynamically allocate AC3EncodeContext fields windowed_samples and mdct
ac3enc: use function pointer to choose between AC-3 and E-AC-3 header output functions.
Roll back 4:4:4 H.264 for now Needs some ARM/PPC asm modifications.
Fix SVQ3 after adding 4:4:4 H.264 support
H.264: fix CODEC_FLAG_GRAY
4:4:4 H.264 decoding support
h264_parser: Fix whitespace after previous change.
h264_parser: Fix behaviour when PARSER_FLAG_COMPLETE_FRAMES is set.
wav: remove an invalid free().
lavf: initialise reference_dts in av_estimate_timings_from_pts.
h264: don't be so picky on decoding pps in extradata.
avcodec.h: add or elaborate on some documentation comments.
h264: change a few comments into error messages
ac3dec: fix doxy-style for comment ("///>" should be "///<" instead).
img2: add .dpx to the list of supported file extensions.
ffv1: fix undefined behavior with insane widths.
ARM: jrevdct_arm: simplify stack usage
...
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit a50f0bea25.
This has been implemented differently in qatar and its better they
maintain it for me instead of me having to spend an average 5sec more
per merge
Conflicts:
libavcodec/h264.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
By observation it did not seem to handle prev_frame_num > frame_num.
This does not affect any files I have.
(cherry picked from commit 43c0092a80f8212cbb783260bafa157f7b85126e)
* qatar/master:
configure: Add -U__STRICT_ANSI__ to CPPFLAGS on Cygwin and DOS.
aacdec: fix typo in scalefactor clipping check
fate: fix fate-h264-conformance-frext-pph10i4-panasonic-a crcs.
fate: update 9/10bit refs.
h264: Properly set coded_{width, height} when parsing H.264.
x86 asm: Add SECTION_TEXT to dct32_sse.asm.
Fix 9/10 bit in swscale.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* ffmpeg-mt/master:
Update todo.
h264: add an assert that copied pictures are valid picture pointers
valgrind-check: run with 1 and 3 threads
h264: When decoding a packet with multiple PPS/SPS, don't start the next thread until all of them have been read
Allow some pictures to be released earlier after 51ead6d2c40c5defdd211f435aec49b19f5f6a18
h264: fix slice threading MC reading uninitialized frame edges.
Please see ffmpeg-mt for a list of authors of these changes.
Conflicts:
libavcodec/h264.c
mt-work/valgrind-check.sh
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
qdm2: Use floating point synthesis filter.
h264: correct border check.
h264: fix loopfilter with threading at slice boundaries.
Fix ff_mpa_synth_filter_fixed() prototype
Rename costablegen.c ---> cos_tablegen.c.
Collapse tableprint.c into tableprint.h.
Simplify trig table rules
Remove potentially unstable filenames from comments in generated files.
Ignore generated tables and generated table generator programs.
Simplify CLEANFILES make variable by using wildcards.
Remove silly insults from avformat_version() Doxygen documentation.
mpegaudiodsp: fix x86 and ppc makefiles
configure: Adjust AVX assembler check.
mpegaudio: remove unused version of SAME_HEADER_MASK
mpegaudio: remove useless #undef at end of file
asfdec: add missing #include for av_bswap32()
mpegaudio: merge two #if CONFIG_FLOAT blocks
mpegaudio: move some struct definitions from mpegaudio.h
Move some mpegaudio functions to new mpegaudiodsp subsystem
Conflicts:
libavcodec/h264.c
libavcodec/x86/Makefile
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When backing up the top-left border, check that the top-left
(rather than left) MB indeed does belong to our slice. If it
doesn't, backing up has no positive effect but may accidentally
interfere with other threads writing in the same space.
Fixes occasional one-off effects when enabling slice-MT.
* qatar/master:
APIchanges: fill in date and commit for request_sample_fmt
Add floating-point sample format support to the ac3, eac3, dca, aac, and vorbis decoders.
Add support for request_sample_format in ffmpeg and ffplay.
Add APIchanges entry for request_sample_fmt.
Add request_sample_fmt field to AVCodecContext.
Add float_interleave() to FmtConvertContext with x86-optimized versions.
Remove unused make variable SEEK_REFFILE
fate: remove redundant aref and vref references
fate: remove do_ffmpeg_nocheck function
fate: do not collect -benchmark output
mpegaudiodec: remove decode_end() function
fate: run aref and vref as regular tests
mpegaudio: sanitise compute_antialias_* names
mpeg12: add slice-threading checks to slice-threading initializers.
h264: copy pixel_shift between slice threading contexts.
mdec: enable frame-level multithreading.
mdec.c: fix overread.
Conflicts:
libavcodec/aacdec.c
libavcodec/ac3dec.c
libavcodec/avcodec.h
libavcodec/dca.c
libavcodec/h264.c
libavcodec/mdec.c
libavcodec/mpeg12.c
libavcodec/options.c
libavcodec/version.h
libavcodec/vorbisdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master: (30 commits)
AVOptions: make default_val a union, as proposed in AVOption2.
arm/h264pred: add missing argument type.
h264dsp_mmx: place bracket outside #if/#endif block.
lavf/utils: fix ff_interleave_compare_dts corner case.
fate: add 10-bit H264 tests.
h264: do not print "too many references" warning for intra-only.
Enable decoding of high bit depth h264.
Adds 8-, 9- and 10-bit versions of some of the functions used by the h264 decoder.
Add support for higher QP values in h264.
Add the notion of pixel size in h264 related functions.
Make the h264 loop filter bit depth aware.
Template dsputil_template.c with respect to pixel size, etc.
Template h264idct_template.c with respect to pixel size, etc.
Preparatory patch for high bit depth h264 decoding support.
Move some functions in dsputil.c into a new file dsputil_template.c.
Move the functions in h264idct into a new file h264idct_template.c.
Move the functions in h264pred.c into a new file h264pred_template.c.
Preparatory patch for high bit depth h264 decoding support.
Add pixel formats for 9- and 10-bit yuv420p.
Choose h264 chroma dc dequant function dynamically.
...
Conflicts:
doc/APIchanges
ffmpeg.c
ffplay.c
libavcodec/alpha/dsputil_alpha.c
libavcodec/arm/dsputil_init_arm.c
libavcodec/arm/dsputil_init_armv6.c
libavcodec/arm/dsputil_init_neon.c
libavcodec/arm/dsputil_iwmmxt.c
libavcodec/arm/h264pred_init_arm.c
libavcodec/bfin/dsputil_bfin.c
libavcodec/dsputil.c
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
libavcodec/h264_loopfilter.c
libavcodec/h264_ps.c
libavcodec/h264_refs.c
libavcodec/h264dsp.c
libavcodec/h264idct.c
libavcodec/h264pred.c
libavcodec/mlib/dsputil_mlib.c
libavcodec/options.c
libavcodec/ppc/dsputil_altivec.c
libavcodec/ppc/dsputil_ppc.c
libavcodec/ppc/h264_altivec.c
libavcodec/ps2/dsputil_mmi.c
libavcodec/sh4/dsputil_align.c
libavcodec/sh4/dsputil_sh4.c
libavcodec/sparc/dsputil_vis.c
libavcodec/utils.c
libavcodec/version.h
libavcodec/x86/dsputil_mmx.c
libavformat/options.c
libavformat/utils.c
libavutil/pixfmt.h
libswscale/swscale.c
libswscale/swscale_internal.h
libswscale/swscale_template.c
tests/ref/seek/lavf_avi
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).
Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)).
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
One of the causes of this bug is that the h264 parser defaults low_delay
to 1, but the h264 codec defaults low_delay to 0. Really Ugly.
After many hours of looking at this, I'm still not sure how has_b_frames
is *intended* to behave, but to me the implementation appears way more
complicated than it ought to be.
My patch relies on the encoder to set an optional field in the SPS. This
works for libx264 streams, but I'm not sure that all h264 encoders will
set it.
* qatar/master:
Duplicate AMV: disable DR1 and don't override EMU_EDGE
Duplicate lavf: inspect more frames for fps when container time base is coarse
Wrong and we have correct fix: Fix races in default av_log handler
vorbis: Replace sized int_fast integer types with plain int/unsigned.
Remove disabled non-optimized code variants.
NO bswap.h: Remove disabled code.
Remove some disabled printf debug cruft.
Replace more disabled printf() calls by av_dlog().
NO tests: Remove disabled code.
NO Replace some commented-out debug printf() / av_log() messages with av_dlog().
vorbisdec: Replace some sizeof(type) by sizeof(*variable).
NO vf_fieldorder: Replace FFmpeg by Libav in license boilerplate.
Conflicts:
libavcodec/h264.c
libavcodec/vorbisdec.c
libavutil/log.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
APIChanges: document git revision for CODEC_CAP_SLICE_THREADS addition.
Introduce slice threads flag.
FATE: allow forcing thread-type when doing threaded fate runs.
Use av_log_ask_for_sample() where appropriate.
error: sort, pack, and align error code and string definitions
The stabilization period after version bumps should be one month, not one week.
applehttp: Expose the stream bitrate via metadata
doc: Add some initial docs on the applehttp demuxer
Provide a fallback version of the libm function trunc
libavdevice: Define _XOPEN_SOURCE for usleep
lavc: provide deprecated avcodec_thread_init until next major version
lavc: provide the opt.h header until the next bump
error: change AVERROR_EOF value
error: remove AVERROR_NUMEXPECTED
error: add error code AVERROR_OPTION_NOT_FOUND, and use it in opt.c
Conflicts:
libavcodec/h264.c
libavutil/error.c
libavutil/error.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* ffmpeg-mt/master:
Release unused pictures even when not calling ff_h264_frame_start()
h264: Fix decoding race condition with PAFF
h264: cosmetic whitespace change
Duplicate Fix REBASE_PICTURE with h.264
Not pulled Update test scripts to use ffmpeg instead of ffmpeg_g
Duplicate Fix ffmpeg-mt fixme in h264
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).
Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)).
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
Fixed-point MDCT with 32-bit unscaled output
lavc: deprecate rate_emu
lavc: mark hurry_up for removal on next major bump
parser: mark av_parser_parse() for removal on next major bump
lavc: add missing audioconvert includes
jvdec: don't use deprecated CODEC_TYPE_*/PKT_FLAG_KEY
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It is pretty hopeless that other considerable projects will adopt
libavutil alone in other projects. Projects that need small footprint
are better off with more specialized libraries such as gnulib or rather
just copy the necessary parts that they need. With this in mind, nobody
is helped by having libavutil and libavcore split. In order to ease
maintenance inside and around FFmpeg and to reduce confusion where to
put common code, avcore's functionality is merged (back) to avutil.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>
None of these symbols should be accessed directly, so declare them as
hidden.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit d36beb3f69)
The header is empty after making the function static, so delete it and
drop its usage.
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
(cherry picked from commit 13eb6b9097)
Don't free RBSP tables (containing decoded NAL units) on resolution
change, because we actually need this data to decode the frame after
reiniting (with new resolution). Fixed issue 2393.
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
(cherry picked from commit 9107892624)
It's incomplete, no one is working on it, and when someone asks about
working on it we advise them not to.
Signed-off-by: Mans Rullgard <mans@mansr.com>
(cherry picked from commit ff3d43104f)
Don't free RBSP tables (containing decoded NAL units) on resolution
change, because we actually need this data to decode the frame after
reiniting (with new resolution). Fixed issue 2393.
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
It's incomplete, no one is working on it, and when someone asks about
working on it we advise them not to.
Signed-off-by: Mans Rullgard <mans@mansr.com>
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
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
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
svq3 still doesn't support multithreading, but it's simpler for clients if
they can enable threading for all codecs by default.
Originally committed as revision 26015 to svn://svn.ffmpeg.org/ffmpeg/trunk
Contrary to progressive, just being able to crop up to 14/15 pixels
is not enough to encode all supported resolutions, and the new
behaviour is also consistent with e.g. MPEG-2 etc.
Originally committed as revision 25669 to svn://svn.ffmpeg.org/ffmpeg/trunk
r25218 made assumptions about the existence of past reference frames that
weren't necessarily true.
Originally committed as revision 25243 to svn://svn.ffmpeg.org/ffmpeg/trunk
h264dsp_mmx.c to h264_idct.asm (as yasm code). Because the loops are now
coded in asm instead of C, this is (depending on the function) up to 50%
faster for cases where gcc didn't do a great job at looping.
Since h264_idct_add8() is now faster than the manual loop setup in h264.c,
in-asm idct calling can now be enabled for chroma as well (see r16207). For
MMX, this is 5% faster. For SSE2 (which isn't done for chroma if h264.c does
the looping), this makes it up to 50% faster. Speed gain overall is ~0.5-1.0%.
Originally committed as revision 25119 to svn://svn.ffmpeg.org/ffmpeg/trunk
Passing an explicit filename to this command is only necessary if the
documentation in the @file block refers to a file different from the
one the block resides in.
Originally committed as revision 22921 to svn://svn.ffmpeg.org/ffmpeg/trunk
The function is only used within that file, so it makes sense to place
it there. This fixes many warnings of the type:
h264.h:1170: warning: ‘fill_filter_caches’ defined but not used
Originally committed as revision 22876 to svn://svn.ffmpeg.org/ffmpeg/trunk
start of decoding a picture instead of at the end.
Fixes mmco01.264
Patch by Stephen Warren
Originally committed as revision 22728 to svn://svn.ffmpeg.org/ffmpeg/trunk
change, not only size changes.
Patch by Janusz Krzysztofik foo=zyszt <jkr$foo@tis.icnet.pl>.
Originally committed as revision 22597 to svn://svn.ffmpeg.org/ffmpeg/trunk
This moves the H264-specific functions from DSPContext to the new
H264DSPContext. The code is made conditional on CONFIG_H264DSP
which is set by the codecs requiring it.
The qpel and chroma MC functions are not moved as these are used by
non-h264 code.
Originally committed as revision 22565 to svn://svn.ffmpeg.org/ffmpeg/trunk
Previously, the area of a lost slice would be left at the slice number of the previous
frame which could occasionally match the number of the next slice and thus a non existing
slice could have been used for prediction leading to additional decoding errors in otherwise
undamaged slices.
Originally committed as revision 22483 to svn://svn.ffmpeg.org/ffmpeg/trunk
This fixes playback of such streams with ffplay (but does not affect
current ffmpeg).
Patch by Janusz Krzysztofik, jkrzyszt A tis D icnet D pl
Originally committed as revision 22112 to svn://svn.ffmpeg.org/ffmpeg/trunk
about 5 cpu cycles slower in the local code but should be overall faster
due to reduced cache use. (my sample though has too few intra4x4 blocks
for this to be meassureable easily either way)
Originally committed as revision 22052 to svn://svn.ffmpeg.org/ffmpeg/trunk
The code read/write code itself was 1 cycle faster, overall its
likely more due to cache effects
Originally committed as revision 22048 to svn://svn.ffmpeg.org/ffmpeg/trunk
This eliminates all aliasing violation warnings in h264 code.
No measurable speed difference with gcc-4.4.3 on i7.
Originally committed as revision 21881 to svn://svn.ffmpeg.org/ffmpeg/trunk
the row code. This function would only be needed on a MB basis for MBAFF+FMO
Originally committed as revision 21860 to svn://svn.ffmpeg.org/ffmpeg/trunk
This should fix a segfault, also it might be faster on systems where the
+52 wasnt free.
Originally committed as revision 21406 to svn://svn.ffmpeg.org/ffmpeg/trunk
loop filter. This removes one obstacle of getting ff_h264_filter_mb_fast()
bitexact. code is maybe 0.1% faster
Originally committed as revision 21280 to svn://svn.ffmpeg.org/ffmpeg/trunk
Run loop filter per row instead of per MB, this also should make it
much easier to switch to per frame filtering and also doing so in a
seperate thread in the future if some volunteer wants to try.
Overall decoding speedup of 1.7% (single thread on pentium dual / cathedral sample)
This change also allows some optimizations to be tried that would not have
been possible before.
Originally committed as revision 21270 to svn://svn.ffmpeg.org/ffmpeg/trunk
Seems to speed the code up a little...
The placement of many generic functions between h264.c and h264.h is still open
Currently they are a little randomly placed between them.
Originally committed as revision 21178 to svn://svn.ffmpeg.org/ffmpeg/trunk
called once per MB in worst case and doesnt seem to benefit from static inline.
Actually the code might be a hair faster now (0.1% according to my benchmark but
this could be random noise)
Originally committed as revision 21173 to svn://svn.ffmpeg.org/ffmpeg/trunk
no speedloss meassured, also its really not touching anything that is speed relevant.
Originally committed as revision 21169 to svn://svn.ffmpeg.org/ffmpeg/trunk
No speedloss meassured (its slightly faster here but that may be random fluctuations)
Originally committed as revision 21165 to svn://svn.ffmpeg.org/ffmpeg/trunk
functions called more than per mb are moved into the header, scan8 is also
as it must be known at compiletime.
The code after this patch duplicates h264data.h, this has been done to minimize
the changes in this step and allow more fine grained benchmarking.
Speedwise this is 1% faster on my pentium dual core with diegos cursed cathedral
sample.
Originally committed as revision 21157 to svn://svn.ffmpeg.org/ffmpeg/trunk
decoder which allows their usage without checking profile_idc.
Patch by Laurent Aimar (fenrir (AT) videolan org)
Originally committed as revision 21107 to svn://svn.ffmpeg.org/ffmpeg/trunk
Files with invalid VUI are now rejected like
other invalid SPS are.
Fixes issue1231.
Originally committed as revision 19335 to svn://svn.ffmpeg.org/ffmpeg/trunk
Before, the decoder could interpret a corrupt frame
as a NAL_DPA and NAL_DPC, and then start decoding
even if decode_slice_header() returned an error.
This frequently caused crashes.
Fixes issue1228, issue1229, and partially issue1238.
Originally committed as revision 19328 to svn://svn.ffmpeg.org/ffmpeg/trunk
First, reverted one was r19239.
Patch by Haruhiko Yamagata, h D yamagata A nifty D com
Originally committed as revision 19258 to svn://svn.ffmpeg.org/ffmpeg/trunk
The threads' contexts and rbsp_buffers were not freed at the end
of decoding.
Fixes issue 1581
Originally committed as revision 19207 to svn://svn.ffmpeg.org/ffmpeg/trunk
This ensures that the MMX loop filter is always bitexact with the C version.
Patch by Haruhiko Yamagata <h.yamagata _a_ nifty com>
Originally committed as revision 18923 to svn://svn.ffmpeg.org/ffmpeg/trunk
contexts, this avoids a crash when freeing the H.264 parser context introduced in
r18406, since h->s.avctx is NULL there.
Originally committed as revision 18418 to svn://svn.ffmpeg.org/ffmpeg/trunk
This ensures that the parser will no longer leak memory for all SPS/PPS it encounters.
Originally committed as revision 18406 to svn://svn.ffmpeg.org/ffmpeg/trunk
AVPacket argument rather than a const uint8_t *buf + int buf_size. This allows
passing of packet-specific flags from demuxer to decoder, such as the keyframe
flag, which appears necessary to playback corePNG P-frames.
Patch by Thilo Borgmann thilo.borgmann googlemail com, see also the thread
"Google Summer of Code participation" on the mailinglist.
Originally committed as revision 18351 to svn://svn.ffmpeg.org/ffmpeg/trunk
just saying that a non-existing id is referenced, show the value of the id.
Originally committed as revision 17771 to svn://svn.ffmpeg.org/ffmpeg/trunk
this will be needed once the parser can figure out has_b_frames
in av_find_stream_info().
Originally committed as revision 17673 to svn://svn.ffmpeg.org/ffmpeg/trunk
timebase stored in the h264 stream.
This should fix fate. (ffmpeg.c used pict_repeat with its default 1/25 timebase)
Originally committed as revision 17622 to svn://svn.ffmpeg.org/ffmpeg/trunk
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
