Linux encode support ... please? Pretty please...
Really, really need a decent codec for intermediate work on my Linux boxes. Right now the best I can hope for are directories of .png files which, for a 90 min show is... well, think of 24 FPS over that time and you get the idea.
If there's a way to do this via WINE or Crossover that would be great too - and I'm quite happy to help in any way I can. Linux has some great pro-level software (for free) like Natron which would benefit from this greatly and at this price even the tightest-walleted (?!) of us can cough up!
I come from a Mac background but I shoot with a loosely knit team of amateur and semi-professional videographers on Canon 5Ds (or similar) with Magic Lantern which gives us passable but not marvellous footage provided there's enough light.
My prehistoric background from over three decades ago is rooted in film which is why I have a ridiculous eye for quality. Ideally, we'd all be shooting on RED or even BMCC at 4K but you can't have it all when everyone works from home and there simply isn't the money shooting weddings and short commercial stuff. Ironically, most clients wouldn't know the difference anyway!
I do though and there is where the problems start. 🙂
Pretty much everything has to be fed through NEAT video (which is utterly magical and quite affordable compared when balanced against the cost of a high-end camera). This adds a potentially lossy stage unless I output to frames (PNG) and even at 720p that's pretty large amounts of data. I think we're running about 100Gb (about 1Gb per min) on the current job which is a something I did for a friend of ours.
Although I come from Mac (After Effects and Hitfilm - [silly name but good value]) I've retrained to use Natron which is a Nuke-like compositor that allows me to use OFX plugins (NEAT being one of them) to do any compositing. I also used Blender for our 3D work but again, that outputs to frames, not video, primarily in case the job craps out part way into a multi-hour render!
My problems started when I went for a professional level editor to splice everything together - with the separately recorded audio - and NO sync slate at a live performance! (I've become quite the lip reader.) Only Kdenlive, Blender and Lightworks (which is Freemium, 720p max) support this facility.
Kdenlive is really rather good now but still a bit flaky using frames with proxies (and the default proxies are too nasty to be usable). Blender it is then - I'm downloading the 2.78a release now to finish this job off since despite its promise, four days of (repeatedly) lost work through crashes etc. are enough to tax the best of us!
Does that help? 🙂
Thanks for the intro!
The major problem with Linux in terms of multimedia is a lack of common APIs to develop for. Developers just slam ffmpeg into whatever multimedia project they're working on. Which is nice except if you're a codec developer not working on ffmpeg. Other than that there is libVLC which is not mature enough yet to be used for an editing application (lack of necessary functionality apart from just playback), and GStreamer, which is nice but also didn't become THE multimedia framework on Linux.
This also has become the case on the Mac too unfortunately when Apple decided to close off the new QuickTime for codec developers, so writing codecs on the Mac is also almost impossible. QuickTime 7 is still there though, but who knows for how long.
Windows still has VFW, which is archaic, but gets the job done.
So I would gladly write an encoder for Linux, if only there was a framework for which I could do that. But there isn't. The closest I once came up with was a filesystem-based DPX compressor, which compresses/decompresses DPX files on the fly.
You mentioned PNG sequences. Using the MagicYUV codec won't net smaller files than PNGs, the benefit would be to be much faster than PNG at around the same/slightly bigger files.
Yeah - I'm I/O bottlenecked - file size is less of an issue now that storage is cheap(er) than it used to be. What I need is throughput - and a stream is far more efficient at that than a spinning hard drive having to seek and wait for each file which (potentially) could be anywhere on the platters.
I feel for you in the lack of standardisation - and "Yay Apple!" for closing another door in everyone's face! The reason I'm on a Linux box (except for the fact that Mac workstations are too damn slow) is that my 3 year old machine blew a cog and can't get inside to repair it. Not a happy bunny...
Seems like poor LibVLC is stuck in the mud somewhere... *sigh*
Am I to assume you can't "plug" your codec into ffmepg and make that the commercial version? I wish I knew more about this but I'm sorta gridlocked with an old brain and not a lot of time to squeeze new stuff in. 🙂
No, that is not possible (plugging a codec into ffmpeg), or at least, not without releasing the source code of the codec (and - though out of the question - even that wouldn't fully work, as ffmpeg uses C, while the official MagicYUV implementation is C++).
Also, reading a similar discussion on the ffmpeg mailing list ( https://ffmpeg.org/pipermail/ffmpeg-devel/2008-December/044479.html ): "FFmpeg is not meant to be a wrapper for third-party libraries."
So with that I'm afraid that free software video editors using ffmpeg have to live with whatever ffmpeg provides.
EDIT: However as ffmpeg is free software, you have the freedom to implement whatever codec you would like to suit your needs 🙂 - sorry for the harsh pun, just had to vent a bit the frustration on the lack of interfaces/standards to develop for 🙂
Sorry for the sarcasm, I meant no offense (hope it went through).
To be fully correct though, it would be possible to make some sort of bridge inside ffmpeg which would allow it to load third-party codecs and usem them to encode/decode (which is different than plugging in a codec directly into ffmpeg). It would be quite a bit of work though, and I'm certain the ffmpeg team wouldn't really like the idea.
I did - try HuffYUV I think - couldn't read it back in the previewer but I think Kdenlive might - I'm back in Natron juggling with different containers (and way outside of my comfort zone)!
For speed (and what little remains of my sanity) I think I'll just run ProRes 422 (MQ) and be done with it. I've already wasted far too much effort and hair on this.
Yes, the sarcasm was well received! 🙂 I really do understand your frustrations.