Add additional memory management documentation

[voxeljorge]

First off thanks for all the work putting this together, clearly no small effort. As a developer that is fairly familiar with ffmpeg as a CLI tool as well as Go, this tool looks really interesting for those cases where the CLI just isn't enough.

One thing that feels like it is particularly missing for me is clear documentation on memory management. When to call free/unref/etc is not super clear if you aren't familiar with the ffmpeg API.

Also, generally including more godocs would be nice. The examples provide a great starting point but for anything more complex it's a bit of guess work. For example I would like to write muxed data into memory buffers so I can handle transport in the rest of my go code. I didn't see an example so I took a guess and made an output format context with an empty string target and fed it an in context similar to the custom io example for reading. Having some documentation on AllocOutputFormatContext would have made this behavior clearer.

[asticode]

First off thanks for the kind words ❤️

I do agree with you regarding the lack of documentation for some subjects like memory management. Even worse, I don't think examples are consistent enough in the way they manage memory 🤔 Regarding your use case, unfortunately I don't see another way than adding examples at the same time as people need the information as it's hard to cover all use cases.

I'll try adding something regarding memory management (as well as make examples more consistent in that matter) and I'll also add a custom io muxing example 👍

[voxeljorge]

One idea for the godocs would be to just reference the main underlying ffmpeg API in use. It is possible to guess a little but anything to reduce the guessing game would be really helpful.

In general the ffmpeg API itself is not amazingly well documented either so this isn't only an issue with this repo. Definitely not an easy one to solve.

[l0rem1psum]

My advice is to ditch the idea of trying to manage the lifecycle of C objects in Go at all.

This means a 1-to-1 direct translation of C APIs without many ergonomics consideration (e.g. no need for use of methods, just straight function calls). In such a case, users of Go APIs can look up the corresponding C API docs when needed without ambiguity.

If, however, use cases for a more ergonomic and idiomatic APIs arise, higher level abstractions can be built upon those simple binding layers by people with more knowledge of the libav APIs.

In short, borrowing the naming convention from the rust community, the idea is to have a libav-sys (lower level) and a libav-go (higher level).

[asticode]

FYI I've done the following:

• I've added links to the ffmpeg's doc for each method allowing developers to see quickly the doc for both C methods and fields
• I've corrected examples to show how to properly unreference both packets and frames
• I've added a Patterns section to the README that only describe how to properly call Alloc(), .Unref() and .Free() for now
• I've added a Custom IO Muxing example

I'll close the discussion for now but feel free to keep commenting, I'll reopen it if needed 👍