Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update ffmpeg archive? #8

Closed
naps62 opened this issue May 24, 2020 · 4 comments
Closed

update ffmpeg archive? #8

naps62 opened this issue May 24, 2020 · 4 comments

Comments

@naps62
Copy link
Contributor

naps62 commented May 24, 2020

I noticed this package has a hardcoded archive pointing to a build of ffmpeg

I'd be interested in updating that. mostly because I was trying to do h265, and my guess as to why I fail to find that encoder is because it didn't exist in this version

I'm not sure how I should go about this though. I have ffmpeg built on my own machine, but there's probably some requirements regarding compatibility?

@naps62
Copy link
Contributor Author

naps62 commented May 24, 2020

I was able to get this to work on my own fork

I built an ffmpeg archive similar to the existing one, but using the latest ffmpeg commit (same as what I had installed globally on my system

To get h265 support though, I had to link against libx265.so. I guess this makes the solution not portable at all

Would it be possible to make these linking options defined as arguments to the crate?

e.g.:

[dependencies]
ffmpeg-dev = { version = "...", external_libs = ["x265"] }

Which would do the equivalent of adding --enable-libx265 and the corresponding linking options to libx265.so

Not sure if this technically possible, as I don't know much about these corners of Rust

In the meantime, I hardcoded these changes to my own fork so I can keep going with my work

@colbyn
Copy link
Member

colbyn commented May 26, 2020

@naps62 Okay fine with me. Regarding linking the x265 I usually try to avoid system dependencies, so everything in this crate is designed to self contained.

Anyway, I need to get back to an assignment...

But to be brief. I'm fine with adding optional dependencies, but I'd personally prefer for these dependencies to be likewise self contained and statically linked into the resulting binary.

So this entails build time stuff, which can be done. If you're interested in making this work, see #7 for an example using my x264-dev crate. I.e. reuse the build.rs file from that crate.

@colbyn
Copy link
Member

colbyn commented May 26, 2020

Interesting how you wanna do everything the ffmpeg C API. Personally I prefer to use the x265 C API directly, and ffmpeg for only container level stuff and general decoding (since the x265 C api is really easy).

I.e. decode in ffmpeg then send the decoded pixel buffer to x265.

Best of luck with your project! Only the brave get into the ffmpeg C api :)

@naps62
Copy link
Contributor Author

naps62 commented May 27, 2020

I.e. decode in ffmpeg then send the decoded pixel buffer to x265.

This makes a lot of sense. I actually didn't know for sure this was feasible, so I didn't really consider it. I'm very new to ffmpeg (or at least the libav side), and currently just trying to get a few base demos work to get me going, before moving to my real goals.
But I'll definitely look into this option

as for the overall post, I ended up having to move to ffmpeg4_ffi with dynamic linking for now. It turns out that --enable-libv4l2 (which I also needed, in addition to x265) wasn't working by itself. Maybe other dependencies were required as well.

I'll definitely be looking into this later though, as I'd prefer having a fully contained binary at the end.

Thank you

@naps62 naps62 closed this as completed Jun 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants