Fixes calculating the ts offset for audio codecs with delay.

This results in DefaultDuration not being written when the framerate is
not known, but as this field is purely informative, this should not
break any sane demuxers.

This avoids misleading encoder names like "encoder = prores"

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

Files won't validate with mkvalidtor if these two elements are missing.
Use a const "Lavf" string that wont change with library version bumps.

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The element was only being written when the value == 1.  But the default
value of this element is 1, so this has no useful effect.  This element
needs to be written when the value == 0.

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

Tags must have at least one SimpleTag element to be spec conformant.
Updated lavf-mkv and seek-lavf-mkv FATE references as the tests were affected by
this.

Fixes ticket #2785

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Most formats do not support negative timestamps, shift them to avoid
unexpected behaviour and a number of bad crashes.

CC:libav-stable@libav.org

Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Each fate-seek test depends now only on the corresponding fate-acodec,
fate-vsynth2 or fate-lavf test which creates the file seek-tests
operates on. The tests and references are renamed to match the test they
depend on.

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."

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

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

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>

Update FATE references due to encoder delay.

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>

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.

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>

Originally committed as revision 24345 to svn://svn.ffmpeg.org/ffmpeg/trunk

Start them on keyframes when reasonable, and delay writing audio packets
to help ensure that there's audio samples available for the first frame in
clusters.

Patch by James Zern <jzern at google>

Originally committed as revision 23473 to svn://svn.ffmpeg.org/ffmpeg/trunk

This isn't exactly semantically equivalent, but the field has already been
long abused to mean this, and writing it helps in determining a decent cfr
time base when transcoding from a mkv where the video codec stores none (VP8).

Originally committed as revision 23284 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 23248 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 22158 to svn://svn.ffmpeg.org/ffmpeg/trunk