6639f02b80
Bug caught by clippy:
error: offset calculation on zero-sized value
--> src/filter/filter.rs:98:33
|
98 | let pad = Pad::wrap(self.ptr.offset(self.cur));
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[deny(clippy::zst_offset)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#zst_offset
The problem is that `AVFilterPad` is zero-sized:
#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct AVFilterPad {
_unused: [u8; 0],
}
which is in turn due to `AVFilterPad` being an opaque type in
`libavfilter/avfilter.h`:
typedef struct AVFilterContext AVFilterContext;
typedef struct AVFilterLink AVFilterLink;
typedef struct AVFilterPad AVFilterPad;
typedef struct AVFilterFormats AVFilterFormats;
Doing pointer arithmetic on an opaque (incomplete) type doesn't work. We have
to use the proper FFI calls to obtain info on individual pads. The API has to
be tweaked a bit; hopefully it doesn't break user programs (if it does it
should only break bugged ones...).
Fixes #20.
This is a fork of the abandoned ffmpeg crate by meh..
Support for different FFmpeg versions are guarded by feature flags:
| FFmpeg version | lavc version | corresponding feature |
|---|---|---|
| 4.3.x | 58.91.100 | ffmpeg43 (current default) |
| 4.2.x | 58.54.100 | ffmpeg42 |
| 4.1.x | 58.35.100 | ffmpeg41 |
| 4.0.x | 58.18.100 | ffmpeg4 |
| 3.4.x | 57.107.100 | none |
See my metadata project for an example of targeting multiple versions of FFmpeg.
A word on versioning: major and minor versions of this crate track major and minor versions of FFmpeg, e.g. 4.2.x of this crate has been updated to support the 4.2.x series of FFmpeg. Patch level is reserved for bug fixes of this crate and does not track FFmpeg patch versions.
If you have problem building this crate, please have a look at the wiki.
Please realize that this crate is in maintenance-only mode for the most part. Which means I'll try my best to ensure the crate compiles against all release branches of FFmpeg 3.4 and later (only the latest patch release of each release branch is officially supported) and fix reported bugs, but if a new FFmpeg version brings new APIs that require significant effort to port to Rust, you might have to send me a PR (and just to be clear, I can't really guarantee I'll have the time to review). Any PR to improve existing API is unlikely to be merged, unfortunately.
🤝 If you have significant, demonstrable experience in Rust and multimedia-related programming, please let me know, I'll be more than happy to invite you as a collaborator. 🤝