ff_mp4_obj_type contains the wrong type of tags for
AVOutputFormat.codec_tag. AVOutputFormat.codec_tag is used to
validate AVCodecParameters.codec_tag so needs to be the same
type of tag.
Creates new tag lists for mp4 and ismv. New tag lists support
same list of codecs found in ff_mp4_obj_type. psp uses the same
tag list as mp4 since these both use mp4_get_codec_tag to look up tags.
(cherry picked from commit 713efb2c0d)
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Skip the codec_tag altogether here, to let the user (try to) set
whichever codec/tag is preferred; the individual chained muxer will
reject invalid codecs anyway.
(cherry picked from commit 61f589e31e)
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Otherwise AVTimebaseSource gets av_apply_bitstream_filters' documentation in doxygen.
Signed-off-by: Max Weber <mii7303@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This implements the 0x10 frame format for Interplay MVE movies. The
format is a variation on the 0x06 format with some changes. In addition
to the decoding map there's also a skip map. This skip map is used to
determine what 8x8 blocks can change in a particular frame.
This format expects to be able to copy an 8x8 block from before the last
time it was changed. This can be an arbitrary time in the past. In order
to implement this this decoder allocates two additional AVFrames where
actual decoding happens. At the end of a frame decoding changed blocks
are copied to a finished frame based on the skip map.
The skip map's encoding is a little convulted, I'll refer to the code
for details.
Values in the decoding map are the same as in format 0x06.
Signed-off-by: Hein-Pieter van Braam <hp@tmm.cx>
This implements the 0x06 frame format for Interplay MVE movies. The
format is relatively simple. The video data consists of two parts:
16 bits per 8x8 block movement data
a number of 8x8 blocks of pixel data
For each 8x8 block of pixel data the movement data is consulted. There
are 3 possible meanings of the movement data:
* zero : copy the 8x8 block from the pixel data
* negative : copy the 8x8 block from the previous frame from an offset
determined by the actual value of the entry -0xC000.
* positive : copy the 8x8 block from the current frame from an offset
determined by the actual value of the entry -0x4000
Decoding happens in two passes, in the fist pass only new pixeldata is
copied, during the second pass data is copied from the previous and
current frames.
The codec expects that the current frame being decoded to still has the
data from 2 frames ago on it when decoding starts.
Signed-off-by: Hein-Pieter van Braam <hp@tmm.cx>
Interplay MVE can contain up to three different frame formats. They
require different streams of information to render a frame. This patch
changes the IP packet format to prepare for the extra frame formats.
Signed-off-by: Hein-Pieter van Braam <hp@tmm.cx>
Interplay MVE movies have a SEND_BUFFER operation. Only after this
command does the current decoding buffer get displayed. This is required
for the other frame formats. They are fixed-size and can't always encode
a full frame worth of pixeldata.
This code prevents half-finished frames from being emitted.
Signed-off-by: Hein-Pieter van Braam <hp@tmm.cx>
Buffering more than one packet can be a huge performance improvement for
encoding files with small packets (e.g. wav) over SMB/CIFS.
Acked-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
If flushing is not disabled, then mux.c will signal the end of the packets with
an AVIO_DATA_MARKER_FLUSH_POINT, and aviobuf will be able to decide to flush or
not based on the preferred minimum packet size set by the used protocol.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
This patch makes aviobuf work more like traditinal file IO, which is how people
think about it.
For example, in the past, aviobuf only flushed buffers until the current buffer
position, even if more data was written to it previously, and a backward seek
was used to reposition the IO context.
From now, aviobuf will keep track of the written data, so no explicit seek will
be required till the end of the buffer, or till the end of file before flushing.
This fixes at least one regression, fate-vsynth3-flv was broken if
flush_packets option was set to false, an explicit seek was removed in
4e3cc4bdd8.
Also from now on, if a forward seek in the write buffer were to cause a gap
between the already written data and the new file position, a flush will
happen.
The must_flush varable is also removed, which might have caused needless
flushes with multiple seeks whithin the write buffer. Since we know the amount
of data written to it, we will know when to flush.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes a NULL pointer derefence when ogg_init() returns a failure and
a stream's private data was not yet allocated.
This is a regression since 3c5a53cdfa
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
When the hlsenc at BYTERANGE mode, it should not show the warning message:
"Duplicated segment filename detected:"
Reported-by: Marco <marco@worldcast.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Daniel Kucera <daniel.kucera@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Daniel Kucera <daniel.kucera@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the videos starts with B frame, then the minimum composition time
as computed by stts + ctts will be non-zero. Hence we need to shift
the DTS, so that the first pts is zero. This was the intention of that
code-block. However it was subtracting by the wrong amount.
For example, for one of the videos in the bug nonFormatted.mp4 we have
stts:
sample_count duration
960 1001
ctts:
sample_count duration
1 3003
2 0
1 3003
....
The resulting composition times are : 3003, 1001, 2002, 6006, ...
The minimum composition time or PTS is 1001, which should be used to
offset DTS. However the code block was wrongly using ctts[0] which is
3003. Hence the PTS was negative. This change computes the minimum pts
encountered while fixing the index, and then subtracts it from all the
timestamps after the edit list fixes are applied.
Samples files available from:
https://bugs.chromium.org/p/chromium/issues/detail?id=721451https://bugs.chromium.org/p/chromium/issues/detail?id=723537
fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2
B frames. Before this change the PTS of first two B-frames was -6006
and -3003, and I am guessing one of them got dropped when being decoded
and remuxed to the framecrc before, and now it is not being dropped.
Signed-off-by: Sasi Inguva <isasi@google.com>
This reduces the attack surface of local file-system
information leaking.
It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.
Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.
The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.
Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel
This recommits the security fix without the author name joke which was
originally requested by Nicolas.
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reduces the attack surface of local file-system
information leaking.
It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.
Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.
The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.
Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Atempt to read and propagate only full ADTS frames and not other data,
like id3v1 or APETags at the end of the file.
Fixes ticket #6437.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
The loglevel is choosen so that the main filename and any images of
multi image sequences are shown only at debug level to avoid
clutter.
This makes exploits in playlists more visible. As they would show
accesses to private/sensitive files
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
WebM supports a subset of elements from the Chapters master.
See https://www.webmproject.org/docs/container/#chapters
Addresses ticket #6425
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This prevents part of one exploit leading to an information leak
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
instead of deciding whether to encrypt based on the encryption scheme,
decide according to whether cenc was initialized or not.
mov_create_timecode_track calls ff_mov_write_packet with a track that
doesn't have cenc initialized.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This adapts and merges commit f4bf236338
from libav, originally skipped in 13a211e632
as it was not necessary back then.
Is's applied now in preparation for the following patches, where the
aac_adtstoasc bitstream filter will start to correctly propagate the new
extradata through packet side data.
Signed-off-by: James Almer <jamrial@gmail.com>
Don't just look at zero sized packets, and also check for AAC extradata
updates, in preparation for the following patches.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
If the source is using a custom IO, setting this flag causes heavy leaks
since the segments will not have their avio context closed.
Regression since f5da453b06.
Using AVOnce as a stack variable makes no sense as the state is lost
when the function exits.
This fixes repeated calls to av(filter/device)_register_all
* commit '1920382aa9f21d7ed1a3c2214990da8d2b067a92':
dashenc: add option to provide UTC timing source
Also use E instead of AV_OPT_FLAG_ENCODING_PARAM to be consistent with
the other AVOption.
Merged-by: Clément Bœsch <u@pkh.me>
* commit '95f1004bdfdf2d26c330c1d4b7c4ac9352d60b18':
dashenc: add mandatory id to AdaptationSet and Period in manifest
Merged-by: Clément Bœsch <u@pkh.me>
Some samples have their metadata track time_scale incorrectly set to 0
and the check introduced by a398f054fd
prevents playback of those samples. Setting the time_scale to 1 fixes
playback.
Only checks the extension and MIME type, since determining whether
a file is SVG is difficult since they're just XML files.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This brings our generation of the vpcC box up to date to version 1.0
of the VP Codec ISO Media File Format Binding.
Specifically, color/transfer properties are now written with values
based on ISO/IEC 23001-8, which is the same reference specification the
AVColor* enumerations are based on.
ff_accept can return AVERROR(ETIMEDOUT) and errno will be 0 (or
undefined), return ret instead and return ff_neterror() in
ff_poll_interrupt instead of AVERROR(errno) to parse WSAGetLastError on
Windows.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Coverity CID: 1405453
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Replicates lavf/librtmp.c behavior in L149-156 and rtmpdump's
behavior with "--swfVfy <url>" passing the url to swfUrl.
Fixes trac ticket #5549.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '92db5083077a8b0f8e1050507671b456fd155125':
build: Generate pkg-config files from Make and not from configure
build: Store library version numbers in .version files
Includes cherry-picked commits 8a34f36593 and
ee164727dd to fix issues.
Changes were also made to retain support for raise_major and build_suffix.
Reviewed-by: ubitux
Merged-by: James Almer <jamrial@gmail.com>
* commit '11a9320de54759340531177c9f2b1e31e6112cc2':
build: Move build-system-related helper files to a separate subdirectory
"ffbuild" directory name is used instead of "avbuild".
Merged-by: Clément Bœsch <u@pkh.me>
find_fps attempts to infer framerate from AVCodec's timebase. When this
results in a frame rate that isn't explicitly marked as supported in
av_timecode_check_frame_rate, find_fps returns the AVStream's
avg_frame_rate, which, per avformat.h, _may_ be set (or not).
mov_get_mpeg2_xdcam_codec_tag, mov_get_h264_codec_tag and
find_compressor attempt to call av_q2d on the return value of find_fps,
which in the above case, may result in division by zero and therefore,
an undefined frame rate when NaN is converted to int.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
Add an option to webm_dash_manifest demuxer to specify a value for
"bandwidth" field in the DASH manifest. The value is then used by
the muxer. Fixes an existing FIXME in the code.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Zern <jzern@google.com>
* commit '9265364bec0af2e8b7c3a6de7bfc8291a0b70bca':
build: Separate avisynth and avxsynth support
Mostly noop, since it could break linux configure with --enable-avisynth,
and the configure code which was simplified isn't even present in
ffmpeg.
Only merged the cosmetic re-ordering in the Makefile.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Based on the draft spec at http://vfrmaniac.fushizen.eu/contents/opus_in_isobmff.html
'-strict -2' is required to create files in this format.
Signed-off-by: Matthew Gregan <kinetik@flim.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Experimental VP9 support was added to the muxer recently.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This merges commits 8e2ea69135 and
096a8effa3 by Anton Khirnov, with the
following change:
- extract_extradata_check() is added to know if the codec is supported
by the bsf before trying to initialize it. This behaviour is similar to
the old AVCodecParser.split checks.
The FATE reference changes are due to the filtered out NAL units that
the old AVCodecParser.split implementation left alone.
Decoding is unchanged as the functions that parse extradata simply
ignored said unnecessary NAL units.
Signed-off-by: James Almer <jamrial@gmail.com>
This fixes a proble where ffmpeg would cause crash to do a seek when the network disconnect.
The log like this:
01-01 10:53:03.441 6580 6580 F DEBUG : backtrace:
01-01 10:53:03.441 6580 6580 F DEBUG : #00 pc 0002942e /system/lib/libavformat.so (ffurl_write+9)
Signed-off-by: tiejun.peng <tiejun.peng@foxmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This adds partial support for the RFC 4175 (raw video over RTP). The
only supported formats are the YCbCr-4:2:2 8 bit because it's natively
supported by FFmpeg with pixel format UYVY, and 10 bit which requires
the vrawdepay codec to convert the payload in a format handled by
FFmpeg.
Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* commit '537b5b773b317af79d3a5b576ee9683e15ed84f6':
rtmpdh: Do global initialization before running the test
Merged-by: James Almer <jamrial@gmail.com>
This avoids an integer overflow
the solution matches oggparsevorbis.c and 45581ed15d
Fixes: 700242
Found-by: Thomas Guilbert <tguilbert@google.com>
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '3cc3463f306f425f76bd962755df1132eeac6dfa':
avisynth: Support pix_fmts added to AviSynth+
This commit is mostly a noop, see
92916e8542.
Cosmetics and a small fix are merged.
Merged-by: Clément Bœsch <u@pkh.me>
Adding an MOV format option to turn on/off the editlist supporting code, introduced in ca6cae73db
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is more robust in case some change or corner case causes them to be
dereferenced before being set
Fixes CID1396274, CID1396275
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
refer to SPEC:
Annex E. The FLV File Format said:
E.3 TheFLVFileBody have a table:
Field Type Comment
PreviousTagSize0 UI32 Always 0
Reviewed-by: Bela Bodecs <bodecsb@vivanet.hu>
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
* commit 'c541a44e029e8a4f21db028c34fee3ad1c10a409':
Revert "rtmpproto: Don't include a client version in the unencrypted C1 handshake"
Merged-by: Clément Bœsch <u@pkh.me>
The old "API" that signaled rotation as a metadata value has been
replaced by DISPLAYMATRIX side data quite a while ago.
There is no reason to make muxers/demuxers/API users support both. In
addition, the metadata API is dangerous, as user tags could "leak" into
it, creating unintended features or bugs.
ffmpeg CLI has to be updated to use the new API. In particular, we must
not allow to leak the "rotate" tag into the muxer. Some muxers will
catch this properly (like mov), but others (like mkv) can add it as
generic tag. Note applications, which use libavformat and assume the
old rotate API, will interpret such "rotate" user tags as rotate
metadata (which it is not), and incorrectly rotate the video.
The ffmpeg/ffplay tools drop the use of the old API for muxing and
demuxing, as all muxers/demuxers support the new API. This will mean
that the tools will not mistakenly interpret per-track "rotate" user
tags as rotate metadata. It will _not_ be treated as regression.
Unfortunately, hacks have been added, that allow the user to override
rotation by setting metadata explicitly, e.g. via
-metadata:s:v:0 rotate=0
See references to trac #4560. fate-filter-meta-4560-rotate0 tests this.
It's easier to adjust the hack for supporting it than arguing for its
removal, so ffmpeg CLI now explicitly catches this case, and essentially
replaces the "rotate" value with a display matrix side data. (It would
be easier for both user and implementation to create an explicit option
for rotation.)
When the code under FF_API_OLD_ROTATE_API is disabled, one FATE
reference file has to be updated (because "rotate" is not exported
anymore).
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
