You can instruct ffprobe to output the metadata in JSON (-print_format json), removing the need for manual parsing. Although you already utilize "-print_format compact" - was this a deliberate choice?
I originally wanted to use json for parsing, however the unmarshalling would have required a large struct with fields for all the metadata ffprobe outputs. I thought that using "-print_format compact" resulted in a simpler parsing approach. Correct me if I'm wrong there, I'm still relatively new to Go.
Thanks for sharing the link to your project. I'll try to implement the stdout buffering with "bytes" rather than doing it manually.
You don’t need fields for everything that’s printed, you only need to specify fields of interest, the rest are automatically discarded. You can also use alternative json parsers like fastjson that are more dynamic instead of upfront.
Did you look at joy4[0] (or now joy5[1])? These wrappers expose a lot of ffmpeg functionality in a Go idiomatic style. You could easily write a GIF generator using them.
I’m not familiar with FFMPEG. How hard would it be to reproduce bits of it in Go natively? Why does everyone need to sub process out to this one library.
Yeah, it feels like something I don’t want to replicate all of (because I probably won’t need all of it), but it would also be nice to be able to use the bits I need from Go without depending on C. :/
Side note the image-rs crate in the Rust ecosystem has no external dependencies and can encode and decode animated gifs and a variety of other image formats, 100% rust https://github.com/image-rs/image. At my startup we use this in a lambda to process user-uploaded images, with great success.
The image-rs crate has some serious design flaws and it has put me off trying to do any image processing in Rust at all. It may support many formats, but the basic image type is complete garbage. It’s conceptually a 2D array of some specific pixel type—which means that any pixel value must carry with it colorspace information. I can’t honestly recommend it to anyone.
The issues I’m talking about are acknowledged as design flaws / mistakes if you start browsing the GitHub issues.
Sounds like typical Rust... They're well-meaning people in general, but they usually lack domain knowledge in the particular field they're trying to reinvent in Rust, so the end result often looks like a square-shaped wheel.
Glad it worked out for you—it seemed like the features are there for basic image conversion, but try to do something a little more sophisticated and you run into some severe design limits. Here is the kind of underlying problem I’m talking about:
Why would you do something more sophisticated though, versus just using your own pixel data structures and the converting if/when you want to load/save. This is supposed to be a stand-in for image magic, not a panacea for doing image processing in Rust. Maybe start an image-processing crate if that is your interest?
README shows various structs with zero exported fields, and example code working with those unexported fields which don't make sense and won't work unless directly placed in this package. There are other problems like non-idiomatic snake_case naming. I guess this is OP's golang learning project? (To be clear, making mistakes in the beginning is completely fine.)
That's correct. I like to use go for image processing and wanted to apply some of the algorithms I made to video but did not find a simple way to do so. I set out to make a video I/O module.
I'm currently fixing all the non-idiomatic problems as well as adding some getters for each struct. Thanks for the feedback!
There's quite a bit of overhead in execing and piping data from ffmpeg. If performance is a concern, then using the C ffmpeg API is a better bet(see pyav for a good example of this) . Cool project though!
I'll fix that up when I have some time. Thanks for pointing it out. Most panics come from when something went wrong with the ffmpeg subprocess. I didn't know that there is a way for the user to handle errors coming from this subprocess.
Even if an error is unrecoverable by the caller, that doesn't mean it should be a `panic`. If a server is running your code in a request handler, a `panic` would normally terminate the entire process. That's never what anyone wants.
Made a push adding getters for relevant fields and making field names uppercase in the Options struct. Don't know how long it takes for pkg.dev to update, but the issue should be resolved now.
Also, you don't have to do manual stdout buffering. Have a look at ReadChapters function in here: https://github.com/MawKKe/audiobook-split-ffmpeg-go/blob/f95... (fyi it's my own repo)