Right now, the caller has to manually manage some allocated
AVCodecContext fields, like extradata or subtitle_header. This is
fragile and prone to leaks, especially if we want to add more such
fields in the future.
The only reason for this behaviour is so that the AVStream codec context
can be reused for decoding. Such reuse is discouraged anyway, so this
commit is the first step to deprecating it.
Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
These functions are using the POSIX clock_gettime() function with the
CLOCK_MONOTONIC clock id. If these are not present on the targeted
platform, the new functions will fallback on using the original realtime functions
av_gettime() and av_usleep().
Monotonic support can be added on other platforms with their
equivalent native system API eventually if possible.
Whenever time is requested to measure relative time, the monotonic clock,
when available, is superior to the system realtime clock because it is
not affected by discontinuous jumps in the system time
In a future step, offering the flexibility to let the user choose between
rt and monotonic clock for avdevices packets will be investigated.
It is very easy to experience the issues that this patch attempt to address
by rewinding back in the past the system time while ffmpeg is running.
this is breaking the ffmpeg report printing (ffmepg.c:print_report()) and
the the rate emulator functionality (-re) without the patch.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* cus/stable:
ffplay: add support for toggling between multiple video filters with the w key
ffplay: fix typo in docs
ffplay: try multiple sample rates if audio open fails
cmdutils: replace usages of "#ifdef __MINGW32__" with "#ifdef _WIN32" because MSVC only defines _WIN32
ffplay: fix compilation with Visual Studio
ffplay: increase AV_SYNC_THRESHOLD_MIN to 0.04
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Less than 0.04 sec delays should not be noticable, and it helps us with 50fps
content where some timing errors can cause a frame dup where it is not really
necessary.
Signed-off-by: Marton Balint <cus@passwd.hu>
The second argument is a temp register for non-SSSE3 cases
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
it was always 1 before with ISOBMFF(cherry picked from commit fb1402b1ec78d80acd6ced76bf78d65560965c4c)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
