ffmpeg example

[lattice0]

I'd like to write an ffmpeg example. I already have some ffmpeg decode code that almost works with retina, but do you think the dev-dependencies would have too many deps? Because ffmpeg brings too many deps:

├── ffmpeg-next v4.4.0-dev (/home/dev/orwell/deps/rust-ffmpeg-1)
│   ├── bitflags v1.3.1
│   ├── ffmpeg-sys-next v4.3.4 (/home/dev/orwell/deps/rust-ffmpeg-sys-1)
│   │   └── libc v0.2.99
│   │   [build-dependencies]
│   │   ├── bindgen v0.54.0
│   │   │   ├── bitflags v1.3.1
│   │   │   ├── cexpr v0.4.0
│   │   │   │   └── nom v5.1.2
│   │   │   │       └── memchr v2.4.0
│   │   │   │       [build-dependencies]
│   │   │   │       └── version_check v0.9.3
│   │   │   ├── cfg-if v0.1.10
│   │   │   ├── clang-sys v0.29.3
│   │   │   │   ├── glob v0.3.0
│   │   │   │   ├── libc v0.2.99
│   │   │   │   └── libloading v0.5.2
│   │   │   │       [build-dependencies]
│   │   │   │       └── cc v1.0.69
│   │   │   │   [build-dependencies]
│   │   │   │   └── glob v0.3.0
│   │   │   ├── clap v2.33.3
│   │   │   │   ├── ansi_term v0.11.0
│   │   │   │   ├── atty v0.2.14 (*)
│   │   │   │   ├── bitflags v1.3.1
│   │   │   │   ├── strsim v0.8.0
│   │   │   │   ├── textwrap v0.11.0
│   │   │   │   │   └── unicode-width v0.1.8
│   │   │   │   ├── unicode-width v0.1.8
│   │   │   │   └── vec_map v0.8.2
│   │   │   ├── env_logger v0.7.1
│   │   │   │   ├── atty v0.2.14 (*)
│   │   │   │   ├── humantime v1.3.0
│   │   │   │   │   └── quick-error v1.2.3
│   │   │   │   ├── log v0.4.14 (*)
│   │   │   │   ├── regex v1.5.4 (*)
│   │   │   │   └── termcolor v1.1.2
│   │   │   ├── lazy_static v1.4.0
│   │   │   ├── lazycell v1.3.0
│   │   │   ├── log v0.4.14 (*)
│   │   │   ├── peeking_take_while v0.1.2
│   │   │   ├── proc-macro2 v1.0.28 (*)
│   │   │   ├── quote v1.0.9 (*)
│   │   │   ├── regex v1.5.4 (*)
│   │   │   ├── rustc-hash v1.1.0
│   │   │   ├── shlex v0.1.1
│   │   │   └── which v3.1.1
│   │   │       └── libc v0.2.99
│   │   ├── cc v1.0.69
│   │   ├── num_cpus v1.13.0 (*)
│   │   └── pkg-config v0.3.19
│   └── libc v0.2.99

should I do it as a separate project? If so, should I put it inside retina or should I do another separate repo?

[scottlamb]

A ffmpeg example would be a very welcome contribution, thank you!

should I do it as a separate project? If so, should I put it inside retina or should I do another separate repo?

I like the idea of having the examples be their own crates inside the same repository. I happened to read a comment by axum's author the other day suggesting the same thing for another reason:

Currently we're just using cargo's built-in "examples" feature which has the unfortunate downside of using the same Cargo.toml as axum itself, which makes it hard to see what the dependencies actually are. I'm starting to think that making each example an isolated crate, in the same repo, will make things much more clear.

What will your example's output be? an uncompressed video file, or something else?

[lattice0]

I was going to make an example that just decompresses a video but don't even save it, but we can add more features, maybe saving the frames, I don't know. It's mainly for testing. I'm gonna start now on another branch

[lattice0]

I forgot to ask which OS you use, because I don't know if it will compile due to ffmpeg dependencies. I tested on Ubuntu 20.04 and I had to install the dependencies in the readme. I can help you with ffmpeg if you want and I have a Dockerfile that builds ffmpeg for android/linux but I don't know if it's easy to make it work for macOS.

You see that I included my own ffmpeg-sys crates because it's hard to find someone that wants to maintain them with my adds (hardware decoding support)

[scottlamb]

Writing quickly; haven't had a chance yet to look through your example.

Personally I use both Linux (various Debian-based setups) and macOS. I think it's inherent to using a C library that it won't be quite as easy to compile everywhere as retina itself, which is fine.

As an example of how to integrate retina and ffmpeg, IMHO it might be best to use the most common ffmpeg crate forks if hardware acceleration isn't central to the example. That'd make it more focused and widely applicable. (fwiw, I also have my own ffmpeg crate moonfire-ffmpeg but I'm not really trying to make it full-featured or encourage wide adoption of it, so I'm not proposing an example with it.)

[lattice0]

Ok, in the future before merging I'll switch to the most used ffmpeg crate

[scottlamb]

I have a draft PR #19 with an example which uses the ffmpeg-next crate to decode the images and dump them to files in .ppm format. Something's wrong with the generated images, though. Not sure yet what the problem is.