These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In order to send VP9 tracks with FLV or RTMP, the enhanced RTMP
specification tells that VPCodecConfigurationRecord, a.k.a. vpcC
ISO-BMFF box, must be inserted into a metadata message. However, the
function responsible for generating vpcCs currently returns invalid
boxes, that are lacking the Version and Flag fields, inherited from
FullBox. For some reason, both flags were being added manually in
movenc. This patch fixes the issue.
Signed-off-by: Alessandro Ros <aler9.dev@gmail.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
- Changes in mov_write_video_tag function to handle EVC elementary stream
- Provided structure EVCDecoderConfigurationRecord that specifies the decoder configuration information for ISO/IEC 23094-1 video content
Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
Also make duration check for mvhd more consistent with the others, write
version 1 of mvhd if duration is at least INT32_MAX instead of UINT32_MAX.
Signed-off-by: Marton Balint <cus@passwd.hu>
When write multi-trun box, the MOV_TRUN_FIRST_SAMPLE_FLAGS flag
need judge by first param, not 0.
If the original video contains consecutive I frames,
this will cause the packets of fmp4 have error sample_flags ,
and then incorrect keyframes were generated,
and then error packet will be seeked.
Signed-off-by: Wang Yaqiang <wangyaqiang03@kuaishou.com>
Signed-off-by: Steven Liu <liuqi05@chinaffmpeg.org>
3GPP TS 26.244 Table 8.10 specifies that longitude is written before
latitude. The MOV demuxer already expects the correct order. So, write
them in that order.
However, the user supplied string may also be used in MOV mode which
requires ISO 6709 format which specifies latitude first. The demuxer
also exports the loci value in that format. So parser adjusted as well.
ISOBMFF (14496-12) made this field ('channelcount') in the
AudioSampleEntry structure non-template¹ somewhere before the
release of the 2022 edition. As for ETSI TS 126 244 AKA 3GPP
file format (V16.1.0, 2020-10), it does not seem contain any
references limiting the channelcount entry in AudioSampleEntry
or in its own definition of EVSSampleEntry.
fate-mov-mp4-chapters test had to be adjusted as it output a
mono vorbis stream, which would now be properly marked as such
in the container.
1: As per 14496-12:
Fields shown as “template” in the box descriptions are fields
which are coded with a default value unless a derived
specification defines their use and permits writers to use
other values than the default.
libavutil/color_utils contains some avpriv_ symbols that map
enum AVTransferCharacteristic values to gamma-curve approximations and
to the actual transfer functions to invert them (i.e. -> linear).
There's two issues with this:
(1) avpriv is evil and should be avoided whenever possible
(2) libavutil/csp.h exposes a public API for handling color that
already handles primaries and matricies
I don't see any reason this API has to be private, so this commit takes
the functionality from avutil/color_utils and merges it into avutil/csp
with an exposed av_ API rather than the previous avpriv_ API.
Every reference to the previous API has been updated to point to the
new one. color_utils.h has been deleted as well. This should not break
any applications as it only contained avpriv_ symbols in the first
place, so nothing in that header could be referenced by other
applications.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This commit does for AVOutputFormat what commit
20f9727018 did for AVCodec:
It adds a new type FFOutputFormat, moves all the internals
of AVOutputFormat to it and adds a now reduced AVOutputFormat
as first member.
This does not affect/improve extensibility of both public
or private fields for muxers (it is still a mess due to lavd).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The HEIF specification permits specifying the looping behavior of
animated sequences by using the EditList (elst) box. The track
duration will be set to the total duration of all the loops (or
infinite) and the duration of a single loop will be set in the edit
list box.
The default behavior is to loop infinitely.
Compliance verification:
* This was added in libavif recently [1] and the files produced by
ffmpeg after this change have EditList boxes similar to the ones
produced by libavif (and avifdec is able to parse the loop count as
intended).
* ComplianceWarden is ok with the produced files.
* Chrome is able to play back the produced files.
[1] 4d2776a3af
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Allow specifying the movie_timescale options to AVIF ouptut.
This also makes sure that when movie_timescale is not specified,
the default value of 1000 is used instead of 0. Animated AVIF
files which don't specify the movie_timescale will have the
correct duration written in the track and movie headers after this
change (instead of writing 0).
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The old warning is no longer applicable in the inner block after
c5b20cfe19.
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Gyan Doshi <ffmpeg@gyani.pro>
Profile can be derived from values codecpar pixel format only with software
formats. For hardware formats, we're forced to parse a frame header to get
the required information.
Signed-off-by: James Almer <jamrial@gmail.com>
According to the HEIF specification (ISO/IEC 23008-12) Section
7.5.3.1, tracks with handler_type 'auxv' must contain a 'auxi' box
in its SampleEntry to notify the nature of the auxiliary track to the
decoder.
The content is the same as the 'auxC' box. So parameterize and re-use
the existing function.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Zern <jzern@google.com>
The fLaC and dfLa box IDs have been registered with the MP4 RA
(they are now listed at https://mp4ra.org/#/codecs) and support
for muxing FLAC in MP4 has been experimental in ffmpeg for
6 years now, since Nov 21, 2016
This patch removes the experimental status and removes the MP4
object type, as none has been registered for FLAC as it was not
deemed necessary.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Regression since c9de096851.
Fixes Coverity ID 1506839.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This leaves out RealAudio DolbyNet, which utilizes bsids 9 and 10,
It is not clear whether the interpreted bit rate value (divided by
2 or 4 depending on the variant), or the original bit rate value
should be utilized to receive the bit_rate_code index.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Add the AC-3 frame type, as well as early exit from additional packet
parsing in case of AC-3, as only a single packet is required to get
the required information.
Additionally, expose ac3_bit_rate_code via the eac3_info struct as
it is required for AC3SpecificBox.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
This simplifies the code to no longer have #ifs in a manner which
does not require handling avpriv_ac3_parse_header returning ENOSYS.
As an existing example, the MPEG-TS muxer already requires the AC-3
parser, and in order to fix existing issues with the current AC-3
movenc code, switching to use the AC-3 parser is required, so this
is an enabling change for that.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
AVIF specification allows for alpha channel as an auxiliary item (in
case of still images) or as an auxiliary track (in case of animated
images). Add support for both of these. The AVIF muxer will take
exactly two streams (when alpha is present) as input (first one being
the YUV planes and the second one being the alpha plane).
The input has to come from two different images (one of it color and
the other one being alpha), or it can come from a single file
source with the alpha channel extracted using the "alphaextract"
filter.
Example using alphaextract:
ffmpeg -i rgba.png -filter_complex "[0:v]alphaextract[a]" -map 0 -map "[a]" -still-picture 1 avif_with_alpha.avif
Example using two sources (first source can be in any pixel format and
the second source has to be in monochrome grey pixel format):
ffmpeg -i color.avif -i grey.avif -map 0 -map 1 -c copy avif_with_alpha.avif
The generated files pass the compliance checks in Compliance Warden:
https://github.com/gpac/ComplianceWarden
libavif (the reference avif library) is able to decode the files
generated using this patch.
They also play back properly (with transparent background) in:
1) Chrome
2) Firefox (only still AVIF, no animation support)
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Add an AVIF muxer by re-using the existing the mov/mp4 muxer.
AVIF Specification: https://aomediacodec.github.io/av1-avif
Sample usage for still image:
ffmpeg -i image.png -c:v libaom-av1 -still-picture 1 image.avif
Sample usage for animated AVIF image:
ffmpeg -i video.mp4 animated.avif
We can re-use any of the AV1 encoding options that will make
sense for image encoding (like bitrate, tiles, encoding speed,
etc).
The files generated by this muxer has been verified to be valid
AVIF files by the following:
1) Displays on Chrome (both still and animated images).
2) Displays on Firefox (only still images, firefox does not support
animated AVIF yet).
3) Verified to be valid by Compliance Warden:
https://github.com/gpac/ComplianceWarden
Fixes the encoder/muxer part of Trac Ticket #7621
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Add a parameter to omit seq header when generating the av1C atom.
For now, this does not change any behavior. This will be used by a
follow-up patch to add AVIF support.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
ff_get_packet_palette() and ff_reshuffle_raw_rgb() belong together:
E.g. the former takes the return value of the latter as argument.
So move ff_get_packet_palette() to rawutils.c (which consists solely
of ff_reshuffle_raw_rgb()).
Also add a separate header for these two functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
supports forcing or disabling the writing of the btrt atom.
the default behavior is to write the atom only for mp4 mode.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
On output streams where a multichannel stream needs to be stored as one track
per channel, each track will have a channel layout describing the position of
the channel they contain. For the track with front center, the mov muxer was
using the mov layout "mono" instead of the label for the front center position.
Since our channel layout API considers front center == mono, we need to do some
heuristics. To achieve this, we make sure all audio tracks contain streams with
a single channel, and only one of them is front center. In that case, we write
the front center label instead of signaling mono layout.
Fixes the last part of ticket #2865
Signed-off-by: James Almer <jamrial@gmail.com>
Fix below error message when timecode packet is written.
"Application provided duration: -9223372036854775808 / timestamp: -9223372036854775808 is out of range for mov/mp4 format"
try to reproduce by:
ffmpeg -y -f lavfi -i color -metadata "timecode=00:00:00:00" -t 1 test.mov
Note although error message is printed, the timecode packet will be written anyway. So
the patch 2/2 will try to change the log level to warning.
Fixes ticket #9488
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
This avoids unnecessary rebuilds of most source files if only the
list of enabled components has changed, but not the other properties
of the build, set in config.h.
Signed-off-by: Martin Storsjö <martin@martin.st>
The muxer seems to have had one seemingly accidental use of
LIBAVCODEC_IDENT, while LIBAVFORMAT_IDENT probably is the
relevant one (which is used multiple times in the same file).
Signed-off-by: Martin Storsjö <martin@martin.st>
mvhd and tkhd present the post-editlist duration, while mdhd should
have the pre-editlist duration. Regression since c2424b1f3.
Signed-off-by: Martin Storsjö <martin@martin.st>
Up until now, we had a PacketList structure which is actually
a PacketListEntry; a proper PacketList did not exist
and all the related functions just passed pointers to pointers
to the head and tail elements around. All these pointers were
actually consecutive elements of their containing structs,
i.e. the users already treated them as if they were a struct.
So add a proper PacketList struct and rename the current PacketList
to PacketListEntry; also make the functions use this structure
instead of the pair of pointers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This function is quite small (96B with GCC 11.2 on x64 Ubuntu 21.10
at -O3), making it more economical to duplicate it into libavformat
instead of exporting it as avpriv: Doing so saves 2x24B in .dynsim,
2x16B in .dynstr, 2x2B .gnu.version, 24B in .rela.plt, 16B in .plt,
16B in .plt.sec (if enabled), 4B .gnu.hash; besides the actual
duplicated code this also adds 2x8B .eh_frame_hdr and 24B .eh_frame.
In other words: Duplicating is neutral size-wise (it is also presumed
neutral for other systems). Given that it avoids the runtime
overhead of dynamic symbols, it is advantageouos to duplicate the
function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
libavcodec currently exports four avpriv symbols that deal with
PixelFormatTags: avpriv_get_raw_pix_fmt_tags, avpriv_find_pix_fmt,
avpriv_pix_fmt_bps_avi and avpriv_pix_fmt_bps_mov. The latter two are
lists of PixelFormatTags, the former returns such a list and the second
searches a list for a pixel format that matches a given fourcc; only
one of the aforementioned three lists is ever searched.
Yet for avpriv_pix_fmt_bps_avi, avpriv_pix_fmt_bps_mov and
avpriv_find_pix_fmt the overhead of exporting these functions actually
exceeds the size of said objects (at least for ELF; the following numbers
are for x64 Ubuntu 20.10):
The code size of avpriv_find_pix_fmt is small (GCC 10.2 37B, Clang 11 41B),
yet exporting it adds a 20B string for the name alone to the exporting
as well as to each importing library; there is more: Four bytes in the
exporting libraries .gnu.hash; two bytes each for the exporting as well
as each importing libraries .gnu.version; 24B in the exporting as well
as each importing libraries .dynsym; 16B+24B for an entry in .plt as
well as the accompanying relocation entry in .rela.plt for each
importing library.
The overhead for the lists is similar: The strings are 23B and the
.plt+.rela.plt pair is replaced by 8B+24B for an entry in .got and
a relocation entry in .rela.dyn. These lists have a size of 80 resp.
72 bytes.
Yet for ff_raw_pix_fmt_tags, exporting it is advantageous compared to
duplicating it into libavformat and potentially libavdevice. Therefore
this commit replaces all library uses of the four symbols with a single
function that is exported for shared builds. It has an enum parameter
to choose the desired list besides the parameter for the fourcc. New
lists can be supported with new enum values.
Unfortunately, avpriv_get_raw_pix_fmt_tags could not be removed, as the
fourcc2pixfmt tool uses the table of raw pix fmts. No other user of this
function remains.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
