Signed-off-by: Marth64 <marth64@proxyid.net>
Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
used open source tool for processing 608/708 closed caption (CC) sources.
It can be used to archive the original, raw CC bitstream and to produce
a source file file for later CC processing or conversion. As a result,
it also allows for interopability with ccextractor for processing CC data
extracted via ffmpeg. The format is simple to parse and can be used
to retain all lines and variants of CC.
A free specification of RCWT can be found here:
https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT
This muxer implements the specification as of 01/05/2024, which has
been stable and unchanged for 10 years as of this writing.
This muxer will have some nuances from the way that ccextractor muxes RCWT.
No compatibility issues when processing the output with ccextractor
have been observed as a result of this so far, but mileage may vary
and outputs will not be a bit-exact match.
Specifically, the differences are:
(1) This muxer will identify as "FF" as the writing program identifier, so
as to be honest about the output's origin.
(2) ffmpeg's MPEG-1/2, H264, HEVC, etc. decoders extract closed captioning
data differently than ccextractor from embedded SEI/user data.
For example, DVD captioning bytes will be translated to ATSC A53 format.
This allows ffmpeg to handle 608/708 in a consistant way downstream.
This is a lossless conversion and the meaningful data is retained.
(3) This muxer will not alter the extracted data except to remove invalid
packets in between valid CC blocks. On the other hand, ccextractor
will by default remove mid-stream padding, and add padding at the end
of the stream (in order to convey the end time of the source video).
This prevents code duplication in the source form by calling the parse
code that was moved to avcodec last commit. The code will be duplicated
in binary form for shared builds (it's not that large), but for source
code it will only exist in one location now.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Add demuxer to probe raw vvc and parse vvcc byte stream format.
Co-authored-by: Nuo Mi <nuomi2021@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>
Animated JPEG XL files requires a separate demuxer than image2, because
the timebase information is set by the demuxer. Should the timebase of
an animated JPEG XL file be incompatible with the timebase set by the
image2pipe demuxer (usually 1/25 unless set otherwise), rescaling will
fail. Adding a separate demuxer for animated JPEG XL files allows the
timebase to be set correctly.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
It is a URL rewriter for IPFS gateways, not an actual implementation of
IPFS, and naming it as such was both incorrect and misleading.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
They are also needed by the MMSH and MMST protocols and therefore
the file they are in is pulled in when these protocols are enabled
and used. By moving them to a separate file, linking statically to
libavformat while only using AVIO no longer pulls in all the
muxers/demuxers (and also no longer any AVCodecs when linking
statically to libavcodec).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This file will contain the AVFormatContext-specific parts
that are used by both demuxers and muxers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This file is both for the various public APIs that are demuxer-only
as well as for the demuxer-only internal functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by muxers. Given that it is not part of
the core muxing code and given that mux.c is already big enough,
it is moved to a new file for utility functions for muxing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids having to rebuild big files every time FFMPEG_VERSION
changes (which it does with every commit).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This patch adds support for:
- ffplay ipfs://<cid>
- ffplay ipns://<cid>
IPFS data can be played from so called "ipfs gateways".
A gateway is essentially a webserver that gives access to the
distributed IPFS network.
This protocol support (ipfs and ipns) therefore translates
ipfs:// and ipns:// to a http:// url. This resulting url is
then handled by the http protocol. It could also be https
depending on the gateway provided.
To use this protocol, a gateway must be provided.
If you do nothing it will try to find it in your
$HOME/.ipfs/gateway file. The ways to set it manually are:
1. Define a -gateway <url> to the gateway.
2. Define $IPFS_GATEWAY with the full http link to the gateway.
3. Define $IPFS_PATH and point it to the IPFS data path.
4. Have IPFS running in your local user folder (under $HOME/.ipfs).
Signed-off-by: Mark Gaiser <markg85@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
James Almer
Ingo Oppermann
Thomas Siedel
Marth64
Paul B Mahol
Leo Izen
Steven Liu
Dawid Kozinski
Jerome Martinez
Zhao Zhili
Derek Buitenhuis
Anton Khirnov
Timo Rothenpieler
Limin Wang
Andreas Rheinhardt
Mark Gaiser
Pierre-Anthony Lemieux
Martin Storsjö