This is a minimal change to matroskaenc that implements CueRelativePosition in the output.
Most players will probably ignore this additional information, but it is in the
matroska spec, and it'd be nice to be able to make use of it.
Signed-off-by: Bernt Habermeier <bernt@wulfram.com>
Tested-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
According to the PIFF specification[1] the base_data_offset field MUST be
omitteed. See section 5.2.17. Since the ISMV files created by ffmpeg state
that they are 'piff' compatible via 'ftyp' box, this needs to be corrected.
[1] http://www.iis.net/learn/media/smooth-streaming/protected-interoperable-file-format
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
To define accurately the delay between two frames, it is necessary to
have both available. Before this commit, the first frame had a delay of
0; while in practice the problem is not visible in most situation, it is
problematic with low frame rate and large scene change.
This commit notably fixes output generated with commands such as:
ffmpeg -i big_buck_bunny_1080p_h264.mov
-vf "select='gt(scene,0.4)',scale=320:-1,setpts=N/TB"
-frames:v 5 -y out.gif
Also, to avoid odd loop delays, the N-1 delay is duplicated for the last
frame.
This commit removes the badly duplicated code between the encoder and
the muxer. That may sound surprising, but the encoder is now responsible
from the encoding of the picture when muxing to a .gif file. It also
does not require anymore a manual user intervention such as a -pix_fmt
rgb24 to work properly. To summarize, output gif are now easier to
generate, code is saner and simpler, and files are smaller (thanks to
the lzw encoding which was unused so far with the default .gif output).
We can certainly make things even better, but this is the first step.
FATE is updated because of the output being produced by the encoder and
not the muxer (no lzw in the muxer), and in the seek test only the size
mismatches.
Fixes Ticket #2262
Other software does not store it in this case, and the information
is provided by the codec stream
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The QuickTime specification does not contain any hint that the atom
must not be written in some cases and both the QuickTime and the
AVID decoders do not fail if the atom is present.
This change allows to signal (visually) interlaced streams with
a codec different from uncompressed video.
As a side-effect, this fixes ticket #2202
We have to make some symetric changes elsewhere as this increases
the precission with which samples are stored.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
After making some blind tests on a small collection of music
samples for home usage. It turned out that the default cutoff
was too low.
The impact of filter_size was not clearly distinguishable (the
results were on the edge) with the music samples but turned out
to be clearly audible in some synthetic samples.
Thanks to Daniel for helping out with the listening tests.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
It is broken, and results will be messed up when seeking.
This also fix duration displayed for streams when using -c copy.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Without this exception files with ".gif" extension by default
recognized as input suitable for image2 demuxer rather than gif.
In order to pass image through gif demuxer it was necessary
to use -f gif option.
This change affected 'make fate' test results because previously
image2 demuxer and gif decoder took only first frame of multiframe
test data, which is no longer true with gif demuxer.
Signed-off-by: Vitaliy E Sugrobov <vsugrob@hotmail.com>
Currently FFM files generated with one versions of ffmpeg generally
cannot be read by another.
By spliting data into chunks, more fields can saftely be appended to
chunks as well as new chunks added.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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."
