The av_log() is done outside the lock, but this way the accesses to the
field (reads and writes) are always protected by a mutex. The av_log()
is not run inside the lock context because it may involve user callbacks
and doing that in performance-sensitive code is probably not a good idea.
This should fix occasional tsan warnings when running fate-h264, like:
WARNING: ThreadSanitizer: data race (pid=10916)
Write of size 4 at 0x7d64000174fc by main thread (mutexes: write M2313):
#0 update_context_from_user src/libavcodec/pthread_frame.c:335 (ffmpeg+0x000000df7b06)
[..]
Previous read of size 4 at 0x7d64000174fc by thread T1 (mutexes: write M2311):
#0 ff_thread_await_progress src/libavcodec/pthread_frame.c:592 (ffmpeg+0x000000df8b3e)
(cherry picked from commit 2e664b9c1e)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This tries to handle cases where separate invocations of decode_frame()
(each running in separate threads) write to respective fields in the
same AVFrame->data[]. Having per-field owners makes interaction between
readers (the referencing thread) and writers (the decoding thread)
slightly more optimal if both accesses are field-based, since they will
use the respective producer's thread objects (mutex/cond) instead of
sharing the thread objects of the first field's producer.
In practice, this fixes the following tsan-warning in fate-h264:
WARNING: ThreadSanitizer: data race (pid=21615)
Read of size 4 at 0x7d640000d9fc by thread T2 (mutexes: write M1006):
#0 ff_thread_report_progress pthread_frame.c:569 (ffmpeg:x86_64+0x100f7cf54)
[..]
Previous write of size 4 at 0x7d640000d9fc by main thread (mutexes: write M1004):
#0 update_context_from_user pthread_frame.c:335 (ffmpeg:x86_64+0x100f81abb)
(cherry picked from commit 083300bea9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes tsan warnings like this in fate-vp8-test-vector-007:
WARNING: ThreadSanitizer: data race (pid=65909)
Write of size 4 at 0x7d8c0000e088 by thread T1:
#0 vp8_decode_mb_row_sliced vp8.c:2519 (ffmpeg:x86_64+0x100995ede)
[..]
Previous write of size 4 at 0x7d8c0000e088 by thread T2:
#0 vp8_decode_mb_row_sliced vp8.c:2519 (ffmpeg:x86_64+0x100995ede)
(cherry picked from commit fed92adbb3)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes tsan warnings like this in fate-vp8-test-vector-007:
WARNING: ThreadSanitizer: data race (pid=3590)
Write of size 4 at 0x7d8c0000e07c by thread T2:
#0 decode_mb_row_no_filter src/libavcodec/vp8.c:2330 (ffmpeg+0x000000ffb59e)
[..]
Previous write of size 4 at 0x7d8c0000e07c by thread T1:
#0 decode_mb_row_no_filter src/libavcodec/vp8.c:2330 (ffmpeg+0x000000ffb59e)
(cherry picked from commit 9a54c6f243)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes the following tsan warning when running fate-vsynth_lena-ffvhuff:
WARNING: ThreadSanitizer: data race (pid=6484)
Write of size 8 at 0x7d64000154b8 by main thread (mutexes: write M1331):
#0 update_context_from_user src/libavcodec/pthread_frame.c:331 (ffmpeg+0x000000dca887)
[..]
Previous read of size 8 at 0x7d64000154b8 by thread T2 (mutexes: write M1334):
#0 draw_slice src/libavcodec/huffyuvdec.c:857 (ffmpeg+0x000000bcc86f)
(cherry picked from commit 7c7e7c44a6)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes tsan warnings in fate-apng:
WARNING: ThreadSanitizer: data race (pid=51230)
Read of size 4 at 0x7d50000042fc by main thread (mutexes: write M1000):
#0 frame_copy_props frame.c:302 (ffmpeg:x86_64+0x1019a35d6)
[..]
Previous write of size 4 at 0x7d50000042fc by thread T1 (mutexes: write M997):
#0 decode_idat_chunk pngdec.c:708 (ffmpeg:x86_64+0x100f5562a)
(cherry picked from commit eff2861a75)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes a reported (but false) race condition in tsan for fate-apng:
WARNING: ThreadSanitizer: data race (pid=6274)
Read of size 4 at 0x7d680001ec78 by main thread (mutexes: write M1338):
#0 update_thread_context src/libavcodec/pngdec.c:1456 (ffmpeg+0x000000dacf0c)
[..]
Previous write of size 4 at 0x7d680001ec78 by thread T1 (mutexes: write M1335):
#0 decode_idat_chunk src/libavcodec/pngdec.c:737 (ffmpeg+0x000000dae951)
(cherry picked from commit 478f1c3d5e)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Values from subsequent values are guaranteed to be identical (since
poc and nal_unit_type are checked to be the same between slices), so
this doesn't affect output in any way, but does resolve the remaining
reported race conditions (by tsan) in fate-hevc.
In practice, this fixes tsan warnings like this:
WARNING: ThreadSanitizer: data race (pid=25334)
Read of size 4 at 0x7d9c0001adcc by main thread (mutexes: write M1386):
#0 hevc_update_thread_context src/libavcodec/hevcdec.c:3310 (ffmpeg+0x000000b41c7c)
[..]
Previous write of size 4 at 0x7d9c0001adcc by thread T1 (mutexes: write M1383):
#0 hls_slice_header src/libavcodec/hevcdec.c:596 (ffmpeg+0x000000b43a22)
(cherry picked from commit 1f50baa2b2)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise the thread may still be in the middle of decoding a previous
frame, which would effectively trigger a race condition on any field
concurrently read and written.
In practice, this fixes tsan warnings like the following:
WARNING: ThreadSanitizer: data race (pid=17380)
Write of size 4 at 0x7d64000160fc by main thread:
#0 update_context_from_user src/libavcodec/pthread_frame.c:335 (ffmpeg+0x000000dca515)
[..]
Previous read of size 4 at 0x7d64000160fc by thread T2 (mutexes: write M1821):
#0 ff_thread_report_progress src/libavcodec/pthread_frame.c:565 (ffmpeg+0x000000dcb08a)
(cherry picked from commit 1269cd5b6f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Should fix tsan warnings in fate-fifo-muxer-h264/wav:
WARNING: ThreadSanitizer: data race (pid=26552)
Write of size 4 at 0x000001e0d7c0 by main thread:
#0 transcode_init src/ffmpeg.c:3761 (ffmpeg+0x00000050ca1c)
[..]
Previous read of size 4 at 0x000001e0d7c0 by thread T1:
#0 decode_interrupt_cb src/ffmpeg.c:460 (ffmpeg+0x0000004fde19)
(cherry picked from commit 76d8c77430)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is how the ref list manager links bitstream IDs to H264Picture/Ref
objects, and is local to the producer thread. There is no need for the
consumer thread to know the bitstream IDs of its references in their
respective producer threads.
In practice, this fixes tsan warnings when running fate-h264:
WARNING: ThreadSanitizer: data race (pid=19295)
Read of size 4 at 0x7dbc0000e614 by main thread (mutexes: write M1914):
#0 ff_h264_ref_picture src/libavcodec/h264_picture.c:112 (ffmpeg+0x0000013b3709)
[..]
Previous write of size 4 at 0x7dbc0000e614 by thread T2 (mutexes: write M1917):
#0 build_def_list src/libavcodec/h264_refs.c:91 (ffmpeg+0x0000013b46cf)
(cherry picked from commit e72690b18d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I'm hoping that this will address the remaining tsan fate-h264 issues:
WARNING: ThreadSanitizer: data race (pid=24478)
Read of size 8 at 0x7dbc0001c828 by main thread (mutexes: write M3243):
#0 ff_h264_ref_picture src/libavcodec/h264_picture.c:107 (ffmpeg+0x0000013b78d8)
[..]
Previous write of size 1 at 0x7dbc0001c82e by thread T2 (mutexes: write M3245):
#0 ff_h264_direct_ref_list_init src/libavcodec/h264_direct.c:137 (ffmpeg+0x000001382c93)
But I'm not sure because I haven't been able to reproduce locally.
(cherry picked from commit 7f05c5cea0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Experimental VP9 support was added to the muxer recently.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit d36a3f5a78)
The custom callback can cause significant CPU usage on Windows for some large
files with many index entries for some reason.
v2: Move check after parsing options.
Signed-off-by: Marton Balint <cus@passwd.hu>
This changes nothing but is nicer looking as this checks rlen
Maybe this helps coverity remove CID1397743
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c94d551ea7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should help coverity see that the issues this leads to cannot occur
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 8dd0c12648)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Doesn't work yet with slice threading and won't work with AMV.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 03eb0515c1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When coding lossless jpeg the priv context will be pointing to LJpegEncContext
rather than MpegEncContext, which the function expects.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
(cherry picked from commit 2c9be3882a)
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* commit 'e18ba2dfd2d19aedc8afccf011d5fd0833352423':
hwcontext_dxva2: make sure the sw frame format is the right one during transfer
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '9d7026574bbbe67d004a1c32911da75375692967':
hwcontext_dxva2: fix handling of the mapping flags
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '0d3176e32f351d18d6174d8b05796829a75a4c6b':
hwcontext_dxva2: do not assume the destination format during mapping is always the right one
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '0a4b9d0ccd10b3c39105f99bd320f696f69a75a2':
hlsenc: Add encryption support
This commit is a noop, see 907ac20aa2
Note that this commit differs from our encryption support in various
ways so it may need some adjustments in the future.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bb265b764a055f2dc576b9aec62460d9580868f4':
examples/transcode_aac: Drop pointless return value const qualifier
This commit is a noop, the function doesn't exist in FFmpeg anymore
since e181e2909b.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bfe92dfe60f601b3f20a918ffcc0acdf40a5955c':
Ignore all generated example binaries
This commit is a noop, the .gitignore was updated during the merges of
these examples.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3cc3463f306f425f76bd962755df1132eeac6dfa':
avisynth: Support pix_fmts added to AviSynth+
This commit is mostly a noop, see
92916e8542.
Cosmetics and a small fix are merged.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'aaae59700f7fc10fd80cb93b38c5d109900872d9':
avisynth: Simplify the pix_fmt check for the newer AviSynth API
This commit is a noop, see 0ed5c3ce81
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bcefafa226dcda23d4d9af9601d19389cb918a5b':
avisynth: Fix setting stream timebase
This commit is a noop, see 8009a1f1fd
Merged-by: Clément Bœsch <u@pkh.me>
* commit '481ff3cf018811ba3235f1c236e970f32a6300b9':
fate: Add h264 and hevc extradata reload tests
Only the HEVC part is merged, see 00c8079816
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd5d62ce6d643de704e7bd62a2375e6391c0ffb9a':
mov: Fix identity matrix boolean logic
This commit is a noop, see 7010ebdf1f
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e7ae8f7a715843a5089d18e033afb3ee19ab3057':
aarch64: vp9: loop filter: replace 'orr; cbn?z' with 'adds; b.{eq,ne};
This commit is a noop, see e7ae8f7a71
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd7595de0b25e7064fd9e06dea5d0425536cef6dc':
aarch64: vp9: use alternative returns in the core loop filter function
This commit is a noop, see 62ea07d797
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e17567a831dede1f24e3a1a4c305a93012d7a8ce':
libilbc: support for latest git of libilbc
This commit is a noop, see 59af5383c1
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ffe89e1edb0281ff65d1bda88253784e9283b717':
configure: Move mjpeg_vaapi_decoder dependency declarations to the right place
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'fbd1f7639d0142c391bec85d1d840c835210843f':
af_asyncts: Use llabs instead of labs for 64-bit variable
This commit is a noop, see a8fe8d6b4a
Merged-by: Clément Bœsch <u@pkh.me>
* commit '182cf170a544bce069c8690c90b49381150a1f10':
vp8: Return stream format information from parser
Return codes are adjusted to consume the whole packet in case of error
as the API does not allow returning AVERROR codes (a negative return
value is valid).
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b6582b29277e00e5d49f400e58beefa5a21d83b8':
qsv: Add VC-1 decoder
See fb57bc6c34.
Merged for cosmetic purposes to reduce differences with libav.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fea4dc05b41f5465bedc786b67966f204ec6150c':
vc1: Return stream format information from parser
This commit is a noop, see 4df6605da7
Merged-by: James Almer <jamrial@gmail.com>
* commit '0940b748bdba36c4894fc8ea6be631d821fdf578':
qsvdec: Only warn about unconsumed data if it happens more than once
Merged-by: James Almer <jamrial@gmail.com>
* commit '030d84fa2e35af0e77516735de35bf1a52371c86':
qsvdec: Pass field order information to libmfx
qsvdec: Pass the correct profile to libmfx
These commits are a noop, see 1f26a231bb
Merged-by: James Almer <jamrial@gmail.com>
* commit '3297577f3eac1c87d48dedd527942de2bd28e7a5':
mpegvideo: Return correct coded frame sizes from parser
This commit is a noop, see 309fe16a12
Merged-by: James Almer <jamrial@gmail.com>
* commit '3c9546dfafcdfe8e7860aff9ebbf609318220f29':
aarch64: vp9: Add NEON itxfm routines
This commit is a noop, see f43079e11c
Merged-by: James Almer <jamrial@gmail.com>
* commit '01348e411f962f5e4605d649fc9a47a54587ba8e':
avconv_opt: Consistently iterate through hwaccels array in all cases
Merged-by: James Almer <jamrial@gmail.com>
* commit '8ddfa5ae5ef64a25dd087d74954ebdb9081f0d67':
vf_drawtext: Drop wrong void* cast
This commit is a noop, see 4c96985af1
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fcbdd605b5409103c3f4bfa063ea270f2229b125':
nut: Use correct function pointer casts instead of void*
This commit is a noop. Casts are not needed.
Merged-by: James Almer <jamrial@gmail.com>
* commit '3b50dbc51fb0978d09c1a5b83d4bf5a59d170e1e':
ratecontrol: Use correct function pointer casts instead of void*
Merged-by: James Almer <jamrial@gmail.com>
* commit 'dd299a2d6d4d1af9528ed35a8131c35946be5973':
arm: vp9: Add NEON loop filters
This commit is a noop, see 6bec60a683
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f7d183f08472e566a2e6b62a80e200a12670ed0e':
libxvid: Check return value of write() call
This commit is a noop, see 25f35df115
Merged-by: James Almer <jamrial@gmail.com>
* commit '12db2832e41aa71b5903ef7fa5c59c5473ded2c5':
libxvid: Require availability of mkstemp()
This commit is a noop. Our libxvid wrapper doesn't use mkstemp().
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a67ae67083151f2f9595a1f2d17b601da19b939e':
arm: vp9: Add NEON itxfm routines
This commit is a noop, see b4dc7c341e
Merged-by: James Almer <jamrial@gmail.com>
* commit '0b37cd09a67c3ba4db044404b99c65a32b4ad932':
checkasm: add vp9dsp.itxfm_add tests.
This commit is a noop, see 0b227c6d47
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fd0fae60372cddbe0bec8830d07e760195f80bad':
pthread_frame: Unreference hw_frames_ctx on per-thread codec contexts
This commit is a noop, see fb69a8e1f1
Merged-by: James Almer <jamrial@gmail.com>
* commit '11623217e3c9b859daee544e31acdd0821b61039':
arm: vp9mc: Use a different helper register for PIC loads
This commit is a noop, see 68caef9d48
Merged-by: James Almer <jamrial@gmail.com>
* commit '824e8c284054f323f854892d1b4739239ed1fdc7':
arm: Clear the gp register alias at the end of functions
This commit is a noop, see 86c5a23ee5
Merged-by: James Almer <jamrial@gmail.com>
* commit '6a62795d4051f435a9a2c59395d96913693922f8':
aarch64: h264idct: Use the offset parameter to movrel
This commit is a noop, see da5c8284c0
Merged-by: James Almer <jamrial@gmail.com>
* commit '557c1675cf0e803b2fee43b4c8b58433842c84d0':
arm: vp9mc: Minor adjustments from review of the aarch64 version
This commit is a noop, see 68caef9d48
Merged-by: James Almer <jamrial@gmail.com>
* commit '383d96aa2229f644d9bd77b821ed3a309da5e9fc':
aarch64: vp9: Add NEON optimizations of VP9 MC functions
This commit is a noop, see 1f7801c2bc
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c44a8a3eabcd6acd2ba79f32ec8a432e6ebe552c':
aarch64: Add an offset parameter to the movrel macro
This commit is a noop, see 7fe898dbb9
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a4cfcddcb0f76e837d5abc06840c2b26c0e8aefc':
vp9: Make the subpel filters non-static
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit '98cae966c77875e26c5958206a6cfe7eba6269e8':
matroskaenc: write updated STREAMINFO metadata for FLAC streams if available
This commit is a noop, see 8c1342e631
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f4bf236338f6001736a4784b9c23de863057a583':
matroskaenc: fix muxing AAC streams when using aac_adtstoasc bsf
This commit is a noop. aac_adtstoasc bsf sends its extradata update
straight to codecpar->extradata.
This behavior violates the bsf API and should be fixed so this change
may then be applied.
Merged-by: James Almer <jamrial@gmail.com>
* commit '84f225684cd389747907381122c073aa1c8b6bf1':
pthread_frame: properly propagate the hw frame context across frame threads
This commit is a noop, see 98f89d615b.
Merged-by: James Almer <jamrial@gmail.com>
* commit '72a19f4013ec2c7f8581416f8ad4bf81df163fb6':
mpegaudiodsp: aarch64: Adjust function prototype after 2caa93b813
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c78495d1cdac6dd13786a7e5571b606604a360bd':
configure: Log name and parameters of all helper functions where it makes sense
Merged-by: James Almer <jamrial@gmail.com>
* commit '831005b2302cbeb377e3f00fd18c78928bcec185':
configure: Log correct test name and use correct filter when testing objective C flags
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fe7bc1f16abaefe66d8a20f734ca3eb8a4ce4d43':
configure: Do not unconditionally check for (and enable) xlib
Merged-by: James Almer <jamrial@gmail.com>
The value must be identical between slices, since mbaff depends on
picture_structure and sps, both of which are checked to be identical
to the first slice before this point.
In practice, this silences some tsan warnings in fate-h264.
This fixes race conditions reported by tsan in fate-lagarith. The races
were because each thread's LagarithContext::avctx was set to the first
thread's AVCodecContext.
Otherwise all thread's private contexts have the avctx pointer set to
the AVCodecContext of the first thread, which means all writes to
ctx->avctx->* (in e.g. read_header) are effectively race conditions.
Fixes fate-dnxhd under tsan.
Adding an MOV format option to turn on/off the editlist supporting code, introduced in ca6cae73db
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'd1a91ebe4990001e0800ee9ac54ed2207e4f56ff':
configure: Print list of enabled programs
This commit is mostly a noop, see 832b4a4a43
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'a3483f79933e8f1fd99d524e3218688e14c59150':
avconv: Drop stray leftover debug output
This commit is a noop, see a283665693
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '59d2b00d201935c16408a2917957d89a170fe58f':
configure: Add --quiet command line parameter to suppress informative output
The license assignment is moved out of the quiet condition to make sure
it ends up in config.h
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'de6e2ff3ddf506d5b487c2f226cea73e095ad6d1':
mov: Read multiple stsd from DV
This commit is a noop, see a765ba647d
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '47a795727f5433f5238a8a244cf181f61ea5af2c':
hevc: Support extradata changes from multiple stsd
This commit is a noop, see 25fcbf7a84
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '2fe30b4743c0f4c3bdf37b91ae534cafa85e4036':
hevc: Allow parsing external extradata buffers
This commit is a noop as it matches FFmpeg state.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '5be21531119d7a97ebc706800d1608272ee5a507':
hevc: Move hevc_decode_extradata before frame decoding
This commit is a noop, hevc_decode_extradata() is already above
hevc_decode_frame().
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'bed2c4b2652b1412b584e5545d6dd2ef8c613be0':
lavc: Add hevc main10 profile to avconv cli
This commit is a noop, see 271afd632f
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '0361e4dcb4d394c88c33364415a3b8fe315b67d1':
h264_qpel: x86: Move function with only one instance out of template macro
Note: warning is present with clang.
Merged-by: Clément Bœsch <cboesch@gopro.com>
This is more robust in case some change or corner case causes them to be
dereferenced before being set
Fixes CID1396274, CID1396275
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '88f0cf8cd30c8ea283430e6710a7bd98bb9c0301':
avplay: Correct function pointer assignments in options array
This commit is a noop, see a9a1bc56ab
Merged-by: Clément Bœsch <u@pkh.me>
* commit '943533d64c7fa7a1b2fc9559e67652c349d21d51':
avconv: Correct function pointer assignments in options array
This commit is a noop, see 4c96985af1
Merged-by: Clément Bœsch <u@pkh.me>
* commit '43de8b328b62cf21ec176c3989065168da471a5f':
lzf: update pointer p after realloc
This commit is a noop, see bb6a7b6f75
Merged-by: Clément Bœsch <u@pkh.me>
* commit '00aeedd84105a17f414185bd33ecadebeddb3a27':
qsv{dec,enc}: use a struct as a memory id with internal memory allocator
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '404e51478ecad060249d5b9bee6ab39a8a9d8c1c':
qsv{dec,enc}: always use an internal mfxFrameSurface1
Minor fixups for differences in the QSV encoder because of a53cc.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '8ea15afbf2c1ec89b5d4bac1f0b8345e4b906a5d':
hwcontext_qsv: transfer data through the child context when VPP fails
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit 'b91ce4860054430d3712deb0d9487cac2fcb7d68':
hwcontext_qsv: do not fail when download/upload VPP session creation fails
Merged-by: Mark Thompson <sw@jkqxz.net>
This is an example, people will copy and use this. The maximum supported is quite
unreasonable as a default choice
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'fabfbfe5710050812147f93a351a53fdda56ff8c':
dxva2: fix surface selection when compiled with both d3d11va and dxva2
This commit is a noop, see 153b36fc62
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'db0b3dccb3842de134721e8d5c275f56d384340d':
libx265: Add option to force IDR frames
This commit is a noop, see 8a8902f221
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '3cba09e5228c889d63814dc43bc68f15c9dbac77':
x86: Drop stray semicolons after function definitions
This commit is a noop, they are already fixed in FFmpeg.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'd1ef1b9eaa45043ea5df5a004fb37243e05da61d':
configure: Silence lld-link when getting the version number
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '392caa65df3efa8b2d48a80f08a6af4892c61c08':
arm: vp9mc: Insert a literal pool at the middle of the file
This commit is a noop, see 68caef9d48
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '99434f4df81b6801b2b535d5b9143305595784f6':
float_dsp: Have implementation match function pointer prototype
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '6354957a95022864746180525680cca872ab0e0a':
dnxhdenc: Have function pointer prototype match implementation
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'c778eb15b89d875cb246b18f65b3b4321cb1e7d6':
pixblockdsp: Have function pointer prototype match implementation
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '99ddeddc7fc996c0c1e842112928490e78542bd5':
ituh263dec: Have function signature match across declaration and definition
This commit is a noop, see 2d2b363c65
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '67c65e461cb073d61ffbc78845d4a3d8f14bf481':
vf_hwupload_cuda: Fix build error
This commit is a noop, see 78e871ebbc
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '13fcdfb976038f63b9f753e2ebcc8e04d7c7abc2':
svq3: Drop unused function dctcoef_get()
This commit is a noop, see 1e298e7724
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'ee59f0540875ab42496af2aacddd942757707683':
intrax8: Have function signature match across declaration and definition
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '1a469a5e423bdad779b8534247dea8cc86169b88':
options_table: Remove a now unnecessary include of config.h
This commit is a noop, see 76f43cbe26
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'ffbd1d2b0002576ef0d976a41ff959c635373fdc':
arm: vp9: Add NEON optimizations of VP9 MC functions
This commit is a noop, see 68caef9d48
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '2e55e26b40e269816bba54da7d0e03955731b8fe':
vp9: Flip the order of arguments in MC functions
This commit is a noop, it was made to match our prototypes.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '7e2561fa8313982aa21f7657953eedeeb33b210d':
lavfi: Use ff_get_video_buffer in all filters using hwframes
vf_hwupload_cuda: Fix build error
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
* commit '7433feb82f75827884d909de34d341a1c4401d4a':
lavfi: Make default get_video_buffer work with hardware frames
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
This conflict with the DJGPP libc math.h which includes a PI macro (to
M_PI).
We cannot make DJGPP POSIX only (using -D_POSIX_SOURCE) to avoid this
kind of symbols conflicts due to the lack of both posix_memalign and
memalign (DJGPP non standard function) in that POSIX mode. We currently
rely on memalign for aligned heap allocation.
This conflict with the DJGPP libc which includes a pow2 function¹
We cannot make DJGPP POSIX only (using -D_POSIX_SOURCE) to avoid this
kind of symbols conflicts due to the lack of both posix_memalign and
memalign (DJGPP non standard function) in that POSIX mode. We currently
rely on memalign for aligned heap allocation.
[1]: http://www.delorie.com/djgpp/doc/libc-2.02/libc_536.html
This conflict with the DJGPP libc which includes a pow2 function¹
We cannot make DJGPP POSIX only (using -D_POSIX_SOURCE) to avoid this
kind of symbols conflicts due to the lack of both posix_memalign and
memalign (DJGPP non standard function) in that POSIX mode. We currently
rely on memalign for aligned heap allocation.
[1]: http://www.delorie.com/djgpp/doc/libc-2.02/libc_536.html
* commit '39cea6570c11a49b64b2ec8d71e218db03b4c742':
aactab: Move extern keyword to the front of array declarations
Merged-by: Clément Bœsch <u@pkh.me>
* commit '85baef4ff1512bcc2544928bfa5f42072903a691':
vf_drawtext: Move static keyword to beginning of variable declaration
This commit is mostly a noop, see:
d9e2aceb7f6d7aa437e1
Merged-by: Clément Bœsch <u@pkh.me>
* commit '636515c324facaa14ccd8ab0732740a240a31ba9':
examples/decode_video: remove a stray unrelated comment
This commit is a noop, see 8c4753f7f5
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5b4d7ac7ae5d821cfa6ab89f8eab4d31851ef32c':
examples/encode_video: use the AVFrame API for allocating the frame
Merged-by: Clément Bœsch <u@pkh.me>
* commit '7b1f03477f1a43d2261fbd83e50a4ad90c7f806d':
examples/avcodec: split the remaining two examples into separate files
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f5df897c4b61985e3afc89ba1290649712ff438e':
examples/avcodec: split audio decoding into a separate example
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f76698e759a08e8d3b629c06edb0439f474e7fee':
examples/encode_audio: use the AVFrame API for allocating the data
Merged-by: Clément Bœsch <u@pkh.me>
* commit '40aaa8dadfd1c69ff4460d04750e1403b5535a6d':
examples/avcodec: split audio encoding into a separate example
Merged-by: Clément Bœsch <u@pkh.me>
Get rid of the "ret" variable, and always use err. Report the packet as
consumed if err is unset. This should be equivalent to the old code,
which obviously required err=0 for p->result>=0 (and otherwise,
p->result must have had the value err was last set to). The code block
added by commit 32a5b63126 is also not needed anymore, because the new
code strictly returns err if it's >=0.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Intra-only codecs should either be able to read these items from the
bitstream, or they should be set upon codec initialization. In both
cases, syncing these items at runtime is unnecessary.
In practice, this fixes race conditions for decoders that read these
values from the bitstream.
If ret is NULL, a dummy common holder is created to hold *all* the
parallel function returns, which gets written concurrently. This commit
simplify the whole logic by simply not writing to that holder when not
set.
Needed for the C+11 atomics. Also change add_cxxflags to check_cxxflags.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
refer to SPEC:
Annex E. The FLV File Format said:
E.3 TheFLVFileBody have a table:
Field Type Comment
PreviousTagSize0 UI32 Always 0
Reviewed-by: Bela Bodecs <bodecsb@vivanet.hu>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
adding demuxer and other logs should be easy
This forces single threaded decoding for simplicity
It also requires pthreads, this could be avoided either with
some lockless tricks or simply by assuming av_log would never be called from
another thread.
Fixes Ticket5521
Previous version reviewed by Stefano
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '064f19f39e2f17927278c6ad8fe884a5b92310d6':
avconv: support parsing bitstream filter options
This commit is a noop, see 5ef1959080
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ecd2ec69ce10e13f6ede353d2def7ce9f45c1a7d':
mov: Evaluate the movie display matrix
This commit is a noop, see 7010ebdf1f
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b90c8a3d08e3f9ad4de1253376d2d1d93abb8b8c':
fate: Add tests for mov display matrix
Adapted to use ffprobe -show_entries
Merged-by: James Almer <jamrial@gmail.com>
* commit '7d308bf84bda78d47c01439ff625bb06624991a7':
avprobe: Add -show_stream_entry to get a single stream property
This commit is a noop, we have a generic -show_entry option.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '218ed7250c103a975e874fb16e8e5941f4cbe223':
openssl: Allow newer TLS versions than TLSv1
This commit is a noop, see e8634fb92e
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'dad7514f9ec8a8c5e44d70fcfbbcedeff16f7e13':
xcb: Add all the libraries to the link line explicitly
This commit is a noop. It appears we already link against the xcb shape
library since 54170a33c2.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c541a44e029e8a4f21db028c34fee3ad1c10a409':
Revert "rtmpproto: Don't include a client version in the unencrypted C1 handshake"
Merged-by: Clément Bœsch <u@pkh.me>
* commit '801ac7156d3efb8e088fb6024f568eb36a293887':
qsv: Be informative when reporting that no data has been consumed
Merged-by: Clément Bœsch <u@pkh.me>
* commit '30015305f3b523ed7640f2c3c58b017140533c58':
Use avpriv_request_sample() where appropriate
Only the roqvideo chunk is merged because we actually support 24bpp
flic, see 5781c983d8.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '07cac07c0c0360d67e73a7472214c79d6c520a4b':
dash: Use correct ISO C scanf conversion specifier
This commit is a noop: the use of SCN (scanf) format is wrong here.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3ec6f855d0f21d90a0494fb798c4cf203fdb3db0':
srt: Adjust signedness of sscanf format strings
This commit is a noop, a different fix is included in the big -Wformat
patch under review
(http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html)
Merged-by: Clément Bœsch <u@pkh.me>
* commit '7a2b2b6a92c4b528ecb640790eca0aa790d858f4':
dxtory: Drop nonsense ISO C printf conversion specifiers for standard types
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c454dfcff90f0ed39c7b0d4e85664986a8b4476c':
Use ISO C printf conversion specifiers where appropriate
This commit is a noop, an equivalent patch is currently under review on
the mailing-list: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html
Merged-by: Clément Bœsch <u@pkh.me>
Could lead to random behavior. This possibly happened due to commit
32a5b63126. This should/could probably be simplified, but for no apply
a minimal fix to quell the errors.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
async_mutex has is used in a very strange but intentional way: it is
locked by default, and unlocked only in regions that can be run
concurrently.
If the user was calling API functions to the same context from different
threads (in a safe way), this could unintentionally unlock the mutex on
a different thread than the previous lock operation. It's not allowed by
the pthread API.
Fix this by emulating a binary semaphore using a mutex and condition
variable. (Posix semaphores are not available on all platforms.)
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
The old "API" that signaled rotation as a metadata value has been
replaced by DISPLAYMATRIX side data quite a while ago.
There is no reason to make muxers/demuxers/API users support both. In
addition, the metadata API is dangerous, as user tags could "leak" into
it, creating unintended features or bugs.
ffmpeg CLI has to be updated to use the new API. In particular, we must
not allow to leak the "rotate" tag into the muxer. Some muxers will
catch this properly (like mov), but others (like mkv) can add it as
generic tag. Note applications, which use libavformat and assume the
old rotate API, will interpret such "rotate" user tags as rotate
metadata (which it is not), and incorrectly rotate the video.
The ffmpeg/ffplay tools drop the use of the old API for muxing and
demuxing, as all muxers/demuxers support the new API. This will mean
that the tools will not mistakenly interpret per-track "rotate" user
tags as rotate metadata. It will _not_ be treated as regression.
Unfortunately, hacks have been added, that allow the user to override
rotation by setting metadata explicitly, e.g. via
-metadata:s:v:0 rotate=0
See references to trac #4560. fate-filter-meta-4560-rotate0 tests this.
It's easier to adjust the hack for supporting it than arguing for its
removal, so ffmpeg CLI now explicitly catches this case, and essentially
replaces the "rotate" value with a display matrix side data. (It would
be easier for both user and implementation to create an explicit option
for rotation.)
When the code under FF_API_OLD_ROTATE_API is disabled, one FATE
reference file has to be updated (because "rotate" is not exported
anymore).
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Squelches the following compiler warnings:
libavcodec/opusenc.c:1051:16: warning: format specifies type 'long' but
the argument has type 'long long' [-Wformat]
avctx->bit_rate/1000, clipped_rate/1000);
^~~~~~~~~~~~~~~~~~~~
libavcodec/opusenc.c:1051:38: warning: format specifies type 'long' but
the argument has type 'long long' [-Wformat]
avctx->bit_rate/1000, clipped_rate/1000);
^~~~~~~~~~~~~~~~~
This was skipped in c17563c5d3 because
it depended on the filter setup merge, but was forgotten after that
actually happened.
Fixes hwaccel fate for stream size change tests.
Changes to the parsing code originally committed to mpegvideo_parser.c
in 73fb23dc5a.
Required by some samples, like PVA_test-partial.pva
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'fbe425c8d29e473a8f69ae2dc52b1a10b77f3b44':
hap: Adjust printf length modifiers to match variable types
This commit is a noop, see 5a51ca2da7
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f22363c72968f1a1fc4881d8695ec7068b0aa03c':
openssl: Avoid double semicolons after the GET_BIO_DATA macro
This commit is a noop, see fc83de7e1d
Merged-by: Clément Bœsch <u@pkh.me>
* commit '99aeae20de4d09ea313fdc619d4e2df825155e62':
scale_npp: fix passthrough mode
This commit is a noop, see f524275ef9
Merged-by: Clément Bœsch <u@pkh.me>
* commit '754b20d7ebccbe8d316b12128c8cb433d5a516ac':
vaapi_h264: fix RefPicList[] field flags.
This commit is a noop, see 88325c2e0b
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ee050797664c7c74cae262ffab05006b55d47a11':
openssl: Support version 1.1.0.
This commit is mostly a noop, see 798c6ecce5
Included the simplifications by Martin Storsjö and fixed the
GET_BIO_DATA() macro to prevent a warning after the simplifications.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '2f806622e1270d3ed1d41a53049a19673dafbe70':
bktr: Use memset(0) instead of zero initialization for struct sigaction
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6d5636ad9ab6bd9bedf902051d88b7044385f88b':
hevc: x86: Add add_residual() SIMD optimizations
See a6af4bf64d
This merge is only cosmetics (renames, space shuffling, etc).
The functionnal changes in the ASM are *not* merged:
- unrolling with %rep is kept
- ADD_RES_MMX_4_8 is left untouched: this needs investigation
Merged-by: Clément Bœsch <u@pkh.me>
* commit '043b0b9fb1481053b712d06d2c5b772f1845b72b':
Replace leftover uses of -aframes|-dframes|-vframes with -frames:a|d|v
The merge also includes all our own occurences.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '4b07ebf1eb13561492f7e3c30a67f34415016b3e':
mov: Update colr values
Mostly noop, see a3cab3d433
Only the use of av_color_{primaries,transfer,space}_name() is merged.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '59c90097a0eff0dc81fbec15b8900c929859d1e7':
hevc: factor out a repeated condition
This commit is a noop. It doesn't apply as our codebase has diverged
too much.
Merged-by: James Almer <jamrial@gmail.com>
* commit '096a8effa3f8f3455292c958c3ed07e798def7bd':
lavf: check that the codec is supported by extract_extradata
This commit is a noop. The code it changes was reverted.
See 40fa9d416a
Merged-by: James Almer <jamrial@gmail.com>
This reverts commit 1c193ac1f9, reversing
changes made to 7ebc9f8df4.
Several FATE tests started failing after this merge, so it's reverted
until it can be properly fixed.
* commit '788544ff0ed6fe67fda80ad6d3a0796ace035584':
audiodsp: x86: Remove pointless header file
This commit is a noop, see 6ec3dc97fc
Merged-by: James Almer <jamrial@gmail.com>
* commit 'b89804da9bad2d94dd95bf20ac6187447e9c17e9':
x86: videodsp: Add parentheses to expression to work around warning
Merged-by: James Almer <jamrial@gmail.com>
* commit 'da4f8c8e35a867f2d9fed0fb75e16c81ab968637':
fate: Update filter-pixfmts-scale gbrap12le hash missing from be9dba5c8a
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'be9dba5c8abc6ecf0b8ee4ccb11c7850327fcf8d':
swscale: Properly load alpha for planar rgb
This commit is a noop, see
4170a44bbcdf36257a53
Merged-by: James Almer <jamrial@gmail.com>
* commit '58224dc5f3d4fea40a8d55cca87291a960c11622':
ppc: avcodec: Drop silly "_ppc" suffixes from files in ppc subdirectories
Merged-by: James Almer <jamrial@gmail.com>
* commit '0cf86fabfa5820596cca2cfead63c6f8df76c3f2':
vaapi_encode: Write sequence header as extradata
This commit is a noop. It has already been cherry-picked in
51020adcec
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c91d6a33f872574c95c8784277cf60ffcf6bff4f':
checkasm: aarch64: Add filler args to make sure all parameters are passed on the stack
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f1b3e131385176c3c9d9783b25047856a0dcebf6':
checkasm: aarch64: Clobber the stack before calling functions
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a05cc56124b4f1237f6355784de821e3290ddb44':
checkasm: arm/aarch64: Fix the amount of space reserved for stack parameters
Merged-by: James Almer <jamrial@gmail.com>
* commit '8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4':
lavf: use the new bitstream filter for extracting extradata
Merged-by: James Almer <jamrial@gmail.com>
* commit '89b35a139e838deeb32ec20d8d034c81014401d0':
lavc: add a bitstream filter for extracting extradata from packets
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f6e2f8a9ffda2247bffba991450990d075ea68e3':
hevcdec: move parameter set parsing into a separate header
Merged-by: James Almer <jamrial@gmail.com>
* commit '150c896a9e46b23b97debb0a5f66fbaeaa32f153':
hevcdec: split ff_hevc_diag_scan* declarations into a separate header
Merged-by: James Almer <jamrial@gmail.com>
* commit '645c6ff4231a75a71db58c8e6d06346068d2f949':
hevcdec: drop the prototype of a non-existing function
This commit is a noop. The prototype in question is not in our tree.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'c359d624d3efc3fd1d83210d78c4152bd329b765':
hevcdec: move decoder-independent declarations into a separate header
Merged-by: James Almer <jamrial@gmail.com>
* commit '6c31ba226968f12f898120dbb928dab34e03782b':
avformat/matroska: fix MatroskaVideoFieldOrder enum values
This commit is a noop, see dc781459cc
Merged-by: Clément Bœsch <u@pkh.me>
* commit '20b75970e43a030f959b17ff2dfd561174b6f24e':
file protocol: handle the file: protocol string in file_check
This commit is a noop, see 77015443a8
Merged-by: Clément Bœsch <u@pkh.me>
* commit '7d8d726be7dc46343ab1c98c339c1ed44bcb07c1':
rtmpproto: Don't include a client version in the unencrypted C1 handshake
Merged-by: Clément Bœsch <u@pkh.me>
* commit '9f23f77a532ca9c2b7dc4b5328bc413e4f6f5b56':
rtmpproto: Don't include the libavformat version as "clientid"
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c9527bf3444c5332fa04931d32997308784fc862':
Make the RELEASE file match with the most recent tag
This commit is noop.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '881477c77bb10c3c62fda111b0f1f3554968bc78':
swscale: Add the GBRAP12 output
Add GBRAP12 pixel format support
swscale: Enable GBRP12 output
swscale: x86: Add some forgotten 12-bit planar YUV cases
swscale: Add input support for 12-bit formats
This merge is noop, these commits are recrafted cherry-picks from
FFmpeg.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '1e93aa69a60815d1407a6c34d8da3f83ab193ad5':
Add GBRP12 pixel format support
This commit is a noop, see e9757066e1
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e7e5be8635c1cf0588d2a07e59374135de6da55a':
APIchanges: Expand the name of recently added pixel formats
This commit is a noop, we don't have this entry.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'eb542106029a9b28b4f76ff7c181eb4f542da9c4':
swscale: Add missing yuv444p12 swapping
This commit is a noop, these pixel formats were introduced long ago and
present in the switch case.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'cbd84b8a51aa656d71b7d6ed44bd89041ff081a8':
nvenc: Fix error log
This commit is a noop, the error message is correct in FFmpeg.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'da2848375a2e2121dad9f1e8cbd0ead4e3bf77d6':
nvenc: Force high_444 profile for 444 input
This commit is a noop, see 20abda6b62
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e4128c08d786eb5513578e8c6063671ba03226ab':
Revert "hevc: x86: Refactor IDCT macro declarations"
So apparently this was technically correct be reverted due to
authorship. Reverted as well in FFmpeg for now...
See http://lists.libav.org/pipermail/libav-devel/2016-October/079560.html
Merged-by: Clément Bœsch <u@pkh.me>
* commit '20abcaa273a6e77d0a2e1a98c643c73562c6f8f2':
configure: #include stdint.h as part of libxavs test
This commit is a noop, see 20c4fb2e01
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'be630b1e08ebe8f766b1798accd6b8e5e096f5aa':
d3d11va: Use the proper decoding slice index
This commit is a noop, see 9b462a0b9d
Merged-by: Clément Bœsch <u@pkh.me>
* commit '715f139c9bd407ef7f4d1f564ad683140ec61e6d': (23 commits)
vp9lpf/x86: make filter_16_h work on 32-bit.
vp9lpf/x86: make filter_48/84/88_h work on 32-bit.
vp9lpf/x86: make filter_44_h work on 32-bit.
vp9lpf/x86: make filter_16_v work on 32-bit.
vp9lpf/x86: make filter_48/84_v work on 32-bit.
vp9lpf/x86: make filter_88_v work on 32-bit.
vp9lpf/x86: make filter_44_v work on 32-bit.
vp9lpf/x86: save one register in SIGN_ADD/SUB.
vp9lpf/x86: store unpacked intermediates for filter6/14 on stack.
vp9lpf/x86: move variable assigned inside macro branch.
vp9lpf/x86: simplify ABSSUM_CMP by inverting the comparison meaning.
vp9lpf/x86: remove unused register from ABSSUB_CMP macro.
vp9lpf/x86: slightly simplify 44/48/84/88 h stores.
vp9lpf/x86: make cglobal statement more conservative in register allocation.
vp9lpf/x86: save one register in loopfilter surface coverage.
vp9lpf/x86: add ff_vp9_loop_filter_[vh]_44_16_{sse2,ssse3,avx}.
vp9lpf/x86: add ff_vp9_loop_filter_h_{48,84}_16_{sse2,ssse3,avx}().
vp9lpf/x86: add an SSE2 version of vp9_loop_filter_[vh]_88_16
vp9lpf/x86: add ff_vp9_loop_filter_[vh]_88_16_{ssse3,avx}.
vp9lpf/x86: add ff_vp9_loop_filter_[vh]_16_16_sse2().
...
All these commits are cherry-picks from FFmpeg. Maybe some slight
differences sneaked in but the Libav codebase still differs too much
with our own to make a proper diff. This merge is a noop.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '497c087939e32b26b792515d2dbc7e22561203f7':
avidec: Set palette alpha as fully opaque
This commit is a noop, see 64cafe340b
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bad4aad4037f59ba0ad656164be9ab8f7a0fa2d4':
avidec: Do not special case palette on big-endian
This commit is a noop, see 64cafe340b
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5a5df90d9c05d86d9b0564b8b40b6d64a324df5e':
vaapi_h265: Add main 10 encode support
This commit is a noop, see b9514756ba
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'eaaaabf6c93321cdb78bf61dc383cf515ec12e07':
hwcontext_vaapi: Enable P010 support
This commit is a noop, see 7e0623b70b
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5cc0057f4910c8c72421b812c8f337ef6c43696c':
lavu: remove the custom atomic API
This commit is a noop. The removal is postponed until all usages in
FFmpeg are dropped as well. A patchset is on discussion on the
mailing-list:
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209003.html
Merged-by: Clément Bœsch <u@pkh.me>
This supports retrieving the device from a provided hw_frames_ctx, and
automatically creating a hw_frames_ctx if hw_device_ctx is set.
The old API is not deprecated yet. The user can still use
av_vdpau_bind_context() (with or without setting hw_frames_ctx), or use
the API before that by allocating and setting hwaccel_context manually.
Cherry-picked from Libav commit 1a7ddba5.
(Adds missing APIchanges entry to the Libav version.)
Reviewed-by: Mark Thompson <sw@jkqxz.net>
This "reuses" the flags introduced for the av_vdpau_bind_context() API
function, and makes them available to all hwaccels. This does not affect
the current vdpau API, as av_vdpau_bind_context() should obviously
override the AVCodecContext.hwaccel_flags flags for the sake of
compatibility.
Cherry-picked from Libav commit 16a163b5.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
libavcodec/vaapi.h:58:1: warning: attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration [-Wignored-attributes]
(cherry picked from commit ed6a891c36)
Signed-off-by: Mark Thompson <sw@jkqxz.net>
* commit '59c70227405c214b29971e6272f3a3ff6fcce3d0':
pthread_frame: use atomics for frame progress
This commit is a noop, see b6587421c7
Merged-by: Clément Bœsch <u@pkh.me>
* commit '64a31b2854c589e4f27cd68ebe3bcceb915704e5':
pthread_frame: use atomics for PerThreadContext.state
This commit is a noop, see 7492626932
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'db2733256db323e4b88a34b135320f33274148e2':
pthread_frame: use a thread-safe way for signalling threads to die
This commit is a noop, see 4845f0720e
Merged-by: Clément Bœsch <u@pkh.me>
USE_ATOMICS is only set if there is no thread implementation enabled, in
which case you can't expect any lock mechanism from FFmpeg.
This is also conflicting with the incoming use of stdatomic.
* commit 'eb34d40354e2474517c9b9bd787e0dadc89c2a81':
Add a compat dummy stdatomic.h used when threading is disabled
Add a compat stdatomic.h implementation based on pthreads
Add a compat stdatomic.h implementation based on suncc atomics
Add a compat stdatomic.h implementation based on windows atomics
Add a compat stdatomic.h implementation based on GCC atomics
This merge is a noop, see:
41e891e89e Add a compat dummy stdatomic.h used when threading is disabled
74b5f10862 Add a compat stdatomic.h implementation based on pthreads
70faadc826 Add a compat stdatomic.h implementation based on suncc atomics
c91e72ed52 Add a compat stdatomic.h implementation based on windows atomics
3359eede8f Add a compat stdatomic.h implementation based on GCC atomics
Merged-by: Clément Bœsch <u@pkh.me>
* commit '13f5d2bf75b95a0bfdb9940a5e359a719e242bed':
configure: check for stdatomic.h
This commit is a noop, see 6a4e24280d
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b015872c0d0823e70776e98b865509ec1287e2f6':
huffyuvdsp: Enable the altivec code for PPC little-endian as well
This commit is a noop, see 902ce2a6c4 and
libavcodec/ppc/lossless_videodsp_altivec.c
Merged-by: Clément Bœsch <u@pkh.me>
* commit '1d25a86902946dbc80bb3a38e61755181ca3af7b':
huffyuvdsp: Reenable PPC optimizations
This commit is a noop, see 6596b34954
Merged-by: Clément Bœsch <u@pkh.me>
* commit '22c3ab18646924ce24dc6017a9e882ff69689e40':
checkasm: Add test for huffyuvdsp add_bytes
huffyuvdsp is renamed to llviddsp to be consistent with our codebase.
Note: af607b7e07 wasn't actually required for this test since this
commit is not actually testing huffyuvdsp.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f6772e9bf8251d3943f52f6f34d97d2ce6c4b8af':
avconv: make sure the filtergraph is freed on init failure
This commit is a noop, see 16abc10b09
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd10102d23c9467d4eb84f58e0cd12be284b982f6':
avconv: set the encoding framerate when the output is CFR
This commit is a noop, see 8db301dead
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5bf2454e7cb03609b3ec1a3cf4c22427fe5f8e36':
h264dec: support broken files with mp4 extradata/annex b data
This commit is a noop, see 93b89868e1
The sample pointed out on
https://github.com/HandBrake/HandBrake/issues/339 decodes fine in
FFmpeg.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '2124711b950b03c582a119c75f52a87acc32d6ec':
hwcontext_vaapi: add a quirk for the missing MemoryType attribute
This commit is a noop, see 775a8477b7
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a9ba59591ed509fb7e6decfde8da4cbfd4ddf4b8':
ac3dsp: Add some special-case handling for the C downmix function
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8ea35af7620e4f73f9e8c072e1c0fac9a04ec161':
avio: add a new flag for marking streams seekable by timestamp
Merged-by: James Almer <jamrial@gmail.com>
* commit '8d1267932ca9c2e343ef303349101bab6681d02e':
x86/h264_weight: use appropriate register size for weight parameters
This commit is a noop, see 5ae0ad001a
Merged-by: James Almer <jamrial@gmail.com>
* commit '2caa93b813adc5dbb7771dfe615da826a2947d18':
mpegaudiodsp: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit '15b4f494fc6bddb8178fdb5aed18b420efc75e22':
mss*: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a339e919cad1ab0125948f0dd9d49f6cb590db89':
ea: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit 'ba479f3daafc7e4359ec1212164569ebe59f0bb7':
hevc: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e4a94d8b36c48d95a7d412c40d7b558422ff659c':
h264chroma: Change type of stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
* commit '2ec9fa5ec60dcd10e1cb10d8b4e4437e634ea428':
idct: Change type of array stride parameters to ptrdiff_t
Merged-by: James Almer <jamrial@gmail.com>
Aliased compressed AAC bytes are almost certainly not meaningful SBR
data. In the wild this causes harsh artifacts switching HE-AAC streams
that don't have SBR headers aligned with segment boundaries.
Turning off SBR falls back to a default set of upsampling parameters
that can function as a sort of error concealment. This is consistent
with how the decoder handles other sorts of errors.
* commit '956a54129db522998a5abae869568dae2c9774cb':
vaapi_h264: Set max_num_ref_frames to 1 when not using B frames
vaapi_encode: Sync to input surface rather than output
vaapi_encode: Check packed header capabilities
vaapi_encode: Refactor initialisation
This merge is a noop, see:
ee1d04f970 vaapi_h264: Set max_num_ref_frames to 1 when not using B frames
94f446c628 vaapi_encode: Sync to input surface rather than output
478a4b7e6d vaapi_encode: Check packed header capabilities
c8241e730f vaapi_encode: Refactor initialisation
Merged-by: Clément Bœsch <u@pkh.me>
* commit '67d28f4a0fbb52d0734ca3682b85035e96d294fb':
examples/output: switch to the new encoding API
This commit is a noop, our examples are different. Still, we need to
update them to the new API, so doc/libav-merge.txt is updated.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'de2ae3c1fae5a2eb539b9abd7bc2a9ca8c286ff0':
lavc: add clobber tests for the new encoding/decoding API
The merge only re-order what we already have.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6c09af7e46a5a1ada67ffe832f7895cf2749130b':
APIchanges: fix a typo in the version number
This commit is a noop (typo is not present in FFmpeg).
Merged-by: Clément Bœsch <u@pkh.me>
* commit '0e8d1fc1f013eb805a7b66656d9452bcbca36d22':
lavu: Bump version for the 12bit Planar YUV support
pixfmt: Add yuv444p12 pixel format
pixfmt: Add yuv422p12 pixel format
pixfmt: Add yuv420p12 pixel format
This merge is a noop, we already have all these pixel formats.
Merged-by: Clément Bœsch <u@pkh.me>
It was done on a whim because of the FATE header check and was actually
meant to be removed before pushing.
Also, nobody in review spotted it.
Reviewed-by: wm4
* commit '2b5b1e1e9b89063d352e2efed014f9d761b85032':
swscale: Rename is9_OR_10 to match what it does
This commit is a noop. We use isNBPS() in these places instead since
d736b52a04. is9_15BPS() wouldn't be a good name in our codebase due to
supporting only up to 14 (see 2ea585b8e3).
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e87a501e7d03ac68b58520108fe24ad9d0b36765':
swscale: Update bitdepth range check
This commit is a noop.
Up to 14 bits is supported since fa36f33422. This commits pushes the
limit to 15 bits but we don't seem to have pixel formats that enters in
that category.
12:03 <ubitux> so what's your opinion? should we move to 15 even if unused currently to make it consistent with libav and the function names, or keep our 14 suggesting there might be an issue with 15?
12:05 <ubitux> (functions are called hScale8To15_c, hScale16To15_c, ff_hscale8to15, ...)
12:06 <michaelni> I prefer to keep 14 until theres a case that allows us to test this and i suspect it will not work with 15 at least not all the code
Merged-by: Clément Bœsch <u@pkh.me>
libavcodec now automatically serializes decoding for hwaccels which
are not thread-safe. This means API users, which rely on the libavcodec
native software fallback mechanism, can now simply enable threading
without running into problems.
Certain hardware decoding APIs are not guaranteed to be thread-safe, so
having the user access decoded hardware surfaces while the decoder is
running in another thread can cause failures (this is mainly known to
happen with DXVA2).
For such hwaccels, only allow the decoding thread to run while the user
is inside a lavc decode call (avcodec_send_packet/receive_frame).
Merges Libav commit d4a91e65.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
This improves commit 59c7022740.
In ff_thread_report_progress(), the fast code path can load
progress[field] with the relaxed memory order, and the slow code path
can store progress[field] with the release memory order. These changes
are mainly intended to avoid confusion when one inspects the source code.
They are unlikely to have measurable performance improvement.
ff_thread_report_progress() and ff_thread_await_progress() form a pair.
ff_thread_await_progress() reads progress[field] with the acquire memory
order (in the fast code path). Therefore, one expects to see
ff_thread_report_progress() write progress[field] with the matching
release memory order.
In the fast code path in ff_thread_report_progress(), the atomic load of
progress[field] doesn't need the acquire memory order because the
calling thread is trying to make the data it just decoded visible to the
other threads, rather than trying to read the data decoded by other
threads.
In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
atomic_init().
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Merges Libav commit 343e2833.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
When decoding with threads enabled, the get_format callback will be
called with one of the per-thread codec contexts rather than with the
outer context. If a hwaccel is in use too, this will add a reference
to the hardware frames context on that codec context, which will then
propagate to all of the other per-thread contexts for decoding. Once
the decoder finishes, however, the per-thread contexts are not freed
normally, so these references leak.
Merges Libav commit fd0fae60.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This patch deprecates anything that has to do with merging/splitting
side data. Automatic side data merging (and splitting), as well as all
API symbols involved in it, are removed completely.
Two FF_API_ defines are dedicated to deprecating API symbols related to
this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in
libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates
AVFMT_FLAG_KEEP_SIDE_DATA in libavformat.
Since it was claimed that changing the default from merging side data to
not doing it is an ABI change, there are two additional FF_API_ defines,
which stop using the side data merging/splitting by default (and remove
any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec,
and FF_API_LAVF_MERGE_SD in libavformat.
It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD
are quickly defined to 0 in the next ABI bump, while the API symbols are
retained for a longer time for the sake of compatibility.
AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for
most of the time it will still be defined. Keep in mind that no code
exists that actually tries to unset this flag for any reason, nor does
such code need to exist. Code setting this flag explicitly will work as
before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once
side data merging has been removed from libavformat.
In order to avoid that anyone in the future does this incorrectly, here
is a small guide how to update the internal code on bumps:
- next ABI bump (probably soon):
- define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it
- define FF_API_MERGE_SD to 0, and remove all code covered by it
- next API bump (typically two years in the future or so):
- define FF_API_LAVF_KEEPSIDE_FLAG to 0, and remove all code covered
by it
- define FF_API_MERGE_SD_API to 0, and remove all code covered by it
This forces anyone who actually wants packet side data to temporarily
use deprecated API to get it all. If you ask me, this is batshit fucked
up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be
set by default was rejected as an ABI change, so I'm going all the way
to get rid of this once and for all.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
This filter does not implement all features of MPEG7. Missing features:
- compression of signature files
- work only on (cropped) parts of the video
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '70de2ea4261f860457a04e3d0c58c5543f403325':
nvenc: Extended rate-control support as provided by SDK 7
This commit is a noop, see facc19ef06
Merged-by: Clément Bœsch <u@pkh.me>
* commit '358c887a9fa0fb2e7ce089eaea71ab924a3e47a7':
nvenc: Add support for high bitdepth
This commit is a noop, see d1bf8a3aa8
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e02e2515b24bfc37ede6ca1744696230be55e50b':
nvenc: Add some easier to understand presets that match x264 terminology
This commit is a noop, see a81b000a39 and
faffff88c2.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '352741b5ead1543d775ccf6040f33023e4491186':
nvenc: Make sure that enum and array index match
This commit is a noop, see a81b000a39
Merged-by: Clément Bœsch <u@pkh.me>
* commit '12004a9a7f20e44f4da2ee6c372d5e1794c8d6c5':
audiodsp/x86: yasmify vector_clipf_sse
audiodsp: reorder arguments for vector_clipf
Merged the version from Libav after a discussion with James Almer on
IRC:
19:22 <ubitux> jamrial: opinion on 12004a9a7f20e44f4da2ee6c372d5e1794c8d6c5?
19:23 <ubitux> it was apparently yasmified differently
19:23 <ubitux> (it depends on the previous commit arg shuffle)
19:24 <ubitux> i don't see the magic movsxdifnidn in your port btw
19:24 <ubitux> it's a port from 1d36defe94
19:25 <jamrial> seems better thanks to said arg shuffle
19:25 <jamrial> the loop is the same, but init is simpler
19:25 <jamrial> probably worth merging
19:25 <ubitux> OK
19:25 <ubitux> thanks
19:26 <jamrial> curious they didn't make len ptrdiff_t after the previous bunch of commits, heh
19:26 <ubitux> yeah indeed
Both commits are merged at the same time to prevent a conflict with our
existing yasmified ff_vector_clipf_sse.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'eea9857bfd6925d0c34382c00b971ee6df12ad44':
blockdsp: drop the high_bit_depth parameter
This commit is a noop, see 562ba4a827
Merged-by: Clément Bœsch <u@pkh.me>
* commit '340f12f71207513672b5165d810cb6c8622c6b21':
hwcontext_cuda: Add P010 and YUV444P16 pixel format
This commit is a noop, we already have P010 and P016.
18:52 <@BtbN> Adding AV_PIX_FMT_YUV444P16 won't hurt, but doesn't gain anything.
18:53 <@BtbN> I'd say just noop it. If we'll ever need it, it will be added in turn.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '75d98e30afab61542faab3c0f11880834653bd6b':
audiodsp/x86: clear the high bits of the order parameter on 64bit
Merged-by: Clément Bœsch <u@pkh.me>
* commit '1d6c76e11febb58738c9647c47079d02b5e10094':
audiodsp/x86: fix ff_vector_clip_int32_sse2
No functionnal changes, only cosmetics. This issue was fixed in
9a9e2f1c8a.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'de64dd13cbd47fd54334b6aa2a2cd3c7c36daae2':
avcodec: Add the extended pixel format profile for HEVC
This commit is a noop, see 5a41999d81
Merged-by: Clément Bœsch <u@pkh.me>
* commit '136f55207521f0b03194ef5b55ba70f1635d6aee':
mpegvideo_motion: Handle edge emulation even without unrestricted_mv
This commit is a noop, see 7b1e0beb2d
Merged-by: Clément Bœsch <u@pkh.me>
* commit '15fcf6292ed79be274c824fedb099c2665f4cc15':
build: remove hardcoded name of version header
This commit is noop, our version.sh is completely different.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8c201dde0ab62e5cd581d958e78d7609e0ba710d':
build: doc: more fine-grained dependencies for generated texi files
This commit is a noop, we have a different system for handling the
documentation.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'bc7399934def210c2a84ea51375d50f79c676c96':
libdc1394: Distinguish between enumeration errors and no cameras found
This commit is a noop, see 384251daff
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'df3795025337479a639cb3cd26c93a4e82ccd4db':
rtsp: Fix a crash with the RTSP muxer
This commit is a noop, see f8a13c7213
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3a9662af6c741f8354b1ca97642f78f5c02e2e8f':
vaapi_h264: Fix HRD bit_rate/cpb_size scaling
This commit is a noop, see 06d73d002e
Merged-by: Clément Bœsch <u@pkh.me>
* commit '7081620aca36e616ea96f71fd71d2703e3abae09':
hwcontext_vdpau: Fix missing subscripts
This commit is a noop, see f7e9275f83
Merged-by: Clément Bœsch <u@pkh.me>
Regression from 4563a86f01.
Both need stdint.h included before the respective x264.h and xavs.h.
Old require() used different, separate checks that didn't actually
need stdint.h to work. require2()'s (now require) check_func_headers()
does include stdint.h but only after the custom headers.
For libxavs this would also be consequently fixed by libav's
commit 20abcaa273 which wasn't merged yet.
* commit 'ab3554e1a7c04a5ea30f9c905de92348478ef7c8':
configure: Drop check_lib()/require() in favor of check_lib2()/require2()
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6ce93757ee6b81fe727bfdc9f546fd0ddf9139c3':
ppc: Update #endif comments
This commit is mostly a noop as we seem to support PPC LE (see
902ce2a6c4). Only the h264 chunks are
updated.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '75d642a944d5579e4ef20ff3701422a64692afcf':
vaapi_vp8: Explicitly include libva vp8 decode header
vaapi_decode: Ignore the profile when not useful
lavc/vaapi: Add VP8 decode hwaccel
vp8: Add hwaccel hooks
This merge is a noop as these commits are already under review on the
mailing list. doc/libav-merge.txt is updated to track its progress.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '52730e0f867fe77b7d2353d8b44e92edb7079ca5':
iir_filter: Change type of array stride parameters to ptrdiff_t
The merge also updates the MIPS code and drop the extra log.h include.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '3aa9d37d03da3c9b482d19b3988659287815280e':
build: Fix directory dependencies of tests/pixfmts.mak target
This might not be necessary given our mkdirs in the configure, but it
probably doesn't hurt.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '0e5dde739943168d6f61d3fb40b3f622e7abfeff':
configure: Fix --disable-pod2man / --disable-texi2html
This commit is a noop, we have dedicated documentation option for this
purpose.
Merged-by: Clément Bœsch <u@pkh.me>
The configure has the --disable-manpages option for this purpose, and
--disable-pod2man is currently ignored due to that. This is also
consistent with the other documentation options.
* commit '2610c9528f86286e4c6e174411a26ff5b4815cde':
configure: Move initial VAAPI check to a more sensible place
This commit is a noop, see 17989dcf54
Merged-by: Clément Bœsch <u@pkh.me>
* commit '4fb311c804098d78e5ce5f527f9a9c37536d3a08':
Drop memalign hack
Merged, as this may indeed be uneeded since
46e3936fb0.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f01f7a7846529b7c3ef343f117eaa2c0a1457af0':
hwcontext_dxva2: use the special UC copy for downloading frames
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd7bc52bf456deba0f32d9fe5c288ec441f1ebef5':
imgutils: add a function for copying image data from GPU mapped memory
Merged-by: Clément Bœsch <u@pkh.me>
* commit '851960f6f8cf1f946fe42fa36cf6598fac68072c':
lavc: Remove old vaapi decode infrastructure
avconv_vaapi: Convert to use hw_frames_ctx only
vaapi_mpeg4: Convert to use the new VAAPI hwaccel code
vaapi_vc1: Convert to use the new VAAPI hwaccel code
vaapi_mpeg2: Convert to use the new VAAPI hwaccel code
vaapi_h264: Convert to use the new VAAPI hwaccel code
lavc: Rewrite VAAPI decode infrastructure
This merge is a noop, these commits have already been cherry-picked.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '72eba6558ee4f10239ba3f472c0b033ec70082a7':
wmavoice: Simplify GetBitContext initialization
This commit is a noop. We don't have that code anymore since
3deb4b54a2.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '728e80cd2e1d4b7c3e26489efcd77bd7a9e84a99':
High Definition Compatible Digital (HDCD) decoder filter, using libhdcd
This commit is a noop, we have that code natively.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '95f80293456d9d4b1b096621260c38bc90325ec0':
avprobe: Fix memory leak
This commit is a noop, ffprobe is not affected.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '8db804e8f549d5b86a1edf62736e0ef80f160da9':
mov: Remove old b-frame/video delay heuristic
This commit is a noop, see 425be3c810
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'eb96505b761eb02b6a3efc76d854afa6a41941ff':
mov: Remove ancient heuristic hack
This commit is a noop, see 04f8d31287
Merged-by: Clément Bœsch <u@pkh.me>
Fixes: 864/clusterfuzz-testcase-4774385942528000
See: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: 2147483647 - -14133 cannot be represented in type 'int'
See: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: -9 - 2147483647 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This work is sponsored by, and copyright, Google.
This avoids loading and calculating coefficients that we know will
be zero, and avoids filling the temp buffer with zeros in places
where we know the second pass won't read.
This gives a pretty substantial speedup for the smaller subpartitions.
The code size increases from 21512 bytes to 31400 bytes.
The idct16/32_end macros are moved above the individual functions; the
instructions themselves are unchanged, but since new functions are added
at the same place where the code is moved from, the diff looks rather
messy.
Before:
vp9_inv_dct_dct_16x16_sub1_add_10_neon: 284.6
vp9_inv_dct_dct_16x16_sub2_add_10_neon: 1902.7
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 1903.0
vp9_inv_dct_dct_16x16_sub8_add_10_neon: 2201.1
vp9_inv_dct_dct_16x16_sub12_add_10_neon: 2510.0
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2821.3
vp9_inv_dct_dct_32x32_sub1_add_10_neon: 1011.6
vp9_inv_dct_dct_32x32_sub2_add_10_neon: 9716.5
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 9704.9
vp9_inv_dct_dct_32x32_sub8_add_10_neon: 10641.7
vp9_inv_dct_dct_32x32_sub12_add_10_neon: 11555.7
vp9_inv_dct_dct_32x32_sub16_add_10_neon: 12499.8
vp9_inv_dct_dct_32x32_sub20_add_10_neon: 13403.7
vp9_inv_dct_dct_32x32_sub24_add_10_neon: 14335.8
vp9_inv_dct_dct_32x32_sub28_add_10_neon: 15253.6
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16179.5
After:
vp9_inv_dct_dct_16x16_sub1_add_10_neon: 282.8
vp9_inv_dct_dct_16x16_sub2_add_10_neon: 1142.4
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 1139.0
vp9_inv_dct_dct_16x16_sub8_add_10_neon: 1772.9
vp9_inv_dct_dct_16x16_sub12_add_10_neon: 2515.2
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2823.5
vp9_inv_dct_dct_32x32_sub1_add_10_neon: 1012.7
vp9_inv_dct_dct_32x32_sub2_add_10_neon: 6944.4
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 6944.2
vp9_inv_dct_dct_32x32_sub8_add_10_neon: 7609.8
vp9_inv_dct_dct_32x32_sub12_add_10_neon: 9953.4
vp9_inv_dct_dct_32x32_sub16_add_10_neon: 10770.1
vp9_inv_dct_dct_32x32_sub20_add_10_neon: 13418.8
vp9_inv_dct_dct_32x32_sub24_add_10_neon: 14330.7
vp9_inv_dct_dct_32x32_sub28_add_10_neon: 15257.1
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16190.6
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/aarch64/vp9itxfm_16bpp_neon.o from
26288 to 21512 bytes.
This gives a small slowdown of a couple of tens of cycles, but makes
it more feasible to add more optimized versions of these transforms.
Before:
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 1887.4
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2801.5
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 9691.4
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16154.9
After:
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 1899.5
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 2827.2
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 9714.7
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 16175.9
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/arm/vp9itxfm_16bpp_neon.o from
17500 to 14516 bytes.
This gives a small slowdown of a couple tens of cycles, up to around
150 cycles for the full case of the largest transform, but makes
it more feasible to add more optimized versions of these transforms.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 4237.4 3561.5 3971.8 2525.3
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 6371.9 5452.0 5779.3 3910.5
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22068.8 17867.5 19555.2 13871.6
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37268.9 38684.2 32314.2 23969.0
After:
vp9_inv_dct_dct_16x16_sub4_add_10_neon: 4375.1 3571.9 4283.8 2567.2
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 6415.6 5578.9 5844.6 3948.3
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22653.7 18079.7 19603.7 13905.3
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37593.2 38862.2 32235.8 24070.9
Signed-off-by: Martin Storsjö <martin@martin.st>
Keep the idct32 coefficients in narrow form in q6-q7, and idct16
coefficients in lengthened 32 bit form in q0-q3. Avoid clobbering
q0-q3 in the pass1 function, and squeeze the idct16 coefficients
into q0-q1 in the pass2 function to avoid reloading them.
The idct16 coefficients are clobbered and reloaded within idct32_odd
though, since that turns out to be faster than narrowing them and
swapping them into q6-q7.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22653.8 18268.4 19598.0 14079.0
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37699.0 38665.2 32542.3 24472.2
After:
vp9_inv_dct_dct_32x32_sub4_add_10_neon: 22270.8 18159.3 19531.0 13865.0
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 37523.3 37731.6 32181.7 24071.2
Signed-off-by: Martin Storsjö <martin@martin.st>
Align the second/third operands as they usually are.
Due to the wildly varying sizes of the written out operands
in aarch64 assembly, the column alignment is usually not as clear
as in arm assembly.
This is cherrypicked from libav commit
7995ebfad1.
Signed-off-by: Martin Storsjö <martin@martin.st>
In the half/quarter cases where we don't use the min_eob array, defer
loading the pointer until we know it will be needed.
This is cherrypicked from libav commit
3a0d5e206d.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reduces the number of lines and reduces the duplication.
Also simplify the eob check for the half case.
If we are in the half case, we know we at least will need to do the
first three slices, we only need to check eob for the fourth one,
so we can hardcode the value to check against instead of loading
from the min_eob array.
Since at most one slice can be skipped in the first pass, we can
unroll the loop for filling zeros completely, as it was done for
the quarter case before.
This allows skipping loading the min_eob pointer when using the
quarter/half cases.
This is cherrypicked from libav commit
98ee855ae0.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '4ab496261b12e20ef293b7adca4fcaef1a67c538':
libvpx: Cast a pointer to const to squelch a warning
This commit is a noop, see 09b3bbe605
Merged-by: James Almer <jamrial@gmail.com>
* commit '802727b538b484e3f9d1345bfcc4ab24cfea8898':
vp8: Update some assembly comments left unchanged in bd66f073fe
Merged-by: James Almer <jamrial@gmail.com>
* commit '6755eb5b212384e0599f7f2c5de42df49fff57de':
mss12: validate display dimensions
This commit is a noop, see ee9151b616
Merged-by: Clément Bœsch <u@pkh.me>
* commit '33f10546ec012ad4e1054b57317885cded7e953e':
vc1: check that slices have a positive height
This commit is a noop, see e985cfd18b
Merged-by: Clément Bœsch <u@pkh.me>
* commit '09b23786b3986502ee88d4907356979127169bdd':
pcx: use the bytestream2 API for reading from input
This commit is a noop, see 8cd1c0febe
Merged-by: Clément Bœsch <u@pkh.me>
* commit '221402c1c88b9d12130c6f5834029b535ee0e0c5':
pcx: check that the packet is large enough before reading the header
See 8cd1c0febe
Merged-by: Clément Bœsch <u@pkh.me>
* commit '15ee419b7abaf17f8c662c145fe93d3dbf43282b':
pcx: properly pad the scanline
This commit is a noop, see d24de4596c
Merged-by: Clément Bœsch <u@pkh.me>
* commit '796dca027be09334d7bbf4f2ac1200e06bb054cb':
alac: do not return success if nothing was decoded
See e11983bda0
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f5d46d332258dcd8ca623019ece1d5e5bb74142b':
vmnc: check that subrectangles fit into their containing rectangles
See 6ba02602aa
This merge keeps our condition against w-i and h-j instead of bw and bh.
One may be more correct than the other, but I'm keeping our behaviour
here for safety reasons.
The style and formatting is merged.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b53d8c3ccfeff77874f5ca7c68136b6d87a0a69c':
mjpegdec: Drop disabled code
The last chunk is replaced with a comment describing the structure.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'aa37d2bf4505afc106e2a23c44afc722bb204a8e':
swscale: Kill non-compiling disabled cruft
The isGray() chunk is not merged as an alternative patch actually fixing
the dead code is currently under review on the mailing-list.
The SWS_X chunk is merged, with an additional cosmetic.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '00a0419c7f7ebce9010cba93b7ff67c9f1165815':
mathematics: Kill non-compiling disabled cruft
This commit is a noop, see 1e1513d01a
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5a667322f5cb0e77c15891fc06725c19d8f3314f':
vaapi_vc1: Remove redundant version check
This commit is a noop, see d07d01bcce
Merged-by: Clément Bœsch <u@pkh.me>
* commit '01d6f84f49a55fd591aa120960fce2b9dba92d0d':
vaapi_vc1: Constify pointers
This commit is a noop, see 845c2c140b
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ee9061293e925916fe2e0b7c08fbbd1f981b1d29':
vaapi_mpeg2: Constify pointers
This commit is a noop, see 6bc2808c41
Merged-by: Clément Bœsch <u@pkh.me>
* commit '03adfe913062c6995136eb1ca51152b6d596c0f4':
vaapi_h264: Constify pointers
This commit is a noop, see d0897da924
Merged-by: Clément Bœsch <u@pkh.me>
* commit '121f34d5f0c8d7d376829a467590fbbe4c228f4f':
hwcontext_vaapi: Try the first render node as the default DRM device
This commit is a noop, see 8d47d84075
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f6d2fed811dea36c4ebaf991927e44c78eb0aca5':
avconv: Make sure that inputless filtergraphs are configured
This commit is a noop. Related code is pretty different in ffmpeg, and
-filter_complex testsrc works.
See also af1761f7b5
Merged-by: Clément Bœsch <u@pkh.me>
* commit '602abe77b02f9702c18c2787d208fcfc9d94b70f':
avconv: Check the fifo allocation
This commit is a noop, see af1761f7b5
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'f2143c57b6a61fef382f3128138d8558a9bdecee':
vp9: reindent after last commit
vp9: add frame threading
vp9: allocate 'b', 'block/uvblock' and 'eob/uveob' dynamically.
vp9: split last/cur_frame from the reference buffers.
This commit is a noop, we already have all these changes. Again, we will
need in the future to analyse the tiny differences between the two
repository on the vp9 files. But in the current state, it's a real pain
to do at every commit due to the huge differences (such as files split
and cosmetics).
Merged-by: Clément Bœsch <u@pkh.me>
* commit '04763c6f87690b31cfcd0d324cf36a451531dcd0':
h264_direct: use the reference mask from the actual reference
This commit is a noop, see d8151a7e94
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e9bfff1cc66c85b91b262c41e8aa5e8685606225':
lavc: free buffer_frame/pkt on avcodec_open2() failure
This commit is a noop, see 27adf9f9cd.
Only reordered to reduce diff.
Merged-by: Clément Bœsch <u@pkh.me>
The typeof keyword is apparently not available when using the -std=c99 option.
Fixes the use of C11 atomic functions with old GCC.
Reviewed-by: Muhammad Faiz <mfcc64@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Not used by anything at all since we don't auto insert lavr filters.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
use fltp when doing s32 -> s32 resampling
because s32p has no simd optimization
benchmark:
old 17.913s
new 7.584s (use fma3)
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
These values are defined to be 32bit in the specification,
so it makes more sense to store them as fixed width.
Based on a patch by Micahel Niedermayer <michael@niedermayer.cc>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This field is of little value, and interferes with testing side data,
since sizes can be different on multiple architectures.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit '0638b99cdba52554691fc668d9e477bc184c7a33':
aiff: Skip padding byte for odd-sized chunks
Also removes to odd-size checks from get_aiff_header and get_meta to use
the generic path introduced by the original commit.
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.
Adds an internal helper function for bitrate guessing.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
when set_compensation is called with zero sample_delta,
compensation does not happen (because dst_incr == ideal_dst_incr)
but compensation_distance is set
regression since 01ebb57c03
Found-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Reflects the actual code and silences a gcc warning:
ffprobe.c:1797:42: warning: passing argument 1 of 'av_spherical_tile_bounds' discards 'const' qualifier from pointer target type
* commit '0df4801105d84883071b0978cb3afc7cd5184ce8':
vp9: make mv bounds 32bit.
This commit is a noop, see 024fac5cd4
Merged-by: Clément Bœsch <u@pkh.me>
* commit '24a362569bff1d4161742fffaca80a4a4428be8a':
buffer: fix av_buffer_realloc() when the data is offset wrt buffer start
Merged-by: Clément Bœsch <u@pkh.me>
Reflects the actual code and silences a gcc warning:
libavcodec/utils.c:2102:36: warning: passing argument 1 of 'av_packet_get_side_data' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
* commit 'e99ecda55082cb9dde8fd349361e169dc383943a':
checkasm: add vp9 MC tests.
vp9mc/x86: sse2 MC assembly.
vp9mc/x86: add AVX and AVX2 MC
vp9mc/x86: rename ff_* to ff_vp9_*
vp9mc/x86: rename ff_avg[48]_sse to ff_avg[48]_mmxext
vp9mc/x86: simplify a few inits.
vp9mc/x86: add 16px functions (64bit only).
Noop (aside from a formatting comment in vp9mc.asm). We already have all
of this. We should consider making a final diff between the two projects
when the dust comes down.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '89466de4aeaf5e359489b81b8a9920a2bc7936d6':
vp9/x86: rename vp9dsp to vp9mc
File was already renamed, only the top description is updated.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '63ac8e2d93080b74f6be32c7c3c1a1e44aacf34e':
lavu: add LOCAL_ALIGNED_32
This commit is a noop, see 25d5ea6d5a
Merged-by: James Almer <jamrial@gmail.com>
* commit 'd3e4d406b020b0464486318aceda08bd8f69ca41':
h264dec: reset nb_slice_ctx_queued for hwaccel decoding
This commit is a noop, see 7448019890
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e5b019725f53b79159931d3a7317107cbbfd0860':
m4vdec: Check for non-startcode 00 00 00 sequences in probe
This commit is a noop, see 7c1835c52a
Merged-by: James Almer <jamrial@gmail.com>
* commit '3ccec334b8502701e72ef13bed25913c3578022e':
sbrdsp: Move a misplaced #endif directive to the right spot
Merged-by: James Almer <jamrial@gmail.com>
* commit 'e723dce6f8ba1e8260433b6ecfe5a3262f4c7a99':
dvbsubdec: Use NULL instead of 0 as pointer value
This commit is a noop. The affected code isn't in our tree.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'fc94a1acc27ab7296edce3fa81ef36691af5c134':
Revert "libavutil: Use an intermediate variable in AV_COPY*U"
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit '9806b9ab5c7fb2ac5efd8ffa8713fea0c5fd218d':
Revert "Don't use expressions with side effects in macro parameters"
This commit is a noop.
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f79d847400d218cfd0b95f10358fe6e65ec3c9c4':
intreadwrite: Use the __unaligned keyword on MSVC for ARM and x86_64
Merged-by: James Almer <jamrial@gmail.com>
* commit '230b1c070baa3b6d4bd590426a365b843d60ff50':
intreadwrite: Add intermediate variables in the byteswise AV_W*() macros
Mostly a noop. Merged for cosmetic purposes.
See d83ff76ca0
Merged-by: James Almer <jamrial@gmail.com>
* commit '014773b66bdff4de24f384066d1a85d2a5bb6774':
libavutil: Use an intermediate variable in AV_COPY*U
This commit is a noop. It would be reverted in a future merge either
way.
Merged-by: James Almer <jamrial@gmail.com>
* commit '25bacd0a0c32ae682e6f411b1ac9020aeaabca72':
Don't use expressions with side effects in macro parameters
This commit is a noop. It would be reverted in a future merge either
way.
Merged-by: James Almer <jamrial@gmail.com>
Benchmarks with START_TIMER indicate that the code is faster with unsigned, (that is
with the patch), there was quite some fluctuation in the numbers so this may be just
random
Fixes: 811/clusterfuzz-testcase-6465493076541440
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libnpp was erroneously grouped up with libfdk-aac and openssl to check
if --enable-nonfree wasn't passed only with --enable-gpl in
9f28db47ac. The latter two are compatible
with LGPL, libnpp is not.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '7ebdffc353f3f0827864e8e3461fdc00cc243b14':
dxv: Check to make sure we don't overrun buffers on corrupt inputs
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'e328178da90f44690e0076f4dbfd16da9175f441':
qsvdec: only access hwaccel_context is the pixel format is QSV
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5ebef79abecc3ffcc4ab0d46e203d13b068107c9':
Fix instances of broken indentation found by gcc 6
Noop, see 21d3f0c02, 6089c44a2
Merged-by: Clément Bœsch <u@pkh.me>
* commit '2ac00d2d1d51047c6ce69d5fbe1a08392d142658':
mov: Validate the ID number
This commit is a noop as the modified check is not present in FFmpeg.
See d30870cc73.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a115eb9e750543f1d8bf951414d291069bf396c2':
mimic: do not release the newly obsolete reference at the end of decoding
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'ae90119c6701fa09ff747cca35238e36b2d2ab2f':
configure: Simplify license incompatibility check
An extra GPLV3 list is added for libsmbclient as having it in both GPL
and VERSION3 lists would cause a duplicate in the final config list.
Also, for consistency, libnpp is treated the same as the other nonfree
component (libfdk_aac and openssl).
Merged-by: Clément Bœsch <u@pkh.me>
add kVTCompressionPropertyKey_DataRateLimits support by rc_max_bitrate
Reviewed-by: Rick Kern <kernrj@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
* commit 'e46a6fb7732a7caef97a916a4f765ec0f779d195':
avconv: Check that muxing_queue exists before reading from it
Mostly noop. This was fixed in FFmpeg in 7f7c494a3.
The merge makes the cosmetics match but does not include the weird
av_log().
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '100fb0ddfda958da70f98feac81f924c02483789':
configure: Allow detecting and using LLVM lld-link as linker for windows
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '56af0bc10f49654b5b5f3efe82c69a13bf15fc8b':
configure: Check for strtoll and redirect to _strtoi64 in the msvcrt block
Also includes _strtoui64 in the check.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'b183abfb5b6366b177cf44f244c66156257a6fd6':
vpx: Support color range
Decoder chunk not merged as the framework automatically copies avctx
color range to the frame color range. And we already set the avctx field
since cbcc88c039.
Merged-by: Clément Bœsch <cboesch@gopro.com>
Preparation for potentially disabling merged side data by default in the
libs. Do this in particular because it affects fate tests.
The changed tests either reflect added packet side data, or the changed
packet size due to merged side data removal reducing the packet size.
The current form of the messages indicating matches in the white
or black lists seems to be a bit too much relying on context.
Make the messages more explicit.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Fixes: 755/clusterfuzz-testcase-5369072516595712
See: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_direct: Fix runtime error: signed integer overflow: 2147483647 - -14133 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
the SECOND_LEVEL* flags process and name is too long
extract all of them output to funtions, make code clear
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
so tsf option in aresample will have effect
previously tsf/internal_sample_format had no effect
fate is updated
s32p previously used fltp internally
dblp previously used fltp/dblp internally
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Add missing return value checks to suppress build warning and
remove noop ff_formats_unref() calling.
Note: most filters using ff_formats_ref() didn't have a suitable
error handling, it's a potential memory leak issue.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
* commit 'ad71d3276fef0ee7e791e62bbfe9c4e540047417':
lavfi: add a QSV deinterlacing filter
Minor fixup for lavfi differences.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '0956fd460681e8ccbdae19f135f0d3970bf95c2f':
qsvenc: do not re-execute encoding on all positive status codes
Noop, see fb240a6276.
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit 'd9ec3c60143babe1bb77c268e1d5547d15acd69b':
qsvenc: take only the allocated dimensions from the frames context
Merged-by: Mark Thompson <sw@jkqxz.net>
* commit '8b7a9729aa162e2bbd571933f1aa40767f1ff47b':
avconv_qsv: use the actual pixel format provided by lavc
This commit is a noop, see 03cef34aa6
Merged-by: Clément Bœsch <u@pkh.me>
* commit '6f40181cad8ac04adff7bd10e1e1ab65f22bc1f0':
avconv_qsv: align the surface size to 32
This commit is a noop, see 03cef34aa6
Merged-by: Clément Bœsch <u@pkh.me>
Fixes: 732/clusterfuzz-testcase-4872990070145024
See: [FFmpeg-devel] [PATCH 2/6] avcodec/dca_xll: Fix runtime error: signed integer overflow: 2147286116 + 6298923 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Provides a way to change bandwidth parameter inside DASH manifest after a non-CBR H.264 encoding.
Caller now is able to compute the bitrate by itself, after all packets have been written, and then set that value in AVFormatContext->streams->codecpar->bit_rate before calling av_write_trailer. As a result that value will be set in DASH manifest.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This matches the order they are in the 16 bpp version.
There they are in this order, to make sure we access them in the
same order they are declared, easing loading only half of the
coefficients at a time.
This makes the 8 bpp version match the 16 bpp version better.
This is cherrypicked from libav commit
b8f66c0838.
Signed-off-by: Martin Storsjö <martin@martin.st>
This matches the order they are in the 16 bpp version.
There they are in this order, to make sure we access them in the
same order they are declared, easing loading only half of the
coefficients at a time.
This makes the 8 bpp version match the 16 bpp version better.
This is cherrypicked from libav commit
08074c092d.
Signed-off-by: Martin Storsjö <martin@martin.st>
All elements are used pairwise, except for the first one.
Previously, the 16th element was unused. Move the unused element
to the second slot, to make the later element pairs not split
across registers.
This simplifies loading only parts of the coefficients,
reducing the difference to the 16 bpp version.
This is cherrypicked from libav commit
09eb88a12e.
Signed-off-by: Martin Storsjö <martin@martin.st>
All elements are used pairwise, except for the first one.
Previously, the 16th element was unused. Move the unused element
to the second slot, to make the later element pairs not split
across registers.
This simplifies loading only parts of the coefficients,
reducing the difference to the 16 bpp version.
This is cherrypicked from libav commit
de06bdfe6c.
Signed-off-by: Martin Storsjö <martin@martin.st>
The idct32x32 function actually pushed d8-d15 onto the stack even
though it didn't clobber them; there are plenty of registers that
can be used to allow keeping all the idct coefficients in registers
without having to reload different subsets of them at different
stages in the transform.
After this, we still can skip pushing d12-d15.
Before:
vp9_inv_dct_dct_32x32_sub32_add_neon: 8128.3
After:
vp9_inv_dct_dct_32x32_sub32_add_neon: 8053.3
This is cherrypicked from libav commit
65aa002d54.
Signed-off-by: Martin Storsjö <martin@martin.st>
The idct32x32 function actually pushed q4-q7 onto the stack even
though it didn't clobber them; there are plenty of registers that
can be used to allow keeping all the idct coefficients in registers
without having to reload different subsets of them at different
stages in the transform.
Since the idct16 core transform avoids clobbering q4-q7 (but clobbers
q2-q3 instead, to avoid needing to back up and restore q4-q7 at all
in the idct16 function), and the lanewise vmul needs a register in
the q0-q3 range, we move the stored coefficients from q2-q3 into q4-q5
while doing idct16.
While keeping these coefficients in registers, we still can skip pushing
q7.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_32x32_sub32_add_neon: 18553.8 17182.7 14303.3 12089.7
After:
vp9_inv_dct_dct_32x32_sub32_add_neon: 18470.3 16717.7 14173.6 11860.8
This is cherrypicked from libav commit
402546a172.
Signed-off-by: Martin Storsjö <martin@martin.st>
For this case, with 8 inputs but only changing 4 of them, we can fit
all 16 input pixels into a q register, and still have enough temporary
registers for doing the loop filter.
The wd=8 filters would require too many temporary registers for
processing all 16 pixels at once though.
Before: Cortex A7 A8 A9 A53
vp9_loop_filter_mix2_v_44_16_neon: 289.7 256.2 237.5 181.2
After:
vp9_loop_filter_mix2_v_44_16_neon: 221.2 150.5 177.7 138.0
This is cherrypicked from libav commit
575e31e931.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is one cycle faster in total, and three instructions fewer.
Before:
vp9_loop_filter_mix2_v_44_16_neon: 123.2
After:
vp9_loop_filter_mix2_v_44_16_neon: 122.2
This is cherrypicked from libav commit
3bf9c48320.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes building with clang for linux with PIC enabled.
This is cherrypicked from libav commit
8847eeaa14.
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds lots of extra .ifs, but speeds it up by a couple cycles,
by avoiding stalls.
This is cherrypicked from libav commit
b0806088d3.
Signed-off-by: Martin Storsjö <martin@martin.st>
This adds lots of extra .ifs, but speeds it up by a couple cycles,
by avoiding stalls.
This is cherrypicked from libav commit
e18c39005a.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously we first calculated hev, and then negated it.
Since we were able to schedule the negation in the middle
of another calculation, we don't see any gain in all cases.
Before: Cortex A7 A8 A9 A53 A53/AArch64
vp9_loop_filter_v_4_8_neon: 147.0 129.0 115.8 89.0 88.7
vp9_loop_filter_v_8_8_neon: 242.0 198.5 174.7 140.0 136.7
vp9_loop_filter_v_16_8_neon: 500.0 419.5 382.7 293.0 275.7
vp9_loop_filter_v_16_16_neon: 971.2 825.5 731.5 579.0 453.0
After:
vp9_loop_filter_v_4_8_neon: 143.0 127.7 114.8 88.0 87.7
vp9_loop_filter_v_8_8_neon: 241.0 197.2 173.7 140.0 136.7
vp9_loop_filter_v_16_8_neon: 497.0 419.5 379.7 293.0 275.7
vp9_loop_filter_v_16_16_neon: 965.2 818.7 731.4 579.0 452.0
This is cherrypicked from libav commit
e1f9de86f4.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
Before: Cortex A53
vp9_inv_dct_dct_16x16_sub1_add_neon: 235.3
vp9_inv_dct_dct_32x32_sub1_add_neon: 555.1
After:
vp9_inv_dct_dct_16x16_sub1_add_neon: 180.2
vp9_inv_dct_dct_32x32_sub1_add_neon: 475.3
This is cherrypicked from libav commit
3fcf788fbb.
Signed-off-by: Martin Storsjö <martin@martin.st>
No measured speedup on a Cortex A53, but other cores might benefit.
This is cherrypicked from libav commit
388e0d2515.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fold the field lengths into the macro.
This makes the macro invocations much more readable, when the
lines are shorter.
This also makes it easier to use only half the registers within
the macro.
This is cherrypicked from libav commit
5e0c2158fb.
Signed-off-by: Martin Storsjö <martin@martin.st>
The ld1r is a leftover from the arm version, where this trick is
beneficial on some cores.
Use a single-lane load where we don't need the semantics of ld1r.
This is cherrypicked from libav commit
ed8d293306.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This avoids loading and calculating coefficients that we know will
be zero, and avoids filling the temp buffer with zeros in places
where we know the second pass won't read.
This gives a pretty substantial speedup for the smaller subpartitions.
The code size increases from 14740 bytes to 24292 bytes.
The idct16/32_end macros are moved above the individual functions; the
instructions themselves are unchanged, but since new functions are added
at the same place where the code is moved from, the diff looks rather
messy.
Before:
vp9_inv_dct_dct_16x16_sub1_add_neon: 236.7
vp9_inv_dct_dct_16x16_sub2_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub4_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub8_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub12_add_neon: 1387.4
vp9_inv_dct_dct_16x16_sub16_add_neon: 1387.6
vp9_inv_dct_dct_32x32_sub1_add_neon: 554.1
vp9_inv_dct_dct_32x32_sub2_add_neon: 5198.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 5198.6
vp9_inv_dct_dct_32x32_sub8_add_neon: 5196.3
vp9_inv_dct_dct_32x32_sub12_add_neon: 6183.4
vp9_inv_dct_dct_32x32_sub16_add_neon: 6174.3
vp9_inv_dct_dct_32x32_sub20_add_neon: 7151.4
vp9_inv_dct_dct_32x32_sub24_add_neon: 7145.3
vp9_inv_dct_dct_32x32_sub28_add_neon: 8119.3
vp9_inv_dct_dct_32x32_sub32_add_neon: 8118.7
After:
vp9_inv_dct_dct_16x16_sub1_add_neon: 236.7
vp9_inv_dct_dct_16x16_sub2_add_neon: 640.8
vp9_inv_dct_dct_16x16_sub4_add_neon: 639.0
vp9_inv_dct_dct_16x16_sub8_add_neon: 842.0
vp9_inv_dct_dct_16x16_sub12_add_neon: 1388.3
vp9_inv_dct_dct_16x16_sub16_add_neon: 1389.3
vp9_inv_dct_dct_32x32_sub1_add_neon: 554.1
vp9_inv_dct_dct_32x32_sub2_add_neon: 3685.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 3685.1
vp9_inv_dct_dct_32x32_sub8_add_neon: 3684.4
vp9_inv_dct_dct_32x32_sub12_add_neon: 5312.2
vp9_inv_dct_dct_32x32_sub16_add_neon: 5315.4
vp9_inv_dct_dct_32x32_sub20_add_neon: 7154.9
vp9_inv_dct_dct_32x32_sub24_add_neon: 7154.5
vp9_inv_dct_dct_32x32_sub28_add_neon: 8126.6
vp9_inv_dct_dct_32x32_sub32_add_neon: 8127.2
This is cherrypicked from libav commit
a63da4511d.
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows reusing the macro for a separate implementation of the
pass2 function.
This is cherrypicked from libav commit
79d332ebbd.
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows reusing the macro for a separate implementation of the
pass2 function.
This is cherrypicked from libav commit
47b3c2c18d.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/aarch64/vp9itxfm_neon.o from
19496 to 14740 bytes.
This gives a small slowdown of a couple of tens of cycles, but makes
it more feasible to add more optimized versions of these transforms.
Before:
vp9_inv_dct_dct_16x16_sub4_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub16_add_neon: 1372.2
vp9_inv_dct_dct_32x32_sub4_add_neon: 5180.0
vp9_inv_dct_dct_32x32_sub32_add_neon: 8095.7
After:
vp9_inv_dct_dct_16x16_sub4_add_neon: 1051.0
vp9_inv_dct_dct_16x16_sub16_add_neon: 1390.1
vp9_inv_dct_dct_32x32_sub4_add_neon: 5199.9
vp9_inv_dct_dct_32x32_sub32_add_neon: 8125.8
This is cherrypicked from libav commit
115476018d.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This reduces the code size of libavcodec/arm/vp9itxfm_neon.o from
15324 to 12388 bytes.
This gives a small slowdown of a couple tens of cycles, up to around
150 cycles for the full case of the largest transform, but makes
it more feasible to add more optimized versions of these transforms.
Before: Cortex A7 A8 A9 A53
vp9_inv_dct_dct_16x16_sub4_add_neon: 2063.4 1516.0 1719.5 1245.1
vp9_inv_dct_dct_16x16_sub16_add_neon: 3279.3 2454.5 2525.2 1982.3
vp9_inv_dct_dct_32x32_sub4_add_neon: 10750.0 7955.4 8525.6 6754.2
vp9_inv_dct_dct_32x32_sub32_add_neon: 18574.0 17108.4 14216.7 12010.2
After:
vp9_inv_dct_dct_16x16_sub4_add_neon: 2060.8 1608.5 1735.7 1262.0
vp9_inv_dct_dct_16x16_sub16_add_neon: 3211.2 2443.5 2546.1 1999.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 10682.0 8043.8 8581.3 6810.1
vp9_inv_dct_dct_32x32_sub32_add_neon: 18522.4 17277.4 14286.7 12087.9
This is cherrypicked from libav commit
0331c3f5e8.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids concatenation, which can't be used if the whole macro
is wrapped within another macro.
This is also arguably more readable.
This is cherrypicked from libav commit
58d87e0f49.
Signed-off-by: Martin Storsjö <martin@martin.st>
The 'sqrt' and 'cbrt' scalers were added in commit
80262d8c86, but their symbolic option values
only made available to the showwaves filter, not showwavespic, despite
the scalers working properly by their numerical option values.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
1. limit to single layer, as there is no current support for setting distortion/quality of multiple layers
2. encoder mode should be kept at default setting (0)
3. remove fixed_alloc parameter from context : seldom if ever used, and no way of properly configuring at the moment
4. add irreversible setting, to allow for lossless encoding. Set to OpenJPEG default (enabled)
5. set numresolution max to 33, which is the maximum number of allowed resolutions according the J2K spec
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
Make it clear that there is no timing-dependent behavior. In particular,
there is no state in which both input and output are denied, and where
you have to wait for a while yourself to make progress (apparently some
hardware decoders like to do this).
Avoid wording that makes references to time. It shouldn't be mistaken
for some kind of asynchronous API (like POSIX read() can return EAGAIN
if there is no new input yet). It's a state machine, so try to use
appropriate terms.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Merges Libav commit 8a60bba0ae.
Apparently the demuxer outputs the wrong padding for HE-AAC (based on
the raw sample rate, or so). aacdec contains a hack to adjust the muxer
padding accordingly before it's used to trim the decoder output. This
modified the packet side data, which in combination with the old
decoding API would change the packet the user passed to the decoder.
This is clearly not allowed, and it breaks running some gapless fate
tests with "-fflags +keepside" applied (without keepside, the packet
metadata is typically newly allocated, essentially making a copy and not
modifying the user's input packet).
This should probably be fixed in the demuxer (and consequently also the
muxer), but for now only fix the immediate problem.
Regression since 946ed78f5f (2012).
except filter_length == 1
odd filter_length gives worse frequency response,
even when compared with shorter filter_length
also makes build_filter simpler
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
This reverts commit faa9d29829.
This change became superfluous when support for C11 atomics was introduced.
Reverting it will make the removal of this implementation in an upcoming
merge conflict free.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The constants used in the decoder used floating point precision,
and this caused different values to be generated on different
architectures.
So, eradicate floating point numbers and use fixed point (32.32)
arithmetics everywhere, replacing constants with precomputed integer
values.
Signed-off-by: Vittorio Giovara <vittorio.giovara at gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
The way videotoolbox hooks in as a hwaccel is pretty hacky. The VT decode
API is not invoked until end_frame(), so alloc_frame() returns a dummy
frame with a 1-byte buffer. When end_frame() is eventually called, the
dummy buffer is replaced with the actual decoded data from
VTDecompressionSessionDecodeFrame().
When the VT decoder fails, the frame returned to the h264 decoder from
alloc_frame() remains invalid and should not be used. Before
9747219958, it was accidentally being
returned all the way up to the API user. After that commit, the dummy
frame was unref'd so the user received an error.
However, since that commit, VT hwaccel failures started causing random
segfaults in the h264 decoder. This happened more often on iOS where the
VT implementation is more likely to throw errors on bitstream anomolies.
A recent report of this issue can be see in
http://ffmpeg.org/pipermail/libav-user/2016-November/009831.html
The issue here is that the dummy frame is still referenced internally by the
h264 decoder, as part of the reflist and cur_pic_ptr. Deallocating the
frame causes assertions like this one to trip later on during decoding:
Assertion h->cur_pic_ptr->f->buf[0] failed at src/libavcodec/h264_slice.c:1340
With this commit, we leave the dummy 1-byte frame intact, but avoid returning it
to the user.
This reverts commit 9747219958.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Without this the FPU state becomes trashed and causes mysterious
fate failures with cpuflags=0
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Ever since the codecpar changes, this has been always printed when
opening a flv file. This is because the codecpar changes made all
streams to be added lazily as read_packet is called.
There is no reason that draining couldn't return an error or two. But
some decoders don't handle this very well, and might always return an
error. This can lead to API users getting into an infinite loop and
burning CPU, because no progress is made and EOF is never returned.
In fact, ffmpeg.c contains a hack against such a case. It is made
unnecessary with this commit, and removed with the next one. (This
particular error case seems to have been fixed since the hack was
added, though.)
This might lose frames if decoding returns errors during draining.
The code modifying the buffer on big endian systems was removed.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
The filter field is often used to check whether a filter is
configured. If configuring the filter actually fails somewhere in
the middle of it, these fields could still be set to non-NULL, which
lead to other code accessing the half-configured filter graph, which
in turn could lead to crashes within libavfilter.
Solve this by properly resetting all fields.
This was triggered by a fuzzed sample after the recent changes. It's
unknown whether this behavior could be triggered before that.
If a subtitle packet came before the first video frame could be fully
decoded, the subtitle packet would get discarded. This puts the subtitle
into a queue instead, and processes it once the attached filter graph is
initialized.
Be more careful when an input stream encounters EOF when its filtergraph
has not been configured yet. The current code would immediately mark the
corresponding output streams as finished, while there may still be
buffered frames waiting for frames to appear on other filtergraph
inputs.
This should fix the random FATE failures for complex filtergraph tests
after a3a0230a98
This merges Libav commit 94ebf55. It was previously skipped.
This is the last filter init related Libav commit that was skipped, so
this also removes the commits from doc/libav-merge.txt.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This is a more appropriate place for it, and will also be useful in the
following commit.
This merges Libav commit d2e56cf. It was previously skipped.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This makes sure the actual stream parameters are used, which is
important mainly for hardware decoding+filtering cases, which would
previously require various weird workarounds to handle the fact that a
fake software graph has to be constructed, but never used.
This should also improve behaviour in rare cases where
avformat_find_stream_info() does not provide accurate information.
This merges Libav commit a3a0230. It was previously skipped.
The code in flush_encoders() which sets up a "fake" format wasn't in
Libav. I'm not sure if it's a good idea, but it tends to give
behavior closer to the old one in certain corner cases.
The vp8-size-change gives different result, because now the size of
the first frame is used. libavformat reported the size of the largest
frame for some reason.
The exr tests now use the sample aspect ratio of the first frame. For
some reason libavformat determines 0/1 as aspect ratio, while the
decoder returns the correct one.
The ffm and mxf tests change the field_order values. I'm assuming
another libavformat/decoding mismatch.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This will be useful in the following commit, after which the muxer
timebase is not always available when encoding.
This merges Libav commit 3e265ca. It was previously skipped.
There are some changes with how/when the mux_timebase field is set,
because the Libav approach often causes a too imprecise time base
to be set. This is hard, because the muxer's write_header function
can readjust the timebase, at which point we might already have
encoded packets buffered. (It might be better to buffer them after
the encoder, instead of after all the timestamp handling logic
before muxing.)
The two FATE tests change because the output time base is raised
for subtitles. (Needed to avoid certain rounding issues in other
cases.)
Includes a minor merge fix by Mark Thompson, and
avconv: Move rescale to stream timebase before monotonisation
also by Mark Thompson <sw@jkqxz.net>.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Some callers (like do_subtitle_out()) call this with an AVPacket that is
not refcounted. This can cause undefined behavior.
Calling av_packet_move_ref() does not make a packet refcounted if it
isn't yet. (And it can't be made to, because it always succeeds,
and can't return ENOMEM.)
Call av_packet_ref() instead to make sure it's refcounted.
I couldn't find a case that is fixed by this with the current code. But
it will fix the fate-pva-demux test with the later patches applied.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Found a case where we use size==0, the other related commits
remain needed, and should be sufficient to fix the original issue
This reverts commit 7e4f32f4e4.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If AVVideotoolboxContext.cv_pix_fmt_type is set to 0, don't set the
kCVPixelBufferPixelFormatTypeKey value on the VT decoder.
This makes VT output its native format, which can be much faster on
some hardware iterations (if the native format does not match with
the requested format, it will be converted, which is slow).
The default is still forcing nv12.
Public fields were added after the private fields (negating the entire
point of this). New private fields go into AVStreamInternal anyway.
The new marker was set by guessing which fields are supposed to be
private and wshich not. recommended_encoder_configuration is accessed by
ffserver_config.c directly, and is supposed to use the public API.
ffmpeg.c accesses AVStream.cur_dts, even though it's a private field,
but that seems to be an older error.
Allow all struct fields to be accessed directly, as long as they're
public.
Before this change, many fields were "public", but could be accessed via
AVOption only. This meant they were effectively not public, but were
present for documentation purposes, which was incredibly confusing at
best.
qmin and qmax are not necessary for nvenc vbr.
Enforcing this constraint, doesn't allow user to use vbr 2 pass mode without explicity setting the qmin and qmax options
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Rodger Combs will be added to the ffmpeg-security alias when this patch is applied
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
wm4 will be added to the ffmpeg-security alias when this patch is applied
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The size 0 special case causes side data to be created which is
different and a special case if for any reasons size = 0 is passed
Fixes: multiple runtime error: null pointer passed as argument 1, which is declared to never be null
Fixes: 653/clusterfuzz-testcase-5773837415219200
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: shift exponent 34 is too large for 32-bit type 'int'
Fixes: 653/clusterfuzz-testcase-5773837415219200
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should fix the fate failure due to a truncated last frame.
Alternatively the frame could be dropped.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
MSVC doesn't support the %s time format, and instead of returning an
error the invalid parameter handler is invoked which (by default)
terminates the process.
Reviewed-by：Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
refer to ticket id: #6170
rename file from temp to origin name after complete current segment
Reviewed-by: Aman Gupta <ffmpeg@tmm1.net>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Since the PVQ search has been well fuzzed and is guaranteed to never
break SUM(abs(y[])) == K, the assert is no longer needed.
Also the assert only prevented coding the wrong vector index but didn't
prevent crashes during searching for it, which made the assert rather
informational than practical.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Since the probelm mentioned only happened when the phase was negative
(e.g. the sum had to be decreased), only discarding dimensions with a
zero pulse in that case restored the search's previously low distortion
at low Ks when the phase is never negative.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This is not necessarily specific to fuzzed files
Fixes: Multiple integer overflows
Fixes: 656/clusterfuzz-testcase-6463814516080640
Fixes: 658/clusterfuzz-testcase-6691260146384896
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes#6081. Some dictionary keys are not present on OS X 10.8.
This loads the symbols and uses a default value if not present.
Signed-off-by: Rick Kern <kernrj@gmail.com>
This ensures that the wrapped avframe will not get reallocated later, which
would invalidate internal references such as extended data.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
When setting the channel layout directly using AVBufferSrcParameters
the channel layout was correctly set however the init function still
expected the old string format to set the number of channels (when it
hadn't already been specified).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The quantization table is stored in the natural order, but when we
access it, we use an index that's in zigzag order, causing us to read
the wrong value. This causes artifacts, especially in areas with
horizontal or vertical edges. The artifacts look a lot like the
DCT ringing artifacts you'd expect to see from a low-bitrate file,
but when comparing to NewTek's own decoder, it's obvious they're not
supposed to be there.
Fix by simply storing the scaled quantization table in zigzag order.
Performance is unchanged.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the PVQ search picked a place to increment/decrement on the y[]
vector which had no pulse then it would cause a desync since it would
change the sum in the wrong direction. Fix this by not considering
places without pulses as viable.
This makes the PVQ search slightly worse at K < 5 which isn't all that
common. Still, this is a workaround to prevent making broken files until
I can think of a better way of fixing it.
Also add an assertion, which can be removed or moved to assert1/2 once
the PVQ search is stable.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This dts value can end up in the list in the absence of durations and is in that
case semantically identical to AV_NOPTS_VALUE. We can alternatively prevent
storing RELATIVE_TS_BASE if there is no duration.
Fixes Ticket3640
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Originally committed to x264 in 1637239a by Henrik Gramner who has
agreed to re-license it as LGPL. Original commit message follows.
x86: Avoid some bypass delays and false dependencies
A bypass delay of 1-3 clock cycles may occur on some CPUs when transitioning
between int and float domains, so try to avoid that if possible.
If there is progressive input it will disable deinterlacing in cuvid for
all future frames even those interlaced.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Fixes Ticket 6018
This fixes a regression, and allows playback of files containing mpeg4video that are otherwise
not supported
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When the http method is not set, the method will use POST for ts,
PUT for m3u8, it is not unify, now set it unify.
This ticket id: #5315
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Channel mapping 2 additionally supports a non-diegetic stereo track
appended to the end of a full-order ambisonics signal, such that the
total channel count is either
(n + 1) ^ 2, or
(n + 1) ^ 2 + 2
where n is the ambisonics order
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Skips using temporary files when outputting to a protocol other than
"file", which enables dash to output content over network
protocols. The logic has been copied from the HLS format.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit optimizes HTTP performance by reducing forward seeks, instead
favoring a read-ahead and discard on the current connection (referred to
as a short seek) for seeks that are within a TCP window's worth of data.
This improves performance because with TCP flow control, a window's worth
of data will be in the local socket buffer already or in-flight from the
sender once congestion control on the sender is fully utilizing the window.
Note: this approach doesn't attempt to differentiate from a newly opened
connection which may not be fully utilizing the window due to congestion
control vs one that is. The receiver can't get at this information, so we
assume worst case; that full window is in use (we did advertise it after all)
and that data could be in-flight
The previous behavior of closing the connection, then opening a new
with a new HTTP range value results in a massive amounts of discarded
and re-sent data when large TCP windows are used. This has been observed
on MacOS/iOS which starts with an initial window of 256KB and grows up to
1MB depending on the bandwidth-product delay.
When seeking within a window's worth of data and we close the connection,
then open a new one within the same window's worth of data, we discard
from the current offset till the end of the window. Then on the new
connection the server ends up re-sending the previous data from new
offset till the end of old window.
Example (assumes full window utilization):
TCP window size: 64KB
Position: 32KB
Forward seek position: 40KB
* (Next window)
32KB |--------------| 96KB |---------------| 160KB
*
40KB |---------------| 104KB
Re-sent amount: 96KB - 40KB = 56KB
For a real world test example, I have MP4 file of ~25MB, which ffplay
only reads ~16MB and performs 177 seeks. With current ffmpeg, this results
in 177 HTTP GETs and ~73MB worth of TCP data communication. With this
patch, ffmpeg issues 4 HTTP GETs and 3 seeks for a total of ~22MB of TCP data
communication.
To support this feature, the short seek logic in avio_seek() has been
extended to call a function to get the short seek threshold value. This
callback has been plumbed to the URLProtocol structure, which now has
infrastructure in HTTP and TCP to get the underlying receiver window size
via SO_RCVBUF. If the underlying URL and protocol don't support returning
a short seek threshold, the default s->short_seek_threshold is used
This feature has been tested on Windows 7 and MacOS/iOS. Windows support
is slightly complicated by the fact that when TCP window auto-tuning is
enabled, SO_RCVBUF doesn't report the real window size, but it does if
SO_RCVBUF was manually set (disabling auto-tuning). So we can only use
this optimization on Windows in the later case
Signed-off-by: Joel Cunningham <joel.cunningham@me.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This marks the first time anyone has written an Opus encoder without
using any libopus code. The aim of the encoder is to prove how far
the format can go by writing the craziest encoder for it.
Right now the encoder's basic, it only supports CBR encoding, however
internally every single feature the CELT layer has is implemented
(except the pitch pre-filter which needs to work well with the rest of
whatever gets implemented). Psychoacoustic and rate control systems are
under development.
The encoder takes in frames of 120 samples and depending on the value of
opus_delay the plan is to use the extra buffered frames as lookahead.
Right now the encoder will pick the nearest largest legal frame size and
won't use the lookahead, but that'll change once there's a
psychoacoustic system.
Even though its a pretty basic encoder its already outperforming
any other native encoder FFmpeg has by a huge amount.
The PVQ search algorithm is faster and more accurate than libopus's
algorithm so the encoder's performance is close to that of libopus
at zero complexity (libopus has more SIMD).
The algorithm might be ported to libopus or other codecs using PVQ in
the future.
The encoder still has a few minor bugs, like desyncs at ultra low
bitrates (below 9kbps with 20ms frames).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This is meant to be applied on top of my previous patch which
split PVQ into celt_pvq.c and made opus_celt.h
Essentially nothing has been changed other than renaming CeltFrame
to CeltBlock (CeltFrame had absolutely nothing at all to do with
a frame) and CeltContext to CeltFrame.
3 variables have been put in CeltFrame as they make more sense
there rather than being passed around as arguments.
The coefficients have been moved to the CeltBlock structure
(why the hell were they in CeltContext and not in CeltFrame??).
Now the encoder would be able to use the exact context the decoder
uses (plus a couple of extra fields in there).
FATE passes, no slowdowns, etc.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
A huge amount can be reused by the encoder, as the only thing
which needs to be done would be to add a 10 line celt_icwrsi,
a wrapper around it (celt_alg_quant) and templating the
ff_celt_decode_band to replace entropy decoding functions
with entropy encoding.
There is no performance loss but in fact a performance gain of
around 6% which is caused by the compiler being able to optimize
the decoding more efficiently.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Handles strides (needed for Opus transients), does pre-reindexing and folding
without needing a copy.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Mostly used the RFC document, the decoding functions and
the reference encoder's implmenentation as a reference.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
A strict reading of the spec seems to imply that it should be aligned to
the start of the element instance tag, but that would break all of the
samples with PCEs.
It seems like a well formed LATM stream should have its PCE in the ASC
rather than inband.
Fixes ticket 4544
D3D9Ex uses different driver paths. This helps with "headless"
configurations when no user logs in. Plain D3D9 device creation will
fail if no user is logged in, while it works with D3D9Ex.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Merges Libav commit c2f97f0508.
This is an extended version of the AVFrame.opaque field, which can be
used to attach arbitrary user information to an AVFrame.
The usefulness of the opaque field is rather limited, because it can
store only up to 32 bits of information (or 64 bit on 64 bit systems).
It's not possible to set this field to a memory allocation, because
there is no way to deallocate it correctly.
The opaque_ref field circumvents this by letting the user set an
AVBuffer, which makes the user data refcounted.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Merges Libav commit 04f3bd3496.
hls-encoder currenlty does not provide stream level metadata to mpegts
muxer. This patch fixes track #3848 bug.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This enables having multiple tracks of the same type which would
be treated as different things by the media server (as opposed to
different bit rate versions of the same track). According to the
smooth streaming specification, just setting the systemLanguage
tag is not enough to note that a track with the same attributes
differs from another one.
Reviewed-by: Martin
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When user use the hls_wrap, there have many problem:
1. some platform refersh the old but usefull segment
2. CDN(Content Delivery Network) Deliver HLS not friendly
The hls_wrap is used to wrap segments for use little space,
now user can use hls_list_size and hls_flags delete_segments
instead it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This way it's clear the size field accounts for the footer length plus every
tag entry, but not the header.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The size field in the header/footer accounts for the entire APE tag
structure except the 32 bytes from header, for compatibility with
APEv1.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
According to the spec[1], a value of 0 means the footer is present and a value
of 1 means it's absent, the exact opposite of header presence flag where 1
means present and 0 absent.
The reason for this is compatibility with APEv1 tags, where there's no header,
footer presence was mandatory for all files, and the flags field was a zeroed
reserved field.
[1] http://wiki.hydrogenaud.io/index.php?title=Ape_Tags_Flags
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This limits the bugs, speedloss and extra memory allocation to the case when
optimal tables are needed.
Fixes regressions with slice multi-threading
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If this is wanted iam not against it but it must be designed to work with all cases
like slice threads, and a single growing buffer does not work very well with slices.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Only do this when building for a recent VAAPI version - initial
driver implementations were confused about the interpretation of the
framerate field, but hopefully this will be consistent everywhere
once 0.40.0 is released.
(cherry picked from commit ff35aa8ca4)
Default to using VBR when a target bitrate is set, unless the max rate
is also set and matches the target. Changes to the Intel driver mean
that min_qp is also respected in this case, so set a codec default to
unset the value rather than using the current default inherited from
the MPEG-4 part 2 encoder.
(cherry picked from commit eddfb57210)
This includes a backward-compatibility hack to choose CBR anyway on
old drivers which have no CBR support, so that existing programs will
continue to work their options now map to VBR.
(cherry picked from commit f033ba470f)
Before this change, it was possible to overflow pic_order_cnt_lsb and
generate a stream with invalid POC numbering. This makes sure that
the field is large enough that a single IDR B* P sequence uses fewer
than half the available POC lsb values.
(cherry picked from commit 89725a8512)
This change makes the configured GOP size be respected exactly -
previously the value could be exceeded slightly due to flaws in the
frame type selection logic.
(cherry picked from commit 37fab0661a)
Core of patch is from paul@paulmehta.com
Reference https://crbug.com/643951
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Check value reduced as the code does not support values beyond INT_MAX
Also the check is moved to a more common place and before integer truncation
Adds a `-hls_flags +temp_file` which will write segment data to
filename.tmp, and then rename to filename when the segment is complete.
This patch is similar in spirit to one used in Plex's ffmpeg fork, and
allows a transcoding webserver to ensure incomplete segment files are
never served up accidentally.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Bodecs Bela <bodecsb@vivanet.hu>
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Blocks are marked as key frames whenever the "reference" field is
zero. This breaks for non-keyframe Blocks with a reference timestamp
of zero.
The likelihood of reference timestamp being zero is increased by a
longstanding bug in muxing that encodes reference timestamp as the
absolute time of the referenced frame (rather than relative to the
current Block timestamp, as described in MKV spec).
Now using INT64_MIN to denote "no reference".
Reported to chromium at http://crbug.com/497889 (contains sample)
The original code is correctly following the API - vaTerminate() must
be called to free the resources of a VADisplay after it is created by
any of the vaGetDisplay*() calls; it is not necessary to have
successfully called vaInitialize() on it. The segfaults which
prompted this change must therefore be bugs in libva or the driver it
loads.
This reverts commit 3606602f11.
Detecting a leap second depends on a lot of things, segment time, segment
offset, system leap second implementation, the removed part is a huge
simplification which can be misleading, so it is best to remove it.
Signed-off-by: Marton Balint <cus@passwd.hu>
Not starting a new segment if the elapsed microsecs since the start of the day
equals the the elapsed microsecs since the start of the day at the time of the
last cut seems plain wrong to me, Deti do you remember the original reason
behind this check?
Signed-off-by: Marton Balint <cus@passwd.hu>
Without the /UTF-8 switch, the MSVC compiler treats all files as in the
system codepage, instead of in UTF-8, which causes UTF-8 string literals
to be interpreted wrong.
This switch was only introduced in VS2015 Update 2, and any earlier
versions do not have an equivalent solution.
Fixes fate-sub-scc on MSVC 2015+
Fixes out of array read
Fixes: 544/clusterfuzz-testcase-5936536407244800.f8bd9b24_8ba77916_70c2c7be_3df6a2ea_96cd9f14
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes ubsan warnings in non debug builds by using unsigned operations
in debug builds the correct signed operations are retained so that overflows
(which should not occur in valid files and may indicate problems in the DSP code
or decoder) can be detected.
Alternatively they can be changed to unsigned unconditionally, then its
not possible though to detect overflows easily if someone wants to test
the DSP code for overflows.
The 2nd alternative would be to leave the code as it is and accept that
there are undefined operations in the DSP code and that ubsan output is
full of them in some cases.
Similar changes would be needed in some other DSP routines
Suggested-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Clarify that setting loop=0 is required to make the stream loop infinitely, rather than saying that a value "less than 1" is needed.
Signed-off-by: Lou Logan <lou@lrcd.com>
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000aff8a4 in vaTerminate ()
#1 0x0000000000ae50ce in vaapi_device_free (ctx=<optimized out>) at libavutil/hwcontext_vaapi.c:882
#2 0x0000000000ae1f9e in hwdevice_ctx_free (opaque=<optimized out>, data=<optimized out>) at libavutil/hwcontext.c:66
#3 0x0000000000ad856f in buffer_replace (src=0x0, dst=0x7fffa26ef1b8) at libavutil/buffer.c:119
#4 av_buffer_unref (buf=buf@entry=0x7fffa26ef1f8) at libavutil/buffer.c:129
#5 0x0000000000ae299f in av_hwdevice_ctx_create (pdevice_ref=0x170ac50 <hw_device_ctx>, type=type@entry=AV_HWDEVICE_TYPE_VAAPI, device=<optimized out>,
opts=opts@entry=0x0, flags=flags@entry=0) at libavutil/hwcontext.c:494
#6 0x0000000000400968 in vaapi_device_init (device=<optimized out>) at ffmpeg_vaapi.c:223
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Implements support for height/width expressions in vf_scale_vaapi,
by refactoring common code into a new libavfilter/scale.c
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Change the encoding of the original developer name from ISO-8859-1 to UTF-8.
Remove the stale/completed TODO list.
Fix two small typos.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '7f549b8338ed3775fec4bf10421ff5744e5866dd':
riff: don't overwrite bps from WAVEFORMATEX if EXTENSIBLE doesn't contain that data.
Only cosmetics, the change was already present.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '6135c3b61e084be93c0876cecd06f4e764f961c0':
Revert "avprobe: Zero the allocated avio buffer memory"
This commit is a noop, see 591cf8aa0e
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'ed9b2a5178d7a7c5a95694da3a808af327f36aff':
mov: Rework the check for invalid indexes in stsc
This commit is a noop, see 3c058f5701.
The proposed fix breaks seeking in multiple_stsd.mp4 (ticket #3962) and
playback of wwwq_cut.mp4 (ticket #2991).
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Certain alpha run lengths (for SHQ1/SHQ3/SHQ5) could be stored in
both long and short versions, and we would only accept the short version,
returning -1 (invalid code) for the others. This could cause an
out-of-bounds write on malicious input, as discovered by
Andreas Cadhalpun during fuzzing.
Fix by simply allowing both versions, leaving no invalid codes
in the alpha VLC.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Multichannel joint stereo simply interleaves stereo pairs (6ch: 2ch + 2ch + 2ch), so each pair is decoded separatedly.
***
To test my changes, I converted examples to wav with ffmpeg.exe (old and new), and compared them to see they are byte-exact.
Regular 2ch files (JS and normal) were straightforward to test.
For multichannel, to check each JS pair is correctly decoded separatedly I did:
- manually demux 6ch.msf into 3 pairs and convert them (2ch_1.wav + 2ch_2.wav + 2ch_3.wav)
- convert the 6ch.msf file to wav (with my changes)
- manually demux the 6ch.wav into 3 pairs (6ch_d1.wav + 6ch_d2.wav + 6ch_d3.wav)
- compare each pair (ex. 2ch_3.wav vs 6ch_d3.wav): all pairs are byte-exact.
The new code just processes each JS pair separatedly, there are no algorithm changes.
It could be improved a bit but I'm not sure about typical styles.
I've only seen 6ch .MSF (probably the AT3 spec only supports 2ch audio).
Signed-off-by: bnnm <bananaman255@gmail.com>
Fixes: u263_b-frames_1.avi
Fixes part of Ticket1536
return -1 is used here as it is used in similar code in this function, I intend
to replace it by proper error codes in the whole function.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '90bc423212396e96a02edc1118982ab7f7766a63':
mov: Wrap stsc index and count compare in a separate function
The mov_stsc_index_valid() function is replaced with a macro to prevent
signdness issues (index is not always signed, and count is always
unsigned currently).
The comparison is also adjusted to reduce the risk of overflows.
Merged-by: Clément Bœsch <u@pkh.me>
Retain the ranges of frame indexes when applying edit list in
mov_fix_index. The index ranges are then used to keep track of the frame
index of the current sample. In case of a discontinuity in frame indexes
due to edit, update the auxiliary info position accordingly.
Reviewed-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '209ee680ce99035202520b900326a57f7fa0aceb':
mov: Fix stsc_count comparison
This commit is a noop, see 3c058f5701
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a1f6a2dfdaf9beb42ca66e49d10bfaf5905a0128':
ratecontrol: Reorder functions to avoid forward declarations
Merged, but this seems to break the clear separation of 1-pass vs
2-pass.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd639dcdae022130078c9c84b7b691c5e9694786c':
ratecontrol: Move Xvid-related functions to the place they are actually used
Merged-by: Clément Bœsch <u@pkh.me>
* commit '44972e227df0f7ad5aa9004d971fb54e9dc5c849':
ratecontrol: Move mpegenc-only function where it is used
This commit is a noop. ff_write_pass1_stats() is used in snowenc as
well.
Merged-by: Clément Bœsch <u@pkh.me>
The code relies on their validity and otherwise can try to access a NULL
object->rle pointer, causing segmentation faults.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The assumption this is based on is wrong, the code is not always run with bitexact flags
This reverts commit a956164e1e, reversing
changes made to f6005907fd.
Approved-by: James Almer <jamrial@gmail.com>
* commit 'd06dfaa5cbdd20acfd2364b16c0f4ae4ddb30a65':
x86: huffyuv: Use EXTERNAL_SSSE3_FAST convenience macro where appropriate
Merged-by: James Almer <jamrial@gmail.com>
* commit '8e9cd81d291b1010c625b2766058aadf4affb537':
x86: cpu: Detect Conroe CPUs and their slow shuffle unit
Merged-by: James Almer <jamrial@gmail.com>
* commit '7d7355aa92bb36ca0765c49a569a999bcb96f332':
x86: Add SSSE3_SLOW CPU flag and related convenience macros
Merged-by: James Almer <jamrial@gmail.com>
* commit '4efab89332ea39a77145e8b15562b981d9dbde68':
x86: Use *_FAST/*_SLOW CPU feature detection macros where appropriate
Merged-by: James Almer <jamrial@gmail.com>
* commit '0a39c9ac0bfd7345fe676b4e2707d9cec3cbb553':
x86: hpeldsp: Don't check for bitexact flag when initializing VP3-specific code
Merged-by: James Almer <jamrial@gmail.com>
* commit '1dfc3cf89d0eb026af28be46294b85d79499ffb5':
x86: hpeldsp: Split off VP3-specific bits into a separate file
Merged-by: James Almer <jamrial@gmail.com>
* commit '0e0538aefc75958ded49f5d075c99a81cf6b2bbb':
avprobe: Zero the allocated avio buffer memory
This commit is a noop, no such thing exists in ffprobe.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'e344e65109f1a75ca82aff4cecec44e79197753c':
h264dec: do not call finish_setup() if we have not started a frame
This commit is a noop, see bdbbb8f11e
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '1f7b4f9abc6bae94e576e710b8d10117ca3c8238':
h264dec: make sure not to call finish_setup() more than once per frame
This commit is a noop, see bdbbb8f11e
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'da917fcf5183ed249ad1285b8edd330f421376c4':
avconv_dxva2: add a profile check for hevc
This commit is a noop, see a655bc8344
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '1ecb63cd1c1a4ddc5efed4abbc3158b969d8c5e4':
hevc: set profile based on the profile compatibility flags if needed
This commit is a noop, see f85cc3bf12
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'fca3c3b61952aacc45e9ca54d86a762946c21942':
hevc: Add AVX2 DC IDCT
Mostly noop as we already have that code.
In the ASM, code is merged with the exception of SECTION which is kept
uppercase for consistency with the rest of the codebase.
Still in the ASM, the prototype comment is fixed to honor the '_' added
from the original commit.
idct_dc_proto() is dropped as it's not used anymore here.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit 'cc16da75c2f99d92f7a6461100f041352deb6d88':
hevc: Add coefficient limiting to speed up IDCT
Noop again as we have these changes already, only random spacing
changes.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '4f247de3b797cdc9d243d26534412f81c306e5b5':
hevcdsp_template: Templatize IDCT
This commit is a noop as we already have that code from a previous
commits (see 92cccb7bcd).
Spacing is adjusted to reduce the diff.
Merged-by: Clément Bœsch <cboesch@gopro.com>
* commit '1bd890ad173d79e7906c5e1d06bf0a06cca4519d':
hevc: Separate adding residual to prediction from IDCT
This commit should be a noop but isn't because of the following renames:
- transform_add → add_residual
- transform_skip → dequant
- idct_4x4_luma → transform_4x4_luma
Merged-by: Clément Bœsch <cboesch@gopro.com>
Allows the user to reserve space for the ODML master index. A sufficient
sized master index in the AVI header avoids storing follow-up master
indexes within the 'movi' data later. If the option is omitted or zero
the index size is estimated from output duration and bitrate.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Codec 4 (frame size 98) uses joint stereo per spec and examples.
Also removed an incorrect "align" var which wasn't used anyway (it was overwrittern).
Probably all/only .AT3 of frame size 98 are JS, too.
Signed-off-by: bnnm <bananaman255@gmail.com>
Instead of just updating statistics and leaving the work to the
call site, have it actually do the work.
Also: skip the samples by updating the frame data pointers
instead of moving the samples. More efficient and avoid writing
into shared frames.
Found-By: Muhammad Faiz <mfcc64@gmail.com>
Name and purpose are more appropriate there since the code isn't
an ideal example.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This allows testing EC and non EC. Avoids spending most time in EC on
high res samples and reduces the likelyhood of hitting timeouts
Fixes: Timeout in 467/fuzz-2-ffmpeg_VIDEO_AV_CODEC_ID_H263_fuzzer
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When detecting a swapped AC3 marker the data of the frame is swapped. However, in subsequent frames the data swapped is taken from the first frame rather than the current frame.
Signed-off-by: Marijn Meijles <marijn@bitpit.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
From e24d95c0e06a878d401ee34fd6742fcaddeeb95f Mon Sep 17 00:00:00 2001
From: Joel Cunningham <joel.cunningham@me.com>
Date: Mon, 9 Jan 2017 13:37:51 -0600
Subject: [PATCH] tcp: set socket buffer sizes before listen/connect/accept
Attempting to set SO_RCVBUF and SO_SNDBUF on TCP sockets after connection
establishment is incorrect and some stacks ignore the set call on the socket at
this point. This has been observed on MacOS/iOS. Windows 7 has some peculiar
behavior where setting SO_RCVBUF after applies only if the buffer is increasing
from the default while decreases are ignored. This is possibly how the incorrect
usage has gone unnoticed
Unix Network Programming Vol. 1: The Sockets Networking API (3rd edition, seciton 7.5):
"When setting the size of the TCP socket receive buffer, the ordering of the
function calls is important. This is because of TCP's window scale option,
which is exchanged with the peer on SYN segments when the connection is
established. For a client, this means the SO_RCVBUF socket option must be
set before calling connect. For a server, this means the socket option must
be set for the listening socket before calling listen. Setting this option
for the connected socket will have no effect whatsoever on the possible window
scale option because accept does not return with the connected socket until
TCP's three-way handshake is complete. This is why the option must be set on
the listening socket. (The sizes of the socket buffers are always inherited from
the listening socket by the newly created connected socket)"
Signed-off-by: Joel Cunningham <joel.cunningham@me.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When bytes_read overflowed, last_bytes_read did not yet overflow
and no bytes-read report was created leading to a timeout.
Analyzed-by: Thomas Bernhard
Fixes ticket #5836.
Current code returned the number of channels as channel layout in that case,
and if nret is not set then unknown layouts are typically not supported.
Also use the common parsing code. Use a temporary workaround to parse an
unknown channel layout such as '13c', after a 1 year grace period only '13C'
will work.
Signed-off-by: Marton Balint <cus@passwd.hu>
Return a channel layout and the number of channels based on the specified name.
This function is similar to av_get_channel_layout(), but can also parse unknown
channel layout specifications.
Unknown channel layout specifications are a decimal number and a capital 'C'
suffix, in order to not break compatibility with the lowercase 'c' suffix,
which is used for a guessed channel layout with the specified number of
channels.
Signed-off-by: Marton Balint <cus@passwd.hu>
This work is sponsored by, and copyright, Google.
This is similar to the arm version, but due to the larger registers
on aarch64, we can do 8 pixels at a time for all filter sizes.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_loop_filter_h_4_8_10bpp_neon: 213.2 172.6
vp9_loop_filter_h_8_8_10bpp_neon: 281.2 244.2
vp9_loop_filter_h_16_8_10bpp_neon: 657.0 444.5
vp9_loop_filter_h_16_16_10bpp_neon: 1280.4 877.7
vp9_loop_filter_mix2_h_44_16_10bpp_neon: 397.7 358.0
vp9_loop_filter_mix2_h_48_16_10bpp_neon: 465.7 429.0
vp9_loop_filter_mix2_h_84_16_10bpp_neon: 465.7 428.0
vp9_loop_filter_mix2_h_88_16_10bpp_neon: 533.7 499.0
vp9_loop_filter_mix2_v_44_16_10bpp_neon: 271.5 244.0
vp9_loop_filter_mix2_v_48_16_10bpp_neon: 330.0 305.0
vp9_loop_filter_mix2_v_84_16_10bpp_neon: 329.0 306.0
vp9_loop_filter_mix2_v_88_16_10bpp_neon: 386.0 365.0
vp9_loop_filter_v_4_8_10bpp_neon: 150.0 115.2
vp9_loop_filter_v_8_8_10bpp_neon: 209.0 175.5
vp9_loop_filter_v_16_8_10bpp_neon: 492.7 345.2
vp9_loop_filter_v_16_16_10bpp_neon: 951.0 682.7
This is significantly faster than the ARM version in almost
all cases except for the mix2 functions.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 2-3x.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
Compared to the arm version, on aarch64 we can keep the full 8x8
transform in registers, and for 16x16 and 32x32, we can process
it in slices of 4 pixels instead of 2.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_inv_adst_adst_4x4_sub4_add_10_neon: 111.0 109.7
vp9_inv_adst_adst_8x8_sub8_add_10_neon: 914.0 733.5
vp9_inv_adst_adst_16x16_sub16_add_10_neon: 5184.0 3745.7
vp9_inv_dct_dct_4x4_sub1_add_10_neon: 65.0 65.7
vp9_inv_dct_dct_4x4_sub4_add_10_neon: 100.0 96.7
vp9_inv_dct_dct_8x8_sub1_add_10_neon: 111.0 119.7
vp9_inv_dct_dct_8x8_sub8_add_10_neon: 618.0 494.7
vp9_inv_dct_dct_16x16_sub1_add_10_neon: 295.1 284.6
vp9_inv_dct_dct_16x16_sub2_add_10_neon: 2303.2 1883.9
vp9_inv_dct_dct_16x16_sub8_add_10_neon: 2984.8 2189.3
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 3890.0 2799.4
vp9_inv_dct_dct_32x32_sub1_add_10_neon: 1044.4 1012.7
vp9_inv_dct_dct_32x32_sub2_add_10_neon: 13333.7 9695.1
vp9_inv_dct_dct_32x32_sub16_add_10_neon: 18531.3 12459.8
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 24470.7 16160.2
vp9_inv_wht_wht_4x4_sub4_add_10_neon: 83.0 79.7
The larger transforms are significantly faster than the corresponding
ARM versions.
The speedup vs C code is smaller than in 32 bit mode, probably
because the 64 bit intermediates in the C code can be expressed
more efficiently in aarch64.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This has mostly got the same differences to the 8 bit version as
in the arm version. For the horizontal filters, we do 16 pixels
in parallel as well. For the 8 pixel wide vertical filters, we can
accumulate 4 rows before storing, just as in the 8 bit version.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_avg4_10bpp_neon: 35.7 30.7
vp9_avg8_10bpp_neon: 93.5 84.7
vp9_avg16_10bpp_neon: 324.4 296.6
vp9_avg32_10bpp_neon: 1236.5 1148.2
vp9_avg64_10bpp_neon: 4639.6 4571.1
vp9_avg_8tap_smooth_4h_10bpp_neon: 130.0 128.0
vp9_avg_8tap_smooth_4hv_10bpp_neon: 440.0 440.5
vp9_avg_8tap_smooth_4v_10bpp_neon: 114.0 105.5
vp9_avg_8tap_smooth_8h_10bpp_neon: 327.0 314.0
vp9_avg_8tap_smooth_8hv_10bpp_neon: 918.7 865.4
vp9_avg_8tap_smooth_8v_10bpp_neon: 330.0 300.2
vp9_avg_8tap_smooth_16h_10bpp_neon: 1187.5 1155.5
vp9_avg_8tap_smooth_16hv_10bpp_neon: 2663.1 2591.0
vp9_avg_8tap_smooth_16v_10bpp_neon: 1107.4 1078.3
vp9_avg_8tap_smooth_64h_10bpp_neon: 17754.6 17454.7
vp9_avg_8tap_smooth_64hv_10bpp_neon: 33285.2 33001.5
vp9_avg_8tap_smooth_64v_10bpp_neon: 16066.9 16048.6
vp9_put4_10bpp_neon: 25.5 21.7
vp9_put8_10bpp_neon: 56.0 52.0
vp9_put16_10bpp_neon/armv8: 183.0 163.1
vp9_put32_10bpp_neon/armv8: 678.6 563.1
vp9_put64_10bpp_neon/armv8: 2679.9 2195.8
vp9_put_8tap_smooth_4h_10bpp_neon: 120.0 118.0
vp9_put_8tap_smooth_4hv_10bpp_neon: 435.2 435.0
vp9_put_8tap_smooth_4v_10bpp_neon: 107.0 98.2
vp9_put_8tap_smooth_8h_10bpp_neon: 303.0 290.0
vp9_put_8tap_smooth_8hv_10bpp_neon: 893.7 828.7
vp9_put_8tap_smooth_8v_10bpp_neon: 305.5 263.5
vp9_put_8tap_smooth_16h_10bpp_neon: 1089.1 1059.2
vp9_put_8tap_smooth_16hv_10bpp_neon: 2578.8 2452.4
vp9_put_8tap_smooth_16v_10bpp_neon: 1009.5 933.5
vp9_put_8tap_smooth_64h_10bpp_neon: 16223.4 15918.6
vp9_put_8tap_smooth_64hv_10bpp_neon: 32153.0 31016.2
vp9_put_8tap_smooth_64v_10bpp_neon: 14516.5 13748.1
These are generally about as fast as the corresponding ARM
routines on the same CPU (at least on the A53), in most cases
marginally faster.
The speedup vs C code is around 4-9x.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This is more in line with how it will be extended for more bitdepths.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This is pretty much similar to the 8 bpp version, but in some senses
simpler. All input pixels are 16 bits, and all intermediates also fit
in 16 bits, so there's no lengthening/narrowing in the filter at all.
For the full 16 pixel wide filter, we can only process 4 pixels at a time
(using an implementation very much similar to the one for 8 bpp),
but we can do 8 pixels at a time for the 4 and 8 pixel wide filters with
a different implementation of the core filter.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_loop_filter_h_4_8_10bpp_neon: 1.83 2.16 1.40 2.09
vp9_loop_filter_h_8_8_10bpp_neon: 1.39 1.67 1.24 1.70
vp9_loop_filter_h_16_8_10bpp_neon: 1.56 1.47 1.10 1.81
vp9_loop_filter_h_16_16_10bpp_neon: 1.94 1.69 1.33 2.24
vp9_loop_filter_mix2_h_44_16_10bpp_neon: 2.01 2.27 1.67 2.39
vp9_loop_filter_mix2_h_48_16_10bpp_neon: 1.84 2.06 1.45 2.19
vp9_loop_filter_mix2_h_84_16_10bpp_neon: 1.89 2.20 1.47 2.29
vp9_loop_filter_mix2_h_88_16_10bpp_neon: 1.69 2.12 1.47 2.08
vp9_loop_filter_mix2_v_44_16_10bpp_neon: 3.16 3.98 2.50 4.05
vp9_loop_filter_mix2_v_48_16_10bpp_neon: 2.84 3.64 2.25 3.77
vp9_loop_filter_mix2_v_84_16_10bpp_neon: 2.65 3.45 2.16 3.54
vp9_loop_filter_mix2_v_88_16_10bpp_neon: 2.55 3.30 2.16 3.55
vp9_loop_filter_v_4_8_10bpp_neon: 2.85 3.97 2.24 3.68
vp9_loop_filter_v_8_8_10bpp_neon: 2.27 3.19 1.96 3.08
vp9_loop_filter_v_16_8_10bpp_neon: 3.42 2.74 2.26 4.40
vp9_loop_filter_v_16_16_10bpp_neon: 2.86 2.44 1.93 3.88
The speedup vs C code measured in checkasm is around 1.1-4x.
These numbers are quite inconclusive though, since the checkasm test
runs multiple filterings on top of each other, so later rounds might
end up with different codepaths (different decisions on which filter
to apply, based on input pixel differences).
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 2-4x.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This is structured similarly to the 8 bit version. In the 8 bit
version, the coefficients are 16 bits, and intermediates are 32 bits.
Here, the coefficients are 32 bit. For the 4x4 transforms for 10 bit
content, the intermediates also fit in 32 bits, but for all other
transforms (4x4 for 12 bit content, and 8x8 and larger for both 10
and 12 bit) the intermediates are 64 bit.
For the existing 8 bit case, the 8x8 transform fit all coefficients in
registers; for 10/12 bit, when the coefficients are 32 bit, the 8x8
transform also has to be done in slices of 4 pixels (just as 16x16 and
32x32 for 8 bit).
The slice width also shrinks from 4 elements to 2 elements in parallel
for the 16x16 and 32x32 cases.
The 16 bit coefficients from idct_coeffs and similar tables also need
to be lenghtened to 32 bit in order to be used in multiplication with
vectors with 32 bit elements. This leads to the fixed coefficient
vectors needing more space, leading to more cases where they have to
be reloaded within the transform (in iadst16).
This technically would need testing in checkasm for subpartitions
in increments of 2, but that slows down normal checkasm runs
excessively.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_inv_adst_adst_4x4_sub4_add_10_neon: 4.83 11.36 5.22 6.77
vp9_inv_adst_adst_8x8_sub8_add_10_neon: 4.12 7.60 4.06 4.84
vp9_inv_adst_adst_16x16_sub16_add_10_neon: 3.93 8.16 4.52 5.35
vp9_inv_dct_dct_4x4_sub1_add_10_neon: 1.36 2.57 1.41 1.61
vp9_inv_dct_dct_4x4_sub4_add_10_neon: 4.24 8.66 5.06 5.81
vp9_inv_dct_dct_8x8_sub1_add_10_neon: 2.63 4.18 1.68 2.87
vp9_inv_dct_dct_8x8_sub4_add_10_neon: 4.52 9.47 4.24 5.39
vp9_inv_dct_dct_8x8_sub8_add_10_neon: 3.45 7.34 3.45 4.30
vp9_inv_dct_dct_16x16_sub1_add_10_neon: 3.56 6.21 2.47 4.32
vp9_inv_dct_dct_16x16_sub2_add_10_neon: 5.68 12.73 5.28 7.07
vp9_inv_dct_dct_16x16_sub8_add_10_neon: 4.42 9.28 4.24 5.45
vp9_inv_dct_dct_16x16_sub16_add_10_neon: 3.41 7.29 3.35 4.19
vp9_inv_dct_dct_32x32_sub1_add_10_neon: 4.52 8.35 3.83 6.40
vp9_inv_dct_dct_32x32_sub2_add_10_neon: 5.86 13.19 6.14 7.04
vp9_inv_dct_dct_32x32_sub16_add_10_neon: 4.29 8.11 4.59 5.06
vp9_inv_dct_dct_32x32_sub32_add_10_neon: 3.31 5.70 3.56 3.84
vp9_inv_wht_wht_4x4_sub4_add_10_neon: 1.89 2.80 1.82 1.97
The speedup compared to the C functions is around 1.3 to 7x for the
full transforms, even higher for the smaller subpartitions.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
The plain pixel put/copy functions are used from the 8 bit version,
for the double size (e.g. put16 uses ff_vp9_copy32_neon), and a new
copy128 is added.
Compared with the 8 bit version, the filters can no longer use the
trick to accumulate in 16 bit with only saturation at the end, but now
the accumulators need to be 32 bit. This avoids the need to keep track
of which filter index is the largest though, reducing the size of the
executable code for these filters.
For the horizontal filters, we only do 4 or 8 pixels wide in parallel
(while doing two rows at a time), since we don't have enough register
space to filter 16 pixels wide.
For the vertical filters, we still do 4 and 8 pixels in parallel just
as in the 8 bit case, but we need to store the output after every 2
rows instead of after every 4 rows.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_avg4_10bpp_neon: 2.25 2.44 3.05 2.16
vp9_avg8_10bpp_neon: 3.66 8.48 3.86 3.50
vp9_avg16_10bpp_neon: 3.39 8.26 3.37 2.72
vp9_avg32_10bpp_neon: 4.03 10.20 4.07 3.42
vp9_avg64_10bpp_neon: 4.15 10.01 4.13 3.70
vp9_avg_8tap_smooth_4h_10bpp_neon: 3.38 6.22 3.41 4.75
vp9_avg_8tap_smooth_4hv_10bpp_neon: 3.89 6.39 4.30 5.32
vp9_avg_8tap_smooth_4v_10bpp_neon: 5.32 9.73 6.34 7.31
vp9_avg_8tap_smooth_8h_10bpp_neon: 4.45 9.40 4.68 6.87
vp9_avg_8tap_smooth_8hv_10bpp_neon: 4.64 8.91 5.44 6.47
vp9_avg_8tap_smooth_8v_10bpp_neon: 6.44 13.42 8.68 8.79
vp9_avg_8tap_smooth_64h_10bpp_neon: 4.66 9.02 4.84 7.71
vp9_avg_8tap_smooth_64hv_10bpp_neon: 4.61 9.14 4.92 7.10
vp9_avg_8tap_smooth_64v_10bpp_neon: 6.90 14.13 9.57 10.41
vp9_put4_10bpp_neon: 1.33 1.46 2.09 1.33
vp9_put8_10bpp_neon: 1.57 3.42 1.83 1.84
vp9_put16_10bpp_neon: 1.55 4.78 2.17 1.89
vp9_put32_10bpp_neon: 2.06 5.35 2.14 2.30
vp9_put64_10bpp_neon: 3.00 2.41 1.95 1.66
vp9_put_8tap_smooth_4h_10bpp_neon: 3.19 5.81 3.31 4.63
vp9_put_8tap_smooth_4hv_10bpp_neon: 3.86 6.22 4.32 5.21
vp9_put_8tap_smooth_4v_10bpp_neon: 5.40 9.77 6.08 7.21
vp9_put_8tap_smooth_8h_10bpp_neon: 4.22 8.41 4.46 6.63
vp9_put_8tap_smooth_8hv_10bpp_neon: 4.56 8.51 5.39 6.25
vp9_put_8tap_smooth_8v_10bpp_neon: 6.60 12.43 8.17 8.89
vp9_put_8tap_smooth_64h_10bpp_neon: 4.41 8.59 4.54 7.49
vp9_put_8tap_smooth_64hv_10bpp_neon: 4.43 8.58 5.34 6.63
vp9_put_8tap_smooth_64v_10bpp_neon: 7.26 13.92 9.27 10.92
For the larger 8tap filters, the speedup vs C code is around 4-14x.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
This is more in line with how it will be extended for more bitdepths.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'fd5e6a095f69495c558069315d6b36ea410c31fa':
x86util: Extend SPLATW for avx2
This commit is a noop, see 1ace9573dc
(only libavutil/x86/x86util.asm chunk).
Merged-by: Clément Bœsch <u@pkh.me>
* commit '37961044c6':
checkasm: arm: Ignore changes to bits 0-4 and 7 of FPSCR
cheackasm/arm: remove NEON instructions from checkasm_checked_call_vfp
checkasm: arm: Don't start new const blocks for each string
This merge is a noop: the changes were included in 9f1c81e5ec.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '5ece6911010b3464d2fdacfa8031c15b5bd83418':
apichanges: Fill in missing hashes and dates
This commit is a noop as we need to fill with our own hashes.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'facdfe40805559963b5875931af9406ed5ddcd5c':
swscale: Add proper ff_ prefix to init functions
This commit is a noop, see e8c3716064
I'm keeping our ff_sws_ vs ff_ since we use ff_sws_ in other places in
swscale.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'c0fd2fb27bebd1d5ab028e6df6bca9119d269122':
swscale: Rename sws_context_class to ff_sws_context_class
This commit is a noop, see 8bfbc8c5e5
Merged-by: Clément Bœsch <u@pkh.me>
* commit '71a0472114574993df7035f4de9aa007e03817b8':
checkasm: arm: report the first clobbered register in checkasm_checked_call
Also includes 446353ea18, 59aeed93e4, and 37961044c6 to avoid breaking
too much stuff.
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'a8fce24b9c5a87187f5bd864b18f5b3e575f8c3d':
avconv_dxva2: support HEVC Main10 decoding
This commit is a noop, see 1ec14612a5
Merged-by: Clément Bœsch <u@pkh.me>
* commit '33f6690eb4e21acc4b581688eecfc4cc5ea9515e':
hevc: offer DXVA2 for 10bit 420
This commit is a noop, see ccb94789e2
Merged-by: Clément Bœsch <u@pkh.me>
* commit '38efff92f1ef81f3de20ff0460ec7b70c253d714':
FATE: add a test for H.264 with two fields per packet
h264: fix decoding multiple fields per packet with slice threads
This merge includes two commits because the FATE test was useful in
order to make proper testing.
The merge gets rid of the now unused:
- SLICE_SINGLETHREAD and SLICE_SKIPED macros
- max_contexts
- "again" label in decode_nal_units()
This commit also includes the fix from d3e4d406b.
Thanks to wm4 and Michael Niedermayer for their testing.
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
This treats the case of no slices like no frames which it basically is.
The field is added to the context as other nal related fields are also there
and passing the has_slices field per *arguments is ugly and not consistent
Found-by: ubitux
Approved-by: ubitux
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If fifo is enabled on tee muxer, ffmpeg exits because of an unknown option passed to fifo muxer.
Option name "format_options" was replaced by "format_opts" on tee muxer.
Signed-off-by: Felipe Astroza <felipe@astroza.cl>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
CUVID on GeForce GT 730 and GeForce GTX 1060 does not report any error when
decoding 8K h264 packets. However, it does return an error during
cuvidCreateDecoder call if the indicated video resolution is not
supported.
Given that stream resolution is typically known as a result of probing
it is better to use this information during avcodec_open2 call to fail
immediately, rather than proceeding to decode and never receiving any
frames from the decoder nor receiving any indication of decode failure.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This happens because segment_end() returns an error, so seg_write_packet
never proceeds to segment_start(), and seg->avf->pb is never re-set,
so we crash with a null pb when av_write_trailer flushes the packet
queue.
This doesn't seem to be clearly recoverable, so I'm just failing more
gracefully.
Repro:
ffmpeg -i input.ts -f segment -c copy -segment_list /noaxx.m3u8 test-%05d.ts
(assuming you don't have write access to /)
This makes the code 7 times faster with the testcase from libfuzzer
and should reduce the amount of timeouts we hit in automated fuzzing.
(for example 438/fuzz-2-ffmpeg_VIDEO_AV_CODEC_ID_RV40_fuzzer)
The code is also faster with more realistic input though the difference
is small here as that is far from the worst cases the fuzzers pick out
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
use av_lfg_init_from_data() to seed AC-3 dithering from the AC-3 frame
data to make it consistent given the same AC-3 frame, if option is set.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Raises max channels to 6 (for non joint-stereo only),
there is no difference decoding 1 or N discrete channels.
Fixes trac issue #5840
Signed-off-by: bnnm <bananaman255@gmail.com>
When use http method to delete the old segments,
there is only io_open, hove not io_close yet,
this patch is used to fix it
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
when push hls to http server, the old segemnts can not delete by hls formats.
so add the http option into hls_delete_old_segments
Reported-by: Yin Jiaoyuan <yinjiaoyuan@163.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Moves much of the setup logic for VAAPI decoding into lavc; the user
now need only provide the hw_frames_ctx.
(cherry picked from commit 123ccd07c5)
(cherry picked from commit 5e879b54a3)
(cherry picked from commit 0aec37e625)
(cherry picked from commit cfa4eb4fba)
* commit 'f450cc7bc595155bacdb9f5d2414a076ccf81b4a':
h264: eliminate decode_postinit()
Also includes fixes from 1f7b4f9abc and e344e65109.
Original patch replace H264Context.next_output_pic (H264Picture *) by
H264Context.output_frame (AVFrame *). This change is discarded as it
is incompatible with the frame reconstruction and motion vectors
display code which needs the extra information from the H264Picture.
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
We can pick the correct slice index directly from the ID3D11VideoDecoderOutputView
casted from data[3].
Also added myself as maintainer for DXVA2 and D3D11VA.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
No need to loop through the known surfaces, we'll use the requested surface
anyway.
The loop is only done for DXVA2.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When support for this was added the details weren't yet finalized.
This is no longer the case.
Fixes writing of mkv/webm files with HDR.
Reported-by: Kagami Hiiragi <kagami@genshiken.org>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
This work is sponsored by, and copyright, Google.
Previously all subpartitions except the eob=1 (DC) case ran with
the same runtime:
vp9_inv_dct_dct_16x16_sub16_add_neon: 1373.2
vp9_inv_dct_dct_32x32_sub32_add_neon: 8089.0
By skipping individual 8x16 or 8x32 pixel slices in the first pass,
we reduce the runtime of these functions like this:
vp9_inv_dct_dct_16x16_sub1_add_neon: 235.3
vp9_inv_dct_dct_16x16_sub2_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub4_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub8_add_neon: 1036.7
vp9_inv_dct_dct_16x16_sub12_add_neon: 1372.1
vp9_inv_dct_dct_16x16_sub16_add_neon: 1372.1
vp9_inv_dct_dct_32x32_sub1_add_neon: 555.1
vp9_inv_dct_dct_32x32_sub2_add_neon: 5190.2
vp9_inv_dct_dct_32x32_sub4_add_neon: 5180.0
vp9_inv_dct_dct_32x32_sub8_add_neon: 5183.1
vp9_inv_dct_dct_32x32_sub12_add_neon: 6161.5
vp9_inv_dct_dct_32x32_sub16_add_neon: 6155.5
vp9_inv_dct_dct_32x32_sub20_add_neon: 7136.3
vp9_inv_dct_dct_32x32_sub24_add_neon: 7128.4
vp9_inv_dct_dct_32x32_sub28_add_neon: 8098.9
vp9_inv_dct_dct_32x32_sub32_add_neon: 8098.8
I.e. in general a very minor overhead for the full subpartition case due
to the additional cmps, but a significant speedup for the cases when we
only need to process a small part of the actual input data.
This is cherrypicked from libav commits
cad42fadcd and
a0c443a398.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This work is sponsored by, and copyright, Google.
Previously all subpartitions except the eob=1 (DC) case ran with
the same runtime:
Cortex A7 A8 A9 A53
vp9_inv_dct_dct_16x16_sub16_add_neon: 3188.1 2435.4 2499.0 1969.0
vp9_inv_dct_dct_32x32_sub32_add_neon: 18531.7 16582.3 14207.6 12000.3
By skipping individual 4x16 or 4x32 pixel slices in the first pass,
we reduce the runtime of these functions like this:
vp9_inv_dct_dct_16x16_sub1_add_neon: 274.6 189.5 211.7 235.8
vp9_inv_dct_dct_16x16_sub2_add_neon: 2064.0 1534.8 1719.4 1248.7
vp9_inv_dct_dct_16x16_sub4_add_neon: 2135.0 1477.2 1736.3 1249.5
vp9_inv_dct_dct_16x16_sub8_add_neon: 2446.7 1828.7 1993.6 1494.7
vp9_inv_dct_dct_16x16_sub12_add_neon: 2832.4 2118.3 2266.5 1735.1
vp9_inv_dct_dct_16x16_sub16_add_neon: 3211.7 2475.3 2523.5 1983.1
vp9_inv_dct_dct_32x32_sub1_add_neon: 756.2 456.7 862.0 553.9
vp9_inv_dct_dct_32x32_sub2_add_neon: 10682.2 8190.4 8539.2 6762.5
vp9_inv_dct_dct_32x32_sub4_add_neon: 10813.5 8014.9 8518.3 6762.8
vp9_inv_dct_dct_32x32_sub8_add_neon: 11859.6 9313.0 9347.4 7514.5
vp9_inv_dct_dct_32x32_sub12_add_neon: 12946.6 10752.4 10192.2 8280.2
vp9_inv_dct_dct_32x32_sub16_add_neon: 14074.6 11946.5 11001.4 9008.6
vp9_inv_dct_dct_32x32_sub20_add_neon: 15269.9 13662.7 11816.1 9762.6
vp9_inv_dct_dct_32x32_sub24_add_neon: 16327.9 14940.1 12626.7 10516.0
vp9_inv_dct_dct_32x32_sub28_add_neon: 17462.7 15776.1 13446.2 11264.7
vp9_inv_dct_dct_32x32_sub32_add_neon: 18575.5 17157.0 14249.3 12015.1
I.e. in general a very minor overhead for the full subpartition case due
to the additional loads and cmps, but a significant speedup for the cases
when we only need to process a small part of the actual input data.
In common VP9 content in a few inspected clips, 70-90% of the non-dc-only
16x16 and 32x32 IDCTs only have nonzero coefficients in the upper left
8x8 or 16x16 subpartitions respectively.
This is cherrypicked from libav commit
9c8bc74c2b.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids reloading them if they haven't been clobbered, if the
first pass also was idct.
This is similar to what was done in the aarch64 version.
This is cherrypicked from libav commit
3c87039a40.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since the same parameter is used for both input and output,
the name inout is more fitting.
This matches the naming used below in the dmbutterfly macro.
This is cherrypicked from libav commit
79566ec8c7.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The clobbering tests in checkasm are only invoked when testing
correctness, so this bug didn't show up when benchmarking the
dc-only version.
This is cherrypicked from libav commit
4d960a1185.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is one instruction less for thumb, and only have got
1/2 arm/thumb specific instructions.
This is cherrypicked from libav commit
e5b0fc170f.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The latter is 1 cycle faster on a cortex-53 and since the operands are
bytewise (or larger) bitmask (impossible to overflow to zero) both are
equivalent.
This is cherrypicked from libav commit
e7ae8f7a71.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since aarch64 has enough free general purpose registers use them to
branch to the appropiate storage code. 1-2 cycles faster for the
functions using loop_filter 8/16, ... on a cortex-a53. Mixed results
(up to 2 cycles faster/slower) on a cortex-a57.
This is cherrypicked from libav commit
d7595de0b2.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Seemingly ff_clear_block_sse assumed that the block array is aligned,
so make sure it is.
Fixes ticket #6079
Signed-off-by: James Almer <jamrial@gmail.com>
when hlsenc use flag second_level_segment_index,
second_level_segment_size and second_level_segment_duration,
the rename is ok but the output filename always use the old filename
so move the rename operation after the close the ts file and
before open new segment
Reported-by: Christian Johannesen <chrisjohannesen@gmail.com>
Reviewed-by: Bodecs Bela <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
CID: 1396852
check the devices_list alloc status,
and release the devices_list when alloc devices error
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
avfilter_graph_request_oldest() does work that should be done by
either the filter or the application.
The principle of this function, calling ff_request_frame() from
outside the filter was always shaky. This version is less elegant
since it requires making special cases for each filter, but it
is more robust since it no longer calls ff_request_frame()
directly without notifying the filter.
Eventually, avfilter_graph_request_oldest() will be deprecated
for a function to just run the graph.
Unlike av_frame_is_writable(), it uses the link's alloc callback,
making direct rendering possible.
The code comes from ff_filter_frame_framed(), moved with mostly
trivial changes.
start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to specify start_number source parameter by
introducing hls_start_number_source with 3 possible values:
generic/epoch/datetime. This ensures to set start sequence number
automatically for practically unique numbers. Generic option is the
default and this is the curent behaviour: start_number option value
specifies the start sequence number. (start_number default value is 0)
If hls_start_number_source is set to epoch, then the start number will
be the seconds since epoch (1970-01-01 00:00:00). If set to datetime,
then the start sequence number will be based on the current date/time
value as YYYYmmddHHMMSS. e.g. 20161231235659.
Hls speficication allows 64 bit integers as sequence numbers. This patch
also changes some code where only 32 bit integer values were handled
correctly.
Reviewed-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Reason: For some cases, such as 2 or more graphics cards existing, the
default command line may fail because ffmpeg does not open the correct
device node:
ffmpeg -hwaccel qsv -c:v h264_qsv -i test.264 -c:v h264_qsv out.264
Let user choose the proper one by running like below:
ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -c:v h264_qsv \
-i test.264 -c:v h264_qsv out.264
Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com>
Signed-off-by: Huang, Zhengxu <zhengxu.maxwell@gmail.com>
Signed-off-by: Andrew, Zhang <huazh407@gmail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
This decoder can decode all existing SpeedHQ formats (SHQ0–5, 7, and 9),
including correct decoding of the alpha channel.
1080p is decoded in 142 fps on one core of my i7-4600U (2.1 GHz Haswell),
about evenly split between bitstream reader and IDCT. There is currently
no attempt at slice or frame threading, even though the format trivially
supports both.
NewTek very helpfully provided a full set of SHQ samples, as well as
source code for an SHQ2 encoder (not included) and assistance with
understanding some details of the format.
This is what gimp, ImageMagick and FreeImage do and what the
Adobe Photoshop file format specification suggests.
Fixes a sample from ticket #6045.
Reviewed-by: Martin Vignali
when the segments largest duration value is look like 4.000000, the
EXT-X-TARGETDURATION value should equ 4.
it's wrong when hlsenc use ceil, so fix it.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
cid: 1396268
when av_strdup(str) error, the lst need release
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
This should make no difference as the value should not be able to be that large
but its more correct this way
Fixes CID1348138
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When allocating stack space with an alignment requirement that is larger
than the current stack alignment we need to store a copy of the original
stack pointer in order to be able to restore it later.
If we chose to use another register for this purpose we should not pick
eax/rax since it can be overwritten as a return value.
Disable B frames when using baseline/constrained baseline profile,
following H.264 spec Annex A.2.1.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Yi A Wang <yi.a.wang@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
When the command line for children is created, it is assumed that
my_program_name always ends with "ffserver", which doesn't have to
be true if ffserver is called through a symbolic link.
In such a case, it could be that not enough space for "ffmpeg" is
available at the end, leading to a buffer overflow.
One example would be:
$ ln -s /usr/bin/ffserver ~/f; ~/f
As this is only a local buffer overflow, i.e. is based on a weird
program call, this has NO security impact.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The following three commits created a regression by writing initially
invalid mkv headers:
650e17d88b avformat/matroskaenc: write a
CRC32 element on Tags
3bcadf8227 avformat/matroskaenc: write a
CRC32 element on Info
ee888cfbe7 avformat/matroskaenc: postpone
writing the Tracks master
Symptoms:
- You can no longer playback a file that is still processed by ffmpeg,
e.g. VLC fails playback
- You can no longer stream a file to a client while if is still being
processed
- Various diagnosing tools show header errors or incomplete headers
(e.g. ffprobe, mediainfo, mkvalidator)
Note: The symptoms do not apply to completed files or ffmpeg runs that
were interrupted with 'q'
Cause:
The mentioned commits made changes in a way that some header elements
are only partially written in
mkv_write_header, leaving the header in an invalid state. Only in
mkv_write_trailer, these elements
are finished correctly, but that does only occur at the end of the
process.
Regression:
Before these commits were applied, mkv headers have always been valid,
even before completion of ffmpeg.
This has worked reliably over many versions of ffmpeg, to it was an
obvious regression.
Bugtracker:
This issue has been recorded as #5977 which is resolved by this patch
Patch:
The patch adds a new function 'end_ebml_master_crc32_preliminary' that
preliminarily finishes the ebml
element without destroying the buffer. The buffer can be used to update
the ebml element later during
mkv_write_trailer. But most important: mkv_write_header finishes with a
valid mkv header again.
Signed-off-by: James Almer <jamrial@gmail.com>
This commit adds the avio_get_dyn_buf function which allows accessing
the
content of a DynBuffer without destroying it.
This is required in matroskaenc for preliminary writing (correct) mkv
headers.
Context for this change is fixing regression bug #5977.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
looks like there is a bug in commit
1a08758e7c relating to the handling of
ptr in decode_frame after decode_block is called, before this commit
ptr would have been incremented for each line in the data window, now
after the commit it is left at the start of the first included line
rather than the line after the data window then the code sets the
remaining lines to 0 and thus the whole image is over written.
Fix by adjusting ptr to the correct line after decode_block returns
Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
This commit replaces the current inefficient non-power-of-two FFT with a
much faster FFT based on the Prime Factor Algorithm.
Although it is already much faster than the old algorithm without SIMD,
the new algorithm makes use of the already very throughouly SIMD'd power
of two FFT, which improves performance even more across all platforms
which we have SIMD support for.
Most of the work was done by Peter Barfuss, who passed the code to me to
implement into the iMDCT and the current codebase. The code for a
5-point and 15-point FFT was derived from the previous implementation,
although it was optimized and simplified, which will make its future
SIMD easier. The 15-point FFT is currently using 6% of the current
overall decoder overhead.
The FFT can now easily be used as a forward transform by simply not
multiplying the 5-point FFT's imaginary component by -1 (which comes
from the fact that changing the complex exponential's angle by -1 also
changes the output by that) and by multiplying the "theta" angle of the
main exptab by -1. Hence the deliberately left multiplication by -1 at
the end.
FATE passes, and performance reports on other platforms/CPUs are
welcome.
Performance comparisons:
iMDCT, PFA:
101127 decicycles in speed, 32765 runs, 3 skips
iMDCT, Old:
211022 decicycles in speed, 32768 runs, 0 skips
Standalone FFT, 300000 transforms of size 960:
PFA Old FFT kiss_fft libfftw3f
3.659695s, 15.726912s, 13.300789s, 1.182222s
Being only 3x slower than libfftw3f is a big achievement by itself.
There appears to be something capping the performance in the iMDCT side
of things, possibly during the pre-stage reindexing. However, it is
certainly fast enough for now.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Prep work for the next commit, which will add a new FFT algorithm
which makes the iMDCT over 3x faster than it is currently (standalone,
the FFT is with some framesizes over 10x faster).
The new FFT algorithm uses the already thouroughly SIMD'd power of two
FFT which already has SIMD for AArch64, so users of that platform will
still see an improvement.
The previous FFT+SIMD was barely 2.5x faster than the C versions on these
platforms.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
CID: 1398228
Passing null pointer dirname to strlen, which dereferences it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
in get_default_pattern_localtime_fmt the default pattern contains
%Y%m%d%H%I%S but the original intention was %Y%m%d%H%M%S
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
fix CID: 1398364 Resource leak
refine the code of the new options
Reviewed-by: Bodecs Bela <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
A wrong, unitialized variable is used for testing. This patch fixes this
typo.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
1st:
This patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 20000 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
2nd:
doc/muxers: beside second_level_segment_duration and second_level_segment_size,
added some more details and example to hls_segment_filename,
use_localtime, use_localtime_mkdir, hls_flags. hls_flags option list
reformatted to table
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
if the http server don't response the http command,
then the thread will be blocked and never be interrupted.
Reported-by: yinyunjiang <yinyunjiang1991@qq.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Round qpIntra and qpInter calculation instead of old floor behavior.
Adopted from vaapi_encode_h264.c
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Current implementation of finding duplicate segment filenames may fail
if use_localtime_mkdir and use_localtime are in effect and
segment_filename option expression contains subdirectories with
date/time specifiers. This patch fixes this false behaviour.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
in hlcenc.c, in the hls_write_header() function the default format
string for strftime() function contains %s specifier when use_localtime
is true. This %s specifier will insert the seconds since EPOCH. But %s
is not available on all system/environment. This patch check %s
availabilty at runtine and alter the default format string if necessary.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
cutoff is implemented as an option global to lavc, but supported only
by a few encoders. This fact is now reflected in its documentation. ac3's
support of this option is added for completeness.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Pass the cutoff option from lavc's avcodec_options[] to libmp3lame's
lowpass option, without allowing to adjust its default behavior.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Prevents memory leak when read_samples_from_audio_fifo() is
called more than once by deallocating before reallocating
more memory.
Fixes space indentation for contents in ERROR().
Signed-off-by: Thomas Turner <thomastdt@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Old ICC verions don't advertise having a full C11 implementation but
may nonetheless include a feature-incomplete stdatomic.h header.
Fixes ticket #6049
Signed-off-by: James Almer <jamrial@gmail.com>
In ff_index_search_timestamp(), if b == num_entries,
m == num_entries - 1, and entries[m].flags & AVINDEX_DISCARD_FRAME is
true, then the search for the next non-discarded packet could access
entries[nb_entries], exceeding its bounds. This change adds a protection
against that scenario. Reference: https://crbug.com/666770
Reviewed-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When delete_segments hls_flag is specified, deleting old segments may
fail in certain cases when use_localtime_mkdir is in effect and
hls_segment_filename expression contains subdirs. This patch fixes this
behaviour.
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%.
Changed fate-suite sample files:
* filter/hdcd-mix.flac (958K) added. It is a much better test than
filter/hdcd.flac (910K), which is now unused, but can't be removed.
* filter/hdcd-fake20bit.flac (168K) added. It is the first second of
filter/hdcd.flac, with the 16-bit LSB copied into bit 20 of a 24-bit
stream. There isn't an actual non-16-bit HDCD sample available to test.
Signed-off-by: Burt P <pburt0@gmail.com>
The checked bitstream reader does that already. To allow parsing of
superframes split over a packet boundary, we always decode the last
superframe in each packet at the start of the next packet, even if
theoretically we could have decoded it. The last superframe in the
last packet is decoded using AV_CODEC_CAP_DELAY.
in filenames
Putting date/time values into segment filenames is very usefull.
But to produce non-conflicting segment filenames with -use_localtime
option with date/time
values in hls_segment_filename option, sometimes is not enough.
Like in cases when multiple segments produced in the same second.
But hlsenc currently does not make possible to use segment index (%d) at
the
same time whe use_localtime is in effect, due to identifier conflict.
This patch makes possible to use strftime identifiers and still put
segment index (%d) at same time in segment filenames by introducing
second_level_segment_index flag. When -use_localtime is active,
identifier %d is for month day index, so %%d is the segment index
placeholder. This enhanced behaviour only exists when new
second_level_segment_index flag is specified.
For instance putting 'segment_%Y%m%d%H%M%S_%%05d.ts' value into
-hls_segment_filename option and specifing -hls_flags
second_level_segment_index and -use_localtime 1, may produce segment
filename as 'segment_20161230235758_00002.ts'
An example:
ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i anullsrc=r=44100:cl=stereo -c:v mpeg2video -g 25 -acodec aac
-cutoff 20000 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags delete_segments+second_level_segment_index -use_localtime 1
-hls_segment_filename "segment_%Y%m%d%H%M%S_%%05d.ts" stream.m3u8
will produce segments filenames:
....
segment_20161227005902_00013.ts
segment_20161227005902_00014.ts
segment_20161227005902_00015.ts
segment_20161227005903_00016.ts
segment_20161227005903_00017.ts
segment_20161227005903_00018.ts
segment_20161227005903_00019.ts
segment_20161227005903_00020.ts
....
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
initial_prog_date_time shouldn't be adjusted when deleting segments
from disk, but rather when segments are removed from the playlist.
Signed-off-by: Jesper Ek <deadbeef84@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
It is now bitexact with the ssse3 and sse4.1 versions of the function.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
ffmpeg-devel
with use_localtime parameter hlsenc may produce identical filenames for
different but still existing segments. It happens when
hls_segment_filename contains
syntacticaly correct but inadequate format parameters. Currently there
is no any log message when such a situaton occurs but these cases should
be avoided in most times. This patch generate warning log messages in
these cases.
ticketID: #6043
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>
This should fix issues on BSD
CLOCKS_PER_SEC is 128 on BSD while SUSv2 requires it to be a million
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes pts gaps when reading AVI files > 256GiB generated by FFmpeg.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
With min_samples, if a frame arrives but is too small, it clears
frame_wanted_out. In most cases, the destination filter would be
activated again later because of frame_wanted_out on its own
outputs, but not sinks.
avfilter_graph_request_oldest() is doing the work of the sink
itself, and is therefore allowed to use frame_blocked_in.
Configure checks if the ebx register can be used for asm and it has to
be saved if and only if this is not the case.
Without this the build fails when configuring with --toolchain=hardened
--disable-pic on i386 using gcc 4.8:
error: PIC register clobbered by '%ebx' in 'asm'
In that case gcc 4.8 reserves the ebx register for the GOT needed for
PIE, so it can't be used in asm directly.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A lot of changes happen at the same time:
- Add a framequeue fifo to AVFilterLink.
- split AVFilterLink.status into status_in and status_out: requires
changes to the few filters and programs that use it directly
(f_interleave, split, filtfmts).
- Add a field ready to AVFilterContext, marking when the filter is ready
and its activation priority.
- Add flags to mark blocked links.
- Change ff_filter_frame() to enqueue the frame.
- Change all filtering functions to update the ready field and the
blocked flags.
- Update ff_filter_graph_run_once() to use the ready field.
- buffersrc: always push the frame immediately.
This makes it possible to decode motion jpeg 2000
encoded in a transport stream without a correct PMT/PAT.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The assumption that avcodec_send_packet makes regarding decoders
consuming the entire packet is not true if the codec supports
truncated decoding mode and the truncated flag is turned on.
Steps to reproduce:
./ffmpeg_g -flags truncated \
-i "http://samples.ffmpeg.org/MPEG2/test-ebu-422.40000.pakets.ts" \
-c:v ffv1 -c:a copy -y /tmp/truncated.nut
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Clang is not able to eliminate the reference to ff_spdif_probe() when
there is a goto target in the same block and optimization is disabled.
This fixes the following build failure on OS X:
./configure --disable-everything --disable-doc \
--enable-decoder=pcm_s16le --enable-demuxer=wav \
--enable-protocol=file --disable-optimizations --cc=clang
make
...
Undefined symbols for architecture x86_64:
"_ff_spdif_probe", referenced from:
_set_spdif in libavformat.a(wavdec.o)
ld: symbol(s) not found for architecture x86_64
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most decoders return the amount of data used.
This is more consistent
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most decoders return the amount of data used.
This is more consistent
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most decoders return the amount of data used.
This is more consistent
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Most decoders return the amount of data used.
This is more consistent
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
MPEG Audio frame header must be 4 bytes. If we fail to read
4 bytes bail early to avoid Use-of-uninitialized-value msan error.
Reference https://crbug.com/666874.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Height of canvas produced by drawtext varies depending on symbols in
text, so add example for printing separate texts aligned horizontally.
Wording suggested by Lou Logan <lou@lrcd.com>
Signed-off-by: Andrey Utkin <andrey.utkin@pb.com>
Signed-off-by: Lou Logan <lou@lrcd.com>
Decode the Image Data Section (which contains merged pictures).
Support RGB/A and Grayscale/A in 8bits and 16 bits per channel.
Support uncompress and rle decompression in Image Data Section.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
integrate it inside multiple_resample
allow some calculations to be performed outside loop
Suggested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
-pie was added to C flags for ThreadSanitizer in commit
19f251a288. Under clang 3.8.0, the -pie
flag causes a compiler warning and a linker error when running configure
--toolchain=clang-tsan. Here is an excerpt from config.log:
clang ... -fsanitize=thread -pie -std=c11 -fomit-frame-pointer -pthread -c -o /tmp/ffconf.hL61stP9.o /tmp/ffconf.YO6ZaSFG.c
clang: warning: argument unused during compilation: '-pie'
clang -fsanitize=thread -pie -Wl,--as-needed -Wl,-z,noexecstack -o /tmp/ffconf.W5c2e41l /tmp/ffconf.hL61stP9.o -lbz2 -pthread
/usr/bin/ld: /tmp/ffconf.hL61stP9.o: relocation R_X86_64_PC32 against undefined symbol `atan2f@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
clang: error: linker command failed with exit code 1 (use -v to see invocation)
To be conservative, I changed -pie to -fPIE. But the documentation seems
to imply just -fsanitize=thread is enough:
http://clang.llvm.org/docs/ThreadSanitizer.htmlhttps://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Make the one-time initialization in av_get_cpu_flags() thread-safe. The
static variable |cpu_flags| in libavutil/cpu.c is read and written using
normal load and store operations. These are considered as data races.
The fix is to use atomic load and store operations.
The fix can be verified by running the libavutil/tests/cpu_init.c test
program under ThreadSanitizer:
./configure --toolchain=clang-tsan
make libavutil/tests/cpu_init
libavutil/tests/cpu_init
There should be no warnings from ThreadSanitizer.
Co-author: Dmitry Vyukov of Google, who suggested the data race fix.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The demuxer doesn't fill the defaults if the master isn't present.
This results in codecpar->color_space being set with a value of
zero (RGB) on such files.
Signed-off-by: James Almer <jamrial@gmail.com>
As I used simple RGBA formats for subtitles and for the video texture if
avfilter is disabled I kind of assumed that sws_scale won't access data
pointers and strides above index 0, but apparently that is not the case.
Fixes Coverity CID 1396737, 1396738, 1396739, 1396740.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
And only enable them, if they haven't been disabled.
This is needed for the following patch.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
ff_parse_close expects priv_data to be the ParseContext directly and
thus doesn't work if it isn't at the beginning of OpusParseContext.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Make ff_opus_parse_extradata free allocated memory on error instead of
expecting callers to free it in that case.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Since the default in the libav fork is to only allow known layouts, making
unknown layouts allowed by default here can be a security risk for filters
directly merged from libav. However, usually it is simple to detect such cases,
use of av_get_channel_layout_nb_channels is a good indicator, so I suggest we
change this regardless.
See http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/203204.html.
This patch indirectly adds unknown channel layout support for filters where
query_formats is not specified:
abench
afifo
ainterleave
anullsink
apad
aperms
arealtime
aselect
asendcmd
asetnsamples
asetpts
asettb
ashowinfo
azmq
It introduces a query_formats callback for the asyncts filter, which only
supports known channel layouts since it is using libavresample.
And it removes .query_formats callback from filters where it was only there to
support unknown layouts, as this is now the default:
aloop
ametadata
anull
asidedata
asplit
atrim
Acked-by: Nicolas George <george@nsup.org>
Signed-off-by: Marton Balint <cus@passwd.hu>
This decreases the amount of computations and memory needed for analysing mpeg1/2 streams
the properties update is moved from code that is skiped if skip_frame is set
to code that is not skiped so the change doesnt loose that
from being executed
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is faster 2871 -> 2189 cycles for int16 matrixbench -> 23456hz
Fixes a integer overflow in a artificial corner case
Fixes part of 668007-media
Found-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We are checking during encoding if there is enough space as version 4 needs that
check.
Fixes Ticket6005
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Examples use the native FFmpeg AAC encoder but it is no longer
considered experimental and therefore not required.
Signed-off-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 6a62795d40)
Cherry pick Suggested-by: Martin Storsjö
This should fix the build failure on macosx
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This implements Spherical Video V1 and V2, as described in the
spatial-media collection by Google.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
While no decoder currently exports spherical information, this type
represents a frame property that has to be passed through from container
to frames.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
av_find_stream_info() was deprecated by avformat_find_stream_info(),
correct the warning message in the avformat_find_stream_info() and
comments in the avformat.h
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is a bit messy as codecar does not support AVOptions so we need
to use AVCodecContext where AVOptions are required and copy back and forth.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The speex specification does not seem to restrict these values, thus
the limits where choosen so as to avoid multiplicative overflow
Fixes undefined behavior
Fixes: 635422.ogg
Found-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This would be simpler if codecpar supported AVOptions
modern ffserver should be unaffected by this, older ffserver which required the
muxer to directly access the encoder could have issues with this, but this
direct access is just wrong and unsafe
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This accesses the private encoder context, it should not be used by
the current ffserver it may affect old ffserver versions but i believe
there is consens that accessing the private encoder context from the muxer
is completely wrong.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Note, this temporarly drops the ability to set ffmpeg encoder debug and flags2 via ffserver.conf
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts parts of c16582579b. The hard
coded 30 seconds are a lot, and finishing the seek can takes several
seconds when the source is on a network share. Remove this code
entirely, because it does more bad than good.
(Commit message provided by committer, based on the original messages
by the patch author.)
Signed-off-by: Rainer Hochecker <fernetmenta@online.de>
Signed-off-by: wm4 <nfxjfg@googlemail.com>
It randomly causes failures with an error like:
"Failed to set value '-f' for option 'd': Error number -920332800 occurred"
(The error number is different every time.)
Reviewed-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This matrix needs to be applied after all others have (currently only
display matrix from trak), but cannot be handled in movie box, since
streams are not allocated yet. So store it in main context, and apply
it when appropriate, that is after parsing the tkhd one.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
When input surfaces are cuda frames, we will not know what the actual
underlying format (nv12, p010, etc) is at surface allocation time.
On the other hand, we will know when the input frames are actually
registered and associated with a surface.
So, let's delay format discovery until registration time, which is
actually how we handle other frame properties, such as dimensions.
By itself, this change doesn't allow for transcoding of 10bit
content from cuvid, but it reduces the problem to the hardcoding of
the sw format in ffmpeg_cuvid.c
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Using the decode interrupt feature of ffmpeg may cause crashes by
accessing previously freed pointers in matroska_read_close.
To prevent this reset nb_elem to zero after freeing the elements,
because ffmpeg normally tests for nb_elem.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The code calls av_new_packet a few lines above and the allocated memory
has to be freed in case of an error.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The delta escape (2) is supposed to work the same in 4-bit RLE as in
8-bit RLE. This is documented in the MSDN Bitmap Compression page:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd183383(v=vs.85).aspx
The unchecked modification of line is safe, since the loop condition
(line >= 0) will check it before any pixel data is written.
Fixes ticket #5153 (output now matches ImageMagick for the provided sample).
Signed-off-by: Daniel Verkamp <daniel@drv.nu>
This fixes some differences between runs of the ffserver tests
(in my local tree 2 runs gave the same result with this but i had other
changes too)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes a segmentation fault caused by calling memcpy with NULL as
second argument in handle_p_frame_apng.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This should not be needed, our AVParsers should do this
I do not have a testcase though, please help testing this and please
add fate tests if you can.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes null pointer dereference
Testcase is simply a ffmpeg instance sending a stream to ffserver while another ffmpeg reads from it
This reverts commit 6f0a1710d7.
Since this is a C11 feature, it requires -std=c11.
Not actually used for anything yet, that will be added in the following
commits.
This merges libav commit 13f5d2bf75.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
mythtv have problem with non-seekable dont write duration and filesize
and there have problem with some other server and player with 0 value
duation and filesize.
So add a flv flags to fix the ticket and make a choose for users.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
give very bad quality for soxr resampler.
linear_interp is intended for using linear interpolation
between filter bank so quality will be better.
i guess this is misunderstood as 'do not use filter bank,
but directly interpolate linearly between samples'.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
This fixes a heap-buffer-overflow in ff_er_frame_end when decoding mss2
with coded_width/coded_height larger than width/height.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This dubious behaviour in nvenc was finally removed by nvidia, and
as we refuse to run on anything older than 7.0, we don't need to
keep it around for old versions.
floats are not necessarily normalized, so a normalized softfloat needs
MIN_EXP lowered by 23 to cover that range.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Otherwise the codec context and codecpar might disagree on the codec id,
triggering asserts in av_parser_parse2.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
separate dsp.resample to dsp.resample_common and dsp.resample_linear
and choose to call faster resample_common even when linear_interp=on
when c->frac and c->dst_incr_mod are both zero
speed up resampling when exact_rational and linear_interp are both
enabled because exact_rational force c->frac and c->dst_incr_mod to
be zero when soft compensation does not happen
benchmark on exact_rational=on:linear_interp=on
old new
real 8.432s 5.097s
user 7.679s 4.989s
sys 0.125s 0.107s
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Fixes make checkheaders on systems without the Cuda Toolkit, which
was broken after the dynlink changes.
Signed-off-by: James Almer <jamrial@gmail.com>
Move global thread variables to better place.
Use correct variable for simple and complex filtergraphs.
This makes number of threads set per filter work again.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Expands the parser to also accept the separator '-' in addition to
'+', and take the negative sign into consideration.
The optional sign for the first factor in the expression is already
covered by parsing for an integer.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
scaling list is already transfered to raster scan during head parsing,
so no need to transfer it again.
And after this fix, FATE test SLIST_A_Sony_4/SLIST_B_Sony_8/
SLIST_C_Sony_3/SLIST_D_Sony_9 will pass in i965/Skylake.
Signed-off-by: Wang, Yi A <yi.a.wamg@intel.com>
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Remove the |checked| variable because the invalid value of -1 for
|flags| can be used to indicate the same condition. Also rename |flags|
to |cpu_flags| because there are a local variable and a function
parameter named |flags| in the same file.
Co-author: Dmitry Vyukov of Google
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I moved this into the handle_video_sequence callback because that's
the earliest time you can make an accurate decision as to what the
format should be.
However, transcoding requires that the decision between using
the accelerated PIX_FMT_CUDA vs a normal pix format happen at init()
time. There is enough information available to make that decision
and things work out with the underlying format only being discovered
in the sequence callback.
This patch moves the av_frame_make_writable() call from fill_yuv_image
to get_video_frame so that its argument can be the actual frame that
will be sent to the encoder.
This fixes data corruption issues in codecs that keep references on
one or several previous frames.
Signed-off-by: Sam Hocevar <sam@hocevar.net>
Reviewed-by: wm4
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Requested-by: wm4 ([FFmpeg-devel] [PATCH] avutil/opt: Support max > INT64_MAX in write_number() with AV_OPT_TYPE_INT64)
Requested-by: ronald ([FFmpeg-devel] [PATCH] avutil/opt: Support max > INT64_MAX in write_number() with AV_OPT_TYPE_INT64)
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The nvidia 375.xx driver introduces support for P016 output surfaces,
for 10bit and 12bit HEVC content (it's also the first driver to support
hardware decoding of 12bit content).
The cuvid api, as far as I can tell, only declares one output format
that they appear to refer to as P016 in the driver strings. Of course,
10bit content in P016 is identical to P010, and it is useful for
compatibility purposes to declare the format to be P010 to work with
other components that only know how to consume P010 (and to avoid
triggering swscale conversions that are lossy when they shouldn't be).
For simplicity, this change does not maintain the previous ability
to output dithered NV12 for 10/12 bit input video - the user will need
to update their driver to decode such videos.
P016 is the 16-bit variant of NV12 (planar luma, packed chroma), using
two bytes per component.
It may, and in fact is most likely to, be used in situations where
there are less than 16 bits of data. It is the responsibility of
the writer to zero out any unused LSBs.
Currently, it forces IDR frames for both true and false.
Not entirely sure what the original idea behind the tri-state bool
option is.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
User selectable surfaces are not working correctly, if you set number of
surfaces on cmdline, it will always use minimum 32 or 48 depends on
selected resolution, but in nvenc it is not necessary to use so many
surfaces.
So from now you can define as low as 1 surface and nvenc will still
work, it will ofcourse lower GPU memory usage by 95% and async_delay to zero
That was the easy part, now littlebit more...
Next part of this patch is to always prefer rc_lookahead to be more
important for number of surfaces, than user defined surfaces value.
Maximum rc_lookahead from nvidia documentation is 32, but could increase
in future generations so there is no limit for this yet. Value
async_depth is still accepted and prefered over rc_lookahead.
There were also bug when you request more than rc_lookahead > 31, it
will always set maximum 31, because surface numbers recalculation was
after setting lookahead, which is now fixed.
Results:
If you set -rc_lookahead 32 and -bf 3 it will now use only 40 surfaces
and lower GPU memory usage by 20%, also it will now increase PSNR by 0.012dB
Two more comments:
1. from my internal test, i don't understand addition of 4 more surfaces
when lookahead is calculated, i didn't used this and everything works as
with those 4 more extra surfaces, does anybody know what is going on
there? I looks like it was used for B frames which are calculated
separately, because B frames maximum is 4.
2. rc_lookahead is defined default to -1, but in test condition if
(ctx->rc_lookahead) which sets lookahead it will be always true, i don't
know if this is intended behavior, so in default behavior is lookahead
always on!
This is default condition when rc_lokkahead is -1 (not defined on
cmdline), whis is maybe something that is not intended:
ctx->encode_config.rcParams.enableLookahead = 1;
ctx->encode_config.rcParams.lookaheadDepth = 0;
ctx->encode_config.rcParams.disableIadapt = 0;
ctx->encode_config.rcParams.disableBadapt = 0;
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
when meeting IDR frame, vaapi_encode_h264 poc number don't reset, now fix
this issue based on h264 spec. Some decoder don't care this case, but this
fix will enhance the encoder action. Before this fix, poc number is
negative in some case.
Reviewed-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Wang, Yi A <yi.a.wang@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
This was not observed earlier because the only syntax element which
it normally misses with the current setup is slice_qp_delta, but that
is always going to be zero (in IDR frames QP isn't varied on the
slice) which will always exp-golomb code as a single 1 bit. The
immediately following part is the byte alignment, which is always a 1
bit followed by 0s which are ignored, so as long as the bitstream is
never aligned at that point we will never notice because the only
difference is that an ignored bit is a 1 instead of a 0.
(cherry picked from commit fc30a90898)
While outwardly bizarre, this change makes the behaviour consistent
with other VAAPI encoders which sync to the encode /input/ picture in
order to wait for /output/ from the encoder. It is not harmful on
i965 (because synchronisation already happens in vaRenderPicture(),
so it has no effect there), and it allows the encoder to work on
mesa/gallium which assumes this behaviour.
(cherry picked from commit 086e4b58b5)
This allows better checking of capabilities and will make it easier
to add more functionality later.
It also commonises some duplicated code around rate control setup
and adds more comments explaining the internals.
(cherry picked from commit 80a5d05108)
There should be an extra offset of 6 on bit_rate_scale and of 4 on
cpb_size_scale which were not accounted for here.
(cherry picked from commit 3a9662af6c)
FLAC streams originating from the FLAC encoder send updated and more
complete STREAMINFO metadata as part of the last packet, so write that
to CodecPrivate instead of the incomplete one available in extradata
during init.
Signed-off-by: James Almer <jamrial@gmail.com>
A negative extradata size for example gets passed to memcpy in
avcodec_parameters_from_context causing a segmentation fault.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
If realloc fails, the pointer is overwritten and the previously allocated
buffer is leaked, which goes against the expected behavior of keeping the
packet unchanged in case of error.
Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This makes av_stream_add_side_data() consistent with av_packet_add_side_data().
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Functionally similar to av_packet_add_side_data(). Allows the use of an
already allocated buffer as stream side data.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
when parsing keyframe index metadata, list the message by trace log
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit e0c6b32046.
Said commit changed the behavior of the demuxer and decoder in a non
backwards compatible way.
Demuxers should make extradata available at init if possible, and send
new extradata as side data within a packet if needed.
A better fix for the remuxing crash will follow.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '8d07e941b04d63fc4443dd986e3dc7b69cdcca43':
FATE: add a test of H.264 SEI recovery in an intra refresh stream
Our H264 decoder drops 3 frames from the beginning of the stream, but
all frames after those match, hence the difference in the fate test.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '46278ec90ac5ad1dab5e85991f176afe49003fee':
mp3enc: write trailing padding
Noop, we have our own implementation for mp3 gapless.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd60c2d5216930ef98c7d4d6837d6229b37e0dcb3':
mp3dec: read the initial/trailing padding from the LAME tag
Noop, we have our own implementation for mp3 gapless tags.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '2d097c16b833c532ac974a7f1fd05c0a1f3b7675':
libopenh264enc: Return a more sensible error code in some init failure paths
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '36b380dcd52ef47d7ba0559ed51192c88d82a9bd':
libopenh264dec: Simplify the init thanks to FF_CODEC_CAP_INIT_CLEANUP being set
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd0b1e6049b06eeeeca146ece4d2f199c5dba1565':
libopenh264dec: Fix cleanup if the init failed early
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Just the presence of a hw frames context is not enough to detect whether
the transfer is an upload or a download, because hw frames mapped to
system memory will have a hw frames context attached.
D3DLOCK_READONLY properly corresponds to the absence of the write flag,
not to the presence of the read flag, while D3DLOCK_DISCARD is
equivalent to the overwrite flag.
Fixes division by 0
This is similar to how avg_frame_rate is checked elsewhere
Fixes: 6d24add0455f41b1b45b7ba615cd46f3/asan_generic_dc34c3_5480_0a2ef411cae999b9871ed71a2e481b71.mov
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This matches the other branch
Fixes out of array read
Fixes: 4d142ca76d39fe685effcf5017098723/asan_heap-oob_31ae824_8611_348fdb64f9009b63c8a8eae9a0e497c5.mkv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '61bd0ed781b56eea1e8e851aab34a2ee3b59fbac':
h264: Log more information about invalid NALu size
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '80fbb7becae530167373fe5178966b7d7604306e':
checkasm: vp8.mc: initialize the full src buffer after ec32574209
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '17c99b6158f2c6720af74e81ee727ee50d2e7e96':
h2645_parse: handle embedded Annex B NAL units in size prefixed NAL units
This commit is a noop, see a9bb4cf87d
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'a8cbe5a0ccebf60a8a8b0aba5d5716dd54c1595c':
h264_ps: export actual height in MBs as SPS.mb_height
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '99cf943339a2e5171863c48cd1a73dd43dc243e1':
d3d11va: don't keep the context lock while waiting for a frame
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '2866d108c9e9da7baf53ff57a51d470691049a57':
vp8dsp: Remove the comment saying that the height is equal to the width
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '8c816c0c9b12fdefd9046415e97df299880bc9b8':
checkasm/arm: align the clobber check data properly for ldrd
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'ec32574209f36467ef0d22c21a7e811ba98c15b6':
checkasm: vp8: mc: test unequal width/height for partitions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fc5cdc0d5372f5103c71d5dede296734fe71ead2':
doc: escape left brace in texi2pod.pl regex
This commit is a noop, see e43ea1cbb2
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd825b1a5306576dcd0553b7d0d24a3a46ad92864':
libopenh264: Support building with the 1.6 release
This commit is a noop, see 293676c476
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '4f7723cb3b913c577842a5bb088c804ddacac8df':
movenc: Add an option for skipping writing the mfra/tfra/mfro trailer
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
A number of new pix_fmts* have been added to AviSynth+:
16-bit packed RGB and RGBA
10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
8-, 10-, 12-, 14-, and 16-bit Planar RGB
8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA
10-, 12-, 14-, and 16-bit GRAY variants
32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY
*some of which are not currently available pix_fmts here and were
not added to the demuxer due to this
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Stream timebase should be set using avpriv_set_pts_info, otherwise
avctx->pkt_timebase is not correct, leading to A/V desync.
Signed-off-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Stephen Hutchinson <qyot27@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
uint32 need 4 bytes not 1.
Fix decoding when there is half/float and uint32 channel.
This fixes crashes due to pointer corruption caused by invalid writes.
The problem was introduced in commit
03152e74df.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This fixes NULL pointer dereferencing for formats, where frame->data[1]
is not allocated.
The problem was introduced in commit
257fbc3af4.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This prevented the code from correctly exporting the rotation matrix
which caused a few samples to be displayed wrong.
Introduced in ecd2ec69ce.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Fixes building with --disable-everything --enable-shared --enable-dxva2
The hwcontext DXVA2 implementation in avutil needs this library now, instead
of just the ffmpeg program.
The dc-only mode is already checked to work correctly above, but this
allows benchmarking this mode for performance tuning, and allows making
sure that it actually is correctly hooked up.
Signed-off-by: Martin Storsjö <martin@martin.st>
The latter is 1 cycle faster on a cortex-53 and since the operands are
bytewise (or larger) bitmask (impossible to overflow to zero) both are
equivalent.
Since aarch64 has enough free general purpose registers use them to
branch to the appropiate storage code. 1-2 cycles faster for the
functions using loop_filter 8/16, ... on a cortex-a53. Mixed results
(up to 2 cycles faster/slower) on a cortex-a57.
In the latest git commits of libilbc developers removed WebRtc_xxx typedefs.
This commit uses int types instead. It's safe to apply also for previous
versions since WebRtc_Word16 was always a typedef of int16_t and
WebRtc_UWord16 a typedef of uint16_t.
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the loop filters with
16 pixels at a time. The implementation is fully templated, with
a single macro which can generate versions for both 8 and
16 pixels wide, for both 4, 8 and 16 pixels loop filters
(and the 4/8 mixed versions as well).
For the 8 pixel wide versions, it is pretty close in speed (the
v_4_8 and v_8_8 filters are the best examples of this; the h_4_8
and h_8_8 filters seem to get some gain in the load/transpose/store
part). For the 16 pixels wide ones, we get a speedup of around
1.2-1.4x compared to the 32 bit version.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_loop_filter_h_4_8_neon: 144.0 127.2
vp9_loop_filter_h_8_8_neon: 207.0 182.5
vp9_loop_filter_h_16_8_neon: 415.0 328.7
vp9_loop_filter_h_16_16_neon: 672.0 558.6
vp9_loop_filter_mix2_h_44_16_neon: 302.0 203.5
vp9_loop_filter_mix2_h_48_16_neon: 365.0 305.2
vp9_loop_filter_mix2_h_84_16_neon: 365.0 305.2
vp9_loop_filter_mix2_h_88_16_neon: 376.0 305.2
vp9_loop_filter_mix2_v_44_16_neon: 193.2 128.2
vp9_loop_filter_mix2_v_48_16_neon: 246.7 218.4
vp9_loop_filter_mix2_v_84_16_neon: 248.0 218.5
vp9_loop_filter_mix2_v_88_16_neon: 302.0 218.2
vp9_loop_filter_v_4_8_neon: 89.0 88.7
vp9_loop_filter_v_8_8_neon: 141.0 137.7
vp9_loop_filter_v_16_8_neon: 295.0 272.7
vp9_loop_filter_v_16_16_neon: 546.0 453.7
The speedup vs C code in checkasm tests is around 2-7x, which is
pretty much the same as for the 32 bit version. Even if these functions
are faster than their 32 bit equivalent, the C version that we compare
to also became around 1.3-1.7x faster than the C version in 32 bit.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-5x.
Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
A57 gcc-5.3 neon
loop_filter_h_4_8_neon: 256.6 93.4
loop_filter_h_8_8_neon: 307.3 139.1
loop_filter_h_16_8_neon: 340.1 254.1
loop_filter_h_16_16_neon: 827.0 407.9
loop_filter_mix2_h_44_16_neon: 524.5 155.4
loop_filter_mix2_h_48_16_neon: 644.5 173.3
loop_filter_mix2_h_84_16_neon: 630.5 222.0
loop_filter_mix2_h_88_16_neon: 697.3 222.0
loop_filter_mix2_v_44_16_neon: 598.5 100.6
loop_filter_mix2_v_48_16_neon: 651.5 127.0
loop_filter_mix2_v_84_16_neon: 591.5 167.1
loop_filter_mix2_v_88_16_neon: 855.1 166.7
loop_filter_v_4_8_neon: 271.7 65.3
loop_filter_v_8_8_neon: 312.5 106.9
loop_filter_v_16_8_neon: 473.3 206.5
loop_filter_v_16_16_neon: 976.1 327.8
The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
is again 30-50% faster than the cortex-a53.
This is an adapted cherry-pick from libav commits
9d2afd1eb8 and
31756abe29.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the 16x16 and 32x32
transforms in slices 8 pixels wide instead of 4. This gives
a speedup of around 1.4x compared to the 32 bit version.
The fact that aarch64 doesn't have the same d/q register
aliasing makes some of the macros quite a bit simpler as well.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_inv_adst_adst_4x4_add_neon: 90.0 87.7
vp9_inv_adst_adst_8x8_add_neon: 400.0 354.7
vp9_inv_adst_adst_16x16_add_neon: 2526.5 1827.2
vp9_inv_dct_dct_4x4_add_neon: 74.0 72.7
vp9_inv_dct_dct_8x8_add_neon: 271.0 256.7
vp9_inv_dct_dct_16x16_add_neon: 1960.7 1372.7
vp9_inv_dct_dct_32x32_add_neon: 11988.9 8088.3
vp9_inv_wht_wht_4x4_add_neon: 63.0 57.7
The speedup vs C code (2-4x) is smaller than in the 32 bit case,
mostly because the C code ends up significantly faster (around
1.6x faster, with GCC 5.4) when built for aarch64.
Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
A57 gcc-5.3 neon
vp9_inv_adst_adst_4x4_add_neon: 152.2 60.0
vp9_inv_adst_adst_8x8_add_neon: 948.2 288.0
vp9_inv_adst_adst_16x16_add_neon: 4830.4 1380.5
vp9_inv_dct_dct_4x4_add_neon: 153.0 58.6
vp9_inv_dct_dct_8x8_add_neon: 789.2 180.2
vp9_inv_dct_dct_16x16_add_neon: 3639.6 917.1
vp9_inv_dct_dct_32x32_add_neon: 20462.1 4985.0
vp9_inv_wht_wht_4x4_add_neon: 91.0 49.8
The asm is around factor 3-4 faster than C on the cortex-a57 and the asm
is around 30-50% faster on the a57 compared to the a53.
This is an adapted cherry-pick from libav commit
3c9546dfaf.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; it is essentially a 1:1
port with no extra added features, but with some hand tuning
(especially for the plain copy/avg functions). The ARM version
isn't very register starved to begin with, so there's not much
to be gained from having more spare registers here - we only
avoid having to clobber callee-saved registers.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_avg4_neon: 27.2 23.7
vp9_avg8_neon: 56.5 54.7
vp9_avg16_neon: 169.9 167.4
vp9_avg32_neon: 585.8 585.2
vp9_avg64_neon: 2460.3 2294.7
vp9_avg_8tap_smooth_4h_neon: 132.7 125.2
vp9_avg_8tap_smooth_4hv_neon: 478.8 442.0
vp9_avg_8tap_smooth_4v_neon: 126.0 93.7
vp9_avg_8tap_smooth_8h_neon: 241.7 234.2
vp9_avg_8tap_smooth_8hv_neon: 690.9 646.5
vp9_avg_8tap_smooth_8v_neon: 245.0 205.5
vp9_avg_8tap_smooth_64h_neon: 11273.2 11280.1
vp9_avg_8tap_smooth_64hv_neon: 22980.6 22184.1
vp9_avg_8tap_smooth_64v_neon: 11549.7 10781.1
vp9_put4_neon: 18.0 17.2
vp9_put8_neon: 40.2 37.7
vp9_put16_neon: 97.4 99.5
vp9_put32_neon/armv8: 346.0 307.4
vp9_put64_neon/armv8: 1319.0 1107.5
vp9_put_8tap_smooth_4h_neon: 126.7 118.2
vp9_put_8tap_smooth_4hv_neon: 465.7 434.0
vp9_put_8tap_smooth_4v_neon: 113.0 86.5
vp9_put_8tap_smooth_8h_neon: 229.7 221.6
vp9_put_8tap_smooth_8hv_neon: 658.9 621.3
vp9_put_8tap_smooth_8v_neon: 215.0 187.5
vp9_put_8tap_smooth_64h_neon: 10636.7 10627.8
vp9_put_8tap_smooth_64hv_neon: 21076.8 21026.9
vp9_put_8tap_smooth_64v_neon: 9635.0 9632.4
These are generally about as fast as the corresponding ARM
routines on the same CPU (at least on the A53), in most cases
marginally faster.
The speedup vs C code is pretty much the same as for the 32 bit
case; on the A53 it's around 6-13x for ther larger 8tap filters.
The exact speedup varies a little, since the C versions generally
don't end up exactly as slow/fast as on 32 bit.
This is an adapted cherry-pick from libav commit
383d96aa22.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
With apple tools, the linker fails with errors like these, if the
offset is negative:
ld: in section __TEXT,__text reloc 8: symbol index out of range for architecture arm64
This is cherry-picked from libav commit
c44a8a3eab.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
The implementation tries to have smart handling of cases
where no pixels need the full filtering for the 8/16 width
filters, skipping both calculation and writeback of the
unmodified pixels in those cases. The actual effect of this
is hard to test with checkasm though, since it tests the
full filtering, and the benefit depends on how many filtered
blocks use the shortcut.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_loop_filter_h_4_8_neon: 2.72 2.68 1.78 3.15
vp9_loop_filter_h_8_8_neon: 2.36 2.38 1.70 2.91
vp9_loop_filter_h_16_8_neon: 1.80 1.89 1.45 2.01
vp9_loop_filter_h_16_16_neon: 2.81 2.78 2.18 3.16
vp9_loop_filter_mix2_h_44_16_neon: 2.65 2.67 1.93 3.05
vp9_loop_filter_mix2_h_48_16_neon: 2.46 2.38 1.81 2.85
vp9_loop_filter_mix2_h_84_16_neon: 2.50 2.41 1.73 2.85
vp9_loop_filter_mix2_h_88_16_neon: 2.77 2.66 1.96 3.23
vp9_loop_filter_mix2_v_44_16_neon: 4.28 4.46 3.22 5.70
vp9_loop_filter_mix2_v_48_16_neon: 3.92 4.00 3.03 5.19
vp9_loop_filter_mix2_v_84_16_neon: 3.97 4.31 2.98 5.33
vp9_loop_filter_mix2_v_88_16_neon: 3.91 4.19 3.06 5.18
vp9_loop_filter_v_4_8_neon: 4.53 4.47 3.31 6.05
vp9_loop_filter_v_8_8_neon: 3.58 3.99 2.92 5.17
vp9_loop_filter_v_16_8_neon: 3.40 3.50 2.81 4.68
vp9_loop_filter_v_16_16_neon: 4.66 4.41 3.74 6.02
The speedup vs C code is around 2-6x. The numbers are quite
inconclusive though, since the checkasm test runs multiple filterings
on top of each other, so later rounds might end up with different
codepaths (different decisions on which filter to apply, based
on input pixel differences). Disabling the early-exit in the asm
doesn't give a fair comparison either though, since the C code
only does the necessary calcuations for each row.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-9x.
This is pretty similar in runtime to the corresponding routines
in libvpx. (This is comparing vpx_lpf_vertical_16_neon,
vpx_lpf_horizontal_edge_8_neon and vpx_lpf_horizontal_edge_16_neon
to vp9_loop_filter_h_16_8_neon, vp9_loop_filter_v_16_8_neon
and vp9_loop_filter_v_16_16_neon - note that the naming of horizonal
and vertical is flipped between the libraries.)
In order to have stable, comparable numbers, the early exits in both
asm versions were disabled, forcing the full filtering codepath.
Cortex A7 A8 A9 A53
vp9_loop_filter_h_16_8_neon: 597.2 472.0 482.4 415.0
libvpx vpx_lpf_vertical_16_neon: 626.0 464.5 470.7 445.0
vp9_loop_filter_v_16_8_neon: 500.2 422.5 429.7 295.0
libvpx vpx_lpf_horizontal_edge_8_neon: 586.5 414.5 415.6 383.2
vp9_loop_filter_v_16_16_neon: 905.0 784.7 791.5 546.0
libvpx vpx_lpf_horizontal_edge_16_neon: 1060.2 751.7 743.5 685.2
Our version is consistently faster on on A7 and A53, marginally slower on
A8, and sometimes faster, sometimes slower on A9 (marginally slower in all
three tests in this particular test run).
This is an adapted cherry-pick from libav commit
dd299a2d6d.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
For the transforms up to 8x8, we can fit all the data (including
temporaries) in registers and just do a straightforward transform
of all the data. For 16x16, we do a transform of 4x16 pixels in
4 slices, using a temporary buffer. For 32x32, we transform 4x32
pixels at a time, in two steps of 4x16 pixels each.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_inv_adst_adst_4x4_add_neon: 3.39 5.83 4.17 4.01
vp9_inv_adst_adst_8x8_add_neon: 3.79 4.86 4.23 3.98
vp9_inv_adst_adst_16x16_add_neon: 3.33 4.36 4.11 4.16
vp9_inv_dct_dct_4x4_add_neon: 4.06 6.16 4.59 4.46
vp9_inv_dct_dct_8x8_add_neon: 4.61 6.01 4.98 4.86
vp9_inv_dct_dct_16x16_add_neon: 3.35 3.44 3.36 3.79
vp9_inv_dct_dct_32x32_add_neon: 3.89 3.50 3.79 4.42
vp9_inv_wht_wht_4x4_add_neon: 3.22 5.13 3.53 3.77
Thus, the speedup vs C code is around 3-6x.
This is mostly marginally faster than the corresponding routines
in libvpx on most cores, tested with their 32x32 idct (compared to
vpx_idct32x32_1024_add_neon). These numbers are slightly in libvpx's
favour since their version doesn't clear the input buffer like ours
do (although the effect of that on the total runtime probably is
negligible.)
Cortex A7 A8 A9 A53
vp9_inv_dct_dct_32x32_add_neon: 18436.8 16874.1 14235.1 11988.9
libvpx vpx_idct32x32_1024_add_neon 20789.0 13344.3 15049.9 13030.5
Only on the Cortex A8, the libvpx function is faster. On the other cores,
ours is slightly faster even though ours has got source block clearing
integrated.
This is an adapted cherry-pick from libav commits
a67ae67083 and
52d196fb30.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This work is sponsored by, and copyright, Google.
The filter coefficients are signed values, where the product of the
multiplication with one individual filter coefficient doesn't
overflow a 16 bit signed value (the largest filter coefficient is
127). But when the products are accumulated, the resulting sum can
overflow the 16 bit signed range. Instead of accumulating in 32 bit,
we accumulate the largest product (either index 3 or 4) last with a
saturated addition.
(The VP8 MC asm does something similar, but slightly simpler, by
accumulating each half of the filter separately. In the VP9 MC
filters, each half of the filter can also overflow though, so the
largest component has to be handled individually.)
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_avg4_neon: 1.71 1.15 1.42 1.49
vp9_avg8_neon: 2.51 3.63 3.14 2.58
vp9_avg16_neon: 2.95 6.76 3.01 2.84
vp9_avg32_neon: 3.29 6.64 2.85 3.00
vp9_avg64_neon: 3.47 6.67 3.14 2.80
vp9_avg_8tap_smooth_4h_neon: 3.22 4.73 2.76 4.67
vp9_avg_8tap_smooth_4hv_neon: 3.67 4.76 3.28 4.71
vp9_avg_8tap_smooth_4v_neon: 5.52 7.60 4.60 6.31
vp9_avg_8tap_smooth_8h_neon: 6.22 9.04 5.12 9.32
vp9_avg_8tap_smooth_8hv_neon: 6.38 8.21 5.72 8.17
vp9_avg_8tap_smooth_8v_neon: 9.22 12.66 8.15 11.10
vp9_avg_8tap_smooth_64h_neon: 7.02 10.23 5.54 11.58
vp9_avg_8tap_smooth_64hv_neon: 6.76 9.46 5.93 9.40
vp9_avg_8tap_smooth_64v_neon: 10.76 14.13 9.46 13.37
vp9_put4_neon: 1.11 1.47 1.00 1.21
vp9_put8_neon: 1.23 2.17 1.94 1.48
vp9_put16_neon: 1.63 4.02 1.73 1.97
vp9_put32_neon: 1.56 4.92 2.00 1.96
vp9_put64_neon: 2.10 5.28 2.03 2.35
vp9_put_8tap_smooth_4h_neon: 3.11 4.35 2.63 4.35
vp9_put_8tap_smooth_4hv_neon: 3.67 4.69 3.25 4.71
vp9_put_8tap_smooth_4v_neon: 5.45 7.27 4.49 6.52
vp9_put_8tap_smooth_8h_neon: 5.97 8.18 4.81 8.56
vp9_put_8tap_smooth_8hv_neon: 6.39 7.90 5.64 8.15
vp9_put_8tap_smooth_8v_neon: 9.03 11.84 8.07 11.51
vp9_put_8tap_smooth_64h_neon: 6.78 9.48 4.88 10.89
vp9_put_8tap_smooth_64hv_neon: 6.99 8.87 5.94 9.56
vp9_put_8tap_smooth_64v_neon: 10.69 13.30 9.43 14.34
For the larger 8tap filters, the speedup vs C code is around 5-14x.
This is significantly faster than libvpx's implementation of the same
functions, at least when comparing the put_8tap_smooth_64 functions
(compared to vpx_convolve8_horiz_neon and vpx_convolve8_vert_neon from
libvpx).
Absolute runtimes from checkasm:
Cortex A7 A8 A9 A53
vp9_put_8tap_smooth_64h_neon: 20150.3 14489.4 19733.6 10863.7
libvpx vpx_convolve8_horiz_neon: 52623.3 19736.4 21907.7 25027.7
vp9_put_8tap_smooth_64v_neon: 14455.0 12303.9 13746.4 9628.9
libvpx vpx_convolve8_vert_neon: 42090.0 17706.2 17659.9 16941.2
Thus, on the A9, the horizontal filter is only marginally faster than
libvpx, while our version is significantly faster on the other cores,
and the vertical filter is significantly faster on all cores. The
difference is especially large on the A7.
The libvpx implementation does the accumulation in 32 bit, which
probably explains most of the differences.
This is an adapted cherry-pick from libav commits
ffbd1d2b00,
392caa65df,
557c1675cf and
11623217e3.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
We reset .Lpic_gp to zero at the start of each function, which means
that the logic within movrelx for clearing gp when necessary will
be missed.
This fixes using movrelx in different functions with a different
helper register.
This is cherry-picked from libav commit
824e8c2840.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Make them aligned, to allow efficient access to them from simd.
This is an adapted cherry-pick from libav commit
a4cfcddcb0.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Also a small cosmetic change to the avx2 idct16 version to make it
explicit that one of the arguments to the write-out macros is unused
for >=avx2 (it uses pmovzxbw instead of punpcklbw).
libavfilter/af_asyncts.c:212:9: warning: absolute value function 'labs' given an argument of type 'int64_t' (aka 'long long') but has parameter of type 'long' which may cause truncation of value [-Wabsolute-value]
This was correct for H.26[45], because libmfx uses the same values
derived from profile_idc and the constraint_set flags, but it is
wrong for other codecs.
Also avoid passing FF_LEVEL_UNKNOWN (-99) as the level, as this is
certainly invalid.
* commit 'dc08bbf63a217c839aa4c143f2a1d0b7e2e6d997':
vp8dsp: Clarify the first dimension of the mc function tables
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '924e2ecd2b7d51cca60c79351ef16b04dd4245c3':
qsvdec: when a frames ctx is supplied, use its frame dimensions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '92736c74fb1633e36f7134a880422a9b7db14d3f':
qsvdec: add support for P010 (10-bit 420) decoding
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'ce320cf1c4daab3e2e3726ed7d2e879d10f7b991':
qsvdec: use the same mfxFrameInfo for allocating frames that was passed to DECODE_Init
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '536bb17e9659c5ed7576a218d4085cdd6d5742fa':
qsvdec: make ff_qsv_map_pixfmt() return a MFX fourcc as well
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '4926fa9a4aa03f3b751f52e900b9efb87fea0591':
hwcontext_vaapi: Add driver quirks to the hwdevice
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'e78e5b735fd559bc7aa3f5a01e9c8d37dc2ec6d8':
swscale: add P010 input support
This commit is a noop, see 2e31434d84
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'b7c5f885233a7b8692140c920d9f43220dc830d9':
pixfmt: add P010 pixel format
This commit is a noop, see c2869b4640
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'b55566db4c51d920a6496455bb30a608e5a50a41':
avconv: use avcodec_parameters_copy() with streamcopy
The fate-aac-autobsf-adtstoasc changes from writing an audio bitdepth
based on the sample format, which is now available.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'be3e807c8fad1f82766c083073e44396799f155b':
oggparseopus: export pre-skip
Noop, we already export this information
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '029cf99c5166b36f33381cd8ebfa5f1f1f463d1f':
mov: Save number of stsd elements after stream extradata allocation
Mostly noop, see 8b43ee4054
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '6c445990e64124ad64c79423dfd3764520648c89':
tiffenc: Check zlib support for deflate option during initialization
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd8f3b0fb584677d4882e3a2d7c28f8b15c7319f5':
targaenc: Move size check to initialization function
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '67cb2c0f73ec08bdcecd675c1ffe25c3a5b26ef2':
checkasm: hevc: Iterate over features first, then over bitdepths
Noop, we don't have these checkasm tests.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fe27792fd779ac4cdd5e57be5f6f488483c307b2':
build: Move ff_mpeg12_frame_rate_tab to a separate file
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '8c929037ec75fbe9f367e0a31ee34839e92de481':
build: Add a new component for H.264 parsing code
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '3c08b7bc761b6411f55db68189721638dde2c46a':
ffv1: Report additional bitstream information in verbose mode
Noop, we already have bitstream information printing.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fe6e5cbea7dbd5d2c67d79b5570e26debb70e95b':
ffv1: Remove version 2 and mark version 3 as non-experimental
Noop, our ffv1 decoder is far more advanced and version 3 has been stable for a while.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '7c55fac7dfa8bad9644dea5d03309da30be69563':
fate: Add test for webp
Noop, we already have a variety of webp tests, including a fate-webp target,
which would collide with this test.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
__MAC_10_11 can be present in updated revision of an older SDK so it
can't reliably detect availability of kAudioFormatEnhancedAC3 constant.
Fixes: b4daa2c40f ('lavc/audiotoolboxdec: add eac3 decoder')
Cc: Rodger Combs <rodger.combs@gmail.com>
Signed-off-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
Previous version reviewed by: Rodger Combs <rodger.combs@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the 16x16 and 32x32
transforms in slices 8 pixels wide instead of 4. This gives
a speedup of around 1.4x compared to the 32 bit version.
The fact that aarch64 doesn't have the same d/q register
aliasing makes some of the macros quite a bit simpler as well.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_inv_adst_adst_4x4_add_neon: 90.0 87.7
vp9_inv_adst_adst_8x8_add_neon: 400.0 354.7
vp9_inv_adst_adst_16x16_add_neon: 2526.5 1827.2
vp9_inv_dct_dct_4x4_add_neon: 74.0 72.7
vp9_inv_dct_dct_8x8_add_neon: 271.0 256.7
vp9_inv_dct_dct_16x16_add_neon: 1960.7 1372.7
vp9_inv_dct_dct_32x32_add_neon: 11988.9 8088.3
vp9_inv_wht_wht_4x4_add_neon: 63.0 57.7
The speedup vs C code (2-4x) is smaller than in the 32 bit case,
mostly because the C code ends up significantly faster (around
1.6x faster, with GCC 5.4) when built for aarch64.
Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
A57 gcc-5.3 neon
vp9_inv_adst_adst_4x4_add_neon: 152.2 60.0
vp9_inv_adst_adst_8x8_add_neon: 948.2 288.0
vp9_inv_adst_adst_16x16_add_neon: 4830.4 1380.5
vp9_inv_dct_dct_4x4_add_neon: 153.0 58.6
vp9_inv_dct_dct_8x8_add_neon: 789.2 180.2
vp9_inv_dct_dct_16x16_add_neon: 3639.6 917.1
vp9_inv_dct_dct_32x32_add_neon: 20462.1 4985.0
vp9_inv_wht_wht_4x4_add_neon: 91.0 49.8
The asm is around factor 3-4 faster than C on the cortex-a57 and the asm
is around 30-50% faster on the a57 compared to the a53.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the loop filters with
16 pixels at a time. The implementation is fully templated, with
a single macro which can generate versions for both 8 and
16 pixels wide, for both 4, 8 and 16 pixels loop filters
(and the 4/8 mixed versions as well).
For the 8 pixel wide versions, it is pretty close in speed (the
v_4_8 and v_8_8 filters are the best examples of this; the h_4_8
and h_8_8 filters seem to get some gain in the load/transpose/store
part). For the 16 pixels wide ones, we get a speedup of around
1.2-1.4x compared to the 32 bit version.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_loop_filter_h_4_8_neon: 144.0 127.2
vp9_loop_filter_h_8_8_neon: 207.0 182.5
vp9_loop_filter_h_16_8_neon: 415.0 328.7
vp9_loop_filter_h_16_16_neon: 672.0 558.6
vp9_loop_filter_mix2_h_44_16_neon: 302.0 203.5
vp9_loop_filter_mix2_h_48_16_neon: 365.0 305.2
vp9_loop_filter_mix2_h_84_16_neon: 365.0 305.2
vp9_loop_filter_mix2_h_88_16_neon: 376.0 305.2
vp9_loop_filter_mix2_v_44_16_neon: 193.2 128.2
vp9_loop_filter_mix2_v_48_16_neon: 246.7 218.4
vp9_loop_filter_mix2_v_84_16_neon: 248.0 218.5
vp9_loop_filter_mix2_v_88_16_neon: 302.0 218.2
vp9_loop_filter_v_4_8_neon: 89.0 88.7
vp9_loop_filter_v_8_8_neon: 141.0 137.7
vp9_loop_filter_v_16_8_neon: 295.0 272.7
vp9_loop_filter_v_16_16_neon: 546.0 453.7
The speedup vs C code in checkasm tests is around 2-7x, which is
pretty much the same as for the 32 bit version. Even if these functions
are faster than their 32 bit equivalent, the C version that we compare
to also became around 1.3-1.7x faster than the C version in 32 bit.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-5x.
Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
A57 gcc-5.3 neon
loop_filter_h_4_8_neon: 256.6 93.4
loop_filter_h_8_8_neon: 307.3 139.1
loop_filter_h_16_8_neon: 340.1 254.1
loop_filter_h_16_16_neon: 827.0 407.9
loop_filter_mix2_h_44_16_neon: 524.5 155.4
loop_filter_mix2_h_48_16_neon: 644.5 173.3
loop_filter_mix2_h_84_16_neon: 630.5 222.0
loop_filter_mix2_h_88_16_neon: 697.3 222.0
loop_filter_mix2_v_44_16_neon: 598.5 100.6
loop_filter_mix2_v_48_16_neon: 651.5 127.0
loop_filter_mix2_v_84_16_neon: 591.5 167.1
loop_filter_mix2_v_88_16_neon: 855.1 166.7
loop_filter_v_4_8_neon: 271.7 65.3
loop_filter_v_8_8_neon: 312.5 106.9
loop_filter_v_16_8_neon: 473.3 206.5
loop_filter_v_16_16_neon: 976.1 327.8
The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
is again 30-50% faster than the cortex-a53.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'e48746deec48e9ff195841bc3266b4e153a878cd':
checkasm: h264dsp: Move the x and y variables into the randomize_buffer macro
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '82b7525173f20702a8cbc26ebedbf4b69b8fecec':
Add an OpenH264 decoder wrapper
This commit is a noop, see c5d326f551
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '785c25443b56adb6dbbb78d68cccbd9bd4a42e05':
movenc: Apply offsets on timestamps when peeking into interleaving queues
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'eccfb9778ae939764d17457f34338d140832d9e1':
qsvdec_hevc: add the UID of the HEVC HW decoder plugin
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'c3f113d58488df7594a489bdbb993a69ad47063c':
vf_hwdownload: allocate the destination frame for the pool size
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fdfe01365d579189d9a55b3741dba2ac46eb1df8':
hwcontext: allocate the destination frame for the pool size
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '5fcae3b3f93fd02b3d1e009b9d9b17410fca9498':
hwcontext: clarify the behaviour of transfer_data() for cropped frames
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '94ebf5565849e4dc036d2ca43979571ed3736457':
avconv: restructure sending EOF to filters
Noop, as its a fixup to a previously skipped commit
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'd2e56cf753a6c462041dee897d9d0c90f349988c':
avconv: move flushing the queued frames to configure_filtergraph()
Noop, as its a fixup to a previously skipped commit
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The Intel binary iHD driver does not support the
VASurfaceAttribMemoryType, so surface allocation will fail when using
it.
(cherry picked from commit 2124711b95)
If no string argument is supplied when av_hwdevice_ctx_create() is
called to create a VAAPI device, we currently only try the default
X11 display (that is, $DISPLAY) to find a device, and will therefore
fail in the absence of an X server to connect to. Change the logic
to also look for a device via the first DRM render node (that is,
"/dev/dri/renderD128"), which is probably the right thing to use in
most simple configurations which only have one DRM device.
(cherry picked from commit 121f34d5f0)
No longer leaks memory when used with a driver with the "render does
not destroy param buffers" quirk (i.e. Intel i965).
(cherry picked from commit 221ffca631)
Fixes ticket #5871.
The driver being used is detected inside av_hwdevice_ctx_init() and
the quirks field then set from a table of known device. If this
behaviour is unwanted, the user can also set the quirks field
manually.
Also adds the Intel i965 driver quirk (it does not destroy parameter
buffers used in a call to vaRenderPicture()) and detects that driver
to set it.
(cherry picked from commit 4926fa9a4a)
Set up the encoder with a hardware context which will match the one
the decoder will use when it starts later.
Includes 02c2761973, with additional
hackery to get around a3a0230a98 being
skipped.
* commit '8a62d2c28fbacd1ae20c35887a1eecba2be14371':
vaapi_encode: Maintain a pool of bitstream output buffers
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '4a081f224e12f4227ae966bcbdd5384f22121ecf':
libavcodec: fix constness in clobber test avcodec_open2() wrappers
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '02c2761973dfc886e94a60a9c7d6d30c296d5b8c':
avconv_qsv: use the device creation API
Not merged, our ffmpeg hwaccel infra is not quite the same as avconvs.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '232399e3ee219d16d0e0d482c9f31a26202d4993':
avconv: pass the hwaccel frames context to the decoder
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'a3a0230a9870b9018dc7415ae5872784d524cfe5':
avconv: init filtergraphs only after we have a frame on each input
This commit is a noop since it doesn't apply cleanly due to differences
in the dataflow between avconv and ffmpeg, and thus fixing this in the
scope of a merge is unfeasible.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '3e265ca58f0505470186dce300ab66a6eac3978e':
avconv: do packet ts rescaling in write_packet()
This commit is a noop since it doesn't apply cleanly due to differences
in the dataflow between avconv and ffmpeg, and thus fixing this in the
scope of a merge is unfeasible.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'ba7397baef796ca3991fe1c921bc91054407c48b':
avconv: factor out initializing stream parameters for encoding
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The handling of the other block sizes was limited to 'SCALED == 0' in
commit dc96c0f9fc, so this assert should
be disabled, too, as it can now be triggered.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Fixes building for Windows x86 with MSVC using the link libraries distributed with the CUDA SDK.
check_lib2 is required here because it includes the header to get the full signature of the
function, including the stdcall calling convention and all of its arguments, which enables
the linker to determine the fully qualified object name and resolve it through the import
library, since the CUDA SDK libraries do not include un-qualified aliases.
AVFilterLink.frame_count is supposed to count the number of frames
that were passed on the link, but with min_samples, that number is
not always the same for the source and destination filters.
With the addition of a FIFO on the link, the difference will become
more significant.
Split the variable in two: frame_count_in counts the number of
frames that entered the link, frame_count_out counts the number
of frames that were sent to the destination filter.
The test is not supposed to cover audio.
Also, using -vframes along with an audio stream depends on
the exact order the frames are processed by filters, it is
too much constraint to guarantee.
Fixes valgrind warning about "Conditional jump or move depends on uninitialised value(s)"
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
libavcodec/ratecontrol.c:120:9: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
libavcodec/ratecontrol.c:121:9: warning: ISO C forbids initialization between function pointer and ‘void *’ [-Wpedantic]
Otherwise put_bits can be called with a value that doesn't fit in the
sample_len, causing an assertion failure.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
From 'man ppm': The maximum color value (Maxval), again in ASCII decimal.
Must be less than 65536.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also contains the following changes to the library:
- add ff_ prefix to functions
- remove cplusplus defines.
- add FF_ prefix to contants and some structs
- remove true peak calculation feature, since it uses its own resampler, and
af_loudnorm does not need it.
- remove version info and some fprintf(stderr) functions
- convert to use av_malloc
- always use histogram mode for LRA calculation, otherwise LRA data is slowly
consuming memory making af_loudnorm unfit for 24/7 operation. It also uses a
BSD style linked list implementation which is probably not available on all
platforms. So let's just remove the classic mode which not uses histogram.
- add ff_thread_once for calculating static histogram tables
- convert some functions to void which cannot fail
- remove intrinsics and some unused headers
- add support for planar audio
- remove channel / sample rate changer function, in ffmpeg usually we simply
alloc a new context
- convert some static variables to defines
- declare static histogram variables as aligned
- convert some initalizations to mallocz
- add window size parameter to init function and remove window size setter
function
- convert return codes to AVERROR
- fix indentation
Signed-off-by: Marton Balint <cus@passwd.hu>
This work is sponsored by, and copyright, Google.
The implementation tries to have smart handling of cases
where no pixels need the full filtering for the 8/16 width
filters, skipping both calculation and writeback of the
unmodified pixels in those cases. The actual effect of this
is hard to test with checkasm though, since it tests the
full filtering, and the benefit depends on how many filtered
blocks use the shortcut.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_loop_filter_h_4_8_neon: 2.72 2.68 1.78 3.15
vp9_loop_filter_h_8_8_neon: 2.36 2.38 1.70 2.91
vp9_loop_filter_h_16_8_neon: 1.80 1.89 1.45 2.01
vp9_loop_filter_h_16_16_neon: 2.81 2.78 2.18 3.16
vp9_loop_filter_mix2_h_44_16_neon: 2.65 2.67 1.93 3.05
vp9_loop_filter_mix2_h_48_16_neon: 2.46 2.38 1.81 2.85
vp9_loop_filter_mix2_h_84_16_neon: 2.50 2.41 1.73 2.85
vp9_loop_filter_mix2_h_88_16_neon: 2.77 2.66 1.96 3.23
vp9_loop_filter_mix2_v_44_16_neon: 4.28 4.46 3.22 5.70
vp9_loop_filter_mix2_v_48_16_neon: 3.92 4.00 3.03 5.19
vp9_loop_filter_mix2_v_84_16_neon: 3.97 4.31 2.98 5.33
vp9_loop_filter_mix2_v_88_16_neon: 3.91 4.19 3.06 5.18
vp9_loop_filter_v_4_8_neon: 4.53 4.47 3.31 6.05
vp9_loop_filter_v_8_8_neon: 3.58 3.99 2.92 5.17
vp9_loop_filter_v_16_8_neon: 3.40 3.50 2.81 4.68
vp9_loop_filter_v_16_16_neon: 4.66 4.41 3.74 6.02
The speedup vs C code is around 2-6x. The numbers are quite
inconclusive though, since the checkasm test runs multiple filterings
on top of each other, so later rounds might end up with different
codepaths (different decisions on which filter to apply, based
on input pixel differences). Disabling the early-exit in the asm
doesn't give a fair comparison either though, since the C code
only does the necessary calcuations for each row.
Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-9x.
This is pretty similar in runtime to the corresponding routines
in libvpx. (This is comparing vpx_lpf_vertical_16_neon,
vpx_lpf_horizontal_edge_8_neon and vpx_lpf_horizontal_edge_16_neon
to vp9_loop_filter_h_16_8_neon, vp9_loop_filter_v_16_8_neon
and vp9_loop_filter_v_16_16_neon - note that the naming of horizonal
and vertical is flipped between the libraries.)
In order to have stable, comparable numbers, the early exits in both
asm versions were disabled, forcing the full filtering codepath.
Cortex A7 A8 A9 A53
vp9_loop_filter_h_16_8_neon: 597.2 472.0 482.4 415.0
libvpx vpx_lpf_vertical_16_neon: 626.0 464.5 470.7 445.0
vp9_loop_filter_v_16_8_neon: 500.2 422.5 429.7 295.0
libvpx vpx_lpf_horizontal_edge_8_neon: 586.5 414.5 415.6 383.2
vp9_loop_filter_v_16_16_neon: 905.0 784.7 791.5 546.0
libvpx vpx_lpf_horizontal_edge_16_neon: 1060.2 751.7 743.5 685.2
Our version is consistently faster on on A7 and A53, marginally slower on
A8, and sometimes faster, sometimes slower on A9 (marginally slower in all
three tests in this particular test run).
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
For the transforms up to 8x8, we can fit all the data (including
temporaries) in registers and just do a straightforward transform
of all the data. For 16x16, we do a transform of 4x16 pixels in
4 slices, using a temporary buffer. For 32x32, we transform 4x32
pixels at a time, in two steps of 4x16 pixels each.
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_inv_adst_adst_4x4_add_neon: 3.39 5.83 4.17 4.01
vp9_inv_adst_adst_8x8_add_neon: 3.79 4.86 4.23 3.98
vp9_inv_adst_adst_16x16_add_neon: 3.33 4.36 4.11 4.16
vp9_inv_dct_dct_4x4_add_neon: 4.06 6.16 4.59 4.46
vp9_inv_dct_dct_8x8_add_neon: 4.61 6.01 4.98 4.86
vp9_inv_dct_dct_16x16_add_neon: 3.35 3.44 3.36 3.79
vp9_inv_dct_dct_32x32_add_neon: 3.89 3.50 3.79 4.42
vp9_inv_wht_wht_4x4_add_neon: 3.22 5.13 3.53 3.77
Thus, the speedup vs C code is around 3-6x.
This is mostly marginally faster than the corresponding routines
in libvpx on most cores, tested with their 32x32 idct (compared to
vpx_idct32x32_1024_add_neon). These numbers are slightly in libvpx's
favour since their version doesn't clear the input buffer like ours
do (although the effect of that on the total runtime probably is
negligible.)
Cortex A7 A8 A9 A53
vp9_inv_dct_dct_32x32_add_neon: 18436.8 16874.1 14235.1 11988.9
libvpx vpx_idct32x32_1024_add_neon 20789.0 13344.3 15049.9 13030.5
Only on the Cortex A8, the libvpx function is faster. On the other cores,
ours is slightly faster even though ours has got source block clearing
integrated.
Signed-off-by: Martin Storsjö <martin@martin.st>
Documents options and behaviour, noting when 'chunks' option will
not be honoured.
Signed-off-by: Tom Butterworth <bangnoise@gmail.com>
Signed-off-by: Martin Vignali <martin.vignali@gmail.com>
It can read less than the requested amount, in which case buf contains
uninitialized data, causing problems like segmentation faults later on.
Also make sure that image->size is positive, so that it can't match a
negative error code.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
When decoding with threads enabled, the get_format callback will be
called with one of the per-thread codec contexts rather than with the
outer context. If a hwaccel is in use too, this will add a reference
to the hardware frames context on that codec context, which will then
propagate to all of the other per-thread contexts for decoding. Once
the decoder finishes, however, the per-thread contexts are not freed
normally, so these references leak.
The implicit checks via v_data_size and a_data_size don't work in the case
'(hdr_size > 7) && !ctx->alpha_info'.
This fixes segmentation faults due to invalid reads.
This problem was introduced in commit
547c2f002a.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The secondary compression in Hap is optional, this change exposes that option to
the user as some use-cases favour higher bitrate files to reduce workload
decoding.
Adds "none" or "snappy" as options for "compressor". Selecting "none" disregards
"chunks" option: chunking is only of benefit decompressing Snappy.
Reviewed-by: Martin Vignali <martin.vignali@gmail.com>
Signed-off-by: Tom Butterworth <bangnoise@gmail.com>
This fixes crashes since 557c1675cf in linux PIC builds.
Previously, movrelx silently used r12 as helper register, which
doesn't work when r12 is the destination register.
Signed-off-by: Martin Storsjö <martin@martin.st>
We reset .Lpic_gp to zero at the start of each function, which means
that the logic within movrelx for clearing gp when necessary will
be missed.
This fixes using movrelx in different functions with a different
helper register.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
The speedup for the large horizontal filters is surprisingly
big on A7 and A53, while there's a minor slowdown (almost within
measurement noise) on A8 and A9.
Cortex A7 A8 A9 A53
orig:
vp9_put_8tap_smooth_64h_neon: 20270.0 14447.3 19723.9 10910.9
new:
vp9_put_8tap_smooth_64h_neon: 20165.8 14466.5 19730.2 10668.8
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; it is essentially a 1:1
port with no extra added features, but with some hand tuning
(especially for the plain copy/avg functions). The ARM version
isn't very register starved to begin with, so there's not much
to be gained from having more spare registers here - we only
avoid having to clobber callee-saved registers.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch64
vp9_avg4_neon: 27.2 23.7
vp9_avg8_neon: 56.5 54.7
vp9_avg16_neon: 169.9 167.4
vp9_avg32_neon: 585.8 585.2
vp9_avg64_neon: 2460.3 2294.7
vp9_avg_8tap_smooth_4h_neon: 132.7 125.2
vp9_avg_8tap_smooth_4hv_neon: 478.8 442.0
vp9_avg_8tap_smooth_4v_neon: 126.0 93.7
vp9_avg_8tap_smooth_8h_neon: 241.7 234.2
vp9_avg_8tap_smooth_8hv_neon: 690.9 646.5
vp9_avg_8tap_smooth_8v_neon: 245.0 205.5
vp9_avg_8tap_smooth_64h_neon: 11273.2 11280.1
vp9_avg_8tap_smooth_64hv_neon: 22980.6 22184.1
vp9_avg_8tap_smooth_64v_neon: 11549.7 10781.1
vp9_put4_neon: 18.0 17.2
vp9_put8_neon: 40.2 37.7
vp9_put16_neon: 97.4 99.5
vp9_put32_neon/armv8: 346.0 307.4
vp9_put64_neon/armv8: 1319.0 1107.5
vp9_put_8tap_smooth_4h_neon: 126.7 118.2
vp9_put_8tap_smooth_4hv_neon: 465.7 434.0
vp9_put_8tap_smooth_4v_neon: 113.0 86.5
vp9_put_8tap_smooth_8h_neon: 229.7 221.6
vp9_put_8tap_smooth_8hv_neon: 658.9 621.3
vp9_put_8tap_smooth_8v_neon: 215.0 187.5
vp9_put_8tap_smooth_64h_neon: 10636.7 10627.8
vp9_put_8tap_smooth_64hv_neon: 21076.8 21026.9
vp9_put_8tap_smooth_64v_neon: 9635.0 9632.4
These are generally about as fast as the corresponding ARM
routines on the same CPU (at least on the A53), in most cases
marginally faster.
The speedup vs C code is pretty much the same as for the 32 bit
case; on the A53 it's around 6-13x for ther larger 8tap filters.
The exact speedup varies a little, since the C versions generally
don't end up exactly as slow/fast as on 32 bit.
Signed-off-by: Martin Storsjö <martin@martin.st>
With apple tools, the linker fails with errors like these, if the
offset is negative:
ld: in section __TEXT,__text reloc 8: symbol index out of range for architecture arm64
Signed-off-by: Martin Storsjö <martin@martin.st>
FLAC streams originating from the FLAC encoder send updated and more
complete STREAMINFO metadata as part of the last packet, so write that
to CodecPrivate instead of the incomplete one available in extradata
during init.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
aac_adtstoasc makes the aac extradata available only after the first packet
is filtered, and as packet side data.
Assume extradata will be available as part of the first packet if
avpriv_mpeg4audio_get_config() fails the first time due to missing extradata
and reserve space for the OutputSampleRate element in the Tracks master.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Add keyframe index metadata
Used to facilitate seeking; particularly for HTTP pseudo streaming.
1. read live streaming or file by sequence
2. if use add_keyframe_index option, add a mark flag at the position,
use to insert new context at the last step.
3. add the keyframes *offset* and *timestamp* into a list
4. if use add_keyframe_index option, shift the metadata data from
mark flag offset
5. insert the keyframes *offset* and *timestamp* from the list by
sequence
6. free the list
7. end.
Add FATE test case;
Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Steven Liu <liuqi@gosun.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows a subsequent change to compress directly into the output packet when possible.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tom Butterworth <bangnoise@gmail.com>
If the value is negative then it means padding at the start of the packet
instead of at the end.
Based on a patch by Hendrik Leppkes.
Reviewed-by: James Zern <jzern-at-google.com@ffmpeg.org>
Signed-off-by: James Almer <jamrial@gmail.com>
Compare using AVCodecParameters instead of the deprecated
AVStream.codec field
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The libopus encoder does the same thing and its better than
keeping track of when the empty flush frames appear.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The API does not allow returning AVERROR codes.
It triggers an assert in av_parser_parse2.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Commit 04964ac311 ("avformat/hls: Fix missing streams in some
cases with MPEG TS") caused a regression where subdemuxer streams that
use probing (e.g. dts/eac3/mp2 in mpegts) no longer get probed properly.
This is because the codec parameters from the subdemuxer stream, once
probed, are not passed on to the main stream.
Fix that by updating the codec parameters if the codec id changes.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
This will allow implementing the allocator more fully, which is needed
by the HEVC encoder plugin with video memory input.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
For encoding, this avoids modifying the input surface, which we are not
allowed to do.
This will also be useful in the following commits.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
Uploading/downloading data through VPP may not work for some formats, in
that case we can still try to call av_hwframe_transfer_data() on the
child context.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
Certain pixel formats (e.g. P8) might not be supported for
download/upload through VPP operations, but can still be used otherwise.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
When using GPU surfaces with QSV, one needs to supply a frame allocator,
which will be invoked to pass surface pools to libmfx.
For encoding, this allocator gets invoked not only for the pool of input
frames, but also for a separate pool of (apparently) reconstructed frames
and another pool of MFX_FOURCC_P8, which on Windows needs to return
D3DFMT_P8 D3D surfaces. Those are probably used to store the encoded
bitstream on the GPU.
Signed-off-by: Maxym Dmytrychenko <maxym.dmytrychenko@intel.com>
AVCodecParameters.sample_rate is a signed integer, so
XMVAudioPacket.sample_rate should be, too.
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Also check for errors from avpriv_mpeg4audio_get_config in
ff_mp4_read_dec_config_descr.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
fate-aac-al07_96 fails if sample_rate == 0 is rejected in
ff_mov_read_stsd_entries.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
A negative sample rate doesn't make sense and triggers assertions in
av_rescale_rnd.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This is required since some programs are not able to correctly recognize
the metadata. See H.222, 2.6.58 Metadata pointer descriptor.
putstr8() is modified in order to allow to skip writing the string
length.
This should be more useful for users since numerical values for channel
layout can be confusing and unintuitive.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
When ffplay is used to play from the RTSP URL that serves 24 bit audio
content, ffplay fails to recognize the audio codec format. The attached
patch adds support for playing 24 bit audio content over RTSP by
defining a dynamic payload handler for "L24".
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libavcodec/x86/rv40dsp_init.c:97:2: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
libavcodec/x86/vp9dsp_init.c:94:40: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
Fixes valgrind warnings about usage of uninitialized values.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
The bitstream filters do not work with merged in side data
This leaves the input packet split if it is being split.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This reverts commit fba2a8a254.
The changes were right for av_write_frame() but not for av_interleaved_write_frame().
The following commit will fix this in a simpler way.
Signed-off-by: James Almer <jamrial@gmail.com>
In recent lld-link versions, this command prints the version to
stdout, but also prints an error to stderr:
$ lld-link -flavor gnu --version
LLD 4.0.0 (trunk 285641)
lld-link: error: no input files
lld-link: error: target emulation unknown: -m or at least one .o file required
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes errors like this when building non-pic binaries with armv6
as baseline:
Error: invalid literal constant: pool needs to be closer
Signed-off-by: Martin Storsjö <martin@martin.st>
Otherwise it can be non-zero next time decode_lowdelay is called, causing
slice_params_buf not to be allocated, leading to a NULL pointer dereference.
The problem was introduced in commit
dcad4677d6.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
"Vidvox Hap", not "Vidvox Hap encoder" or "Vidvox Hap decoder". Fixes
bad name in "ffmpeg -codecs", matches other codec naming.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
2-channels convolution using complex fft
improves speed significantly
not sure if it should be enabled by default
so disable it by default
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
Takes a frame associated with a hardware context as input and maps it
to something else (another hardware frame or normal memory) for other
processing. If the frame to map was originally in the target format
(but mapped to something else), the original frame is output.
Also supports mapping backwards, where only the output has a hardware
context. The link immediately before will be supplied with mapped
hardware frames which it can write directly into, and this filter
then unmaps them back to the actual hardware frames.
Adds the new av_hwframe_map() function, which allows mapping between
hardware frames and normal memory, along with internal support for
implementing it.
Also adds av_hwframe_ctx_create_derived(), for creating a hardware
frames context associated with one device using frames mapped from
another by some hardware-specific means.
this is somewhat a magic number, which can be understood from reading section
"7.1.2 Exponent Strategy" of the ac3 specification, in short:
Three exponents each represented as number 0-4 are grouped together and
base-5 encoded, so the maximal correct value is 25*4 + 5*4 + 4 = 124.
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The framework will allocate a buffer and copy the data to it,
that takes time. But it avoids constently creating and
destroyng the shared memory segment, and that saves more time.
On my setup,
from ~200 to ~300 FPS at full screen (1920×1200),
from ~1400 to ~3300 at smaller size (640×480),
similar to legacy x11grab and confirmed by others.
Plus, shared memory segments are a scarce resource,
allocating potentially many is a bad idea.
Note: if the application were to drop all references to the
buffer before the next call to av_read_frame(), then passing
the shared memory segment as a refcounted buffer would be
even more efficient, but it is hard to guarantee, and it does
not happen with the ffmpeg command-line tool. Using a small
number of preallocated buffers and resorting to a copy when
the pool is exhausted would be a solution to get the better
of both worlds.
According to spec ISO_IEC_15444_12 "For any media stream for which no segment index is present, referred to as non‐indexed stream, the media stream associated with the first Segment Index box in the segment serves as a reference stream in a sense that it also describes the subsegments for any non‐indexed media stream."
Signed-off-by: Sasi Inguva <isasi@google.com>
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libavutil/x86/float_dsp_init.c(144) : warning C4028: formal parameter 1 different from declaration
libavutil/x86/float_dsp_init.c(144) : warning C4028: formal parameter 2 different from declaration
libavcodec/dnxhdenc.c(326) : warning C4028: formal parameter 1 different from declaration
libavcodec/dnxhdenc.c(329) : warning C4028: formal parameter 1 different from declaration
libavcodec/pixblockdsp.c(58) : warning C4028: formal parameter 1 different from declaration
libavcodec/pixblockdsp.c(63) : warning C4028: formal parameter 1 different from declaration
libavcodec/pixblockdsp.c(66) : warning C4028: formal parameter 1 different from declaration
libavcodec/ituh263dec.c(215) : warning C4028: formal parameter 1 different from declaration
libavcodec/ituh263dec.c(215) : warning C4028: formal parameter 2 different from declaration
The include of config.h was added in 2012 in 1d9c2dc8, due to
the use of CONFIG_SNOW_ENCODER ifdefs within options_table.h.
When the snow codec was dropped later (in a0c5917f8 in 2013),
this include no longer served any purpose.
options_table.h is included in builds for the host as well, when
building documentation. config.h should not be included in code
that is built for the host, since it can contain workarounds
for the target compiler/environment, like adding a missing define
of restrict, defining getenv(x) to NULL for environments that lack
getenv.
The seemingly innocent include reordering in 2025d37871 broke
builds that have getenv(x) defined to NULL in config.h (Windows CE
and Windows Phone/RT), since libavcodec/options_table.h include
config.h, while libavformat/options_table.h end up bringing in
more system headers, and those system headers can contain a proper
definition of getenv, which clash with the getenv define in config.h.
This was avoided earlier as long as libavformat/options_table.h (or
avformat.h) was included before libavcodec/options_table.h.
This fixes builds for Windows Phone/RT and CE.
Signed-off-by: Martin Storsjö <martin@martin.st>
This work is sponsored by, and copyright, Google.
The filter coefficients are signed values, where the product of the
multiplication with one individual filter coefficient doesn't
overflow a 16 bit signed value (the largest filter coefficient is
127). But when the products are accumulated, the resulting sum can
overflow the 16 bit signed range. Instead of accumulating in 32 bit,
we accumulate the largest product (either index 3 or 4) last with a
saturated addition.
(The VP8 MC asm does something similar, but slightly simpler, by
accumulating each half of the filter separately. In the VP9 MC
filters, each half of the filter can also overflow though, so the
largest component has to be handled individually.)
Examples of relative speedup compared to the C version, from checkasm:
Cortex A7 A8 A9 A53
vp9_avg4_neon: 1.71 1.15 1.42 1.49
vp9_avg8_neon: 2.51 3.63 3.14 2.58
vp9_avg16_neon: 2.95 6.76 3.01 2.84
vp9_avg32_neon: 3.29 6.64 2.85 3.00
vp9_avg64_neon: 3.47 6.67 3.14 2.80
vp9_avg_8tap_smooth_4h_neon: 3.22 4.73 2.76 4.67
vp9_avg_8tap_smooth_4hv_neon: 3.67 4.76 3.28 4.71
vp9_avg_8tap_smooth_4v_neon: 5.52 7.60 4.60 6.31
vp9_avg_8tap_smooth_8h_neon: 6.22 9.04 5.12 9.32
vp9_avg_8tap_smooth_8hv_neon: 6.38 8.21 5.72 8.17
vp9_avg_8tap_smooth_8v_neon: 9.22 12.66 8.15 11.10
vp9_avg_8tap_smooth_64h_neon: 7.02 10.23 5.54 11.58
vp9_avg_8tap_smooth_64hv_neon: 6.76 9.46 5.93 9.40
vp9_avg_8tap_smooth_64v_neon: 10.76 14.13 9.46 13.37
vp9_put4_neon: 1.11 1.47 1.00 1.21
vp9_put8_neon: 1.23 2.17 1.94 1.48
vp9_put16_neon: 1.63 4.02 1.73 1.97
vp9_put32_neon: 1.56 4.92 2.00 1.96
vp9_put64_neon: 2.10 5.28 2.03 2.35
vp9_put_8tap_smooth_4h_neon: 3.11 4.35 2.63 4.35
vp9_put_8tap_smooth_4hv_neon: 3.67 4.69 3.25 4.71
vp9_put_8tap_smooth_4v_neon: 5.45 7.27 4.49 6.52
vp9_put_8tap_smooth_8h_neon: 5.97 8.18 4.81 8.56
vp9_put_8tap_smooth_8hv_neon: 6.39 7.90 5.64 8.15
vp9_put_8tap_smooth_8v_neon: 9.03 11.84 8.07 11.51
vp9_put_8tap_smooth_64h_neon: 6.78 9.48 4.88 10.89
vp9_put_8tap_smooth_64hv_neon: 6.99 8.87 5.94 9.56
vp9_put_8tap_smooth_64v_neon: 10.69 13.30 9.43 14.34
For the larger 8tap filters, the speedup vs C code is around 5-14x.
This is significantly faster than libvpx's implementation of the same
functions, at least when comparing the put_8tap_smooth_64 functions
(compared to vpx_convolve8_horiz_neon and vpx_convolve8_vert_neon from
libvpx).
Absolute runtimes from checkasm:
Cortex A7 A8 A9 A53
vp9_put_8tap_smooth_64h_neon: 20150.3 14489.4 19733.6 10863.7
libvpx vpx_convolve8_horiz_neon: 52623.3 19736.4 21907.7 25027.7
vp9_put_8tap_smooth_64v_neon: 14455.0 12303.9 13746.4 9628.9
libvpx vpx_convolve8_vert_neon: 42090.0 17706.2 17659.9 16941.2
Thus, on the A9, the horizontal filter is only marginally faster than
libvpx, while our version is significantly faster on the other cores,
and the vertical filter is significantly faster on all cores. The
difference is especially large on the A7.
The libvpx implementation does the accumulation in 32 bit, which
probably explains most of the differences.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes it match the pattern already used for VP8 MC functions.
This also makes the signature match ffmpeg's version of these
functions, easing porting of code in both directions.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was broken by the following Libav commit:
4c387c7 ppc: dsputil: do unaligned block accesses correctly
The following tests fail due to this:
fate-checkasm
fate-vsynth1-dnxhd-2k-hr-hq fate-vsynth1-dnxhd-edge1-hr
fate-vsynth1-dnxhd-edge2-hr fate-vsynth1-dnxhd-edge3-hr
fate-vsynth1-dnxhd-hr-sq-mov fate-vsynth1-dnxhd-hr-hq-mov
fate-vsynth2-dnxhd-2k-hr-hq fate-vsynth2-dnxhd-edge1-hr
fate-vsynth2-dnxhd-edge2-hr fate-vsynth2-dnxhd-edge3-hr
fate-vsynth2-dnxhd-hr-sq-mov fate-vsynth2-dnxhd-hr-hq-mov
fate-vsynth3-dnxhd-2k-hr-hq fate-vsynth3-dnxhd-edge1-hr
fate-vsynth3-dnxhd-edge2-hr fate-vsynth3-dnxhd-edge3-hr
fate-vsynth3-dnxhd-hr-sq-mov fate-vsynth3-dnxhd-hr-hq-mov
Fixes trac ticket #5508.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The parser depends on the codec and thus must not be used with a different one.
If it is, the 'avctx->codec_id == s->parser->codec_ids[0] ...' assert in
av_parser_parse2 gets triggered.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The old code had to retain a partial frame across two calls in
the case of separate interlaced fields. Now, we know that we'll
get both fields within the same receive_frame call, and so we
don't need to manage the frame as private state any more.
It's not possible to return EAGAIN when we've passed input EOF and are
in draining mode. If do return EAGAIN, we're saying there's no way to
get any more output - which isn't true in many cases.
So let's handled these cases in an internal loop as best we can.
It seems that without all the other 1:1 heuristics, we don't have
a fundamental problem trusting the interlaced flag on output
pictures. That's a relief.
I'm not sure why, but the mpeg4_unpack_bframes bsf is not
interacting well with seeking. Looking at the code, it should be
ok, with possibly one warning shown, but I see it getting stuck
for an extended period of time after a seek where a packed frame
is cached to be shown later.
So, I gave up on that and went back to making the old hardware
based path work. Turns out that it wasn't broken except that some
samples have a 6 byte drop packet which I wasn't accounting for.
Now it works again and seeks are good.
The new decode API allows for m:n decode patterns, which is what
you need to use this hardware in a sane way. There are so many
situations where 1:1 doesn't happen naturally that it's a miracle
I got it working as well as I did.
With this change, we can throw all of the crazy heuristics and
sleeps(!) out, and things work correctly.
Why on earth the hardware returns garbage for the first sample of
a decoded picture is anyone's guess. The simplest reasonable way
to patch it up is to copy the first sample of the second line. This
should result in the correct chroma values (because the data was
original 4:2:0 upsampled to 4:2:2) even if the luma is isn't.
Also adds a new flag to mark filters which are aware of hwframes and
will perform this task themselves, and marks all appropriate filters
with this flag.
This is required to allow software-mapped hardware frames to work,
because we need to have the frames context available for any later
mapping operation in the filter graph.
The output from the filter graph should only propagate further to an
encoder if the hardware format actually matches the visible format
(mapped frames are valid here and have an hw_frames_ctx, but this
should not be given to the encoder as its hardware context).
This avoids potential rounding errors and guarantees the source aspect
ratio is preserved.
Keep writing pixel values when Stereo 3D Mode is enabled and for WebM,
as the format doesn't support anything else.
This fixes ticket #5743, implementing the suggestion from ticket #5903.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes the following warning:
libavcodec/hapenc.c:122:20: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t’ [-Wformat]
Based on a patch by Diego Biurrun.
If there are no index entries, e_old = st->index_entries is only one
byte large, since it was created by av_realloc called with size 0.
Thus accessing e_old[0].timestamp causes a heap buffer overflow.
Reviewed-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This matrix needs to be applied after all others have (currently only
display matrix from trak), but cannot be handled in movie box, since
streams are not allocated yet. So store it in main context, and apply
it when appropriate, that is after parsing the tkhd one.
Fate tests are updated accordingly.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This is needed for improved fate testing and it is modeled after
-show_format_entry. The main behavioral difference is that when a print
function is called with an empty key, rather than discarding it, the
closes key in the hierarchy is used instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The use of TLSv1_*_method() disallows newer protocol versions; instead
use SSLv23_*_method() and then explicitly disable the deprecated
protocol versions which should not be supported.
Merged as-at libav 398f015, and therefore includes outstanding
skipped merges 04b17ff and 130e1f1.
All features not in libav are preserved, and no options change.
pkg-config(1) expects uninstalled pc files to follow the
blah-uninstalled.pc naming convention and the behavior
of the program is impacted by it. Without this fix
overriding PKGP_CONFIG_LIBDIR is required to ensure
uninstalled files are preferred (overkill), instead of
just adding pc-uninstalled/ to the utility's search path
by setting PKG_CONFIG_PATH accordingly.
Signed-off-by: Reynaldo H. Verdejo Pinochet <reynaldo@osg.samsung.com>
The number of channels is used as divisor in decode_frame, so it must
not be zero to avoid SIGFPE crashes.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The use of TLSv1_*_method() disallows newer protocol versions; instead
use SSLv23_*_method() and then explicitly disable the deprecated
protocol versions which should not be supported.
Fixes ticket #5915.
libavcodec/hapenc.c:121:20: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘size_t {aka unsigned int}’ [-Wformat=]
libavcodec/hapenc.c:121:20: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘size_t {aka unsigned int}’ [-Wformat=]
Since avversion.h is a generated header it must be created before
dependencies can be determined as a side effect of compilation.
Otherwise Make stops and restarts the build process to generate
avversion.h and produces related error messages.
The dynamic buffer does not contain the CRC32 element so calls to avio_tell()
don't take it into account. This resulted in CueRelativePosition values being
six bytes short.
This is a regression since 6724525a15
Instead of adding yet another custom check for CRC32 to fix a size or an offset,
remove the existing ones and reserve the six bytes in the dynamic buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
Some people seem to oppose this the patch seems to have been missed for a month on the ML
lets restart the discussion and solve this after the release
This reverts commit e936c8d176.
Allowing larger timestamps makes it impossible to calculate basic things like the
difference of 2 timestamps or their sum without checking each individual computation for
overflow.
This should avoid a significant number of overflow checks
Fixes Ticket5136
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Current code doesn't initialize AVPacket::pos. Made it point to FLVTAG so flv_read_packet can decode from pos
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When the macro is expanded with a semicolon following it and the
macro itself contains a semicolon, we ended up in double semicolons,
which is treated as a statement that disallows further declarations.
This avoids errors about mixed declarations and statements on gcc,
after ee05079766.
Signed-off-by: Martin Storsjö <martin@martin.st>
Allows to write correct value for biBitCount into BITMAPINFOHEADER.
Before, ff_put_bmp_header() always wrote "24" as biBitCount
for utvideo because bits_per_coded_sample was never set by the
encoder.
the bps value is only stored with level >= 1, using rgb48 with level 0 requires the
user app to keep track of the bps by external means, which does not always happen
also we force level >= 1 for other 16bps formats, so this is consistent.
Found-by: Jerome Martinez <jerome@mediaarea.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is intended to workaround bug "665 Integer Divide Instruction May
Cause Unpredictable Behavior" on some early AMD CPUs, which causes a
div-by-zero in this codepath, such as reported in Mozilla bug #1293996.
Note that this isn't guaranteed to fix the bug, since a compiler is free
to reorder instructions that don't depend on each other. However, it
appears to fix the bug in Firefox, and a similar patch was applied to
libvpx also (see Chrome bug #599899).
The buffer map/unmap code was in an early version of this before it
was committed, but the unmap was never removed. While wrong, this
was harmless (and therefore unnoticed) because the buffers can't be
mapped at this point - all drivers just did nothing with the call.
Use new H264Ref.reference field to track field picture flags. The
H264Picture.reference flag in DPB is now irrelevant here.
This is a regression from git commit a12d3188, and that affected
multiple interlaced video streams.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>
When decoding interlaced pictures, the structure is reused to render
to the same surface twice. The parameter buffers were not being
cleared, which caused the i965 driver to error out.
3 parts:
- Supports multiple chapter streams
- Exports regular text chapter streams as opaque data. This prevents consumers
from showing chapters as if they were regular subtitle streams.
- Exports video chapter streams as thumbnails, and provides the first one as
an attached_pic.
This allows a consumer to run the muxer's init function without actually
writing the header, which is useful in chained muxers that support
automatic bitstream filtering.
Instead use our own struct, which we already use when using
gcrypt and gnutls.
In OpenSSL 1.1, the DH struct has been made opaque.
Signed-off-by: Martin Storsjö <martin@martin.st>
1.MMI_ load/store macros are defined in libavutil/mips/mmiutils.h
2.Replace some unnecessary unaligned access with aligned operator
3.The MMI_ load/store is compatible with cpu loongson2e/2f which not support instructions start with gs
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
1.mmiutils.h defined MMI_ load/store macros for loongson2e/2f/3a
2.mmiutils.h defined some mmi assembly macors
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It is negative, so can't be used for left shifting.
This fixes ubsan runtime error: shift exponent -1 is negative
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
sigaction is not defined in standards as a struct starting with another
struct. Some *BSD variants do however, resulting in a warning from the
zero initialization, which this change eliminates.
This partially reverts a92be9b856.
The MMX state must be cleared between using MMX and using memory allocation
thats basically the only location between the 2
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add new mime types AAL2-G726 for g726 as suggested in rfc 3551.
This patch will break interaction with applications that incorrectly
use big-endian G.726 with mime type G726 but we know of at least one
device (DVTel camera) that correctly implements the rfc, so do the same.
Fixes ticket #5890.
vp9_cx_iface actually allows values in range [0..2].
This fixes ticket #5894.
Signed-off-by: Kagami Hiiragi <kagami@genshiken.org>
Signed-off-by: James Zern <jzern@google.com>
For 'nclx', the latest edition of the standard switched from JPEG XR
to 23001-8, which matches the current order of our entries. Bounds
are preserved as a sanity check.
For 'nclc', qtff edition 2016-09-13 introduced a few new entries.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Otherwise another frame gets referenced into picture, triggering an assert
(from commit 13aae8) in av_frame_ref.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
It can be unset in avcodec_parameters_from_context and a value of 0
causes SIGFPE crashes.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
on OSX:
../configure --disable-everything --enable-demuxer=hls make
error message: Undefined symbols for architecture x86_64:
"_av_vda_default_init2", referenced from:_videotoolbox_init in
ffmpeg_videotoolbox.o
so add av_vda_default_init2 when CONFIG_H264_VDA_HWACCEL=0
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: Xidorn Quan <quanxunzhen@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix problem to fail by a RTMP Control Message except "Set Chunk Size (1)" after an RTMP handshake. When 'nginx-rtmp-module' relays an RTMP, it sends not only control message 'Set Chunk Size (1)' but also 'Window Acknowledgement Size (5)'.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This function must be called from the mb or slice encoding loop and MMX state may not
be clean there
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Read video_line_map from MXF generic picture essence descriptor and use
it to derive the coded field order. Use field_dominance to derive the
display field order from coded field order. If field_dominance is not
available the default value "1" is used as defined in SMPTE S377-1.
Fixes field_order detection for a bunch of DV/DVCPRO files. The heuristic
for deriving coded field order from video_line_map is inspired by
MediaInfo.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Negative values don't make sense and too large values can cause
overflows. For AV_CODEC_ID_ADPCM_THP this leads to a too small extradata
buffer being allocated, causing out-of-bounds writes.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Its impossible to update the filesize & duration values if seekback is not
possible as with live streams
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If probe_codec is called with pkt == NULL, it sets probe_packets to 0
and request_probe to -1.
However, request_probe can change when calling s->iformat->read_packet
and thus a probe_packets value of 0 doesn't guarantee a request_probe
value of -1.
In that case calling probe_codec again is necessary to prevent
triggering the assert.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This way it's more clear what the default values refer to, as
Undetermined/Unspecified is 0 for some, 2 for others.
Signed-off-by: James Almer <jamrial@gmail.com>
Performance improvements:
quant_bands:
with: 681 decicycles in quant_bands, 8388453 runs, 155 skips
without: 1190 decicycles in quant_bands, 8388386 runs, 222 skips
Around 42% for the function
Twoloop coder:
abs_pow34:
with/without: 7.82s/8.17s
Around 4% for the entire encoder
Both:
with/without: 7.15s/8.17s
Around 12% for the entire encoder
Fast coder:
abs_pow34:
with/without: 3.40s/3.77s
Around 10% for the entire encoder
Both:
with/without: 3.02s/3.77s
Around 20% faster for the entire encoder
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: James Almer <jamrial@gmail.com>
x29 (FP) is a callee saved register and should be restored on
return. Instead of backing up x29 and restoring it here, back up
sp in a register that we are allowed to overwrite.
This fixes crashes in checkasm on aarch64 since f1b3e13138.
For some reason, gcc builds didn't crash, but clang builds do.
Signed-off-by: Martin Storsjö <martin@martin.st>
mov_finalize_stsd_codec parses stream information from the ALAC extradata,
so run it after the extradata processing is completed in mov_read_stsd.
Fixes playback of 96kHz ALAC streams muxed by qaac or the reference alac encoder.
Fixes trac ticket #5826
This, combined with clobbering the stack space prior to the call,
increases the chances of finding cases where 32 bit parameters
are erroneously treated as 64 bit.
Signed-off-by: Martin Storsjö <martin@martin.st>
Even if MAX_ARGS - 2 (for arm) or MAX_ARGS - 7 (for aarch64) parameters
are passed on the stack to checkasm_checked_call, we actually only
need to store MAX_ARGS - 4 (for arm) or MAX_ARGS - 8 (for aarch64)
parameters on the stack when calling the tested function.
Signed-off-by: Martin Storsjö <martin@martin.st>
This also fixes a minor bug introduced in the codecpar conversion, where
the termination condition for extracting the extradata does not match
the actual extradata setting code. As a result, the packet durations
made up by lavf go back to their values before the codecpar conversion.
That is of little consequence since that code should eventually be
dropped completely.
This way they can be reused by other code without including the whole
decoder-specific hevcdec.h
Also, add the HEVC_ prefix to them, since similarly named values exist
for H.264 as well and are sometimes used in the same code.
The code works just fine regardless of unit, so only make sure DisplayUnit
is not "unknown".
Found-by: Nicolas George <george@nsup.org>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: James Almer <jamrial@gmail.com>
The spec says
9: Interlaced with bottom field displayed first and top field stored first
14: Interlaced with top field displayed first and bottom field stored first
And avcodec.h states
AV_FIELD_TB, //< Top coded first, bottom displayed first
AV_FIELD_BT, //< Bottom coded first, top displayed first
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
It's container level information on some formats (Matroska, MXF, yuv4mpeg), so
it should be printed at higher log levels than debug.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
We don't currently support values 1 (centimeters), 2 (inches) or 3 (DAR),
only the default value 0 (pixels) which doesn't need to be written.
The fate refs are updated as unknown SAR is now signaled in the output
files with the addition of the new element.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
A missing DisplayUnit element or one with the default value of 0 means
DisplayWidth and DisplayHeight should be interpreted as pixels.
The current code setting st->sample_aspect_ratio is wrong when DisplayUnit
is anything else.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
According to the public RTMP specification, these 4 bytes should
be zero.
librtmp in server mode assumes that the RTMPE (FP9) handshake is
used if these bytes are nonzero.
Signed-off-by: Martin Storsjö <martin@martin.st>
When acting as server, the server can include a "clientid" property
in some status messages. But this should be a unique number
identifying the client session, not identifying the server itself.
In practice, omitting it works just as well as including this
incorrect field.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure that e.g. Adobe FME actually reacts to it. As long
as the value we've been sending is the default one (128), the bug
hasn't been noticed.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some applications such as Adobe FME append lots of parameters
here, making it easily overflow the current limit.
Signed-off-by: Martin Storsjö <martin@martin.st>
The calculation of width/height should round up, not round down to
prevent setting width or height to 0.
Also image->comps[compno].w is unsigned (at least in openjpeg2), so the
calculation could silently wrap around without the explicit cast to int.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
openjpeg 2 sets the data pointers of the image components to NULL,
causing segfaults if the image is reused.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This is a similar filter to f_metadata, only it works on side data. Since
adding side data from a user provided arbitrary binary string is unsafe,
because current code assumes that a side data of a certain kind has the proper
size, this filter only implements selection and deletion. Also, no value
matching support is implemented yet, because there is no uniform way to specify
a side data textually.
Signed-off-by: Marton Balint <cus@passwd.hu>
Use check_lib2 to test the header together with the function. This is
necessary, because '-DOPJ_STATIC' changes what the included header does.
Also add '-DOPJ_STATIC' to CPPFLAGS, so that it isn't necessary to
hardcode this in libavcodec/libopenjpeg{dec,enc}.c.
Finally, check for non-static openjpeg 2.1, too.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This fixes a build problem for MIPS architecture that looks like this:
libavcodec/mips/h264dsp_msa.c:2498:6: error: conflicting types for
‘ff_weight_h264_pixels16_8_msa’
void ff_weight_h264_pixels16_8_msa(uint8_t *src, int stride,
This bug was introduced by commit bc26fe8927:
avcodec/h264: Use ptrdiff_t for (bi)weight functions
That commit changed the data type of some function parameters in some
function definitions. However, the implementation of those functions in
libavcodec/mips/h264dsp_msa.c wasn't changed accordingly.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The spec says
9: Interlaced with bottom field displayed first and top field stored first
14: Interlaced with top field displayed first and bottom field stored first
And avcodec.h states
AV_FIELD_TB, //< Top coded first, bottom displayed first
AV_FIELD_BT, //< Bottom coded first, top displayed first
Reviewed-by: Dave Rice <dave@dericed.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The hardware handling of packed bframes was always questionable but
it used to ok with my workaround. Today, not so much. But today we
have a bsf to unpack the bframes, so let's just use that and be
done with it.
With all the various refactorings that have happened over the years,
the current pts logic is very broken for non-trivial cases (ie: ones
where not every frame/field has a meaningful pts assocated with it).
Generally, we do not want to write AV_NOPTS_VALUE as the output
timestamp, regardless of anything else. It's better to pass zero
if there's no other information.
Additionally, interlaced content where the decoder returns each field
separately can result in the first field carrying the timestamp and
the second having AV_NOPTS_VALUE. It's clearly wrong to overwrite
the valid timestamp.
So, let's just never write AV_NOPTS_VALUE into an output frame.
Empirically, this fixed playback of interlaced mpeg2 and h.264 and
mpeg4-asp with packed b-frames in an avi container.
Using lfg was an overkill in this case where the random numbers
were only used for encoder descisions. Should increase result
uniformity between different FPUs and gives a slight speedup.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The spec says:
"Mandatory elements with a default value may be left out of the file. In the absence
of a mandatory element, the element's default value is used."
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Attachment tags were being written targeting non-existent streams in the
output file.
Also filter filename and mimetype entries, as they are standard elements
in the Attachment master.
Signed-off-by: James Almer <jamrial@gmail.com>
The parser for the outdef will accept a negative value for the first
named channel's gain. As negative values effectively only invert the
phase of the signal, and not negate the level, the gains' absolute
values must be used to correctly accumulate the levels.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The optimizations of mipsdsp are not supported by all loongson cpu.
The optimizations of mipsfpu and mipsdspr2 maybe supported by 3A2000/3A3000/3A4000 but not tested yet.
Loongson only support mmi (loongSIMD) optimizations now.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The slice index expected by D3D11VA is the one from the texture not from the
array or texture/slices.
In VLC the slices we provide the decoder don't start from 0 and thus pictures
appear in bogus order. With possible crashes and corruptions when using an
invalid index.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Using the stream timebase simply overflows
Fix integer overflow in psp framerate computation
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '398f015f077c6a2406deffd9e37ff34b9c7bb3bc':
avconv: buffer the packets written while the muxer is not initialized
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The dynamic AVIOContext would get closed pointing to the wrong position
in the buffer.
This is a regression since 650e17d88b.
Reviewed-by: Dave Rice <dave@dericed.com>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '1c169782cae6c5c430ff62e7d7272dc9d0e8d527':
avconv: explicitly postpone writing the header until all streams are initialized
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '5b63b15663d31f50ce45d980b904a68795ad3f7a':
lavfi: set the link hwframes context before configuring the dst input
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '3c84eaae9da0dc450ae99c65bb6b9865e3ba7fad':
h264: Eliminate unused but set variable
Noop, the variable doesn't exist in our code.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fe498ef5144d3712b887f44a0c5e654add99ead7':
hwcontext_vaapi: Return all formats for constraints without config
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '11b8030309ee93d79b3a6cd4b83bf00757db1598':
vaapi_encode: Fix fallback when input does not match any format
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '32c8359093d1ff4f45ed19518b449b3ac3769d27':
lavc: export the timestamps when decoding in AVFrame.pts
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Decoders have previously not used AVFrame.pts, and with the upcoming
deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
interpration of timestamps.
This fixes a long-standing issue where running FATE in parallel could result
in the terminal being left misconfigured, particularly if a test failed or
was canceled wtih ^C.
This allows us to be more selective about the streams we derive durations from
(specifically, ignoring text streams with outlier end times) in the common case
This way, Doxygen is happier as aliases are now grouped together, and
it never handled #define's in an enum well in the first place.
Y400A already exists as an enum assignment.
As all known valid HDCD sample formats and sample rates are now handled
by the filter, remove the scan that "invades the privacy" of the filter graph
and turn off autoconvert by default as requested by Nicolas George.
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197571.html
Signed-off-by: Burt P <pburt0@gmail.com>
I don't have any legitimate 20 or 24-bit HDCD to test. It is known
that the PM Model Two would insert packets into 20 and 24-bit output,
but I have no idea what differences in behavior existed when decoding
20 or 24-bit. For now, as with 16-bit, PE (if enabled) will expand the
top 3dB into 9dB and LLE (gain adjust) will be applied if signaled.
Signed-off-by: Burt P <pburt0@gmail.com>
New versions of hdcd_scan() and hdcd_integrate() that also do the
work of hdcd_scan_stereo() and hdcd_integrate_stereo().
Some code split into previously separate functions to remove
duplication is now merged back into each function in the single
place where it is used.
Signed-off-by: Burt P <pburt0@gmail.com>
The buffer is already being copied anyway, so interlace the planar
format during the copy and remove one use of auto-convert.
Signed-off-by: Burt P <pburt0@gmail.com>
The PM Model Two could output HDCD-encoded audio in CD and all
DVD-Audio sample rates. (44100, 48000, 88200, 96000, 176400, and
192000 Hz)
Signed-off-by: Burt P <pburt0@gmail.com>
The decoding buffer index expected by D3D11VA is the one from the
ID3D11Texture2D not the one from the ID3D11VideoDecoderOutputView array
in AVD3D11VAContext.
Otherwise, when providing decoder slices that do not start from 0,
pictures appear in bogus order. For an invalid index crashes and
image corruption can occur.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Explicitly state that FATE should pass, and code should work
for all reviewers who tested.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Josh de Kock <josh@itanimul.li>
filter16 goes from 508 to 482 (h) or 346 to 314 (v) cycles; filter88
goes from 240 to 238 (h) or 174 to 165 (v) cycles, measured on TOS.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Similar gains as the ssse3 version once again
Additional improvements by Clément Bœsch <u@pkh.me>.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The randomize_buffer() implementation assures that "most of the time",
we'll do a good mix of wide16/wide8/hev/regular/no filters for complete
code coverage. However, this is not mathematically assured because that
would make the code either much more complex, or much less random.
Some fixes and improvements by Rodger Combs <rodger.combs@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This isn't a "version script" in the usual sense, since it doesn't set symbol
versions directly. Instead, the version for the whole .dylib is set in the
linker flags, and we generate a list of symbol patterns to export. This allows
us to keep our local symbols (e.g. ff_*) local on the platform.
The Darwin linker's exported_symbols_list format is a bit different than the
one used by the GNU linker. It doesn't handle local symbols at all, since when
a list is provided, all unlisted symbols are local by default; thus, we remove
local sections. It doesn't handle per-version sections, so we remove the
headers and brackets. It expects symbols to be prefixed with an underscore.
It errors if a listed symbol with no wildcards is not present in the output,
so we append an asterisk to any symbol that doesn't already end in one.
Full width text is really difficult to read, this makes it more
more legible on larger (widescreen) screens. It also means we aren't
inventing our own container instead of using the bootstrap one.
Signed-off-by: Josh de Kock <josh@itanimul.li>
This was not observed earlier because the only syntax element which
it normally misses with the current setup is slice_qp_delta, but that
is always going to be zero (in IDR frames QP isn't varied on the
slice) which will always exp-golomb code as a single 1 bit. The
immediately following part is the byte alignment, which is always a 1
bit followed by 0s which are ignored, so as long as the bitstream is
never aligned at that point we will never notice because the only
difference is that an ignored bit is a 1 instead of a 0.
Errors during decoding are currently considered non-fatal and do not
terminate transcoding, so even if parts of the data are corrupted, the
rest may be decodable.
However, that should apply only to the actual decoding calls, not to the
failures elsewhere (e.g. configuring filters).
The filtergraph's existence is used in several places to mean that the
filtergraph is fully configured. This causes problems if it's allocated,
but the initialization fails (e.g. if a non-existent filter is
specified).
There is really no need for two aac wrappers, we already have
libfdk-aac which is better. Not to mention that faac doesn't
even support HEv1, or HEv2. It's also under a license which is
unusable for distribution, so it would only be useful to people
who will compile their own ffmpeg, only use it themselves (which
at that point should just use fdk-aac).
Signed-off-by: Josh de Kock <josh@itanimul.li>
This is a bit messy, mainly due to timestamp handling.
decode_video() relied on the fact that it could set dts on a flush/drain
packet. This is not possible with the old API, and won't be. (I think
doing this was very questionable with the old API. Flush packets should
not contain any information; they just cause a FIFO to be emptied.) This
is replaced with checking the best_effort_timestamp for AV_NOPTS_VALUE,
and using the suggested DTS in the drain case.
The modified tests (fate-cavs and others) still fails due to dropping
the last frame. This happens because the timestamp of the last frame
goes backwards (ffprobe -show_frames shows the same thing). I suspect
that this "worked" due to the best effort timestamp logic picking the
DTS over the decreasing PTS. Since this logic is in libavcodec (where
it probably shouldn't be), this can't be easily fixed. The timestamps
of the cavs samples are weird anyway, so I chose not to fix it.
Another strange thing is the timestamp handling in the video path of
process_input_packet (after the decode_video() call). It looks like
the code to increase next_dts and next_pts should be run every time
a frame is decoded - but it's needed even if output is skipped.
With the new decode API, doing this in ffmpeg.c is impractical. There
was resistance against removing the warning, so put it into libavcodec.
Not bothering with reducing the warning to verbose log level for
subsequent wanrings. The warning should be rare, and only happen when
developing new codecs for the old API.
Includes a change suggested by Michael Niedermayer.
* commit 'ac7bfd69678f3966e38debdb27f4bde94dc0345c':
lavfi: add a QSV scaling filter
This is a noop since it depends on sharing a hwcontext with the
decoder/encoder, see 04b17ff and 130e1f1
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'ad9c9440d592e4d53d6bec9961b4b22e25387d70':
qsvenc: support getting the session from an AVHWFramesContext
This commit is a noop, as it needs to be fully re-implemented for our
qsv components.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'a0524d9b1e1bb0012207584f067096df7792df6c':
qsvdec: support getting the session from an AVHWFramesContext
This commit is a noop, as it needs to be fully re-implemented for our qsv
components.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Adds a wrapper function for downmixing which detects channel count changes
and updates the selected downmix function accordingly.
Simplification and porting to current x86inc infrastructure by Diego Biurrun.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Also use (float **) instead of (float (*)[2]). This matches the matrix
layout in libavresample so we can reuse assembly code between the two.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
when use use_localtime_mkdir to create multi level dir,
ffmpeg give error message:
ffmpeg -re -i ~/Movies/objectC/facebook.mp4 -c copy -use_localtime 1
-use_localtime_mkdir 1 -hls_segment_filename '%Y%m%d/file-%Y%m%d/%s.ts'
out.m3u8
error message:
Could not create directory 20160926/file-20160926 with use_localtime_mkdir
add mkdir_p for support the multi level dir
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Tested-by: Zuo Genyu <1515161258@qq.com> (Windows)
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>
It is supposed to be a flag. The only currently defined value is
AVIO_SEEKABLE_NORMAL, but other ones may be added in the future.
However all the current lavf code treats this field as a bool (mainly
for historical reasons).
Change all those cases to properly check for AVIO_SEEKABLE_NORMAL.
Copy interrupt callback to slave format context to allow
user to interrupt IO. Copy format flags as well.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Streaming servers appear to ignore all other language metadata.
Signed-off-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Josh de Kock <josh@itanimul.li>
Fixes gapless decoding. Adjust skip_samples field correctly in case of DISCARDed audio frames.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
While outwardly bizarre, this change makes the behaviour consistent
with other VAAPI encoders which sync to the encode /input/ picture in
order to wait for /output/ from the encoder. It is not harmful on
i965 (because synchronisation already happens in vaRenderPicture(),
so it has no effect there), and it allows the encoder to work on
mesa/gallium which assumes this behaviour.
This allows better checking of capabilities and will make it easier
to add more functionality later.
It also commonises some duplicated code around rate control setup
and adds more comments explaining the internals.
This way, in case of bit rate not being set, max_bitrate will be
used instead. This enables, for example, re-using max_bitrate
information from the input or doing transcoding with a rate
control mode that is not bit rate based.
Signed-off-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '5fa255b65c7887cc913f097aed1b581fbf1a8745':
avconv: initialize output framerate earlier
Skipping this for now. It's not needed until several committs ahead,
and should be carefully implemented.
Merged-by: James Almer <jamrial@gmail.com>
This assert can with crafted files fail, a warning is already printed
for this case.
Fixes assertion failure
Fixes:1/assert.avi
Found-by: 连一汉 <lianyihan@360.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also don't set time_base. It's deprecated for decoding and avcodec_open2()
will overwrite it
Reviewed-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: James Almer <jamrial@gmail.com>
This commit is based on commit 35c8580 from Anton Khirnov <anton@khirnov.net>
which was skipped in b8945c4.
The avcodec_copy_context() call in the encode path is left in place for now
as AVStream.codec is apparently still required even after porting ffmpeg to
the new bsf API.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Follow a 420, 422, 444 order instead of a random one.
This simplifies double-checking additions of new formats.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
When the input frames contain side data, it will accumulate endlessly in
the coded frame, as av_frame_copy_props will append any new side data.
Fixes ticket #5799.
Increase the nb_bitstream_filters value as soon as the context is allocated, so
if option parsing fails the last context is actually freed.
Reviewed-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '1e93c1e30ff0e8bf6094a426ca60f005e9cdaed3':
avconv: do not set encoder options when streamcopy is used
This chunk was removed in 955b818cf9
already.
Merged-by: Clément Bœsch <u@pkh.me>
This commit is initially largely based on commit 4426540 from Anton
Khirnov <anton@khirnov.net> and two following fixes (80fb19b and
fe7b21c) which were previously skipped respectively in 98e3153, c9ee36e,
and 7fe7cdc.
mpeg4-bsf-unpack-bframes FATE reference is updated because the bsf
filter now actually fixes the extradata (mpeg4_unpack_bframes_init()
changing one byte is now honored on the output extradata).
The FATE references for remove_extra change because the packet flags
were wrong and the keyframes weren't marked, causing the bsf relying on
these proprieties to not actually work as intended.
The following was fixed by James Almer:
The filter option arguments are now also parsed correctly.
A hack to propagate extradata changed by bitstream filters after the
first av_bsf_receive_packet() call is added to maintain the current
behavior. This was previously done by av_bitstream_filter_filter() and
is needed for the aac_adtstoasc bsf.
The exit_on_error was not being checked anymore, and led to an exit
error in the last frame of h264_mp4toannexb test. Restoring this
behaviour prevents erroring out. The test is still changed as a result
due to the badly filtered frame now not being written after the failure.
Signed-off-by: Clément Bœsch <u@pkh.me>
Signed-off-by: James Almer <jamrial@gmail.com>
This commit also drops SDL1 support for ffplay.
Tested-by: James Almer <jamrial@gmail.com> (Windows, mingw-w64)
Signed-off-by: Josh de Kock <josh@itanimul.li>
Although cuvid can only output 8bit, it can consume HEVC Main10 if
the bit depth is set properly. In cases where >8bit is not supported,
this change is still beneficial as the decoder will fail to be
created instead of plowing throw and decoding as 8bit.
We need to remove the dynlink fanciness and replace it with normal
function prototypes and update the include paths and configure logic.
We don't need to explicitly check for PICPARMS now - they're going
to be there.
For unknown reasons, the only accurately descriptive version of
cuviddec.h is in the Video SDK - the one in CUDA 7.5 lacks vp8
PICPARAMS and the vp9 struct definition is inaccurate. The CUDA 8 RC
includes an ancient version of this file from many many years go.
However, the one in the Video SDK is modified to work through a
dynamic link mechanism which we don't really want to use, so the
next change will modify the files to just declare functions in
the normal way.
I've split the changes so it's clear to see what changed between
the original files and ones that work for us.
Although the old API is supposed to be functional, the crystalhd
decoder is currently not working for non-annex.b h.264 content.
So, let's update to the modern API and make it work again.
Signed-off-by: Philip Langdale <philipl@overt.org>
Currently does not work with the ffmpeg cli tool, due do it using the
old one in one out API.
Anything using the new API, like mpv, can make use of it, provided it is
prepared for a decoder modifying the framerate and outputing multiple
frames per input. FFmpeg itself is not.
This commit is largely based on commit 15e84ed3 from Anton Khirnov
<anton@khirnov.net> which was previously skipped in bbf5ef9d.
There are still a bunch of things raising codecpar related warnings that
need fixing, such as:
- the use of codec->debug in the interactive debug mode
- read_ffserver_streams(): it's probably broken now but there is no test
- lowres stuff
- codec copy apparently required by bitstream filters
The matroska references are updated because they now properly forward
the field_order (previously unknown, now progressive).
Thanks to James Almer for fixing a bunch of FATE issues in this commit.
Signed-off-by: Clément Bœsch <clement@stupeflix.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This FIXME probably meant to suggest to use a AVFrame that no longer
exists in the context.
Found-by: durandal117
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This version, which is the only one doing two processing cycles per loop
iteration, computes the load/store indices incorrectly for the second
cycle.
CC: libav-stable@libav.org
This is the assumption that is made in pixel format conversion do
throughout the code (in particular swscale), and BT-specifications
mandate.
Add a warning to inform the user that an automatic selection is being
made.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
* Multichannel support for TrueHD is experimental
There should be downmix substreams present for 2+ channel bitstreams,
but ffmpeg decoder doesn't need it. Will add support for this soon.
* There might be lossless check failures on LFE channels
* 32-bit sample support has been removed for now, will add it later
While testing, some samples gave lossless check failures when enforcing
s32. Probably this will also get solved with the LFE issues.
Signed-off-by: Jai Luthra <me@jailuthra.in>
Despite the video parser seeming to correctly handle 422 and 444
chroma formats, the video decoder fails miserably to actually
decode frames - even though no errors are ever returned; you just
get frames showing unintialized garbage.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
I'm not really sure how this worked at all before, but we do need to
reinitalize the parser with the stream extradata.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Add an option to specify HTTP header in the WebM Chunk Muxer (this
works the same way as the 'method' parameter in the HLS muxer).
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This was introduced in bc2a32969e.
The whole block that the statement was added to is only
relevant when used as a demuxer, but the other statements
there have had other if statements guarding them. Make
sure to only run this whole block if being used as a
demuxer.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Introduced in 00e122bc / bc2a3296
The whole block that the statement was added to is only
relevant when used as a demuxer, but the other statements
there have had other if statements guarding them. Make
sure to only run this whole block if being used as a
demuxer.
Fixes ticket #5844.
If the input has been decoded from a stream which uses edge cropping
then the whole surface need not be valid. This defines an input
region for the scaler so we only use the active area of the frame.
When there is only one stream and stream_index has not specified,
The ts has been transferd by the timebase of stream0 without modifying the stream_index
In this condation it cause seek failure.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
when split flv file by flv format at first, and cat flvs file
into one flv file, the flv sequence end is be used,
then the whole flv have many flv sequence end TAG.
this flags can give user an option to ignore write sequence end TAG
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This avoids SIMD-optimized functions having to sign-extend their
line size argument manually to be able to do pointer arithmetic.
Also adjust parameter names to be "stride" everywhere.
Useful when the amerge filter parameters are generated from a script based on
the number of input streams, by allowing 1 input it does not have to be handled
specially.
The split filter also allows 1 output, so it is more consistent to allow
merging 1 input as well.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Marton Balint <cus@passwd.hu>
Allows to use values returned from API and from ffprobe directly.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
The latter can do everything the former can do, but also handle conditions
the former cannot like multiple header #includes and checking for headers
and functions in a single test program, which is necessary for certain
library tests.
This is mostly useful for muxers that wrap other muxers, such as dashenc
and segment. The actual duplicated bitstream filtering is largely harmless,
but delaying the header can cause problems when the muxer intended the header
to be written to a separate file.
Should fix "libavcodec/h264_refs.c:372:13: warning: variable 'i' is used uninitialized whenever switch default is taken"
Found-by: durandal_17
Suggested-by: jkqxz
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The cuvid parser is basically undocumented, and although you'd
think that a failed callback would result in the overall parse
call returning an error, that is not true.
So, we end up silently trying to keep going as if nothing is wrong,
which doesn't achieve anything.
Solution: check the internal error flag every time.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
With some old libva versions <va/va.h> does not automatically include
the per-codec subsidiary headers, so we need to include the right one
explicitly ourselves.
Introduced in b7e78c7 and 93ae68d.
Fixes#5835.
The paletteuse debug options that are not part of the official API are
not included (debug_kdtree and color_search).
Signed-off-by: Lou Logan <lou@lrcd.com>
This is simpler and fixes an out of array read, fixing it with AVBuffers
would be more complex
Fixes: e00d9e6e50e5495cc93fea41147b97bb/asan_heap-oob_12dcdbb_8798_b32a97ea722dd37bb5066812cc674552.mov
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ffmpeg have a generic solution working with all muxer named
output_ts_offset, output_ts_offset will instead of initial_offset
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array read
Fixes: 1642cd3962249d6aaf0eec2836023fb6/signal_sigsegv_2557a72_2995_04efaf2ff57a052f609a3b4a2ea4e622.mov
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
we need to check that (count + 1) won't cause overflow.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
nvenc still encodes as yuv, but does the conversion internally which
brings some performance gains.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
add tests/ref/fate/filter-hls-append for FATE
add hls-list-append fate use filter make audio data and test hls_flags
append options
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes regressions with stream copy and output timebase/fps being twice as fine as needed
Makes the timebase and ticks per frame handled identical which should make the
code easier to understand and work with. It does not solve the problem without
st->codec access
Suggested-by: Hendrik Leppkes
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously, we used a different list of checks when deciding whether to
write a set of tags at all than we did when deciding whether to write an
individual tag in the set. This resulted in sometimes writing an empty
tag master and seekhead. Now we use mkv_check_tag_name everywhere, so
if a dictionary is entirely composed of tags we skip, we don't write a
tag master at all.
This affected the test file, since "language" was on one list but not
the other, so we were writing an empty tag master there. The test hash
is updated to reflect that change.
Right now, if we attempt to use cuvid in a media player and then
try to seek, the decoder will happily pass out whatever frames were
already in flight before the seek.
There is both the output queue in our code and some number of frames
within the cuvid decoder that need to be accounted for.
cuvid doesn't support flush, so our only choice is to do a brute-force
re-creation of the decoder, which also implies re-creating the parser,
but this is fine.
The only subtlty is that there is sanity check code in decoder
initialisation that wants to make sure the HWContextFrame hasn't already
been initialised. This is a fair check to do at the beginning but not
after a flush, so it has to be made conditional.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
cuvid/nvdecode also supports mpeg1, mpeg2, h.263/mpeg4-asp and mjpeg.
It should, in theory, also support wmv3 via the vc1 support, given
that vdpau supports this. However, it failed to play wmv3 samples
which vdpau played correctly, so I'm not sure what to make of it.
Signed-off-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This patch is a fix for the bug with ticket number 5812
(https://trac.ffmpeg.org/ticket/5812).
Basically, the bug is that the last segment and the "#EXT-X-ENDLIST"
tag are not being written to the subtitle playlist file when
converting a file with subtitles to the HLS format. The reason for
this seem to be that the filename for the subtitle file is being freed
too early. This solution is simply to free that memory after it's last
use in the "hls_window" function.
Signed-off-by: Franklin Phillips <franklinphillips9p8@inbox.lv>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The filter needs input frames with color properties filled out by
the decoder. Since this is not always possible, add input options to
the filter so that user may override color space, color primaries,
transfer characteristics, and color range, as well as a generic option
to set all properties at once.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Allows testing simple_idct12 correctness/bitexactness, as the sample
was generated using faani as idct.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For some reason, when compiling with gcc-asan and a recent enough gcc
version(seen on 5.3+ so far), linking dlopen works without -ldl, but
dlsym fails with:
undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
So this patchs checks for both dlopen and dlsym to work for determining
if -ldl is needed.
This allows libavcodec/opus to demux ambisonics in an ogg/opus container.
Channel mapping family 2 is being added in this standards track IETF draft:
tools.ietf.org/html/draft-ietf-codec-ambisonics-00
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Including this header in a C++11 program (inside extern "C") will
throw an error because it looks like a user-defined literal. Add a
space between the two tokens to avoid the problem.
Commit 2b1d316ff6 made nvenc depend on
LoadLibrary, but the availability of the latter was never checked.
This fixes nvenc on Windows platforms
Signed-off-by: James Almer <jamrial@gmail.com>
Sometimes it's useful to be able to define the exact track numbers in
the generated track, instead of always beginning at track id 1. Using
the option use_stream_ids_as_track_ids now copies the use stream ids
to track ids. Dynamically generated tracks (ie. tmcd) have their track
numbers defined as continuing from the highest numbered stream id.
Signed-off-by: Erkki Seppälä <erkki.seppala.ext@nokia.com>
Signed-off-by: OZOPlayer <OZOPL@nokia.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When use append_list mode, the hls_init_time set nouse,
Because the append_list only support append at the old m3u8 end
cannot set init segments durations at the middle of the list.
That's invalid. and show a warning message for user.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
cyrpto allows reading of data which has been aes-128-cbc encrypted given a key and an iv. But it did not handle filetypes which require seeking... e.g. it failed on an encrypted .mp4 file.
example:
take 25.mp4 created with:
ffmpeg -f lavfi -i sine=frequency=1000:beep_factor=2:r=48000:duration=720.0 -f lavfi -i testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22 -timecode 10:00:00:00 -r 25 -y out\25.mp4
encrypt with:
openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv 12345678901234567890123456789012 -in 25.mp4 -out 25.enc
then to transcode in ffmpeg:
ffmpeg -key 12345678901234567890123456789012 -iv 12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y 25dec.mp4
prior to this modification, the transcode would fail.
Note also: crypto previously maked both reads and writes as streamed, which caused the whole file
to be read before the transcode started. Now, for read only, if the underlying layer is not marked as streamed,
then crypto is not. This should enable efficient reading of encrypted containers which require seeking.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
the current implementation reads in chunks of 149x16=2384 bytes.
Seems more logical for it to read in chunks of 4096
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A number of new pix_fmts have been added to AviSynth+:
16-bit packed RGB and RGBA
10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
8-, 10-, 12-, 14-, and 16-bit Planar RGB
8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA*
10-, 12-, 14-, and 16-bit GRAY variants*
32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY*
*some of which are not currently available pix_fmts here and were
not added to the demuxer due to this
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
After init_opts() there needs to be an uninit_opts() call
to free the swscale context and other buffers.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This was added before edts support existed, and is no longer
valid.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df0,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
recover segments duration time by hls_time after init hls window.
This is reuqested by Ibrahim Tachijian
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av_log() expects its first parameter to be a pointer to a struct whose
first element is a pointer to an AVClass. In what I can only imagine is
a typo, one call to av_log() in the AAX decryption code instead passes
a pointer to an AVSHA struct, which doesn't even contain a pointer as
its first element, much less a pointer to an AVClass. Change the call to
pass the current MOVContext, as surrounding calls do.
The incorrect AVClass was causing mpv to emit the warning "av_log
callback called with bad parameters" when playing an .aax file.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
As Nvidia has put the most recent Video Codec SDK behind a double
registration wall, of which one needs manual approval of a lenghty
application, bundling this header saves everyone trying to use NVENC
from that headache.
The header is still MIT licensed and thus fine to bundle with ffmpeg.
Not bundling this header would get ffmpeg stuck at SDK v6, which is
still freely available, holding back future development of the NVENC
encoder.
Use proper ISO 8601 timestamps which also signal that they are in UTC.
This changes the format of creation_time and modification_date metadata values
from 2016-06-01 22:30:00 to 2016-01-01T22:30:00.000000Z
Fixes ticket #5673.
Signed-off-by: Marton Balint <cus@passwd.hu>
The min_shift parameter is needed by the MLP encoder
Signed-off-by: Jai Luthra <me@jailuthra.in>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Whenever a full range video is input, since the YUVJ* formats are not
listed as supported for this filter, a range reduction takes place
through the auto-inserted format filter, forcing the conversion to
operate on a limited range,
However the filter handles full range videos perfectly fine, so adding
support to YUVJ* formats will allow skipping a conversion step, while
providing completely identical results.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libavcodec/libvpxdec.c:100:57: warning: passing argument 3 of 'av_image_copy' from incompatible pointer type
av_image_copy(picture->data, picture->linesize, img->planes,
libavutil/imgutils.h:116:6: note: expected 'const uint8_t **' but argument is of type 'unsigned char **'
void av_image_copy(uint8_t *dst_data[4], int dst_linesizes[4],
This avoids SIMD-optimized functions having to sign-extend their
line size argument manually to be able to do pointer arithmetic.
Also adjust parameter names to be "linesize" everywhere.
This avoids SIMD-optimized functions having to sign-extend their
stride argument manually to be able to do pointer arithmetic.
Also adjust parameter names to be "stride" everywhere.
AV_OPT_SEARCH_CHILDREN flag must be passed to av_opt_set_dict()
to set options for private context.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Mostly just re-arranges some code to make it easier to update this
filter and libhdcd together. filter_frame() is much simpler as a
result.
* use the HDCD detection data structure and functions from libhdcd,
moved detection code out of filter_frame()
* moved analyze_mode preparation out of filter_frame() into
hdcd_analyze_prepare(), from libhdcd
* moved some macro definitions to the top so they are all together
Signed-off-by: Burt P <pburt0@gmail.com>
Milliseconds is the de-factor precision for timestamps in
Matroska/WebM media.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df0,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Making sure bestpos is initialized to zero to prevent gcc from kvetching.
It's harmless (although it's not obvious that it's harmless)
from code inspection:
tests/audiomatch.c: In function ‘main’:
tests/audiomatch.c:40: warning: ‘bestpos’ may be used uninitialized in this function
Thanks to Moritz Barsnick for first bringing this to the attention.
Signed-off-by: LiuQi <liuqi@gosun.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The names are hard to understand and also seem to break build on at least some solaris
versions
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This also disabled the case of mixed x/ymin with tiles, the code
handles these cases inconsistent for the 2 coordinate axis and is
unlikely working correctly.
Fixes crash
Fixes: poc1.exr, poc2.exr
Found-by: Yaoguang Chen of Aliapy unLimit Security Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Anton Khirnov:
"[av_frame_copy_props()] potentially contains memory allocation,
so the return value needs to be checked."
Signed-off-by: Burt P <pburt0@gmail.com>
memalign() is not guranteed to be compatible with free() or realloc()
and for platforms in this category we have --enable-memalign-hack
(which should be enabled automatically if such system is detected)
Trying to somehow half support systems that can free() memalign memory
but not reallocate it seems not worth the amount of work needed to
keep 2 then incompatible allocation systems and ensure their
seperation. That is unless this would affect a major platform
on which we want to avoid the memalign hack code
The warnings also cause wasted time and effort as people try
to maintain a separation that does not exist currently.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Now force_codec_ids supports AVMEDIA_TYPE_DATA and
avformat_query_codec accepts data codecs as well in addition to video,
audio and subtitle tracks.
Signed-off-by: Erkki Seppälä <erkki.seppala.ext@nokia.com>
Signed-off-by: OZOPlayer <OZOPL@nokia.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes occurance of NaN/Inf leading to assertion failures and out of array access
Fixes: d1c38a09acc34845c6be3a127a5aacaf/signal_sigsegv_3982225_6121_d18bd5451d4245ee09408f04badd1b83.wmv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Windows versions earlier than XP are not supported.
Should fix compilation of command line tools.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Restore original timestamps in write_packet() if the
actual write operation was not successfull. This allows
to pass the same packet to nonblocking muxer repeatedly
without corrupting the timestamps.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array read
Fixes: 049fdf78565f1ce5665df236d90f8657/asan_heap-oob_10a5a97_1026_42f9d4855547329560f385768de2f3fb.wtv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When ffmpeg exit by exception, start a new ffmpeg will
cover the old segment list, add this flag can continue
append the new segments into old hls segment list
Signed-off-by: LiuQi <liuqi@gosun.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
which will
construct string description of filter chain. This is
done using lazy-initialization, so there is no overhead
if item name is never accessed.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This change relaxes the whitelist on reading color metadata in MOV/BMFF
containers. The whitelist on writing values is still in place.
As a consequence it also fixes an apparent bug in reading 'nclc' values.
The 'nclc' spec [1] is in harmony with ISO 23001-8 for the values it
lists, but the code getting removed was remapping 5->6 and 6->7 for
primaries, which is incorrect, and was remapping 6->5 for color matrix
("colorspace" in the code), which is equivalent but an unnecessary
inconsistency. This logic error doesn't appear in movenc.
Removing the whitelist allows proper conversion when the source codec
relies on the container for proper signaling of newer codepoints, such
as DNxHR and VP9. If converting to a codec or container that has updated
its spec to include the new codepoints, the metadata will be preserved.
If going back to MOV/BMFF, the output whitelist will still kick in, so
this won't result in out-of-spec files being created.
[1] https://developer.apple.com/library/mac/technotes/tn2162/_index.html
Signed-off-by: Steven Robertson <steven@strobe.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array read
Fixes: f29f134ea5f5590df554a7733294a587/asan_stack-oob_309d14e_9188_ea01743d6355aff20530f3d4cdaa841a.wav
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array read
Fixes: 09f46aa2175cade93e3e3932646a56a9/asan_heap-oob_4a5385_2995_498f6abfdc0248288cefe5f4b7ad316c.mov
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array read
Fixes: 13262c363a28da8d6bdcc472aed6e9dc/asan_heap-oob_cfb5e2_3733_31cf3fcc783295c34222eb070a784f84.3gp
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Should fix compilation with non C99 compilers like msvc 2012, where
acosh() is not available.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The implementation does not currently support len=2
Fixes out of array accesses
Fixes: 29d1b3db5ba2205e82b0b3a533e057a3/asan_heap-oob_12b650c_9254_3b8c4e4d931eb2c32841c18ebb297f1d.avi
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array access
Fixes: 6b73fa392ac808f02e95a4e0a5770026/asan_static-oob_1b15f9a_1969_e7778535e5f27225fe0d6ded14721430.AVI
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes use of uninitialized memory
Fixes: 044100cb22845944988a4bd821ff8074/asan_heap-oob_329927a_1366_c3de34ce9217dac820fbb46171031bbb.jsv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The parser changes have lost the support for the needed padding, this adds it back
Fixes out of array reads
Fixes: 03ea21d271abc8acf428d42ace51d8b4/asan_heap-oob_3358eef_5692_16f0cc01ab5225e9ce591659e5c20e35.mkv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The code currently reads the coded dimensions from the extradata, but
expects the display dimensions to be set by the caller, and does not
check that they are compatible (i.e. that the displayed size is smaller
than the coded size).
Make sure that when the display dimensions are set, they are also valid.
Fixes possible invalid memory access.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
It is passed to the get_bits API, which requires buffers to be padded.
Fixes possible invalid reads.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
height - me_y is the line from which we read, so it must be strictly
smaller than the frame height. Fixes possible invalid reads in corrupted
files.
Also, use a proper context for logging the error.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
If we encounter an END element before anything is decoded, we would
return success even though the output frame has not been allocated,
which is invalid.
CC: libav-stable@libav.org
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
the merge commit 1b04ea1 "avconv: create simple filtergraphs earlier"
will init the filtergraphs earlier, then init the QSV transcode can't
suppose the nb_filters's value, else lead to the QSV transcode performance
drop.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
Reviewed-by: Ivan Uskov <ivan.uskov@nablet.com
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch applies same changes as commit e3dfef8e3c of libav:
instead of the obsolete AVBitStreamFilterContext now the new AVBSFContext filter is used to
restore annex-B prefixes.
Based-on: e3dfef8e3c by Anton Khirnov
Push requested by maintainer
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Instead of silently ignoring the content_type option in listen mode,
apply its value to the provided "Content-Type:" header.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This version has had much testing so there's little point in keeping it
maked as experimental.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Does nothing fancy but still sounds very decent at 128kbps.
Still room to improve by bringing in the low pass and PNS management
from the main big twoloop which should improve its quality but not
sacrifice that much speed.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Use of this function can save unnecessary malloc operation
in bitstream filter.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If no string argument is supplied when av_hwdevice_ctx_create() is
called to create a VAAPI device, we currently only try the default
X11 display (that is, $DISPLAY) to find a device, and will therefore
fail in the absence of an X server to connect to. Change the logic
to also look for a device via the first DRM render node (that is,
"/dev/dri/renderD128"), which is probably the right thing to use in
most simple configurations which only have one DRM device.
This makes it easier to use the lowres option when dealing with input
files in different codecs. If the codec doesn't support lowres=1 for
instance, it will throw a warning and use lowres=0 instead of erroring
out completely.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Instead of silently ignoring the headers option in listen mode, use
the provided headers.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The values don't need to be hardcoded since the correct values are
returned by avs_bits_per_pixel.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes valgrind warnings about conditional jumps based on
uninitialized data (even though the uninitialized data only ever
was compared with a direct copy of the same uninitialized data).
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We need more information from last/cur_frame than from reference
buffers, so we can use a simplified structure for reference buffers,
and then store mvs and segmentation map information in last/cur.
This prepares the decoder for frame threading support.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Not from the underlying frame. Fixes races with frame threading in
field-coded files, where decoding would wait for the wrong field (e.g.
random failures in mixed-nal-coding).
Bug-Id: 954
A non-existent av_buffer_pool_can_uninit() function is mentioned instead
of av_buffer_pool_uninit(). Also, this function is to be called by the
caller, not the pool itself.
Restore a check added in 440af105f2
but lost sometime after. avfilter_graph_set_auto_convert() will
have an effect once again.
Signed-off-by: Burt P <pburt0@gmail.com>
Also checking AVFilterLink->type is AVMEDIA_TYPE_AUDIO before
calling av_get_sample_fmt_name() on AVFilterLink->format.
Signed-off-by: Burt P <pburt0@gmail.com>
A new mode, selected by filter option, to aid in analysis of HDCD
encoded audio. In this mode the audio is replaced by a solid tone and
the amplitude is adjusted to signal some specified aspect of the process.
The output file can be loaded in an audio editor alongside the original,
where the user can see where different features or states are present.
Signed-off-by: Burt P <pburt0@gmail.com>
This is required for >= 16bit RGB support
I tried it without templates but its too much duplicated code
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch fixes the h264_qsv decoder issues mentioned
in https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2962.
The patch may be tested by specifying h264_qsv as the decoder to ffplay
for an h264 encoded file.
ffplay -vcodec h264_qsv foo.mts
Signed-off-by: Yuli Khodorkovskiy <ykhodo@gmail.com>
Push requested-by: Ivan Uskov
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When finding a video mode based on frame size and frame rate,
use AVRational methods instead of simple comparison. Add debug information.
Signed-off-by: Matthias Hunstock <atze@fem.tu-ilmenau.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Provide the stream with the correct fps information when capturing.
Signed-off-by: Matthias Hunstock <atze@fem.tu-ilmenau.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This will be used to allow writing file sequences using the tee output onto
multiple places in parallel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also don't include it on files that don't need it.
This reduces differences with libav
Tested-by: Timothy Gu <timothygu99@gmail.com>
Reveiwed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '5e1840622ce6e41c57d9c407604863d3f3dcc3ae':
avconv: fix handling attachments in init_output_stream
Conflicts:
avconv.c
This is functionally a no-op, as we don't have the bug this is trying to
fix. See 843be56ee1.
Merged-by: Timothy Gu <timothygu99@gmail.com>
* commit '49670e4218d34899a1c37abb7a11615efc16f757':
avconv: add a function for determining whether a filtergraph is simple
Conflicts:
avconv.c
Merged-by: Timothy Gu <timothygu99@gmail.com>
* commit '606fb6c032fa44d9fa1efd4971308c228f2ebfff':
h264: call the hwaccel frame_start() from h264_field_start()
This commit is a noop, as it conflicts with 3e53211a57.
Merged-by: Timothy Gu <timothygu99@gmail.com>
* commit 'b13fc1e344011949929975a3451f78f226aa1de3':
h264: do not pass H264Context to h264_slice_header_parse()
Conflicts:
libavcodec/h264dec.h
Did not merge the h264_slice_header_parse() part. We use a few other
members of H264Context for error checking in that function.
Merged-by: Timothy Gu <timothygu99@gmail.com>
If negative pts are possible for some codecs in ogg then the code needs to be
changed to use signed values.
Found-by: Thomas Guilbert <tguilbert@google.com>
Fixes: clusterfuzz_usan-2016-08-02
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The frame dimensions are 16bit, so the mv bounds can easily overflow
int16 for large videos.
Bug-Id: Handbrake/46
CC: libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
In such a case behave as if the buffer was not reallocatable -- allocate a
new one and copy the data (preserving just the part described by the
reference passed to av_buffer_realloc).
CC: libav-stable@libav.org
Reported-By: wm4 <nfxjfg@googlemail.com>
pavgb is an sse integer instruction, so the mmxext flag is enough
Signed-off-by: James Almer <jamrial@gmail.com>
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
10- and 12-bit DNxHR use the same DC coefficient decoding process and
VLC table, just with a different shift value. From SMPTE 2019-1:2016,
8.2.4 DC Coefficient Decoding:
"For 8-bit video sampling, the maximum value of η=11 and for
10-/12-bit video sampling, the maximum value of η=13."
A sample file will be uploaded to show that with this patch, things
decode correctly:
dnxhr_hqx_12bit_1080p_smpte_colorbars_davinci_resolve.mov
Signed-off-by: Steven Robertson <steven@strobe.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit 014773b66b.
Since 230b1c070, the bytewise AV_W*() macros only expand their
argument once, i.e. doing exactly the same change as was done
in the AV_COPY*U macros, so this change is no longer necessary.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts commit 25bacd0a0c.
Since 230b1c070, the bytewise AV_W*() macros only expand their
argument once, so revert to the more readable version of these.
Signed-off-by: Martin Storsjö <martin@martin.st>
In order to avoid possible clipping at the very
beginning. Especially apparent when "alternative"
boundary mode is used.
Adopted from original commit by committer.
The Doxygen command is generated from the list of installed headers,
which may change per configuration (e.g. `--enable-gpl` results in
libpostproc to be built and installed).
AV_WN64 is meant for unaligned data, but the existing av_alias* unions
(without a definition for the av_alias attribute - we don't have one
for MSVC) indicate to the compiler that they would have sufficient
alignment for normal access, i.e. the compiler is free to assume
8 byte alignment.
On ARM, this makes sure that AV_WN64 (or two consecutive AV_WN32) is
done with two str instructions instead of one strd.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids issues with expanding the argument multiple times,
and makes sure that it is of the right type for the following shifts.
Even if the caller of a macro could be expected not to pass parameters
that have side effects if expanded multiple times, these fallback
codepaths are rarely, if ever, tested, so it is expected that such
issues can arise.
Thefore, for safety, make sure the fallback codepaths only expand
the arguments once.
Signed-off-by: Martin Storsjö <martin@martin.st>
HDCD is only encoded in s16@44100Hz. Scan the chain of AVFilterLinks
for any resampling or format conversion/truncation that might cause
problems for the filter and issue warnings.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Issue #5727: gain adjustment should only be applied if matching
gain value from a valid packet in both channels. The existing functions process
each channel separately, so it was not possible.
* New versions of hdcd_process(), hdcd_scan(), hdcd_integrate() named
hdcd_*_stereo() that process both channels together.
* target_gain applied will be the last matching target_gain.
* The old single channel functions remain as an option. They can be
used by: -af hdcd=process_stereo=0.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'bc7f4268514624e1286ea76d27a89a56b4ee18e1':
h264: drop tests whether the codec id is AV_CODEC_ID_H264
Conflicts:
libavcodec/h264dec.c
Merged-by: James Almer <jamrial@gmail.com>
* Moves the filter context member out of state and into HDCDContext
* More useful information when an error is detected
* Gives a location near where the error was detected
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '70b1dcef2d859ae6b3e21d61de928c3dd0cf1aa4':
h264: tighten the valid range for ref_frame_count
Conflicts:
libavcodec/h264_ps.c
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f638b67e5790735f34620bf82025c9b9d6fc7216':
h264: move the parameter set definitions to a new header file
Conflicts:
libavcodec/h264_parse.h
libavcodec/h264_ps.c
libavcodec/h264dec.h
Merged-by: James Almer <jamrial@gmail.com>
If AV_RN and AV_WN are macros with multiple individual reads and
writes, the previous version of the AV_COPYU macro would fail if
the reads and writes overlap.
This should not be any less efficient in any case, given a
sensibly optimizing compiler.
Signed-off-by: Martin Storsjö <martin@martin.st>
AV_WB32 can be implemented as a macro that expands its parameters
multiple times (in case AV_HAVE_FAST_UNALIGNED isn't set and the
compiler doesn't support GCC attributes); make sure not to read
multiple times from the source in this case.
Signed-off-by: Martin Storsjö <martin@martin.st>
The counter is now -1 if the code detect timer was never set,
and 0 if it was set but never expired.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The stereowiden filter uses a buffer, s->buffer[], and a pointer
within the buffer, s->write, to implement inter-channel delays.
The loop which applies the delayed samples turns out to be faulty.
109 for (n = 0; n < in->nb_samples; n++, src += 2, dst += 2) {
110 const float left = src[0], right = src[1];
111 float *read = s->write + 2;
112
113 if (read > s->buffer + s->length)
114 read = s->buffer;
115
116 dst[0] = drymix * left - crossfeed * right - feedback * read[1];
117 dst[1] = drymix * right - crossfeed * left - feedback * read[0];
118
119 s->write[0] = left;
120 s->write[1] = right;
121
122 if (s->write == s->buffer + s->length)
123 s->write = s->buffer;
124 else
125 s->write += 2;
126 }
For one, the buffer gets written past its end in lines 119-120, before
the bound check is done in lines 122-123. This can be easily confirmed
by valgrind.
==3544== Invalid read of size 4
==3544== at 0x593B41: filter_frame (af_stereowiden.c:116)
==3544== Address 0xb1b03c4 is 4 bytes after a block of size 7,680 alloc'd
==3544==
==3544== Invalid read of size 4
==3544== at 0x593B66: filter_frame (af_stereowiden.c:117)
==3544== Address 0xb1b03c0 is 0 bytes after a block of size 7,680 alloc'd
==3544==
==3544== Invalid write of size 4
==3544== at 0x593B79: filter_frame (af_stereowiden.c:119)
==3544== Address 0xb1b03c0 is 0 bytes after a block of size 7,680 alloc'd
==3544==
==3544== Invalid write of size 4
==3544== at 0x593B7D: filter_frame (af_stereowiden.c:120)
==3544== Address 0xb1b03c4 is 4 bytes after a block of size 7,680 alloc'd
Also, using two separate pointers, s->write and read = s->write + 2,
does not seem to be well thought out. To apply the delay of s->buffer[],
it is enough to read the delayed samples at the current position within
the buffer, and then to store new samples at the same current position.
Thus the application of delayed samples can probably be best described
with a single pointer s->cur.
I also introduce a minor change to ensure that the size of s->buffer[]
is always a multiple of 2. Since the delay parameter is a float, it is
otherwise possible to trick the code into allocating off-by-one buffer.
Add an AVOption stats_version with a new header for V2 stats, which
specifies the stats log version and lists the fields that will be
present in the log (to ease parsing).
The primary motivation is to facilitate the addition of optional fields
to the log without breaking backwards compatibility, while making the
logs easier to parse.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The reference frames are used in update_thread_context(), so modifying
them after finish_setup() is a race. The frame in question will be
released during the next decode call.
CC: libav-stable@libav.org
Most systems have this, so it isn't really a problem to include it
even if it's not used, but some do not have memory.h as it is
non-standard. Since it's unused just remove it anyway.
* commit '17e7c03e12d1e4490921e7bffaeaa6b46a7ada4e':
h264: only allow ending a field/starting a new one before finish_setup()
This commit is a noop. According to Michael, after 8385e171 this commit
should not be necessary anymore.
Merged-by: Clément Bœsch <u@pkh.me>
Set the stream_id to 0xbd (private_stream_id_1). Tools seem to assume
that value, and this is consistent with MPEG TS specification (ITU-T
H.222.0 section 2.12.3).
The original code assumes av_realloc() will free ptr if size is zero.
The assumes is incorrect now.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The Peak Extend feature could be enabled permanently or only
when needed. This is now reported.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Rev #2: Fixes doubled header writing, checked FATE running without errors
Rev #3: Fixed coding style
This commit addresses the following scenario:
we are using ffmpeg to transcode or remux mkv (or something else) to mkv. The result is being streamed on-the-fly to an HTML5 client (streaming starts while ffmpeg is still running). The problem here is that the client is unable to detect the duration because the duration is only written to the mkv at the end of the transcoding/remoxing process. In matroskaenc.c, the duration is only written during mkv_write_trailer but not during mkv_write_header.
The approach:
FFMPEG is currently putting quite some effort to estimate the durations of source streams, but in many cases the source stream durations are still left at 0 and these durations are nowhere mapped to or used for output streams. As much as I would have liked to deduct or estimate output durations based on input stream durations - I realized that this is a hard task (as Nicolas already mentioned in a previous conversation). It would involve changes to the duration calculation/estimation/deduction for input streams and propagating these durations to output streams or the output context in a correct way.
So I looked for a simple and small solution with better chances to get accepted. In webmdashenc.c I found that a duration is written during write_header and this duration is taken from the streams' metadata, so I decided for a similar approach.
And here's what it does:
At first it is checking the duration of the AVFormatContext. In typical cases this value is not set, but: It is set in cases where the user has specified a recording_time or an end_time via the -t or -to parameters.
Then it is looking for a DURATION metadata field in the metadata of the output context (AVFormatContext::metadata). This would only exist in case the user has explicitly specified a metadata DURATION value from the command line.
Then it is iterating all streams looking for a "DURATION" metadata (this works unless the option "-map_metadata -1" has been specified) and determines the maximum value.
The precendence is as follows: 1. Use duration of AVFormatContext - 2. Use explicitly specified metadata duration value - 3. Use maximum (mapped) metadata duration over all streams.
To test this:
1. With explicit recording time:
ffmpeg -i file:"src.mkv" -loglevel debug -t 01:38:36.000 -y "dest.mkv"
2. Take duration from metadata specified via command line parameters:
ffmpeg -i file:"src.mkv" -loglevel debug -map_metadata -1 -metadata Duration="01:14:33.00" -y "dest.mkv"
3. Take duration from mapped input metadata:
ffmpeg -i file:"src.mkv" -loglevel debug -y "dest.mkv"
Regression risk:
Very low IMO because it only affects the header while ffmpeg is still running. When ffmpeg completes the process, the duration is rewritten to the header with the usual value (same like without this commit).
Signed-off-by: SoftWorkz <softworkz@hotmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
HLS demuxer calls the subdemuxer avformat_find_stream_info() while
overriding the subdemuxer AVFMTCTX_NOHEADER flag by clearing it.
However, this prevents some streams in some MPEG TS streams from being
detected properly.
Simply removing the clearing of the flag would cause the inner
avformat_find_stream_info() call to take longer in some cases, without
a way to control it.
To fix the issue, do not clear the flag but propagate it to HLS demuxer.
To avoid the above-mentioned mandatory delay, the call to
avformat_find_stream_info() is dropped except in the HLS ID3 timestamped
case. The HLS demuxer user should be calling avformat_find_stream_info()
on the HLS demuxer if it wants to find the stream info.
The main streams are now created dynamically after read_header time if
the subdemuxer uses AVFMTCTX_NOHEADER (mpegts).
Subdemuxer avformat_find_stream_info() is still called for the HLS ID3
timestamped case as the HLS demuxer needs to know the packet durations
to properly interleave ID3 timestamped streams with MPEG TS streams on
sub-segment level.
Fixes ticket #4930.
Creation of main demuxer streams from subdemuxer streams is moved to
update_streams_from_subdemuxer() which can be called repeatedly.
There should be no functional changes.
Commit 81306fd4bdf ("hls: eliminate ffurl_* usage", merged in d0fc5de3a6)
changed the hls demuxer to use AVIOContext instead of URLContext for its
HTTP requests.
HLS demuxer uses the "offset" option of the http demuxer, requesting
the initial file offset for the I/O (http URLProtocol uses the "Range:"
HTTP header to try to accommodate that).
However, the code in libavformat/aviobuf.c seems to be doing its own
accounting for the current file offset (AVIOContext.pos), with the
assumption that the initial offset is always zero.
HLS demuxer does an explicit seek after open_url to account for cases
where the "offset" was not effective (due to the URL being a local file
or the HTTP server not obeying it), which should be a no-op in case the
file offset is already at that position.
However, since aviobuf.c code thinks the starting offset is 0, this
doesn't work properly.
This breaks retrieval of ranged media segments.
To fix the regression, just drop the seek call from the HLS demuxer when
the HTTP(S) protocol is used.
Commit 9200514ad8 ("lavf: replace AVStream.codec with
AVStream.codecpar") merged in commit 6f69f7a8bf changed
avformat_find_stream_info() to put the extradata it got from
st->parser->parser->split() to st->internal->avctx instead of st->codec
(extradata in st->internal->avctx will be later copied to st->codecpar).
However, in the same function, the "is stream ready?" check was changed
to check for extradata in st->codecpar instead of st->codec, even
though st->codecpar is not yet updated at that point.
Extradata retrieved from split() is therefore not considered anymore,
and avformat_find_stream_info() will therefore needlessly continue
probing in some cases.
Fix that by checking for the extradata at st->internal->avctx where it
is actually put.
Adds a counter for when the "code detect timer" expired without
finding a valid packet.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add some comments describing the fields in hdcd_state_t.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
HDCD is now only considered detected if a valid packet
is active in both channels simultaneously.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'f966498e433fead2f5e6b5b66fad2ac062146d22':
h264: decode the poc values from the slice header into the per-slice context
Merged-by: Clément Bœsch <u@pkh.me>
* commit '54dd9b1cdd9e54f1ee39ae25af0324f8aba2831b':
h264: set mb_aff_frame in frame_start()
h264: move the block starting a new field out of slice_header_parse()
Both commits are merged at the same time in order to prevent a
regression with Ticket #4440 (see 38660128).
Merged-by: Clément Bœsch <u@pkh.me>
If a JNI environment is not already attached to the thread where the
MediaCodec calls are made the current implementation will attach /
detach an environment for each MediaCodec call wasting some CPU time.
ff_jni_get_env replaces ff_jni_{attach,detach} by permanently attaching
an environment (if it is not already the case) to the current thread.
The environment will be automatically detached at the thread destruction
using a pthread_key callback.
Saves around 5% of CPU time (out of 20%) while decoding a stream with
MediaCodec.
This allows doing this redirection, if building with clang against
old enough MSVC headers that lack strtoll (2012 and older).
Signed-off-by: Martin Storsjö <martin@martin.st>
The accessors are needed only from outside libavutil.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
It's a small and simple function that can be inlined.
This removes one private symbol and should reduce object dependencies with the next
major bump
Signed-off-by: James Almer <jamrial@gmail.com>
lavc/movenc rely on avpriv_dnxhd_parse_header_prefix declared by
dnxhddata.h since e47981dab7.
Fixes a missing symbol error in lavc/movenc if the dnxhd encoder is not
enabled.
This reverts commit d30cf57a7b, reversing changes made to
acc155ac55. The commit d30cf57a7b
provided irrelevant code complexity and decoding slowdown. But the main disadvantage of this
commit is a decoder crash. So it should be reverted.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There is actually a need for the origin and end point not to be defined.
We can not automatically insert them with the y value of the first and
last point as it will influence the curves in a wrong way.
Fixes#5397
If this still doesnt give the same results on all platforms then this should be
disabled
Found-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix const corectness and zero init the struct. This example code would actually crash when initializing string.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I've been helping out with the project servers' maintenance and migration
to the new machine hosted in Telepoint's data center in Sofia, BG.
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When seeking a file where codec delay is greater than 0, the timecode
can become negative after offsetting by the codec delay. Failing to cast
to a signed int64 will cause the check against skip_to_timecode to evaluate
true for these negative values. This breaks the "skip_to" seek mechanism.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
mpeg4_unpack_bframes_bsf bitstream filters constructs
resulting packet using av_packet_from_data() function.
This function however modifies only buffer (data) and leaves
other fields untouched, so the content of other fields
of the output packet is undefined.
It is working with old BSF API, since old API filters
just data and the packet fields are copied in
av_apply_bitstream_filters from input packet.
This change fixes the behaviour for the new BSF API.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit 0e0538aefc.
The valgrind warning was a false positive due to OSX implementation of
printf (invoking a strnlen), while this code is actually fine, since the
format specifier %.*s guarantes that no more than buf_size bytes from
buf will be read.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Clang normally disguises as GCC (defining __GNUC__), and thus get
all the normal GCC specific attributes.
Clang can also work as a drop-in replacement for MSVC, and in these
cases, it doesn't define __GNUC__, but defines _MSC_VER instead.
Even in these setups, it still supports the GCC style attributes,
thus use them, especially where there isn't any MSVC specific
version, or where the MSVC specific version doesn't work on clang
(for DECLARE_ASM_CONST).
Signed-off-by: Martin Storsjö <martin@martin.st>
When targeting COFF (windows), clang doesn't support this
directive (while binutils supports it for all targets).
Signed-off-by: Martin Storsjö <martin@martin.st>
There are samples with invalid stsc that may work fine as is and
do not need extradata change. So ignore any out of range index, and
error out only when explode is set.
Found-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The current code will ignore the init_get_bits() failure and do an
invalid read from the uninitialized GetBitContext.
Found-By: Jan Ruge <jan.s.ruge@gmail.com>
Bug-Id: 952
This fixes retrieving a valid profile for many of the FATE conformance samples,
allowing them to be properly decoded by the HWAccel after adding a profile check.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
VPx (VP8/VP9) alpha encoding has been part of FFmpeg. Now, add the
ability to decode such files with alpha channel.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
The header was never installed and the function is only used in libavformat
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Add new -march values for Intel and AMD CPUs introduced with GCC 5 and 6, and
improve SunCC flags accordingly.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
The code conflicts with moving the h264_init_ps() call point
Without this, ff_h264_parse_ref_count() fills ref and list count and
h264_init_ps() subsequently wipes them out on a "success" path.
Subsequently things crash as the wiped fields are used.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This ensures that captions are written towards the bottom of the screen
when tuning into mid-stream. The row will be reset on the receipt of the
next PAC command. Row 10 was chosen as it corresponds to the value of
"0" in a PAC (see row_map in handle_pac()).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These bits are set by exceptions in NEON instructions.
Also print the differing bits when FPSCR is clobbered,
and use bic instead of lsl, for clearing the topmost bits.
Signed-off-by: Martin Storsjö <martin@martin.st>
Anshul appears to have no time currently as he has not reacted to patches or mails
and Aman agreed to take over maintaince or help
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Each const block needs to be terminated by one endconst
invocation so either call endconst after each, or just
declare plain labels to the later strings.
This fixes errors such as this, on some binutils versions:
checkasm.S:38: Error: Macro `endconst' was already defined
Signed-off-by: Martin Storsjö <martin@martin.st>
Add ff_format_output_open utility function to wrap
io_open callback of AVFormatContext structure.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This will add support for flushing by writing NULL
packet to the tee muxer, which propagates the action
to slave muxers as expected.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Use ff_stream_encode_params_copy() to copy encoding-related
fields (parameters) of stream.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Since we only know whether a NAL unit corresponds to a new field after
parsing the slice header, this requires reorganizing the calls to slice
parsing, per-slice/field/frame init and actual decoding.
In the previous code, the function for slice header decoding also
immediately started a new field/frame as necessary, so any slices
already queued for decoding would no longer be decodable.
After this patch, we first parse the slice header, and if we determine
that a new field needs to be started we decode all the queued slices.
This function's purpose is not very well defined. Currently it does two
(only marginally related) things: selecting the next output frame and
calling ff_thread_finish_setup() for frame threading. The first of those
more properly belongs under field_start(), while the second can be
called directly from decode_nal_units().
... and attempt to preserve compatibility with clang that was
introduced in 311a953c76 (untested)
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Count and report when a code is signaled but fails to match a known pattern.
For example try Līve - Secret Samadhi.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Only call hdcd_update_info() when the control code changes
instead of every frame, so the counters are more meaningful.
Signed-off-by: Burt P <pburt0@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
because the BSF logic was re-factored into a shareable
function and both av_write_frame and av_interleaved_write_frame use it it
Signed-off-by: LiuQi <liuqi@gosun.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'd78fd2fa21cde28465e40dd0be4446b1387d22a6':
Add MagicYUV decoder
Changes observed from Libav:
- many cosmetics (function renames/move, spacing, line breaks)
- MagicYUVContext.slices_size is now unsigned
- use of pixdesc (include fixed in FFmpeg)
- mention of "Lossless" in the long name dropped (also removed from
general.texi in FFmpeg)
- addition of the FF_CODEC_CAP_INIT_THREADSAFE caps
- use of qsort() instead of AV_QSORT() (NOT MERGED)
- use of AVCodecContext.{width,height} instead of AVCodecContext.coded_{width,height} (NOT MERGED)
See also 77f9c4b7aa
Merged-by: Clément Bœsch <u@pkh.me>
Adding a check for bits == 0 would still make Coverity misdetect this,
so just revert to the normal way of setting the residue to 0.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Can also be used in future cleanups since 99% of the time the leftover
appending will just append to an already empty residue.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Shifting by more than 63 bits is undefined behavior, athough any
compiler not returning 0 after shifting by any amount would be insane.
Found by Coverity, fixes CID1363959 and CID1363960
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The stack used by checkasm_checked_call_vfp was a multiple of 4 when the
checked function is called. AAPCS requires a double word (8 byte)
aligned stack public interfaces. Since both calls are public interfaces
the stack is misaligned when the checked is called.
Might fix the SIGBUS error in the armv7-linux-clang-3.7 fate config.
Fixes a regression in ca2f19b9cc with some mov/mp4 files. The files have
several NAL units in the supposed single NAL unit after the size field.
Annex B start code prefixes are used to separate them. The first NAL unit
is correctly parsed but the buffer does not point to the next size field.
Instead semi random data (it seems to be the rbsp_stop_one_bit and the
start code prefix) is then parsed as length and will exceed the
remaining length of the buffer.
Patch based on the code in h264's decode_nal_units() and a similar
patch by Hendrik Leppkes in FFmpeg (a9bb4cf87d).
Bug-Id: ffmpeg/trac5529
Reported-By: Vittorio Giovara
* commit 'ec9f04423b82afa323e90f5b2c677be74302c1fd':
ffv1: Error out on unsupported format
This commit is a noop, the feature is already present in FFmpeg.
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Fix the demuxer dependencies in some of the tests and remove the vp8 decoder
dependency for the stream copy tests
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '76729970049fe95659346503f7401a5d869f9959':
mov: Implement support for multiple sample description tables
Notes:
* The sc->stsc_data[index].id checks have been moved from the mov_read_stsc
to mov_read_packet before the value is used in mov_change_extradata to
not break playback of samples with broken stsc entries (see sample of
ticket #1918).
* sc->stsc_index is now checked against sc->stsc_count - 1 before it
is incremented so it remains lesser than sc->stsc_count. Fixes a crash
with:
./ffmpeg -i matrixbench_mpeg2.mpg -t 1 -frag_duration 200k test.mov
./ffprobe -show_packets test.mov
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Still much left to optimize, but it provides a significant performance
improvement - 10% for 300Mbps (1080p30), 25% for 1.5Gbps (4k 60fps) in
comparison with the default implementation.
Signed-off-by: Rostislav Pehlivanov <rpehlivanov@obe.tv>
Now coefficients are written to a buffer and are then dequantized by the
new SIMD dequantization functions. For the lower bands without enough
coefficients to fill a register (and hence they overwrite) the C version
of the dequantization function is used.
The buffer is per-thread and will be realloc'd if anything changes.
This prevents regressions and having to limit slice size.
Signed-off-by: Rostislav Pehlivanov <rpehlivanov@obe.tv>
Prevents having to have random magic values in the decoder and a
separate macro in the encoder.
Signed-off-by: Rostislav Pehlivanov <rpehlivanov@obe.tv>
In preparation for the following commits, this commit simplifies the
coefficient parsing and dequantization function. It was needlessly
inlined without much performance gain.
Signed-off-by: Rostislav Pehlivanov <rpehlivanov@obe.tv>
Currently, SPS.mb_height is actually what the spec calls
PicHeightInMapUnits, which is half the frame height when interlacing is
allowed. Calling this 'mb_height' is quite confusing, and there are at
least two associated bugs where this field is treated as the actual
frame height - in the h264 parser and in the code computing maximum
reordering buffer size for a given level.
Fix those issues (and avoid possible future ones) by exporting the real
frame height in this field.
support split hls segment at duration set by hls_time
Signed-off-by: LiuQi <liuqi@gosun.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This comment isn't true, the height can be different from the width
for these functions (which is why the height is passed as a parameter
to them).
Signed-off-by: Martin Storsjö <martin@martin.st>
GNU as evaluates true as '-1' while Apple's variant and llvm's internal
assembler evaluate it as '1'. The best way to avoid this madness is to
eliminate boolean expressions instead of trying to fix it with
preprocessor directives. Use a direct formula to calculate the
required temporary space on the stack in
ff_put_vp8_{epel,bilin}{4,8,16}_h[246]v[246]_armv6().
Fixes a checkasm segfault in vp8dsp.mc when using llvm's internal
assembler for a non-Apple target.
This is an - once again - updated patch, that uses avio_write instead
of avio_puts to stream clean text output without null characters. Works
now for me as intended.
Changes metadata filter to accept general urls as file argument without
breaking former behaviour. As a byproduct, it also allows for writing to
file "-" if specified as "file:-".
Example:
ffmpeg -i test.wav -filter_complex "silencedetect=n=-40dB:d=0.1,ametadata=mode=print:file='pipe\:4'" -f null
Signed-off-by: Sami Hult <sami.hult@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit cb8646af24.
This change has brough more issues than benefits, between compilation
time failures depending on flags used and code miscompilation causing
runtime crashes.
See the "[PATCH 2/2] configure: Enable GCC vectorization on ≥4.9"
thread in the ffmpeg-devel mailing list for the relevant discussion.
* commit 'a2ddfadc2d9e91cf70aa7430a7340b418bdb5b42':
avdevice: Ignore timefilter test program
This commit is a noop, /timefilter entry was added in the original merge
(5d48e4eafa)
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'd6c2c2796d8885e99fc90793cdd7937826f82fab':
LICENSE: Fix silly typo
This commit is a noop, the typo disappeared when the whole paragraph was
reworked in 484aec4da3.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '05a4bacbf7ece618553d339afe1d0b57bc87aea8':
avpacket: Error out when creating 0-sized side data
This commit is a noop, see 5a633ec2dd
AV_PKT_DATA_METADATA_UPDATE can be zero sized in order to clear old
meta.
Note: maybe we could add a start or end marker.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '61f168ae348f94f39e7afc6971654455a5de0e4d':
h264: factor out setting the parameter sets for a frame
Michael's changes on top of the merge undo parts of the original diff
that are not factorization:
"The call point is left where it was before. Such a change should be in
a separate commit and has multiple issues, one being null pointer
dereferences the other is that some safety checks would become
conditional.
I tried to split the PPS init between the new and old functions
similarly to the SPS code."
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
When writing a fragmented file, we by default write an index pointing
to all the fragments at the end of the file. This causes constantly
increasing memory usage during the muxing. For live streams, the
index might not be useful at all.
A similar fragment index is written (but at the start of the file) if
the global_sidx flag is set. If ism_lookahead is set, we need to keep
data about the last ism_lookahead+1 fragments.
If no fragment index is to be written, we don't need to store information
about all fragments, avoiding increasing the memory consumption
linearly with the muxing runtime.
This fixes out of memory situations with long live mp4 streams.
Signed-off-by: Martin Storsjö <martin@martin.st>
a gray channel in exr, is named Y
we admit that the file need to be interpreted as gray
only if no other channel match (except alpha)
to manage RGB and Y in the color conversion part of decode_block,
the color processing is now made with a for loop.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The new HDCD filter really does nothing to show that it is working or
that HDCD control information was even detected in the stream. This
patch collects information about the decode, like which features were
used, and reports it to the user at the end.
Also,
* Fixes low-level gain adjustment
* Updates the documentation
Signed-off-by: Burt P <pburt0@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
H264ParamSets has its SPS/PPS stored raw (SODB) and needs to be
converted to NAL units before sending them to MediaCodec.
This patch adds the missing convertion of the SPS/PPS from SOBP to RBSP
which makes the resulting NAL units correct.
Fixes codec initialization on Nexus 4 and Nexus 7.
Visual Studio 2015 Update 3 introduced a new SSA optimizer, however
it unfortunately causes miscompilations. Until it is fixed, the new
optimizations are disabled and should be re-checked on subsequent
compiler releases.
Fixes recent FATE failure of fate-lavf-pam on VS2015.
The default value of -1 indicates that ffmpeg should determine the channel
mapping automatically, which was the behavior before this commit.
Unless the -mapping_family argument is provided, behavior is unchanged.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The driver being used is detected inside av_hwdevice_ctx_init() and
the quirks field then set from a table of known device. If this
behaviour is unwanted, the user can also set the quirks field
manually.
Also adds the Intel i965 driver quirk (it does not destroy parameter
buffers used in a call to vaRenderPicture()) and detects that driver
to set it.
P010 is the 10-bit variant of NV12 (planar luma, packed chroma), using two
bytes per component to store 10-bit data plus 6-bit zeroes in the LSBs.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This preserves all the information in the codec parameters.
The wavpack ref changes are caused by the fact that now the sample
format is set, so matroskaenc can use it to set the bit depth.
Bug-Id: 945, along with the previous commit
Fixes use of freed memory
Should fix valgrind failures of fate-h264-skip-nointra
Found-by: logan
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'd1f539c97e04e7cebecaf6916c5064f243d39fcf':
h264: merge the two reinit blocks in slice_header_parse()
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '3fba16ecd978d5bed338b8da643c3435e62b3437':
h264: factor starting a new field out of parsing the slice header
Merged-by: Clément Bœsch <clement@stupeflix.com>
This fixes part of Ticket5676
This fixes kodi, mpv, chromium and ffplay build against 3.0 and linked to 3.1
This is a similar ABI fix to 1eb43af1a0
Approved-by: BBB
Approved-by: jamrial
Approved-by: BtbN
Approved-by: nevcairiel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This ensures the AVStream->codec entry is kept in sync when new streams are
discovered mid-playback or changes to the context occur from other sources.
Fixes trac 5678.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes part of Ticket5676
This fixes kodi, mpv, chromium and ffplay build against 3.0 and linked to 3.1
This is a similar ABI fix to 1eb43af1a0
Approved-by: BBB
Approved-by: jamrial
Approved-by: BtbN
Approved-by: nevcairiel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fix ticket #5674
the size of data to process in piz_uncompress, is now calc
using the pixel type of each channel.
the data reorganization, alos take care about the size of
each channel
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch addresses Trac ticket #5570. The optimized functions are in file
libswscale/ppc/input_vsx.c. Each optimized function name is a concatenation of the
corresponding name in libswscale/input.c with suffix _vsx.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In order to be able to make SPS const in H264ParamSets,
modify decode_scaling_matrices so that it returns if the scaling
matrix are present in the SPS, instead of altering the input SPS
structure.
This avoids listing the same feature multiple times in the
test output. Previously the output contained something like this:
SSE2:
- hevc_mc.qpel [OK]
- hevc_mc.epel [OK]
- hevc_mc.unweighted_pred [OK]
- hevc_mc.qpel [OK]
- hevc_mc.epel [OK]
- hevc_mc.unweighted_pred [OK]
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '4cec43a9eeb58eb9e581a2d9d25f78e5bfbb0960':
h264: move calculating the POC out of h264_slice_header_parse()
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '6dd996c7c81575a1e4969987ab175a6df7beab3d':
h264: move building the reference list out of h264_slice_header_parse()
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '0bad254300356005af4aef00a706bf2e8eee96bc':
h264: move initing the implicit pred weight table out of h264_slice_header_parse()
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit 'ed9a20ebe4a89de119ea97bdccf688ece8c6648c':
h264: split reading the ref list modifications and actually building the ref list
ref_modifications.val are read as u32 instead of u8 in FFmpeg.
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '7b50d60442af8d9527e9da46818011fe15a5265a':
h264: call ff_h264_fill_mbaff_ref_list() when constructing the normal ref list
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit 'b93c0aed79f7f942e0dec26e53c147f297ce2ff6':
h264: drop an outdated comment
This commit is a noop, see 237d31e0b9
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '77a1e2c5f8f8250dfacff24b993eb473260ed13e':
h264: move direct mode inits out of h264_slice_header_parse()
Merged-by: Clément Bœsch <clement@stupeflix.com>
This should not be needed anymore and simplifies the next merge
Requested-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should not be needed anymore and simplifies the next merge
Requested-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Even though this is not part of the public API, some external
applications access fields after it, thus breaking after updating from
ffmpeg 3.0 or earlier.
Since it is not public, it can be freely moved to the end to avoid
that problem in the future.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '2940e196c5e439d9869f8c02a49a318d0847453c':
vaapi_h265: cu_qp_delta should not be used in constant-QP mode
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '02fa1ad9266f9b1ea11565ac2f93f45853e351e8':
vaapi_h264: Add source version identifier as unregistered SEI
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit 'b668662939de3a02454cfc9ba3e6d10b87527a40':
get_bits: Move BITSTREAM_READER_LE definition before all relevant #includes
The merge commit also includes changes for libavcodec/interplayacm.c and
libavcodec/truemotion2rt.c
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '2a48a75a6f508121b96b0732a9fe03a46303f579':
sgirledec: simplify, no need to use reget buffer
This commit is a noop, see ccc3f4e710
Merged-by: Clément Bœsch <clement@stupeflix.com>
* commit '6e2ad28cf76461b02d85ad178087ba0c628b8d9d':
aic: add frame threading support
This commit is a noop, see 8e069eb525
Merged-by: Clément Bœsch <clement@stupeflix.com>
This avoids the risk of accidentally clobbering such variables outside
of the macro if the same variables are used there.
Signed-off-by: Martin Storsjö <martin@martin.st>
This fixes valgrind warnings about conditional jumps based on
uninitialized data (even though the uninitialized data only ever
was compared with a direct copy of the same uninitialized data).
Signed-off-by: Martin Storsjö <martin@martin.st>
While it is less featureful (and slower) than the built-in H264
decoder, one could potentially want to use it to take advantage
of the cisco patent license offer.
Signed-off-by: Martin Storsjö <martin@martin.st>
The hw frame used as reference has an attached size but it need not
match the actual size of the surface, so enforcing that the sw frame
used in copying matches its size exactly is not useful.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The source frame may be cropped, so that its dimensions are smaller than
the pool dimensions. The transfer_data API requires the allocated size
of the destination frame to be the same as the pool size.
Be more careful when an input stream encounters EOF when its filtergraph
has not been configured yet. The current code would immediately mark the
corresponding output streams as finished, while there may still be
buffered frames waiting for frames to appear on other filtergraph
inputs.
This should fix the random FATE failures for complex filtergraph tests
after a3a0230a98
* commit '20a8c78ce0a5baf37f6a94e2d1e57e186b6f4b54':
avconv: Do not copy extradata if source buffer is empty
This commit is a noop, see 4d02dfbde4
Merged-by: Clément Bœsch <u@pkh.me>
* commit '38f99017e69bd25e88be87117237c29727c25635':
vp9: Return the correct size when decoding a superframe
This commit is a noop, see c2f3715cb3
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b2d5d6a7f20a255a5f3c9bf539cc507afd909ce5':
build: Only enable symbol reduction if the compiler does proper DCE
Merged-by: Clément Bœsch <u@pkh.me>
P1, P2, and P3 are respectively the text versions of PBM, PGM and PPM
files.
We can not obtain the buffer size using av_imgage_get_buffer_size() as
every pixel in the picture will occupy a random size between 16 and 32
bits ("4 " and "231 " are such example).
Ideally, we could look for the next header (or EOF) in the bytestream,
but this commit is meant to fix a decoding regression introduced by
48ac4532d4.
Fix Ticket #5670
* commit '5b1b495c8d21600eac694d50f428654a3125e217':
build: Print a message when generating version scripts
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
* commit '1e9c5bf4c136fe9e010cc8a7e7270bba0d1bf45e':
asm: FF_-prefix internal macros used in inline assembly
This commit is a noop as the ASM codebase differs too much between libav
and ffmpeg. The corresponding chunks will be found in the next commit.
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Previously we would allocate a new one for every frame. This instead
maintains an AVBufferPool of them to use as-needed.
Also makes the maximum size of an output buffer adapt to the frame
size - the fixed upper bound was a bit too easy to hit when encoding
large pictures at high quality.
This patch also makes BlackMagic drivers v10.6.1 a hard requirement.
Reviewed-by: Deti Fliegl <deti@fliegl.de>
Signed-off-by: Marton Balint <cus@passwd.hu>
This makes sure the actual stream parameters are used, which is
important mainly for hardware decoding+filtering cases, which would
previously require various weird workarounds to handle the fact that a
fake software graph has to be constructed, but never used.
This should also improve behaviour in rare cases where
avformat_find_stream_info() does not provide accurate information.
Currently, a filtergraph will pull in the output constraints from its
corresponding decoder context, which breaks proper layering. Instead,
explicitly send the constaints on the output parameters to the
filtergraph.
This is similar to what is done for filtergraph inputs in
30ab4c51a180610d9f1720c75518d763515c0d9f
Setting the filter input parameters is moved to init_input_stream(),
so that it is done before the decoder is opened, potentially overwriting
the information from avformat_find_stream_info() with less accurate
data.
This commit temporarily disables QSV transcoding with hw frames. The
functionality will be re-added in the following commits.
Currently, calling configure_filtergraph() will pull in the input
parameters from the corresponding decoder context. This has the
following disadvantages:
- the decoded frame is a more proper source for this information
- a filter accessing decoder data breaks proper layering
Add functions for explicitly sending the input stream parameters to a
filtergraph input - currently from a frame and a decoder. The decoder
one will be dropped in future commits after some more restructuring.
The encode function is supposed to just return 0 on success.
This stems from a mixup with the return value of decode functions.
Signed-off-by: Martin Storsjö <martin@martin.st>
No longer make a dummy device configuration to query. Instead, just
return everything we recognise from the whole format list. Also
change the device setup code to query that list only, rather than
intersecting it with the constraint output.
This makes hwupload more usable on mesa/gallium where the video
processor only declares support for RGB formats, making it unable to
deal with YUV formats before this patch. It might introduce some
different trickier failures in the internal upload/download code
because the set of allowed formats there has changed, though I didn't
find any obvious regressions with i965.
The functions may not clean up properly after using MMX
registers. For the normal testing calls, the checkasm_checked_call
functions will do the cleanup (and check that functions that
should clean up do it as well), but when benchmarking functions
that don't clean up, we don't currently properly clean up at all.
This causes issues if a benchmarked function is followed by testing
of a function that is supposed to not clobber the MMX/FPU state but
doesn't touch it at all.
Signed-off-by: Martin Storsjö <martin@martin.st>
Currently it's exported as AVFrame.pkt_pts, which is also the only use
for that field. The reason it is done like this is that lavc used to
export various codec-specific "timing" information in AVFrame.pts, which
is not done anymore.
Since it is confusing to the callers to have a separate field which is
used only for decoder timestamps and nothing else, deprecate pkt_pts and
use just AVFrame.pts everywhere.
The current code assumes that encoding_needed is simply an inverse of
stream_copy, which is not true for manually attached files (for which
neither of those is true).
We already have all the necessary information in open_output_file().
This makes the information about the stream/filtergraph mappings
available earlier.
This is a more appropriate place for this. H264Context.recovery_frame is
shared between frame threads, so modifying it where it is right now is
invalid.
Move the NAL unit types into it. This will allow to stop including the
whole decoder-specific h264dec.h in some code that is unrelated to the
decoder and only needs some enum values.
Right now this code is mixed with selecting the next output frame. Move
it to a separate function called from h264_field_start(), which is a
more appropriate place for this.
While the value of those variables will be constant for the whole frame,
they are only used in two functions called from slice header decoding.
Moving them to the per-slice context allows us to make the H264Context
passed to slice_header_parse() constant.
There is no bitstream parsing in that block and messing with
decoder-global state is not something that belongs into header parsing.
Nothing else in this function depends on the value of current_slice,
except for two validity checks. Those checks are also moved out of
slice_header_parse().
Replace the decoder-global nal_unit_type/nal_ref_idc variables with the
per-NAL ones. The decoder-global ones still cannot be removed because
they are used by hwaccels.
This function needs to return false, or data in the additional tables
will be skipped, and the decoder will not be able to decode frames
associated with them.
Store data from each stsd in a separate extradata buffer, keep track of
the stsc index for read and seek operations, switch buffers when the
index differs. Decoder is notified with an AV_PKT_DATA_NEW_EXTRADATA
packet side data.
Since H264 supports this notification, and can be reset midstream, enable
this feature only for multiple avcC's. All other stsd types (such as
hvc1 and hev1) need decoder-side changes, so they are left disabled for
now.
This is implemented only in non-fragmented MOVs.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This mimics the behaviour of other av_*_new_side_data().
This is not caught by the malloc check, since padding
is always added to the allocated size.
Signed-off-by: Vittorio Giovara <vittorio.giovara@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.
This avoids the danger that get_bits.h might get indirectly #included before
BITSTREAM_READER_LE is defined.
Also sort headers into canonical order where appropriate.
Fixes clang-usan runtime error "null pointer passed as argument 2,
which is declared to never be null" while streamcopying.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
According to avcodec.h, avcodec_decode_video2 should return the number of
bytes used if a frame was decoded.
The current implementation returns size - used size of all the subframes.
This fixes the VLC's bug https://trac.videolan.org/vlc/ticket/16836.
The superframe is always fully consumed.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
With compilers that do not support proper dead code elimination, like
Sun C 5.12, linking fails due to missing references to unavailable,
but also unused, symbols.
Bug-Id: 895
Split version files into one line per symbol/directive to allow compatibility
with the Solaris linker without preprocessing and eliminate $ from version file
templates to simplify the postprocessing shell command.
Patches should be submitted to the [ffmpeg-devel mailing list](https://ffmpeg.org/mailman/listinfo/ffmpeg-devel) using `git format-patch` or `git send-email`. Github pull requests should be avoided because they are not part of our review process and **will be ignored**.
See [https://ffmpeg.org/developer.html#Contributing](https://ffmpeg.org/developer.html#Contributing) for more information.
cudaVideoCreate_Default=0x00,/**< Default operation mode: use dedicated video engines */
cudaVideoCreate_PreferCUDA=0x01,/**< Use a CUDA-based decoder if faster than dedicated engines (requires a valid vidLock object for multi-threading) */
cudaVideoCreate_PreferDXVA=0x02,/**< Go through DXVA internally if possible (requires D3D9 interop) */
cudaVideoCreate_PreferCUVID=0x04/**< Use dedicated video engines directly */
}cudaVideoCreateFlags;
/*!
* \struct CUVIDDECODECREATEINFO
* Struct used in create decoder
*/
typedefstruct_CUVIDDECODECREATEINFO
{
tcu_ulongulWidth;/**< Coded Sequence Width */
tcu_ulongulHeight;/**< Coded Sequence Height */
tcu_ulongulNumDecodeSurfaces;/**< Maximum number of internal decode surfaces */
* \fn CUresult CUDAAPI cuvidMapVideoFrame64(CUvideodecoder hDecoder, int nPicIdx, unsigned long long *pDevPtr, unsigned int *pPitch, CUVIDPROCPARAMS *pVPP);
unsignedintulMaxNumDecodeSurfaces;/**< Max # of decode surfaces (parser will cycle through these) */
unsignedintulClockRate;/**< Timestamp units in Hz (0=default=10000000Hz) */
unsignedintulErrorThreshold;/**< % Error threshold (0-100) for calling pfnDecodePicture (100=always call pfnDecodePicture even if picture bitstream is fully corrupted) */
unsignedintulMaxDisplayDelay;/**< Max display queue delay (improves pipelining of decode with display) - 0=no delay (recommended values: 2..4) */
unsignedintuReserved1[5];/**< Reserved for future use - set to 0 */
void*pUserData;/**< User data for callbacks */
PFNVIDSEQUENCECALLBACKpfnSequenceCallback;/**< Called before decoding frames and/or whenever there is a format change */
PFNVIDDECODECALLBACKpfnDecodePicture;/**< Called when a picture is ready to be decoded (decode order) */
PFNVIDDISPLAYCALLBACKpfnDisplayPicture;/**< Called whenever a picture is ready to be displayed (display order) */
void*pvReserved2[7];/**< Reserved for future use - set to NULL */
CUVIDEOFORMATEX*pExtVideoInfo;/**< [Optional] sequence header data from system layer */
@@ -13,8 +13,9 @@ You can disable all the demuxers using the configure option
the option @code{--enable-demuxer=@var{DEMUXER}}, or disable it
with the option @code{--disable-demuxer=@var{DEMUXER}}.
The option @code{-formats} of the ff* tools will display the list of
enabled demuxers.
The option @code{-demuxers} of the ff* tools will display the list of
enabled demuxers. Use @code{-formats} to view a combined list of
enabled demuxers and muxers.
The description of some of the currently available demuxers follows.
@@ -72,7 +73,7 @@ Do not try to resynchronize by looking for a certain optional start code.
Virtual concatenation script demuxer.
This demuxer reads a list of files and other directives from a text file and
demuxes them one after the other, as if all their packet had been muxed
demuxes them one after the other, as if all their packets had been muxed
together.
The timestamps in the files are adjusted so that the first file starts at 0
@@ -107,7 +108,7 @@ Identify the script type and version. It also sets the @option{safe} option
to 1 if it was -1.
To make FFmpeg recognize the format automatically, this directive must
appears exactly as is (no extra space or byte-order-mark) on the very first
appear exactly as is (no extra space or byte-order-mark) on the very first
line of the script.
@item @code{duration @var{dur}}
@@ -243,30 +244,23 @@ file subdir/file-2.wav
@end example
@end itemize
@section flv
@section flv, live_flv
Adobe Flash Video Format demuxer.
This demuxer is used to demux FLV files and RTMP network streams.
This demuxer is used to demux FLV files and RTMP network streams. In case of live network streams, if you force format, you may use live_flv option instead of flv to survive timestamp discontinuities.
The FFmpeg project merges all the changes from the Libav project
(https://libav.org) since the origin of the fork (around 2011).
With the exceptions of some commits due to technical/political disagreements or
issues, the changes are merged on a more or less regular schedule (daily for
years thanks to Michael, but more sparse nowadays).
WHY
===
The majority of the active developers believe the project needs to keep this
policy for various reasons.
The most important one is that we don't want our users to have to choose
between two distributors of libraries of the exact same name in order to have a
different set of features and bugfixes. By taking the responsibility of
unifying the two codebases, we allow users to benefit from the changes from the
two teams.
Today, FFmpeg has a much larger user database (we are distributed by every
major distribution), so we consider this mission a priority.
A different approach to the merge could have been to pick the changes we are
interested in and drop most of the cosmetics and other less important changes.
Unfortunately, this makes the following picks much harder, especially since the
Libav project is involved in various deep API changes. As a result, we decide
to virtually take everything done there.
Any Libav developer is of course welcome anytime to contribute directly to the
FFmpeg tree. Of course, we fully understand and are forced to accept that very
few Libav developers are interested in doing so, but we still want to recognize
their work. This leads us to create merge commits for every single one from
Libav. The original commit appears totally unchanged with full authorship in
our history (and the conflict are solved in the merge one). That way, not a
single thing from Libav will be lost in the future in case some reunification
happens, or that project disappears one way or another.
DOWNSIDES
=========
Of course, there are many downsides to this approach.
- It causes a non negligible merge commits pollution. We make sure there are
not several level of merges entangled (we do a 1:1 merge/commit), but it's
still a non-linear history.
- Many duplicated work. For instance, we added libavresample in our tree to
keep compatibility with Libav when our libswresample was already covering the
exact same purpose. The same thing happened for various elements such as the
ProRes support (but differences in features, bugs, licenses, ...). There are
many work to do to unify them, and any help is very much welcome.
- So much manpower from both FFmpeg and Libav is lost because of this mess. We
know it, and we don't know how to fix it. It takes incredible time to do
these merges, so we have even less time to work on things we personally care
about. The bad vibes also do not help with keeping our developers motivated.
- There is a growing technical risk factor with the merges due to the codebase
differing more and more.
MERGE GUIDELINES
================
The following gives developer guidelines on how to proceed when merging Libav commits.
Before starting, you can reduce the risk of errors on merge conflicts by using
a different merge conflict style:
$ git config --global merge.conflictstyle diff3
tools/libav-merge-next-commit is a script to help merging the next commit in
the queue. It assumes a remote named libav. It has two modes: merge, and noop.
The noop mode creates a merge with no change to the HEAD. You can pass a hash
as extra argument to reference a justification (it is common that we already
have the change done in FFmpeg).
Also see tools/murge, you can copy and paste a 3 way conflict into its stdin
and it will display colored diffs. Any arguments to murge (like ones to suppress
whitespace differences) are passed into colordiff.
TODO/FIXME/UNMERGED
===================
Stuff that didn't reach the codebase:
-------------------------------------
- HEVC DSP and x86 MC SIMD improvements from Libav (see https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184777.html)
- 1f821750f hevcdsp: split the qpel functions by width instead of by the subpixel fraction
- 818bfe7f0 hevcdsp: split the epel functions by width
- 688417399 hevcdsp: split the pred functions by width
- a853388d2 hevc: change the stride of the MC buffer to be in bytes instead of elements
- 0cef06df0 checkasm: add HEVC MC tests
- e7078e842 hevcdsp: add x86 SIMD for MC
- VAAPI VP8 decode hwaccel (currently under review: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/thread.html#207348)
- Removal of the custom atomic API (5cc0057f49, see http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209003.html)
- Use the new bitstream filter for extracting extradata (8e2ea69135 and 096a8effa3, see https://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209068.html)
- Read aac_adtstoasc extradata updates from packet side data on Matroska once mov and the bsf in question are fixed (See 13a211e632 and 5ef1959080)
Collateral damage that needs work locally:
------------------------------------------
- Merge proresdec2.c and proresdec_lgpl.c
- Merge proresenc_anatoliy.c and proresenc_kostya.c
- Remove ADVANCED_PARSER in libavcodec/hevc_parser.c
- Fix MIPS AC3 downmix
- hlsenc encryption support may need some adjustment (see edc43c571d)
Extra changes needed to be aligned with Libav:
----------------------------------------------
- Switching our examples to the new encode/decode API (see 67d28f4a0f)
- HEVC IDCT bit depth 12-bit support (Libav added 8 and 10 but doesn't have 12)
/** In ABR, we need to priorize less and let rate control do its thing */
energy2uplim=sqrtf(energy2uplim);
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
