In particular, add a sentence to introduce the example, and add a
simpler starting example with no options.
Also use different format for input.avi and output.mp4, to convey
that the conversion also works on the container format.
Address issue:
http://trac.ffmpeg.org/ticket/8730
Document metadata entries set by the filter, extend and clarify
options, add additional example showing how to extract the generated
data.
Address issue:
http://trac.ffmpeg.org/ticket/8766
Drop mention of unsupported N:M syntax, dropped since 0ed61546c4.
Also, drop reference of common expression constants, and fix
description of a expression parameter.
Fix issue:
http://trac.ffmpeg.org/ticket/9974
Reference drawtext textfile option and ffmpeg -filter_complex_script
and -filter_script as possible solutions to avoid shell escaping.
Address issue:
http://trac.ffmpeg.org/ticket/9008
This patch add another ARIB caption decoder using libaribcaption
external library.
Unlike libaribb24, it supports 3 types of subtitle outputs:
* text: plain text
* ass: ASS formatted text
* bitmap: bitmap image
Default subtitle type is ass as same as libaribb24.
Advantages compared with libaribb24 on ASS subtitle are:
* Subtitle positioning.
* Multi-rect subtitle: some captions are displayed at different
position at a time.
* More stability and reproducibility.
To compile with this feature:
* libaribcaption external library has to be pre-installed.
https://github.com/xqq/libaribcaption
* configure with `--enable-libaribcaption` option.
`--enable-libaribb24` and `--enable-libaribcaption` options are
not exclusive. If both enabled, libaribcaption precedes as
order listed in `libavcodec/allcodecs.c`.
Signed-off-by: rcombs <rcombs@rcombs.me>
These fields are supposed to store information about the packet the
frame was decoded from, specifically the byte offset it was stored at
and its size.
However,
- the fields are highly ad-hoc - there is no strong reason why
specifically those (and not any other) packet properties should have a
dedicated field in AVFrame; unlike e.g. the timestamps, there is no
fundamental link between coded packet offset/size and decoded frames
- they only make sense for frames produced by decoding demuxed packets,
and even then it is not always the case that the encoded data was
stored in the file as a contiguous sequence of bytes (in order for pos
to be well-defined)
- pkt_pos was added without much explanation, apparently to allow
passthrough of this information through lavfi in order to handle byte
seeking in ffplay. That is now implemented using arbitrary user data
passthrough in AVFrame.opaque_ref.
- several filters use pkt_pos as a variable available to user-supplied
expressions, but there seems to be no established motivation for using them.
- pkt_size was added for use in ffprobe, but that too is now handled
without using this field. Additonally, the values of this field
produced by libavcodec are flawed, as described in the previous
ffprobe conversion commit.
In summary - these fields are ill-defined and insufficiently motivated,
so deprecate them.
This has not been functional since a year ago, including in our current
minimum dependency of libplacebo (v4.192.0). It also causes build errors
against libplacebo v6, so it needs to be removed from the code. We can
keep the option around for now, but it should also be removed soon.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>
In texi source, @ characters need to be escaped.
This fixes the following build errors:
community.texi:59: unknown command `ffmpeg'
community.texi:143: unknown command `ffmpeg'
Signed-off-by: Martin Storsjö <martin@martin.st>
Remove doc/dev_communit markup files completely as they are at the wrong place.
Create a new community page, merging all of doc/dev_community and subsection Code of Conduct into a common place.
The corresponding patch to ffmpeg-web puts the Organisation & Code of Conduct into a seperate community chapter on the FFmpeg website.
Described in HEVC spec A.3.7. Bump minor version and add APIchanges
entry for new added profile.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Their usefulness is questionable, very few decoders set them, and their type
should have been int64_t. A replacement field can be added later if a valid use
case is found.
Signed-off-by: Marton Balint <cus@passwd.hu>
Frame counters can overflow relatively easily (INT_MAX number of frames is
slightly more than 1 year for 60 fps content), so make sure we use 64 bit
values for them.
Also deprecate the old 32 bit frame_number attribute.
Signed-off-by: Marton Balint <cus@passwd.hu>