This fixes playback in some circumstances (like webm in firefox).
Regression after 2c34367b.
It is also matching the Matroska specifications:
http://matroska.org/technical/specs/notes.html, "The quick eye will
notice that if a Cluster's Timecode is set to zero, it is possible to
have Blocks with a negative Raw Timecode. Blocks with a negative Raw
Timecode are not valid."
The timebases before where only guranteed to be 1/fps precisse
and could cause AV sync errors on low fps
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
While a 25 fps stream can in general store frame durations in 1/25
units, this is not true for the timestamps. For example a 25fps
and a 25000/1001 fps stream when they are stored together might have
a matching 0 timestamp point but when for example a chapter from
this is cut the new start is no longer aligned. The issue gets
MUCH worse when the streams are lower fps, like 1 or 2 fps.
This commit thus makes the muxer choose a multiple of the
framerate as timebase that is at least about 20 micro seconds precise
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With this, when we use a finer timebase than neccessary to store
durations the demuxer still knows what the original timebase was.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Also factorize the common options for the different mov-based tests.
Since the header is now on top in the last generated file, the data
offset in the seek test needed some updates as well.
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
Some of the FATE changes are due to off-by-one different rounding being used
(lrintf vs av_rescale_q).
Some fate changes are due to 1 audio frame less being encoded (the new variant seems
matching what qatar does and according to ffprobe its closer to the requested duration)
the mapchan feature sadly is lost in this commit because it depends on resampling
being done in ffmpeg.c which is now moved completely into the av filter layer
-async is broken after this commit, this will be fixed in subsequent commits
the new filter reconfiguration system is flawed and will drop a frame on each
parameter change which is why the nelly moser checksums need updating.
Conflicts:
ffmpeg.c
tests/ref/fate/smjpeg
This partially reverts acb1730218
which would only have needed to change the checksums if channel mixing had
been properly avoided. This changes the output file size reference and the
seek test reference back to the previous values.
Reduces the amount of upfront data required for cluster parsing
thus decreasing latency on seek and startup.
The change in the seek-lavf_mkv FATE test is due to incremental
parsing no longer reading as much data as the old parser and
thus not having that additional data to generate index entries
based on keyframes. Index entries are added correctly as the
file is parsed.
All FATE tests pass and Chrome has been using this patch for ~6
months without issue.
Currently incremental parsing is not supported for files with
SSA tracks since they require merging packets between clusters.
In this case the code falls back to non-incremental parsing.
Signed-off-by: Aaron Colwell <acolwell@chromium.org>
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Avoids resampling and channel mixing. This only tests the behavior
with respect to input and output audio rather than also testing changes
to the encoder or muxer that do not affect the resulting decoded output.
Signed-off-by: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
Modify the parser initialization so that parsers can
set pict_type themselves. Use this in the mpegvideo parser
so that initial frames are not unconditionally I frames.
I have had this in my tree for several years.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With this we can always know if a timestamp is based on added durations
from an unknown origin or if it is based on a correct timestamp (and possibly
added durations)
This should fix some bugs where this distinction was mixed up.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It is unnecessary. Also, for some codecs we're reading more than 1 frame per
packet. Instead we use a private context variable to calculate the bit rate,
stream duration, and packet durations.
Updated FATE seek test, which has slightly different timestamps due to a
more accurate bit rate calculation.
Seek beyond the end will now directly return an error instead
of claiming to succeed and then return EOF immediately on next read.
This change is because before 47e015e6f1
mkv seek incorrectly never failed.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
This is so that TS fragments produced by
http://code.google.com/p/httpsegmenter/
would be compatible with JW Player.
A new member variable prev_payload_key was added to MpegTSWriteStream
to help detect transition from non-key to key frame, so that
PAT/PMT would not be produced for every keyframe in intra-only videos.
Signed-off-by: Pavel Koshevoy <pkoshevoy@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Current code compares the desired recording time with InputStream.pts,
which has a very unclear meaning. Change the code to use actual
timestamps of the frames passed to the encoder.
In several tests, one less frame is encoded, which is more correct.
In the idroq test one more frame is encoded, which is again more
correct.
Behavior with stream copy should be unchanged.
This uses the old demuxing code for OP1a and separate demuxing code for OPAtom.
Timestamp output is added to the old demuxing code.
The seeking code is made to seek to the start of the desired EditUnit only,
from which the normal demuxing code takes over (if OP1a). This means we
do not use delta entries or slices, only StreamOffsets. OPAtom seeking
basically works like before.
This also makes D-10 seeking behave the same way as OP1a and OPAtom. In other
words, we allow seeking before the start or past the end for D-10 too.
Based on several patches by Tomas Härdin <tomas.hardin@codemill.se> and
Reimar Döffinger <Reimar.Doeffinger@gmx.de>.
Changed av_calloc to av_mallocz, added overflow checks.
This uses the old demuxing code for OP1a and separate demuxing code for OPAtom.
Timestamp output is added to the old demuxing code.
The seeking code is made to seek to the start of the desired EditUnit only,
from which the normal demuxing code takes over (if OP1a). This means we don't
use delta entries or slices, only StreamOffsets.
OPAtom seeking basically works like before.
This also makes D-10 seeking behave the same way as OP1a and OPAtom. In other
words, we allow seeking before the start or past the end for D-10 too.
This fixes ticket #746.
This changes mxf_compute_ptses() to be used for MXFIndexTable, and also adds
code for computing the fake index to it.
This also temporarily disables PTS computation. A future patch will restore it.
As far as I could see the only change is increased pos values,
which is as expected with additional metadata in the files.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
I am not entirely sure the seek functionality is working correctly,
there are some strange cases like successful seek but no dts value.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Victor Vasiliev
Clément Bœsch
Michael Niedermayer
Mans Rullgard
Anton Khirnov
Justin Ruggles
Dale Curtis
Ramiro Polla
Wolfram Gloger
Reimar Döffinger
Pavel Koshevoy
Janne Grunau
Tomas Härdin
Luca Barbato
Diego Biurrun