qoroliang [Fri, 13 Mar 2020 09:02:32 +0000 (17:02 +0800)]
lavc/hevcdec: fix the HEVC decoder crash when memory over-read
Fix an occasional crash for hevc decoder in ARM 32 platform, the
root cause is the memory over read(read cross the memory boundary)
in SAO NENO functions ff_hevc_sao_band_filter_neon_8 and
ff_hevc_sao_edge_filter_neon_8.
After this fix, the crash disapper in the massive Android phone
test.
Martin Storsjö [Sat, 18 Apr 2020 21:24:06 +0000 (00:24 +0300)]
swscale: aarch64: Avoid using the x18 register
The x18 is a reserved platform register on Darwin and Windows.
x8/w8 seems to be unused in this function though (and same about
x10 and x14), so there's really no reason to use x18 here - just change
the uses of x18/w18 into x8/w8 instead without any further rewrites.
The context structure of the truehd_core bsf had a pointer to a const
AVClass as its first member; yet this bsf does not have any AVClass
associated with it, so that this pointer is always NULL. So remove it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/rv40dsp: Fix integer overflows in rv40_weight_func_*()
Fixes: signed integer overflow: 40550400 * 128 cannot be represented in type 'int' Fixes: 20331/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV40_fuzzer-5676685725007872 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently Musepack allocates an array that needs to be freed later in
the demuxer's read_close-function; it is the sole reason for said
function's existence. But it is unnecessary, because one can store this
array in the stream's priv_data pointer, so that it will be freed
generically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskadec: Remove redundant setting of chapter titles
Chapter titles are added to the chapter's metadata since 6cb6e159,
yet since 012867f0 (the predecessor of) avpriv_new_chapter() already
adds the title to the chapter's metadata. So setting it again in
matroskadec.c is redundant and expensive.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is primarily intended to test that muxers correctly write chapters
or metadata; but given that it does this by having our demuxers read the
generated files, it also tests demuxers. And of course it may prove
useful for encoders, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
fate: Fix dependencies for ffprobe tests with external samples
Up until now, they were appended to the FATE_EXTERN-$(CONFIG_FFMPEG)
variable and were therefore activated when ffmpeg was enabled regardless
of whether ffprobe was enabled.
Also the same happened with FATE_SAMPLES_FASTSTART, although the
corresponding test (mov-faststart-4gb-overflow) only requires external
samples.
Furthermore, remove the unused FATE_FULL variable (FATE_EXTERN_FFPROBE has
taken its place).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/flacenc: Only update streaminfo if it has changed
An AVStream's codecpar is supposed to be filled by the caller before
avformat_write_header(); if the CodecParameters change, the caller
should signal this via packet side data, but not touch the AVStream's
codecpar.
The FLAC muxer checks for packet side data containing updated extradata,
yet if nothing has arrived by the time the trailer is written, the
already written extradata is overwritten by the very same extradata
again, unless the output is unseekable, in which case a warning that the
FLAC header can't be rewritten is emitted.
This commit changes this by only trying to rewrite the extradata if a
new streaminfo arrived via packet side data. Only then is a warning
emitted in case the output is unseekable.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When no packet could be output, the interleavement functions
nevertheless initialized the packet destined for output (with the
exception of the data and size fields, making the initialization
pointless), although it will not be used at all. So remove the
initializations.
Reviewed-by: Marton Balint <cus@passwd.hu> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
write_packet() currently saves the original timestamps of the packet it
got and restores them in case writing fails. This is unnecessary as we
are no longer working directly with the user-supplied AVPacket here; and
it is also pointless because the timestamps may already have been
altered before write_packet().
So remove this and add a general comment to the function that timestamps
may be modified; also remove a long outdated comment about side data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The documentation of av_write_frame() explicitly states that the function
doesn't take ownership of the packets sent to it; while av_write_frame()
does not directly unreference the packets after having written them, it
nevertheless modifies the packet in various ways:
1. The timestamps might be modified either by prepare_input_packet() or
compute_muxer_pkt_fields().
2. If a bitstream filter gets applied, it takes ownership of the
reference and the side-data in the packet sent to it.
In case of do_packet_auto_bsf(), the end result is that the returned packet
contains the output of the last bsf in the chain. If an error happens,
a blank packet will be returned; a packet may also simply not lead to
any output (vp9_superframe).
This also implies that side data needs to be really copied and can't be
shared with the input packet.
The method choosen here minimizes copying of data: When the input isn't
refcounted and no bitstream filter is applied, the packet's data will
not be copied.
Notice that packets that contain uncoded frames are exempt from this
because these packets are not owned by and returned to the user. This
also moves unreferencing the packets containing uncoded frames to
av_write_frame() in the noninterleaved codepath; in the interleaved
codepath, these packets are already freed in av_interleaved_write_frame(),
so that unreferencing the packets in write_uncoded_frame_internal() is
no longer needed. It has been removed.
Reviewed-by: Marton Balint <cus@passwd.hu> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Now that ff_interleave_add_packet() always returns blank packets, the
input packet to ff_interleave_packet_per_dts() will always be blank on
return as well (if supplied) and the same goes for interleave_packet()
in mux.c. Document these facts and remove the redundant resetting that
happened in av_interleaved_write_frame().
The last reference to the (long removed) destruct field that AVPackets
once had has been removed as well when updating the documentation of
ff_interleave_packet_per_dts().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/mux: Fix leak when adding packet to interleavement queue fails
When an error happened in ff_interleave_add_packet() when adding
a packet to the packet queue, said packet would not be unreferenced
in ff_interleave_add_packet(), but would be zeroed in
av_interleaved_write_frame(), which results in a memleak.
This has been fixed: ff_interleave_add_packet() now always unreferences
the input packet on error; as a result, it always returns blank packets
which has been documented. Relying on this a call to av_packet_unref()
in ff_audio_rechunk_interleave() can be removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/mux: Fix leaks on error when writing noninterleaved uncoded frames
If writing uncoded frames in noninterleaved mode fails at the preparatory
steps (i.e. before it reaches write_packet()), the packet would not be
unreferenced and the frame would leak. This is fixed by unreferencing
the packet in write_uncoded_frame_internal() instead.
This also makes it possible to remove the unreferencing in
write_packet() itself: In noninterleaved mode frames are now freed in
write_uncoded_frame_internal(), while they are freed in interleaved
mode when their containing packet gets unreferenced (like normal
packets).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/mux: Make uncoded frames av_packet_unref() compatible
Currently uncoded frames (i.e. packets whose data actually points to an
AVFrame) are not refcounted. As a consequence, calling av_packet_unref()
on them will not free them, but may simply make sure that they leak by
losing the pointer to the frame.
This commit changes this by actually making uncoded frames refcounted.
In order not to rely on sizeof(AVFrame) (which is not part of the public
API and so must not be used here in libavformat) the packet's data is
changed to a (padded) buffer containing just a pointer to an AVFrame.
Said buffer is owned by an AVBuffer with a custom free function that
frees the frame as well as the buffer. Thereby the pointer/the AVBuffer
owns the AVFrame.
Said ownership can actually be transferred by copying and resetting
the pointer, as might happen when actually writing the uncoded frames
in AVOutputFormat.write_uncoded_frame() (although currently no muxer
makes use of this possibility).
This makes packets containing uncoded frames compatible with
av_packet_unref(). This already has three advantages in interleaved mode:
1. If an error happens at the preparatory steps (before the packet is
put into the interleavement queue), the frame is properly freed.
2. If the trailer is never written, the frames still in the
interleavement queue will now be properly freed by
ff_packet_list_free().
3. The custom code for moving the packet to the packet list in
ff_interleave_add_packet() can be removed.
It will also simplify fixing further memleaks in future commits.
Suggested-by: Marton Balint <cus@passwd.hu> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The data of an attachment file is put into an AVCodecParameter's
extradata. The corresponding size field has type int, yet there was no
check for the size to fit into an int. As a consequence, it was possible
to create extradata with negative size (by using a big enough max_alloc).
Other errors were also possible: If SIZE_MAX < INT64_MAX (e.g. on 32bit
systems) then the file size might be truncated before the allocation;
and avio_read() takes an int, too, so one would not have read as much
as one desired.
Furthermore, the extradata is now padded as is required.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/ac3dec_fixed: Fix several invalid left shifts in scale_coefs()
Fixes: left shift of negative value -14336 Fixes: 20298/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AC3_FIXED_fuzzer-5675484201615360 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/flac_parser: Do not lose header count in find_headers_search()
Fixes: Timeout Fixes: out of array access Fixes: 20274/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-5649631988154368 Fixes: 19275/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-5757535722405888 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/audiodsp: Fix integer overflow in scalarproduct_int16_c()
Fixes: signed integer overflow: 2145417478 + 76702564 cannot be represented in type 'int' Fixes: 20313/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RA_144_fuzzer-5734487724130304 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Philip Langdale [Fri, 10 Apr 2020 20:32:11 +0000 (13:32 -0700)]
avcodec: Add explicit capability flag for encoder flushing
Previously, there was no way to flush an encoder such that after
draining, the encoder could be used again. We generally suggested
that clients teardown and replace the encoder instance in these
situations. However, for at least some hardware encoders, the cost of
this tear down/replace cycle is very high, which can get in the way of
some use-cases - for example: segmented encoding with nvenc.
To help address that use case, we added support for calling
avcodec_flush_buffers() to nvenc and things worked in practice,
although it was not clearly documented as to whether this should work
or not. There was only one previous example of an encoder implementing
the flush callback (audiotoolboxenc) and it's unclear if that was
intentional or not. However, it was clear that calling
avocdec_flush_buffers() on any other encoder would leave the encoder in
an undefined state, and that's not great.
As part of cleaning this up, this change introduces a formal capability
flag for encoders that support flushing and ensures a flush call is a
no-op for any other encoder. This allows client code to check if it is
meaningful to call flush on an encoder before actually doing it.
I have not attempted to separate the steps taken inside
avcodec_flush_buffers() because it's not doing anything that's wrong
for an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
avcodec/cbs_jpeg_syntax_template: Check array index in huffman_table()
Fixes: index 224 out of bounds for type 'uint8_t [224]' Fixes: 21534/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-6291612167831552 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/cbs_jpeg_syntax_template: Check table index before use in dht()
Fixes: out of array access Fixes: 21515/clusterfuzz-testcase-minimized-ffmpeg_BSF_TRACE_HEADERS_fuzzer-5766121576988672 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Ming Qian [Wed, 1 Apr 2020 02:38:45 +0000 (10:38 +0800)]
avcodec/v4l2_m2m: handle v4l2 end of stream event
When flushing the capture buffers, the driver may send a V4L2_EVENT_EOS
to notify that draining is completed. Currently, v4l2_m2m does not
subscribe to this event, which can cause some devices (i.e. imx8qm) to
hang at the end of encoding/decoding. Support for handling the event is
added in this commit.
Some devices may not signal V4L2_EVENT_EOS. This is logged as a warning
message during initialization and not treated as a fatal error.
Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
The only difference of the currently used write_packet()-function to
ff_raw_write_packet() is that the former also counts the number of
frames. Yet doing so in the muxer itself is unnecessary as this is
already done generically in write_packet() in libavformat/mux.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/Makefile: Remove false dependencies of WebM and Matroska muxer
These muxers don't depend on the WebM Chunk or the WebM DASH Manifest
muxers.
Furthermore, remove some #if checks in webm_chunk.c and webmdashenc.c.
They are always true now that webm_chunk.c and webmdashenc.c are only
compiled when their corresponding muxers are enabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The webm_chunk muxer requires the WebM muxer, yet it does not directly
require anything from libavformat/matroska.c (it does not even include
the corresponding header). So remove the dependency from the Makefile
and add a _select to configure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Don't write elements with their default value
This has happened when writing chapters: Both editions as well as
chapters are by default not hidden and given that we don't support
writing hidden chapters at all, we don't need to write said elements at
all. The same goes for ChapterFlagEnabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
They also annoyingly remapped the following (which are functionally
equivalent but can be treated differently by clients):
- smpte240m primaries to smpte170m.
- smpte170m TRC to bt709.
- bt470bg color space to smpte170m.
The enum values in FFmpeg are the same values as ITU-T H.273 and
ISO/IEC 23001-8 so we can just use them directly, which is both simpler
and preserves the user intent.
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
avformat/matroskaenc: Change signature of mkv_write_track()
Up until now, mkv_write_track() received the index of the stream whose
header data it is about to write as parameter; this index has until
recently been explicitly used to generate both TrackNumber and TrackUID.
But this is no longer so and as there is no reason why the function
for writing a single TrackEntry should even know the index of the
TrackEntry it is about to write, said index is replaced in the list of
function parameters by the corresponding AVStream and mkv_track.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Automatically use right TrackNumber in Cues
mkv_cuepoint (the structure used to store the index entries in the
Matroska muxer) currently contains fields for both the index of the
packet's stream in the AVFormatContext.streams array and for the
Matroska TrackNumber; correspondingly, mkv_add_cuepoint() has parameters
for both. But these two numbers can't be chosen independently, so get
rid of the TrackNumber.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Ignore AttachedFiles for track limit
Attachments are streams in FFmpeg, but they are not tracks in Matroska.
Yet they were counted when checking a limit for the number of tracks that
the Matroska muxer imposes. This is unnecessary and has been changed.
Also use unsigned variables for the variables denoting TrackNumbers as
negative TrackNumbers are impossible.
(The Matroska file format actually has practically no limit on the
number of tracks and this is purely what our muxer supports. But even if
this limit were removed/relaxed in the future, it still makes sense to
use small TrackNumbers as this patch does, because greater numbers need
more bytes to encode.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Make output more deterministic
Using random values for TrackUID and FileUID (as happens when the
AVFMT_FLAG_BITEXACT flag is not set) has the obvious downside of making
the output indeterministic. This commit mitigates this by writing the
potentially random values with a fixed size of eight byte, even if their
actual values would fit into less than eight bytes. This ensures that
even in non-bitexact mode, the differences between two files generated
with the same settings are restricted to a few bytes in the header.
(Namely the SegmentUID, the TrackUIDs (in Tracks as well as when
referencing them via TagTrackUID), the FileUIDs (in Attachments as
well as in TagAttachmentUID) as well as the CRC-32 checksums of the
Info, Tracks, Attachments and Tags level-1-elements.) Without this
patch, there might be an offset/a size difference between two such
files.
The FATE-tests had to be updated because the fixed-sized UIDs are also
used in bitexact mode.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Remove allocations for Attachments
If there are Attachments to write, the Matroska muxer currently
allocates two objects: An array that contains an entry for each
AttachedFile containing just the stream index of the corresponding
stream and the FileUID used for this AttachedFile; and a structure with
a pointer to said array and a counter for said array. These uids are
generated via code special to Attachments: It uses an AVLFG in the
normal and a sha of the attachment data in the bitexact case. (Said sha
requires an allocation, too.)
But now that an uid is generated for each stream in mkv_init(), there is
no need any more to use special code for generating the FileUIDs of
AttachedFiles: One can simply use the uid already generated for the
corresponding stream. And this makes the whole allocations of the
structures for AttachedFiles as well as the structures itself superfluous.
They have been removed.
In case AVFMT_FLAG_BITEXACT is set, the uids will be different from the
old ones which is the reason why the FATE-test lavf-mkv_attachment
needed to be updated. The old method had the drawback that two
AttachedFiles with the same data would have the same FileUID.
The new one doesn't.
Also notice that the dynamic buffer used to write the Attachments leaks
if an error happens when writing the buffer. By removing the
allocations potential sources of errors have been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This commit reuses the random seed generated in mkv_init() (to determine
the TrackUIDs) for the SegmentUID in order to avoid a potentially
expensive call to av_get_random_seed().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the TrackUID of a Matroska track which is supposed to be
random was not random at all: It always coincided with the TrackNumber
which is usually the 1-based index of the corresponding stream in the
array of AVStreams. This has been changed: It is now set via an AVLFG
if AVFMT_FLAG_BITEXACT is not set. Otherwise it is set like it is set
now (the only change happens if an explicit track number has been
chosen via dash_track_number, because the system used in the normal
situation is now used, too). In particular, no FATE tests need to be
updated.
This also fixes a bug in case the dash_track_number option was used:
In this case the TrackUID was set to the provided number, but the tags
were written with a TagTrackUID simply based upon the index, so that
the tags didn't apply to the track they ought to apply to.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Tags in the Matroska file format can be summarized as follows: There is
a level 1-element called Tags containing one or many Tag elements each
of which in turn contain a Targets element and one or many SimpleTags.
Each SimpleTag roughly corresponds to a single key-value pair similar to
an AVDictionaryEntry. The Targets meanwhile contains information to what
the metadata contained in the SimpleTags contained in the containing Tag
applies (i.e. to the file as a whole or to an individual track).
The Matroska muxer writes such metadata. It puts the metadata of every
stream into a Tag whose Targets makes it point to the corresponding
track. And if the output is seekable, then it also adds another Tag for
each track whose Targets corresponds to the track and where it reserves
space in a SimpleTag to write the duration at the end of the muxing
process into.
Yet there is no reason to write two Tag elements for a track and a few
bytes (typically 24 bytes per track) can be saved by adding the duration
SimpleTag to the other Tag of the same track (if it exists).
FATE has been updated because the output files changed. (Tests that
write to unseekable output (pipes) needn't be updated (no duration tag
has ever been written for them) and the same applies to tests without
further metadata.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avformat/matroskaenc: Ensure that ChapterUID are != 0
AVChapters have an int as id field and therefore this value can appear
<= 0. When remuxing from Matroska, this value actually contains
the lower 32 bits of the original ChapterUID (which can be 64 bits).
In order to ensure that the ChapterUID is always > 0, they were offset
as follows (since 07704c61): First max(0, 1LL - chapter[i].id) was computed
and stored in an uint32_t. And then the IDs were offset using this value.
This has two downsides:
1. It does not ensure that the UID is actually != 0: Namely if there is
a chapter with id == INT_MIN, then the offset will be 2^31 + 1 and a
chapter with id == INT_MAX will become 2^31 - 1 + 2^31 + 1 = 2^32 = 0,
because the actual calculation was performed in 32 bits.
2. As soon as a chapter id appears to be negative, a nontrivial offset
is used, so that not even a ChapterUID that only uses 32 bits is
preserved.
So change this by treating the id as an unsigned value internally and
only offset (by 1) if an id vanishes. The actual offsetting then has to
be performed in 64 bits in order to make sure that no UINT32_MAX wraps
around.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/cbs: Avoid leaving the ... out in calls to variadic macros
According to C99, there has to be at least one argument for every ...
in a variadic function-like macro. In practice most (all?) compilers also
allow to leave it completely out, but it is nevertheless required: In a
variadic macro "there shall be more arguments in the invocation than there
are parameters in the macro definition (excluding the ...)." (C99,
6.10.3.4).
CBS (not the framework itself, but the macros used in the
cbs_*_syntax_template.c files) relies on the compiler allowing to leave
a variadic macro argument out. This leads to warnings when compiling in
-pedantic mode, e.g. "warning: must specify at least one argument for
'...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments]"
from Clang.
Most of these warnings can be easily avoided: The syntax_templates
mostly contain helper macros that expand to more complex variadic macros
and these helper macros often omit an argument for the .... Modifying
them to always expand to complex macros with an empty argument for the
... at the end fixes most of these warnings: The number of warnings went
down from 400 to 0 for cbs_av1, from 1114 to 32 for cbs_h2645, from 38 to
0 for cbs_jpeg, from 166 to 0 for cbs_mpeg2 and from 110 to 8 for cbs_vp9.
These eight remaining warnings for cbs_vp9 have been fixed by switching
to another macro in cbs_vp9_syntax_template: The fixed values for the
sync bytes as well as the trailing bits for byte-alignment are now read
via the fixed() macro (this also adds a check to ensure that trailing
bits are indeed zero as they have to be).
Reviewed-by: Mark Thompson <sw@jkqxz.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
projects / ffmpeg / log