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

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Mans Rullgard <mans@mansr.com>

This fixes a bogus bitrate value in the header of WAV files with
alaw/ulaw audio.
Signed-off-by: Mans Rullgard <mans@mansr.com>

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

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This partially reverts acb17302
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>

Change some lavf tests to avoid resampling and channel mixing.

This avoids resampling and channel mixing by using a source with
the correct channel layout and sample rate.

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.

The index must take into account the pre-roll time and must seek backwards,
not forwards.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Update FATE references due to encoder delay.

Update FATE references due to encoder delay.

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.

Also, set the time base based on the sample rate.
lavf-voc seek test updated to reflect slightly different seek points.

Update some demuxing and seeking fate tests.

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 47e015e6
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>

This should have been updated in b590f3a7.

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.

There is no point in this test using the RM format.
Signed-off-by: Mans Rullgard <mans@mansr.com>

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>

This involves computing DTS/PTS from the index tables.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

our ac3 decoder outputs different things on different platforms.

Idea-by: Reimar
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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>

This adds OPAtom support and proper seeking.
D-10 and non-seekable OP1a streams still use the old demuxing/seeking code.

this removes 2 redundant tests for pcm in mkv.
we can add the coverage back in later as fate-lavf tests if needed.

Signed-off-by: Mans Rullgard <mans@mansr.com>