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>
The actual predictor value, set by the trellis code, never
was written back into the variable that was written into
the block header. This was accidentally removed in b304244b.
This significantly improves the audio quality of the trellis
case, which was plain broken since b304244b.
Encoding IMA QT with trellis still actually gives a slightly
worse quality than without trellis, since the trellis encoder
doesn't use the exact same way of rounding as in
adpcm_ima_qt_compress_sample and adpcm_ima_qt_expand_nibble.
Fixes part of Ticket3701
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
adpcm_ima_qt does not produce reproducible results, so it is temporarily
disabled (see #3701).
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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 corrects the bug that caused the checksums to change in
9767d7c092.
It caused the EOS flag to be set incorrectly; the ogg spec does not
allow it to be set in the middle of a logical bitstream.
Signed-off-by: Andrew Kelley <superjoe30@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Before, header information for ogg format files was sent with the
first encoded packet.
This patch makes it so that it is possible for API users to
differentiate between headers and encoded audio. This is useful, for
example, when creating an audio stream where you want to send one set
of headers for every client that connects and then the encoded stream
of audio.
Signed-off-by: Martin Storsjö <martin@martin.st>
Based off the srt encoder. The following features are unimplemented:
- fonts, colors, sizes
- alignment and positioning
The rest works well. For example, use ffmpeg to convert subtitles into the .vtt format:
ffmpeg -i input.srt output.vtt
Signed-off-by: Aman Gupta <ffmpeg@tmm1.net>
Signed-off-by: Clément Bœsch <u@pkh.me>
* commit '6656370b858329ca07a60a2de954d5e90daa0206':
avconv: set the "encoder" tag when transcoding
Conflicts:
ffmpeg.c
tests/ref/lavf/mkv
tests/ref/seek/lavf-mkv
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '93afb6c98df876b15e3d911a9450ad55f92080ce':
avconv: set output avg_frame_rate when known
Conflicts:
ffmpeg.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6072184e702b4b631ac72f1b66b75e5f21e0ce2d':
asfenc: use codec descriptors instead of AVCodecs to write codec info
Conflicts:
tests/ref/lavf/asf
tests/ref/seek/lavf-asf
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also, stop using AVCodecContext.codec_name as fallback, since it will be
deprecated.
Changes the result of the lavf-asf test (and its associated seektest),
since 'msmpeg4v3' gets written instead of just 'msmpeg4'.
Partially undoes commit 2c4e08d893:
riff: always generate a proper WAVEFORMATEX structure in
ff_put_wav_header
A new flag, FF_PUT_WAV_HEADER_FORCE_WAVEFORMATEX, is added to force the
use of WAVEFORMATEX rather than PCMWAVEFORMAT even for PCM codecs.
This flag is used in the Matroska muxer (the cause of the original
change) and in the ASF muxer, because the specifications for
these formats indicate explicitly that WAVEFORMATEX should be used.
Muxers for other formats will return to the original behavior of writing
PCMWAVEFORMAT when writing a header for raw PCM.
In particular, this causes raw PCM in WAV to generate the canonical
44-byte header expected by some tools.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The rational for this is another issue that plex has exposed. When it is
conducting a transcode of video to HLS for streaming, my father noticed
artifacts when played on his GoogleTV (NSZ-GT1). He sent me a test file
and I reproduced it on my device of the same model. It is important to
note that the artifacts were not present when streaming to VLC or QuickTime
Player. I copied the command-line that plex used, and conducted all of the
following tests using FFmpeg git.
Transcode to HLS: artifacts on playback
Transcode to TS: playback is fine
Cat HLS segments into a single TS: playback is fine
Segment single TS file to segments: artifacts on playback
Segment single TS file to segments using Apple's HLS segmenter: playback is
fine
At this point I carefully examined the differences between Apple's HLS
segmenter output and FFmpeg's. Among the considerable differences, I
noticed that the video PES packets always had a 0 length. So I continued:
Transcode to HLS using FFmpeg with 0 length PES packets: playback is fine.
Segment single TS to segments with 0 length PES packets: playback is fine.
All failures mentioned are only on the GTV since it is the only player on
which I could reproduce artifacts. I only tested the GTV, VLC, and
QuickTime Player though, so my test case is limited. I do not know if
other players exhibit this issue.
Since it was useful last time, I have uploaded the test file as
hls_pes_packet_length.m4v along with its associated txt file which contains
the transcode command-line that was used.
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
