Some muxers, such as GPAC, create files with only one sidx, but two streams
muxed into the same fragments pointed to by this sidx.
Prevously, in such a case, when we seeked in such files, we fell back
to, for example, using the sidx associated with the video stream, to
seek the audio stream, leaving the seekhead in the wrong place.
We can still do this, but we need to take care to compare timestamps
in the same time base.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
A gateway can see everything, and we should not be shipping a hardcoded
default from a third party company; it's a security risk.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
In 45bfe8b838, short_seek_threshold was removed
from the public AVIO struct. Although this option was private and not intended
to be used by public API users, it was nonetheless, because it provided functionality
that could otherwise not be gained via public API.
This was especially important for networked I/O like HTTP, where the internal
size for lavf could be way to small depending on the specifics of a user's
usecase, such as reading interlavd media files from cloud storage.
Add an AVOption to make this functionality accessible to the HTTP client.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
bit_rate is not a critical field, and we shouln't hard fail if we
can't caluclate it due to a large timebase - it needlessly breaks
valid files.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
677a030b26 introduced more printable
side data types in ffprobe, however the Audio Service Type side data
'type' field that was introduced aliases an existing field of the same
name within the side data array, which can lead to JSON output like:
"side_data_list": [
{
"side_data_type": "Audio Service Type",
"type": 0
},
{
"side_data_type": "Stereo 3D",
"type": "side by side",
"inverted": 1
}
]
This, while technically valid JSON, is considered bad practice, since it
forces all downstream users to manually parse it and check all types;
it makes simple deserialization impossible. Worse, in som loosely
type languages, it can lead to silent bugs if exising code assumed
it was a different type.
As such, rename this second "type" field to "service_type".
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
These bits are reserved in earlier versions of the H.264 spec, and
some poor hardware decoders require they are zero. Thus, it is useful
to be able to zero these on streams that may have them set. The result
is still a valid H.264 bitstream.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This is important, for example, for connection timed out events,
when used over a network, returning AVERROR(ETIMEDOUT).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The test sample has to have no file extension, otherwise probing
happens to work, based off file extension alone, and we want to
test the actual probing function.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
When extended atom size support was added to probing in
fec4a2d232, the buffer
size check was backwards, but probing continued to work
because there was no minimum size check yet, so despite
size being 1 on these atoms, and failing to read the 64-bit
size, the tag was still correctly read.
When 0b78016b2d introduced a
minimum size check, this exposed the bug, and broke probing
any files with extended atom sizes, such as entirely valid
large files that start whith mdat atoms.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Use the tfra timestamp if it is available and sidx timestamp is not.
Fixes reading the entire file after seeking in a live-style DASH FMP4
with an MFRA.
This specifically fixes when use_mfra_for is set.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
GIF palette entries are not compressed, and writing 256 entries,
which can be up to every frame, uses a significant amount of
space, especially in extreme cases, where palettes can be very
small.
Example, first six seconds of Tears of Steel, palette generated
with libimagequant, 320x240 resolution, and with transparency
optimization + per frame palette:
* Before patch: 186765 bytes
* After patch: 77895 bytes
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This option will disable the writing of the global palette in global
GIF header if it is set to 0, causing only the frame-level palette
to ever be written.
This will be useful later on when further frame-level palette
optimizations are introduced.
The default is 1, which maintains current default behavior.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
avcodec has no facilities to generate timestamps properly from
output frame numbers (and it would be wrong for VFR anyway),
so pass through the timestamps using rav1e's opaque user data
feature, which was added in v0.4.0.
This bumps the minimum librav1e version to 0.4.0.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This also changes a check for mfra_size from < 0 to == 0, since
it was always wrong, as avio_rb32 returns an unsigned integer.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
On files with more than one sidx box, like live fragmented MP4
files, it was previously re-reading and seeking on every singl
sidx box, leading to extremely poor performance on larger files,
especially over the network.
Only do it on the first one, and stash its result.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It should be a 64-bit integer, otherwise it overflows and fails
on files greater than 2GB on some systems like x86_64 Linux.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This useful, because by ffprobe's very nature, you use it to probe
a file and find out what it is. Requiring every format private option
to be known to the demuxer forces one to run ffprobe twice, if one
wants to use ffprobe in a generic way.
For example, say one wants to probe all user-uploaded files, while
also ignoring edit lists for any MP4s that are uploaded. Currently,
you'd have to run ffprobe twice: once to identify the format, and
once again to actually probe the metadata you want. After this
patch, you could set -ignore_editlist 1 on every call and only
probe once.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
When doing streamed output, with e.g. +dash, if the mfra box ended
up being larger than the AVIOContext write buffer, the (unchecked)
seeking back to update the box size would silently fail and produce
an invalid mfra box.
This is similar to how other boxes are written in fragmented mode.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This is a requirement of the AV1-ISOBMFF spec. Section 2.1.
General Requirements & Brands states:
* It SHALL have the av01 brand among the compatible brands array of the FileTypeBox
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Not requiring this leads to unexpected result, since Rav1e's current
two pass API has no way to fail in such a case.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Rav1e currently uses the time base given to it only for ratecontrol... where
the inverse is taken and used as a framerate. So, do what we do in other wrappers
and use the framerate if we can.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Currently, the decoder checks the 128th value of the 4th quant table during
while deriving the context on each sample, in order to speed itself up. This
is due to relying on the behavior of FFmpeg's FFV1 encoder, in which if that
value is zero, the entire 4th and 5th quant tables are assumed to be entirely
zero.
This does not match the FFV1 spec, which has no such restriction, and after
some discussion, it was decided to fix FFmpeg to abide by the spec, rather
than change the spec.
We will now check whether the 4th and 5th quant tables are zero properly,
by checking the 128th valye of both tables (which means they are zero due
to the way they're coded in the bitstream).
For further context, the FFV1 issue in question is located at:
https://github.com/FFmpeg/FFV1/issues/169
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This breaks totally valid files that get caught in its heuristic.
This, according to the commit message, is my own doing, having asked
Michael to implement this check and providing a sample that was
"wrong". I am now atoning for my sins, and removing this hack, having
seen the light (aka that this was silly to do in the first place).
Resotores correct behavior on valid files.
This reverts commit 8e5e84c2a2.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
If we don't copy this value first, it is seen as 0 by h264_slice_header_init,
due to zero-allocation of the new context, triggering an old hack that
multiplied the denominator by 2 for files produced by old x264 versions, but
only if more than one thread was used.
Fixes#7475 and #7083.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Some of these enums have gaps in between their values, since they correspond
to the values in various specs, instead of being an incrementing list.
Fixes segfaults when, for example, using the valid API call:
av_color_primaries_from_name("jecdec-p22");
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The track's media duration from the mdhd atom takes precedence
over both the stts and elst atom for calculating and setting
the track's total duraion.
Technically, we shouldn't be using the stts atom at all for
calculating stream durations.
This fixes incorrect stream and final packet durations on files
with edit lists that are longer than the media duration.
The FATE changes are expected, and output is more correct (the
AAC frame is not 1028 samples).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
JPEGs store embedded profiles under the APP2 marker, signified
with a "ICC_PROFILE" null-terminated string header, and can be
split across multiple APP2 markers, out of order.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The WebM DASH spec states:
The Initialization Segment shall not contain Clusters or Cues.
The Segment Index corresponds to the Cues.
Previously, it included the cues if they were at the front.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Output was apparently not tested for correctness. Passing overlapping
memory to snprintf causes undefined behavior, and usually resulted in
only the very last timestamp being written to metadata, and not a list
at all.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It should not be a value larger than the number of streams we have,
or it will cause invalid reads and/or SIGSEGV.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This seems to be non-optional, and if the muxer is run without it,
strlen() is run on NULL, causing a segfault.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This was added before edts support existed, and is no longer
valid.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df0,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df0,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit '71d3305c2711d4f6ec8b92db09ff64cf4e19a58e':
h264_parse: make sure the ref count is zeroed on all failure paths
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'a6e27f7add2698fdd89911632b570c3d0c3f2aaa':
h264: factor out parsing the reference count into a separate file
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Derek Buitenhuis