Some players do not support setting minimumUpdatePeriod to zero.
This patch adds a new parameter that will let the users set any
value to this field. Also updates the test and the documentation.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
DASH spec requires the presence of either duration of the period
or the minimumUpdatePeriod element. This patch adds the
minimumUpdatePeriod element hardcoded with the value 0 as the
manifest will never be updated for WebM DASH Live streams. Also
updating the fate test reference file.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With this the returned timestamp should match the packet instead of
the requested timestamp, which may lay between packets
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Seeking to a negative time did not have the desired effect of seeking to
the next valid position (the file start). On the other hand, just
"-ss 0" will normally seek to a position higher than 0, because it adds
the start time of the file. (The start time is not 0 because the gapless
code skips a few samples from the start.)
Fix this by using the "-seek_timestamp 1" option, which makes "-ss 0" do
what you'd expect it would do.
Also put the -ss option at the right place, before -i. This actually
makes it seek, instead of something completely else. The ".out-3" test
is no different in the -usetoc 0/1 cases, because the seeking is
inaccurate (in both cases).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
MicroDVD has a "hack" for specifying the video framerate the subtitle
was authored against. The demuxer reads this hint correctly, but didn't
skip it correctly.
This was not noticed, because the exported packet has its duration set
to 0, making it invisible (depending on the API user's rendering logic).
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This patch adds support for creating DASH manifests for WebM Live
Streams. It also updates the documentation and adds a fate test to
verify the behavior of the new muxer flag.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Previously unset, and some software mishandles files if it is absent
Signed-off-by: Tim Nicholson <tim.nicholson@bbc.co.uk>
Reviewed-by: tomas.hardin@codemill.se
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2889c5e16711770437f380f1bead5f72c6a0b17a':
movenc: Heuristically set the duration of the last sample in a fragment if not set
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '46d4d8575979a24a8d026d9805039b724e0e3e5f':
movenc: Avoid writing separate flags for the first sample if not necessary
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '00d751d4fc20ec88d2cc2c9f39ec8b9e9c8cdeba':
movenc: Set tfhd default sample flags based on actual samples, if possible
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Regression test for the bug from trac ticket #4359 fixed in commit efff3854
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
Outputting DNxHD into .mov containers 'corrupts' following atoms until end of stsd
ffmpeg and qtdump could not decode pasp/colr atoms in the files made by ffmpeg,
when outputting DNxHD due to the incorrect padding placement. Now we add the
padding in the correct place
Tidy up FATE changes due to padding changes.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e21d85309943a51b7808f5e01dd258b262e09148':
FATE: add a test for the SVQ1 header byte swapping
Conflicts:
tests/fate/qt.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Avid prefers mpeg range [16-235] by default this change brings
ffmpeg into line with that. To obtain the old behaviour use
'-color_range jpeg' on the command line prior to the ouput
filename.
Signed-off-by: Kevin Wheatley <kevin.j.wheatley@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is a bit ugly as it attempts to keep most of the computation
in integers before the double based fps code. The use of integers
is to reduce the chances of rounding differences between platforms
Previously the timestamp was rounded to the encoder timebase
before being converted back to double precision which could cause loss
of precision
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The existing meridian audio test does not test
ff_mlp_rematrix_channel_arm. This sample (first 640k of
https://samples.libav.org/A-codecs/TrueHD/TrueHD.raw) uses
ff_mlp_rematrix_channel_arm. Since this sample has 5.1 channels it also
allows testing the integrated downmixing.
This uses the RIFF header stored size to figure out the expected AVI
file size, instead of the actual file. To work fully it requires handling
failed avio_seek() instead of assuming they always succeed.
Some fate file has been cut off and contains half a frame at the end which
previously was not output during demuxing. This frame is now output to
encoder, thus the fate diff update.
Bug-Id: 261
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
According to the DPX file format description found at
http://www.fileformat.info/format/dpx/egff.htm the ImageElement part of
the GenericImageHeader also contains an an offset to the real image data
beside the same member that can be found in the GenericFileHeader.
Libav keeps this member empty (=0) while some applications expects it to
be filled properly. FATE test updated accordingly.
Bug-Id: 742
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Only shift limited range luma, and always only shift chroma
for upconversion.
Based off a patch by Michael Niedermayer.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The file is already present in git and by using it we can perform more tests
without the need of fate samples
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The new reference.pnm is a freely licensed replacement. The photo has
been taken by Reinhard Tartler on August 28 2014, and is licensed under
the expat license as stated at http://www.jclark.com/xml/copying.txt
* commit '9257692ac15eff7b07540c1f61cebde0d8823fbd':
lavf: Only initialize s->offset once when using avoid_negative_ts make_zero
Conflicts:
libavformat/mux.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is a generic solution that will not reqiore modifications when new options are added.
This also fixes problem with current implementation when qmin or qmax=-1.
Only 8 bits was sent and read back as 255.
Fixes#1275Fixes#1461
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
Function allows to create string containing object's serialized options.
Such string may be passed back to av_set_options_string() in order to restore options.
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
According to the DASH spec, Representation IDs should be unique
across all adaptation sets. Fixing that and updating the fate
reference file to reflect this change.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'aae6b3b918b4133b8cc2d1631196c1d406d0351a':
movenc: Don't write any iso brands in ismv files
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'c55d1d382cd41345a79782ace41f9b43f45dca9a':
movenc: Don't write any tfdt atom for ismv files
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '00c67fe1d0bc7c2ce49daac9c80ea39d5a663b73':
movenc: Write a 0 duration in mdhd and tkhd for an empty initial moov
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '600d5ee6b12bad144756b0772319bb04796bc528':
movenc: Signal iso6 in compatible_brands when using tfdt
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It is derived from the actual equations of the specs. In
particular, it is closer to the inverse of what the encoder uses.
fate tests accordingly updated.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Uses a similar approach as vf_yadif to flush the last frame in idet.
Quick test with 50 frames from vsynth1:
./ffmpeg.old -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f mp4 -y /dev/null 2>&1 | grep Multi
(gives) [Parsed_idet_0 @ 0x261ebb0] Multi frame detection: TFF:0 BFF:0 Progressive:48 Undetermined:1
./ffmpeg -i fate-suite/ffmpeg-synthetic/vsynth1/%02d.pgm -vf idet -f mp4 -y /dev/null 2>&1 | grep Multi
(gives) [Parsed_idet_0 @ 0x35a0bb0] Multi frame detection: TFF:0 BFF:0 Progressive:49 Undetermined:1
Fate tests have been updated.
(In testing, it seems this filter will also need a subsequent patch for single frame input)
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Regression test for the bug from trac ticket #3849 fixed in commit 14e30255
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
In these cases, only drop dts. Because if we drop both we have no
timestamps at all for some files.
This improves playback of HLS streams from GoPro cameras.
Signed-off-by: Martin Storsjö <martin@martin.st>
Width, Height and Sample Rate should be in the AdaptationSet tag
only if all the contained representations have the same width,
height and sampling rate. Otherwise they should go into the
Representation tag. This patch adds this functionality and a fate
test for the same.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fix an incorrect hard code in cues_end computation. Updating the fate
test reference files related to the fix as well. The earlier computation
was clearly wrong as the cues_end field was greater than the file size
itself in some cases.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This also un-does the fate changes from a52f443714,
leaving this fix without even small differences in the output, that is
a sample for which this makes a vissible difference is very welcome
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes CID1194380
There are no vissible differences in the changed fate samples. Only
a tiny number of pixels change by tiny amounts in the frames i checked
If someone has a file that shows a vissible difference, please post it.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b39ebcddd47daf37659796aaa7d068668086507a':
fate: Add VC-1 interlaced twomv test
Note, this test is not free of artifacts on both sides of the merge
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '28f5cd312c9da9072108edf8b7685d009374ea96':
fate: Switch ra4-288 test from framecrc() to pcm()
Conflicts:
tests/fate/real.mak
The test is kept disabled as it still does not pass on x86-64 due to float
rounding
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Fixes Ticket3901
the seek test error codes change due to a change in the failure path,
this could be avoided by changing the respective error codes to EINVAL
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Add fate tests that test out the functionality of WebM DASH
Manifest XML generation. This patch contains the vpx.mak file
changes and the reference gold XML files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b263f8ffe7599d9cd27ec477a12700da8eb2790d':
lavf: add AVFormatContext.max_ts_probe
Conflicts:
doc/APIchanges
libavformat/avformat.h
libavformat/utils.c
libavformat/version.h
lavf-fate/mp3 changes as the estimated input bitrate changes and that is
copied to the output
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Fixes assertion failure
Fixes Ticket3822
as a side-effect this makes some mkv files a few bytes smaller
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The arrays are fairly large and could cause problems on some embedded systems
also they are not endian safe as they mix 32 and 8bit
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '706208ef47bffd525c982975d2756f7b2b220b8d':
fate: Split fate-pixdesc tests and dispatch them through Make
Conflicts:
tests/fate-run.sh
tests/ref/fate/filter-pixdesc
Merged-by: Michael Niedermayer <michaelni@gmx.at>
- all of them testing HEVC version 1
cherry picked from commit adcdabb4dd062694fb8de6df0faecaad1c36ba33
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Normally, a Laplace distribution is more typical of the residuals
encoded, but for noisy input, it's both better and simpler to be
safe and use a 1/d^2 distribution. Second hunk could use some
renormalization but it has effectively little impact.
Output size of ffvhuff on various 4:2:0 sequences:
context=0,1/d: 851974 27226 1137281
context=0,1/d²: 619081 25069 1051500
context=0,1/d³: 501983 30454 1290561
context=0,lapl: 500650 31754 1304082
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '194be1f43ea391eb986732707435176e579265aa':
lavf: switch to AVStream.time_base as the hint for the muxer timebase
Conflicts:
doc/APIchanges
libavformat/filmstripenc.c
libavformat/movenc.c
libavformat/mxfenc.c
libavformat/oggenc.c
libavformat/swf.h
libavformat/version.h
tests/ref/lavf/mkv
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This avoids the following libass warning when using the subtitles
filter: "Neither PlayResX nor PlayResY defined. Assuming 384x288"
Subtitles tests change because the output is ASS and the PlayRes[XY]
ends up in the output.
Previously, AVStream.codec.time_base was used for that purpose, which
was quite confusing for the callers. This change also opens the path for
removing AVStream.codec.
The change in the lavf-mkv test is due to the native timebase (1/1000)
being used instead of the default one (1/90000), so the packets are now
sent to the crc muxer in the same order in which they are demuxed
(previously some of them got reordered because of inexact timestamp
conversion).
It has not been properly maintained for years and there is little hope
of that changing in the future.
It appears simpler to write a new replacement from scratch than
unbreaking it.
This very slightly improves compression
Found-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
