It is badly named (should have been -top_field_first, or at least -tff),
underdocumented and underspecified, and (most importantly) entirely
redundant with the setfield filter.
Merge three blocks with slightly inconsistent checks into one, treating
encoder input as interlaced when either:
* at least one of ilme/ildct flags is set
* the first frame in the stream is marked as interlaced
* the user specified the -top option
Stop modifying the frame passed to enc_open().
It was added in cb114ed464 with the comment
"This will allow fixing several bugs with the -shortest option".
Since
* there is no explanation of what these bugs are
* libavformat is not the place to work around ffmpeg CLI bugs
* there is no indication that this feature is actually in use
deprecate it without replacement.
Avoid using the deprecated functions ssh_try_publickey_from_file among
others in favor of symbols introduced in libssh 0.6.0 (Jan 2014) and
update configure to require this version.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Since 432adca5fe no decoder
looks at the slice_count and slice_offset fields at all,
so there is no reason to synchronize them between the worker
and the user thread.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When decoding non-keyframes, the decoding process expects
there to be two reference frames, the last one and the golden
one. The existence of the golden one is checked and in case
it is there, it is presumed that the last one exists as well.
This assumption is wrong in case of memory allocation failure,
namely in case the call to ff_thread_ref_frame() that sets
the last frame fails.
Fix this by actually performing a shuffle without creating
new references. This can't fail and has the advantage of
fewer implicit allocations.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When decoding a keyframe, last_frame and golden_frame are
not used at all and (at least when starting decoding)
are not set at all. But due to code sharing pointer arithmetic
on the NULL data-pointers of these frames has nevertheless
been performed. This is undefined behaviour and causes e.g.
"runtime error: applying non-zero offset 173440 to null pointer"
from UBSan in the vp31, vp4, theora-coeff-level64 and theora-offset
FATE-tests.
Fix this by reusing the current frame for unavailable frames.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does not use ThreadFrames at all, so thread.h is the correct place.
bcb0faeaba was wrong.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The '<' in ///< says that the comment pertains to the previous item
on the same line as the ///<.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The 1000 did result in the appearance of a never ending reload loop
The RFC mandates that "If the client reloads a Playlist file and finds that it has not
changed, then it MUST wait for a period of one-half the target
duration before retrying." and if it has changed
"the client MUST wait for at least the target duration before attempting to reload the
Playlist file again"
Trying to reload 3 times seems a better default than 1000 given these
durations
Issue found by: Сергей Колесников
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The issue is that we cannot rely on any context existing when we free
frames. The Vulkan functions are loaded in each context separately,
so until now, we've just been loading them on every frame's destruction.
Rather than do this, just save the function pointers we need in each
frame. The function pointers are guaranteed to not change and exist.
Fixes: out of array write
Found-by: dongsookim@korea.ac.kr
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since bfb28b5ce8 the permutation
type FF_IDCT_PERM_SIMPLE is ARCH_X86_32-only. So use this
knowledge to disable code for it when not on ARCH_X86_32.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When using multi-threaded decoding, every decoding thread
has its own DBP consisting of H264Pictures and each of these
points to its own AVFrames. They are synced during
update_thread_context via av_frame_ref() and therefore
the threads actually decoding (as well as all the others)
must not modify any field that is copied by av_frame_ref()
after ff_thread_finish_setup().
Yet this is exactly what happens when an error occurs
during decoding and the AVFrame's decode_error_flags are updated.
Given that these errors only become apparent during decoding,
this can't be set before ff_thread_finish_setup() without
defeating the point of frame-threading; in practice,
this meant that the decoder did not set these flags correctly
in case frame-threading was in use. (This means that e.g.
the ffmpeg cli tool fails to output its "corrupt decoded frame"
message in a nondeterministic fashion.)
This commit fixes this by adding a new H264Picture field
that is actually propagated across threads; the field
is an AVBufferRef* whose data is an atomic_int; it is
atomic in order to allow multiple threads to update it
concurrently and not to provide synchronization
between the threads setting the field and the thread
ultimately returning the AVFrame.
This unfortunately has the overhead of one allocation
per H264Picture (both the original one as well as
creating a reference to an existing one), even in case
of no errors. In order to mitigate this, an AVBufferPool
has been used and only if frame-threading is actually
in use. This expense will be removed as soon as
a proper API for refcounted objects (not based upon
AVBuffer) is in place.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a pointer parameter that if supplied will be used to return
the updated decode_error_flags. This will allow to fix several
races when using frame-threading; these resulted from AVFrame
that the earlier code updated concurrently being used as source
in an av_frame_ref() call in the decoder's update_thread_context.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When ov_model_const_input_by_name/ov_model_const_output_by_name
failed, input_port/output_port can be wild pointer.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
All Vulkan HWAccels share the same boilerplate code for creating
session params and this includes a common bug: In case actually
creating the video session parameters fails, the buffer destined
to hold them leaks; in case of HEVC this is also true if
get_data_set_buf() fails.
This commit factors this code out and fixes the leak.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The alignment in vulkan_unmap_from_drm() (formerly the clone
of vulkan_frame_free()) is nicer than the in vulkan_frame_free(),
let's preserve it.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVBuffer API uses uint8_t as base type for buffers
and therefore its free callbacks need to abide by this.
Therefore vulkan_frame_free() used an inappropriate signature
which caused casts whenever this function has been called
manually.
This commit changes this by making vulkan_frame_free()
use the proper type and a vulkan_frame_free_cb() that
is used as free callback for the AVBuffer API.
Reviewed-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
