According to its description, it is supposed to be the LCM of all the
frame durations. The usability of such a thing is vanishingly small,
especially since we cannot determine it with any amount of reliability.
Therefore get rid of it after the next bump.
Replace it with the average framerate where it makes sense.
FATE results for the wtv and xmv demux tests change. In the wtv case
this is caused by the file being corrupted (or possibly badly cut) and
containing invalid timestamps. This results in lavf estimating the
framerate wrong and making up wrong frame durations.
In the xmv case the file contains pts jumps, so again the estimated
framerate is far from anything sane and lavf again makes up different
frame durations.
In some other tests lavf starts making up frame durations from different
frame.
AVPacket.duration is mostly made up and thus completely useless, this is
especially true for video streams.
Therefore use dts difference for framerate estimation and
the max_analyze_duration check.
The asyncts test now needs -analyzeduration, because the default is 5
seconds and the audio stream in the sample appears at ~10 seconds.
Useful in cases where a significant analyzeduration is
still needed, while minimizing buffering before output.
An example is processing low-latency streams where all
media types won't necessarily come in if the
analyzeduration is small.
Additional changes by Josh Allmann <joshua.allmann@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
By moving it to a later point relative and unknown timestamps
are more likely to have been corrected
similar patch reviewed-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Conflicts:
libavformat/utils.c
If skip_samples is set and timestamps are synthesized using durations,
make them start at -skip_samples (rescaled) instead of 0,
so that the timestamp of the first undiscarded sample is 0.
This adds the minimum delay needed with the current decoder to
recognize the reorder buffer size for the reference bitstreams.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
To ensure the full range of values is still used, also adjust all uses of this function to loop from 0
instead of 1. This way only 60.00 is added and nothing lost.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This can easily happen when the caller is using a custom AVIOContext.
Behave as if the filename was an empty string in this case.
CC: libav-stable@libav.org
This fixes an issue with a crazy data track starting with a large
negative timestamp.
It could as well be solved in all user apps, but this is looking
attractively simpler ...
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Use codec aspect ratio for frame aspect ratio if AVFrame is NULL.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Guesses the sample aspect ratio of a frame, based on both the stream and the
frame aspect ratio.
Since the frame aspect ratio is set by the codec but the stream aspect ratio
is set by the demuxer, these two may not be equal. This function tries to
return the value that you should use if you would like to display the frame.
Basic logic is to use the stream aspect ratio if it is set to something sane
otherwise use the frame aspect ratio. This way a container setting, which is
usually easy to modify can override the coded value in the frames.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>