This reverts e6e7bfc1 and 365e1ec2.
The code may be incorrect both before and after the revert, but we
do not have any samples that were fixed by the original commits.
Fixes ticket #871.
With gcc 4.6 this part of the code is ca. 4x faster, resulting
in an overall speedup of around 5% for fate-fraps-v5 sample.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Codec has only I- and skip-frames, so there is no
need for reget_buffer, change it so it works with
get_buffer.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Causes FFmpeg to pass through the correct pts values,
instead of clobbering all to AV_NOPTS_VALUE (the av_init_packet
default) to then make up new ones based on only fps when muxing.
Included are also the related FATE ref changes, which all
some reasonable on quick investigation.
Also set all H.264 references to us -vsync drop to reduce the
diff for the ref files.
Otherwise almost all H.264 references need to change, mostly due
to now starting with negative pts values.
About 20 additional H.264 conformance tests needed -vsync
drop anyway because they create pts values that are out of
order and thus not possible to mux otherwise.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* qatar/master:
aacenc: Fix LONG_START windowing.
aacenc: Fix a bug where deinterleaved samples were stored in the wrong place.
avplay: use the correct array size for stride.
lavc: extend doxy for avcodec_alloc_context3().
APIchanges: mention avcodec_alloc_context()/2/3
avcodec_align_dimensions2: set only 4 linesizes, not AV_NUM_DATA_POINTERS.
aacsbr: ARM NEON optimised sbrdsp functions
aacsbr: align some arrays
aacsbr: move some simdable loops to function pointers
cosmetics: Remove extra newlines at EOF
Conflicts:
libavcodec/utils.c
libavfilter/formats.c
libavutil/mem.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Move libgsm_encode_close before its first use and call it
with the correct number of arguments.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
10l: Forgot to adjust deinterleave for new location of incoming samples in 7946a5a.
This produced incorrect, but surprisingly listenable results.
Thanks to Justin Ruggles for the report.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This allows to work around any non-monotonic time-stamp errors
by just discarding all time stamps.
This will be necessary to allow H.264 conformance tests to pass
after fixing time stamps to be passed through rawenc.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
We may or may not be able to play the latter parts
but not demuxing at all seems like the worst possible behaviour.
Fixes playback of e.g.
http://playlist.yahoo.com/makeplaylist.dll?sid=128114687&sdm=web&pt=rd
As a proper solution either multiple video streams should
be exported or side data should be used to update extradata
if necessary.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Since it is set for e.g. webm muxer we should make it possible
to test such streams with framecrc, too.
Though the primary reason is that this allows the H.264 tests
to not run into this check when fixing raw video encode to
pass pts values on.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The tests work fine without it, and it will cause issues when the
rawvideo decoder is changed to properly handle pts values.
The H.264 conformance tests however are still broken, usually losing
the first frames without it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This fixes the video frame pts (off by one for each MVIh)
and makes the "key frames" decode stand-alone (MVIh
contains only palette, such a palette-only frame being
marked as key frame is not really correct).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Previously the decoder would raise an error.
The end result is the same, the time stamps only change
because regression tests create time stamps incorrectly.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
