Brad Smith authored 11 months ago and Michael Niedermayer committed 11 months ago

I try to help out with *BSD patches or build related issues where I can.

Signed-off-by: Brad Smith <brad@comstyle.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

I am willing to maintain these into the future as needed.

Signed-off-by: Marth64 <marth64@proxyid.net>

Once it became fully non-transparent and service of shady practices
behind closed doors, I can not be here any more.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Adding my new gpg key that I will be using from now on.
This key is ed25519, which is more secure than the old rsa4096.

Signed-off-by: Leo Izen <leo.izen@gmail.com>

Missed from a5b2b22d.

Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>

Adding myself for jpegxl* in avcodec as I'm the maintainer of this
parser.

Signed-off-by: Leo Izen <leo.izen@gmail.com>

I use a different nick on IRC now, Traneptora, instead of what I
formerly used, thebombzen.

Signed-off-by:  <leo.izen@gmail.com>

Keyframes are marked automagically

Dawid Kozinski authored 1 year ago and James Almer committed 1 year ago

- MAINTAINERS update

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>

Rémi Denis-Courmont authored 1 year ago and James Almer committed 1 year ago

Signed-off-by: James Almer <jamrial@gmail.com>

The hardware is old and not relevant today. The decoders also have many
special quirks and are effectively unmaintained.

Due to the lack of an active AMF maintainer at the moment, as well
as plans to add the av1 encoder and other improvements of AMF,
I added myself to the maintainers. Timely review and merging
patches targeting AMF integration should improve support
of AMD GPUs and APUs in FFmpeg.
For the last couple of years I have been working on AMF related
patches to ffmpeg and other open source projects.

It's not needed nor used by anything anymore, lavu/tx is faster,
and better in every way. RIP.

The position does not exist anymore.

Michael has not been doing much work on it in the last few years and I
have by far the most commits.

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This updates the list closer to reality.
Iam not a professional server admin, iam happy to help maintain the box as i have
done in the past. But iam not qualified nor volunteering to fix sudden problems
nor do i do major upgrades (i lack the experience to recover the box remotely if
something goes wrong) and also iam not maintaining backups ATM (our backup system
had a RAID-5 failure, raz is working on setting a new one up)

Maybe this should be signaled in a different way than spliting the lines but ATM
people ping me if something is wrong and what i do is mainly mail/ping raz
and try to find another root admin so raz is not the only active & professional
admin on the team. It would be more efficient if people contact raz and others
directly instead of depending on my waking up and forwarding a "ffmpeg.org" is down note

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Yin Shiyou authored 2 years ago and Michael Niedermayer committed 2 years ago

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Leo Izen authored 3 years ago and Lynne committed 3 years ago

This commit adds support to libavformat for muxing
and demuxing Jpeg XL images as image2 streams.

Leo Izen authored 3 years ago and Lynne committed 3 years ago

This commit adds decoding support to libavcodec
for Jpeg XL images via the external library libjxl.

Leo Izen authored 3 years ago and Lynne committed 3 years ago

This commit adds support to libavcodec to read
encoded Jpeg XL images. Jpeg XL is intended to be an
extended-life replacement to legacy mjpeg.

Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Niklas Haas authored 3 years ago and James Almer committed 3 years ago

So I can merge my own changes to this filter after they pass peer
review, as well as keeping it in sync with upstream API changes / new
features.

Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>

This patch builds on my previous DFPWM codec patch, adding a raw
audio format to be able to read/write the raw files that are most commonly
used (as no other container format supports it yet).

The muxers are mostly copied from the PCM demuxer and the raw muxers, as
DFPWM is typically stored as raw data.

Please see the previous patch for more information on DFPWM.

Signed-off-by: Jack Bruienne <jackbruienne@gmail.com>

From the wiki page (https://wiki.vexatos.com/dfpwm):
> DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec
> created by Ben “GreaseMonkey” Russell in 2012, originally to be used
> as a voice codec for asiekierka's pixmess, a C remake of 64pixels.
> It is a 1-bit-per-sample codec which uses a dynamic-strength one-pole
> low-pass filter as a predictor. Due to the fact that a raw DPFWM decoding
> creates a high-pitched whine, it is often followed by some post-processing
> filters to make the stream more listenable.

It has recently gained popularity through the ComputerCraft mod for
Minecraft, which added support for audio through this codec, as well as
the Computronics expansion which preceeded the official support. These
both implement the slightly adjusted 1a version of the codec, which is
the version I have chosen for this patch.

This patch adds a new codec (with encoding and decoding) for DFPWM1a.
The codec sources are pretty simple: they use the reference codec with
a basic wrapper to connect it to the FFmpeg AVCodec system.

To clarify, the codec does not have a specific sample rate - it is
provided by the container (or user), which is typically 48000, but has
also been known to be 32768. The codec does not specify channel info
either, and it's pretty much always used with one mono channel.
However, since it appears that libavcodec expects both sample rate and
channel count to be handled by either the codec or container, I have
made the decision to allow multiple channels interleaved, which as far
as I know has never been used, but it works fine here nevertheless. The
accompanying raw format has a channels option to set this. (I expect
most users of this will not use multiple channels, but it remains an
option just in case.)

This patch will be highly useful to ComputerCraft developers who are
working with audio, as it is the standard format for audio, and there
are few user-friendly encoders out there, and even fewer decoders. It
will streamline the process for importing and listening to audio,
replacing the need to write code or use tools that require very
specific input formats.

You may use the CraftOS-PC program (https://www.craftos-pc.cc) to test
out DFPWM playback. To use it, run the program and type this command:
"attach left speaker" Then run "speaker play <file.dfpwm>" for each file.
The app runs in a sandbox, so files have to be transferred in first;
the easiest way to do this is to simply drag the file on the window.
(Or copy files to the folder at https://www.craftos-pc.cc/docs/saves.)

Sample DFPWM files can be generated with an online tool at
https://music.madefor.cc

. This is the current best way to encode DFPWM
files. Simply drag an audio file onto the page, and it will encode it,
giving a download link on the page.

I've made sure to update all of the docs as per Developer§7, and I've
tested it as per section 8. Test files encoded to DFPWM play correctly
in ComputerCraft, and other files that work in CC are correctly decoded.
I have also verified that corrupt files do not crash the decoder - this
should theoretically not be an issue as the result size is constant with
respect to the input size.

Signed-off-by: Jack Bruienne <jackbruienne@gmail.com>

XvMC was last relevant over 10 years ago, if ever. There is no reason to
use it today.

Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>

U. Artie Eoff authored 3 years ago and Philip Langdale committed 3 years ago

Current listed maintainers for vaapi plugin are
not reponsive and/or currently active in the
ffmpeg community.  Thus, vaapi plugin patches
(and qsv plugin) have generally gone ignored or
lost in the ether for too long.

Remove Gwenole Beauchesne from vaapi maintainer
who has not been active since 2016.

Current alternative maintainer for vaapi is Mark
Thompson whom has not been active since
March/April 2021.

Therefore, add Haihao Xiang to vaapi maintainer
who's primary role is FFmpeg development with a
focus on the vaapi and qsv plugins.  Haihao has
over a decade of media experience and many years
of FFmpeg development experience, amongst other
media frameworks.

The additional patch for adding Haihao as qsv
plugin maintainer has been submitted previously:

https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210608141134.27448-1-zhongli_dev@126.com/



This will help FFmpeg to continue to be the leading
multimedia framework by allowing these plugins to be
actively improved, enhanced, and maintained for existing
and future HW platforms.

Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>

Signed-off-by: Zhong Li <zhongli_dev@126.com>

Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>

Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>

SMVJPEG stores frames as slices of a big JPEG image. The decoder is
implemented as a wrapper that instantiates a full internal MJPEG
decoder, then forwards the decoded frames with offset data pointers.
This is unnecessarily complex and fragile, not supporting useful decoder
capabilities like direct rendering.

Re-implement the decoder inside the MJPEG decoder, which is accomplished
by returning each decoded frame multiple times, setting cropping
information appropriately on each instance.

One peculiar aspect of the previous design is that since
- the smvjpeg decoder returns one frame per input packet
- there are multiple frames in each packets (the aformentioned slices)
the demuxer needs to return each packet multiple times.
This is now also eliminated - the demuxer now returns each packet
exactly once, with the duration set to the number of frames it decodes
to.

This also removes one of the last remaining internal uses of the old
video decoding API.

AMV is a hard-coded (and broken) subset of AVI. It's not worth sullying
the existing AVI muxer with its filth.

Fixes ticket #747.

Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>