Also fix playback of ntsc files.
Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

wtvenc: do not emit stream2 and DSATTRIB_TRANSPORT_PROPERTY chunks; these are not required for playback
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

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>

This way audio frames can be exactly stored even when they are not
aligned with timestamp 0
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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.

The seek test improves in accuracy
Fixes Ticket877
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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>