The ones left using av_gettime are NTP timestamps (for RTCP,
which is specified to send the actual current realtime clock
in RTCP SR packets), and the NUT muxer timestamper, which is
documented as using wallclock time.
Signed-off-by: Martin Storsjö <martin@martin.st>
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: Martin Storsjö <martin@martin.st>
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: Martin Storsjö <martin@martin.st>
Since av_gettime() is used in a number of places where actual
real time clock is required, the monotonic clock introduced in
ebef9f5a5 would have consequences that are hard to handle. Instead
split it into a separate function that can be used in the cases
where only relative time is desired.
On platform where no monotonic clock is available, the difference
between the two av_gettime functions is not clear, and one could
mistakenly use the relative clock where an absolute one is
required. Therefore add an offset, to make it evident that the
time returned from av_gettime_relative never is actual current
real time, even though it is based on av_gettime.
Based on a patch by Olivier Langlois.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, AVERROR(EIO) was returned. Now the value is passed from
lower level, thus it is possible to distinguish ECONNREFUSED, ETIMEDOUT,
ENETUNREACH etc.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Previously, AVERROR(EIO) was returned on failure of
http_open_cnx_internal(). Now the value is passed to upper level, thus
it is possible to distinguish ECONNREFUSED, ETIMEDOUT, ENETUNREACH etc.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Handle it inside the __asm__() block.
Fixes fate-vc1_ilaced_twomv when using the gcc-usan toolchain.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
av_match_list() is only used for whitelists, fix it so it works with
multi-named formats like "mov,mp4,m4a,3gp,3g2,mj2"
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This commit doesn't change any existing logic.
It moves ffserver configuration related code to separate file.
It intends to make maintaining easier.
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
The bytes per row is a better indication of it.
Helps resolving ticket #3874 by fixing ffmpeg's encoder and transforming
the issue in a issue with non-compliant decoders. ffmpeg's one is ok,
but unfortunately, many others aren't handling correctly unusual chroma
samplings.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Uses a similar approach as vf_yadif to flush the last frame in idet.
Quick test with 50 frames from vsynth1:
./ffmpeg.old -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f mp4 -y /dev/null 2>&1 | grep Multi
(gives) [Parsed_idet_0 @ 0x261ebb0] Multi frame detection: TFF:0 BFF:0 Progressive:48 Undetermined:1
./ffmpeg -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f mp4 -y /dev/null 2>&1 | grep Multi
(gives) [Parsed_idet_0 @ 0x35a0bb0] Multi frame detection: TFF:0 BFF:0 Progressive:49 Undetermined:1
Fate tests have been updated.
(In testing, it seems this filter will also need a subsequent patch for single frame input)
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b69183f65d0f6f4cd7a4e6c0deb57d59b0185aba':
nutenc: check for negative index rather than assert
Conflicts:
libavformat/nutenc.c
Not merged, the assert is correct
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '629b2ed0ac77d7c4bf1aeac5e70cafee5fa0fcae':
flvdec: make sure to check create_stream and report the same error
Conflicts:
libavformat/flvdec.c
See: d7d5b5dfc1
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f22aa6b841dc54fa1dd804303885b1e230a5f629':
flvdec: avoid unitialized use of a struct member
See: 396ddcf22d
Merged-by: Michael Niedermayer <michaelni@gmx.at>
If using MFRA for timestamps, the stream may start from a large offset
and/or have gaps. With this change we calculate the bitrate based on
frames we've seen.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>