this allow a filter to be written like this:
aformat =
sample_fmts = fltp|flt:
sample_rates = 44100|44800
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
give high quality resampling
as good as with linear_interp=on
as fast as without linear_interp=on
tested visually with ffplay
ffplay -f lavfi "aevalsrc='sin(10000*t*t)', aresample=osr=48000, showcqt=gamma=5"
ffplay -f lavfi "aevalsrc='sin(10000*t*t)', aresample=osr=48000:linear_interp=on, showcqt=gamma=5"
ffplay -f lavfi "aevalsrc='sin(10000*t*t)', aresample=osr=48000:exact_rational=on, showcqt=gamma=5"
slightly speed improvement
for fair comparison with -cpuflags 0
audio.wav is ~ 1 hour 44100 stereo 16bit wav file
ffmpeg -i audio.wav -af aresample=osr=48000 -f null -
old new
real 13.498s 13.121s
user 13.364s 12.987s
sys 0.131s 0.129s
linear_interp=on
old new
real 23.035s 23.050s
user 22.907s 22.917s
sys 0.119s 0.125s
exact_rational=on
real 12.418s
user 12.298s
sys 0.114s
possibility to decrease memory usage if soft compensation is ignored
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
The only difference is that the first of them contains a
ff_h264_flush_change() call. While that is not necessary in the second
block, it should cause no problems either.
Reduce the verbosity of the reinit log message from info to verbose,
since now it will be displayed during every decode session.
Do it right before the MMCOs are applied to the DPB. This will allow
moving the frame_start() call out of the slice header parsing, since
generating the implicit MMCOs needs to be done after frame_start().
They are stored in the slice header, so technically they are per-slice
(though they must be the same in every slice). This will simplify the
following commits.
This function does not do any bitstream parsing and it depends on the
current frame being allocated, so this will allow the frame_start() to
be moved out eventually.
This will allow postponing the reference list construction (and by
consequence some other functions, like frame_start) until the whole
slice header has been parsed.
Currently it's done in the code that initialises the ref list for
MBAFF, which is not a logical place for it. Move it to the function that
parses the pred table from the bitstream, which is analogous to what is
done for the implicit weight table as well.
That function is currently very long and entangles bitstream parsing and
decoder configuration. This makes the code much harder to read than
necessary.
Begin splitting the code that configures the decoder state based on the
slice header information from the parsing of the slice header.
* commit 'c8dcff0cdb17d0aa03ac729eba12d1a20f1f59c8':
h264: factor out calculating the POC count into a separate file
Merged-by: Clément Bœsch <u@pkh.me>
* commit '113aeee6aed35cb786a9f6d69b0cb210f498b9da':
h264_parser: move the H264DSPContext to the parser context
H264Context is kept locally as it is currently needed for logging
(h->avctx as log context) and for is_avc and nal_length_size. These
later fields will later be obtained when the extradata parsing is
decoupled from the decoder. This code will be updated accordingly when
that commit is merged.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3176217c60ca7828712985092d9102d331ea4f3d':
h264: decouple h264_ps from the h264 decoder
Main changes:
- a local GetBitContext is created for the various
ff_h264_decode_seq_parameter_set() attempts
- just like the old code, remove_sps() is adjusted so it doesn't remove
the pps.
Fixes decode with Ticket #631http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20111108/dae58f17/attachment.mp4
but see next point as well.
- ff_h264_update_thread_context() is updated to work even when SPS
isn't set as it breaks current skip_frame code. This makes sure we
can still decode the sample from ticket #631 without the need for
-flags2 +chunks. (Thanks to Michael)
- keep {sps,pps}_ref pointers that stay alive even when the active
pps/sps get removed from the available lists (patch by michaelni with
additionnal frees in ff_h264_free_context() from mateo)
- added a check on sps in avpriv_h264_has_num_reorder_frames() to fix
crashes with mpegts_with_dvbsubs.ts from Ticket #4074http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4074/mpegts_with_dvbsubs.ts
- in h264_parser.c:h264_parse(), after the ff_h264_decode_extradata() is
called, the pps and sps from the local parser context are updated with
the pps and sps from the used h264context. This fixes fate-flv-demux.
- in h264_slice.c, "PPS changed between slices" error is not triggered
anymore in one condition as it makes fate-h264-xavc-4389 fails with
THREADS=N (Thanks to Michael)
Merged-by: Clément Bœsch <clement@stupeflix.com>
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Thomas Volkert
Vittorio Giovara
Michael Niedermayer
Muhammad Faiz
Matt Oliver
Ilya87
James Almer
Clément Bœsch
Anton Mitrofanov
Anton Khirnov
Petru Rares Sincraian
Paul B Mahol
Carl Eugen Hoyos
Dave Rice