According to the ReplayGain spec, the peak amplitude may overflow and may result
in peak amplitude values greater than 1.0 with psychoacoustically coded audio,
such as MP3. Fully compliant decoders must allow peak overflows.
Additionally, having peak values in the 0<->UINT32_MAX scale makes it more
difficult for applications to actually use the peak values (e.g. when
implementing clipping prevention) since values have to be rescaled down.
This patch corrects the peak parsing by removing the rescaling of the decoded
values between 0 and UINT32_MAX and the 1.0 upper limit.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The gain sign was incorrectly decoded: since the FFSIGN() macro treats 0 as
negative, gain values starting with "0." were always decoded as negative.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Further performance improvements and security fixes by
Vittorio Giovara, Luca Barbato and Diego Biurrun.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Additional fixes by Nigel Touati-Evans <nigel.touatievans@gmail.com>.
Check the index for streams with a time drift of 2s or a buffer drift
of 64MB.
Bug-Id: 666
CC: libav-stable@libav.org
Sample-Id: yet-another-broken-interleaved-avi.avi
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Additional fixes and enhancements by Vittorio Giovara, Gonzalo Garramuno,
Nicolas George, Paul B Mahol and Michael Niedermayer.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Some files set the PreviousPartition field to point to its own offset.
If we are parsing forward the Previous partition is immediately known
and its value could be used, otherwise we can safely point to the
header.
Reported-By: Jean Baptiste Kempf <jb@videolan.org>
For live audio streams, requiring 500 frames for a stream to
be detected is a bit overkill.
This allows live ADTS streams that don't start nicely at
a frame boundary to start up more quickly, e.g.
http://mp3.streampower.be/radio1.aac.
Signed-off-by: Martin Storsjö <martin@martin.st>
If a portion of the probe buffer seem to resemble ADTS frames,
but some data at the end is a mismatch, disregard the whole
probing attempt. If it actually is ADTS data, there shouldn't be
any mismatches within the sequential frame data.
Signed-off-by: Martin Storsjö <martin@martin.st>
mp4 files embedding DVD subtitles do not use the same extradata format
as the rest of Libav expects. The subtitle decoder in libavcodec in
particular does not understand this format.
Convert the extradata to the vobsub .idx format. mp4 stores the palette
as binary 32 bit ints in YUV. The subtitle resolution is stored
separately in the track header, which we access through AVStream.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The icy_metadata_headers string never gets initialized, so,
during the first call to av_strlcatf() in parse_icy(),
strlen() will be called on a pointer to uninitialized memory.
At best this causes some garbage data to be left at the
start of the string.
By initializing icy_metadata_headers to the empty string, the
first call to strlen() will always return 0, so that data is
appended from the start of the string.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Export the metadata as a icy_metadata_packet avoption.
Based on the work of wm4 and Alessandro Ghedini.
Bug-Id: https://bugs.debian.org/739936
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The MSVCRT version of strftime calls the invalid parameter handler
if the struct values in struct tm are invalid. In case no invalid
parameter handler is set for the process, the process is aborted.
This fixes fate failures on MSVC builds since 570af382.
Based on a patch by Hendrik Leppkes.
Signed-off-by: Martin Storsjö <martin@martin.st>
'hvc1' requires that parameter set NAL units be
present only in the samples entry, but not in the
samples themselves, requiring that additional
parameter sets, if present, be filtered out of the
samples and placed in new, additional sample entries
if they override or otherwise conflict with the
parameter sets present in the first sample entry.
We do not have any way of doing this at present, so
the files we produce can only comply with the
restrictions set for the 'hev1' sample entry name in
ISO/IEC 14496-15.
The correct point that seperates ISO and MAC language codes is 0x400
according to the current QT spec. Old QT specs did not list where this
seperation is but apparently only defined the meaning of the first 137.
It is my understanding that "Unless otherwise stated, all data in a
QuickTime movie is stored in big-endian byte ordering" [1] in MOV files.
I have a couple of thousand files, which technically are invalid because
their sound sample description element 4CC is 'lpcm' but its version is
0 - and "Version 0 supports only uncompressed audio in raw ('raw ') or
twos-complement ('twos') format" [2]
Because isom.c only contains a mapping for 4CC 'lpcm' to
AV_CODEC_ID_PCM_S16LE, these files have their audio decoded as LE when
it is actually BE.
This commit adds AV_CODEC_ID_PCM_S16BE as the first match for 4CC 'lpcm'.
[1]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 21
[2]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 178
Reviewed-by: Yusuke Nakamura <muken.the.vfrmaniac@gmail.com>
Based on a suggestion by Martin Panter. This is more descriptive,
since it's the actual timestamp field from the RTMP packet,
which might or might not be a delta depending on context (in
some packets it's a delta, in some packets it's an absolute
timestamp, and in some packets it's 0xffffff to indicate that
the actual delta or absolute timestamp is transmitted separately).
Signed-off-by: Martin Storsjö <martin@martin.st>
Related fix in "rtmpdump":
https://repo.or.cz/w/rtmpdump.git/commitdiff/79459a2
Adobe's RTMP specification (21 Dec 2012), section 5.3.1.3 ("Extended
Timestamp"), says "this field is present in Type 3 chunks". Type 3 chunks are
those with the one-byte header size.
This resolves intermittent hangs and segfaults caused by the read function,
and also includes an untested fix for the write function.
The read function was tested with ABC (Australia) News 24 streams, however
they are probably restricted to only Australian internet addresses. Some of
the packets at the start of these streams seem to contain junk timestamp
fields, often requiring the extended field. Test command:
avplay rtmp://cp81899.live.edgefcs.net/live/news24-med@28772
Signed-off-by: Martin Storsjö <martin@martin.st>
Get the last partition offset and use it when footer partition
offset is missing.
Footer partition may not be present and even if present footer
partition offset may not be set in any partition except last one.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Extrapolate audio timestamps based on the number of samples demuxed.
Deal with some MXF nastiness involving fractional number of
samples per EditUnit when seeking (the specs handwave this away).
Further fixes from Tomas Härdin.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
We cannot easily determine if an mpeg TS's packet size is DVHS, FEC
or so on, for that we need to expose the internal raw_packet_size
field.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Since 2007, the Xiph.org Foundation recommends that .ogg only be used
for Ogg Vorbis audio files.
Source: http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
However we only do it if we have libvorbis available because the
built in vorbis encoder is not as good.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Currently ff_interleave_packet_per_dts() waits until it gets a frame for
each stream before outputting packets in interleaved order.
Sparse streams (i.e. streams with much fewer packets than the other
streams, like subtitles or audio with DTX) tend to add up latency and in
specific cases end up allocating a large amount of memory.
Emit the top packet from the packet_buffer if it has a time delta
larger than a specified threshold.
Original report of the issue and initial proposed solution by
mus.svz@gmail.com.
Bug-id: 31
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This fixes playback of mp3 streams in rtp/asf. This used to work
until c6f1dc8, but mostly by coincidence.
Signed-off-by: Martin Storsjö <martin@martin.st>
The normal differential timestamps can't handle negative
differences, thus send a full packet header with an absolute
timestamp in these cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
If the url ends with .flv, we stripped it but didn't initialize
rt->playpath, doing av_strlcat on an uninitialized buffer.
Signed-off-by: Martin Storsjö <martin@martin.st>
The track duration is often not reliable or is not the duration
represented by the number of frames. In those cases, avg_frame_rate
was reported incorrectly. Removing this code falls back to the
default calculation in avformat_find_stream_info().
This is a partial revert of commit c3aeaa540.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Reviewed-by: Stephen Hutchinson <qyot27@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
It could probably also be considered an error if the pointer isn't
null at this point, but then we might risk rejecting some
slightly broken files that we might have handled so far.
Sample-Id: 00000496-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
These arrays are normally freed at the end of mov_read_trak,
but make sure they're freed in case mov_read_trak returned
early (due to errors) or in case the atoms that allocate arrays
are encountered at some other point than within a trak (which
we don't have checks against).
Sample-Id: 00000496-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Such files have IndexTableSegments which when parsed cover EditUnit
ranges like this:
[0,1)
[249,250)
[249,377)
[0,249)
where each interval is
[IndexStartPosition, IndexStartPosition + IndexDuration)
This would be reduced to a sparse index like:
[0,1), [249,250)
instead of the full range:
[0,249), [249,377)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The Omnia A/XE encoder writes the explicit extra data incorrectly
and wrongly disables parametric stereo. Truncating the extra data
by setting the size to 2 works around this. The AAC extra data
parser will then only parse the correct parts.
Bug-id: 599
The code cannot handle there being none, but that should not happen for
valid files.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
This avoids a memory leak (or having to worry about freeing the
config string) if the colorspace isn't accepted.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some ACTi cameras fail if "*" is passed as the URI.
Signed-off-by: Ismael Luceno <ismael.luceno@corp.bluecherry.net>
Signed-off-by: Martin Storsjö <martin@martin.st>
