Allwinner would be pretty foolish not to fully fund this endeavour (including stretch goals). They couldn't do it themselves this cheap. They'd make up the costs in new sales faster from FOSS-minded devs in no time flat and they'll have minimal recurring dev costs in the long run.
> "Allwinner would be pretty foolish not to fully fund this endeavour"
Why would they fund it? If they saw the potential benefits, they could probably open source their own closed source drivers and avoid this Kickstarter being needed, or at the very least provide documentation to speed this work along.
Patents for what? Algorithms? I've heard similar arguments/excuses made before, I'd like to understand if there's any legal precedence for them, or if it's more of a hypothetical risk.
Lastly, with the 'supply of documentation' approach, does this (to your knowledge) carry the same legal risks?
The third-party is probing into a black box. They have no idea what is or isn't there. So it could be plausible deniability on the side of the chipmaker.
How about documentation then? Let's say Allwinner releases C header files, plus high level descriptions of what each function does. Do they still maintain plausible deniability if the hardware design infringes on patents?
It means they don't need to get lawyers involved to check for any licencing gotchas from other non-free code in the tool chain. They might see it as a liability or reveals other tangentially related proprietary details of their tooling. There may not be much formal documentation, and if there is it would likely need to be combed through, updated, translated, etc.
Even without getting lawyers involved, I don't see how they could do any of the above tasks for less than the price of this Kickstarter.
> "It means they don't need to get lawyers involved to check for any licencing gotchas from other non-free code in the tool chain."
They don't need to open source the whole toolchain, just the parts of the code they own/wrote themselves. For the parts of the toolchain they can provide documentation (writing it out if this documentation needed to be created/revised) to fill in the missing pieces.
> "I don't see how they could do any of the above tasks for less than the price of this Kickstarter."
You seem to be overlooking that reverse engineering hardware drivers is a hugely inefficient process. People only do it out of necessity. Furthermore, the Kickstarter has set modest goals of enhancing the work that has already been done (MPEG2 acceleration, etc...), the end result is not a driver that can be used for more general purpose graphics acceleration (e.g. no OpenGL driver). That's not to say it isn't a good step forward, I welcome it, but you should be aware that there's a long road ahead after the work for the Kickstarter has been completed. If you don't believe me, look at the ongoing work being done by the Nouveau team.
Couldn’t that path just be left without acceleration, being it’s a less complex codec to begin with, usage is not growing, and the data sources are likely smaller to begin with (no 4k for example)?
It's still useful for some applications. ATSC digital broadcasts in the U.S., for example, are in MPEG-2, as are the signals provided by many cable companies. I have an HDHomeRun Prime, and purchased the MPEG-2 HW Decoder license[1] for my Raspberry Pi 3 to make things a bit smoother.
Not if you want it to do anything else at the same time, and not if you need de-interlacing of the 1080i streams that half the over-the-air channels use.
Since they want to do hardware x264, are there any patent issues they'll have to deal with, or will that be included in the cost? I didn't see anything listed on the Kickstarter page.
What kind of hardware is this that makes it usable for encoding/decoding mpeg2/h264/h265? Is this something that should be exposed as a general programming target instead of a set of video specific APIs?
the device is generally single-function for each codec, with the decoding pipeline implemented in actual hardware. Unless you were able to express your kernel as a data transform used in a common video codec and express your I/O data as pixels, you're unlikely to accelerate a general purpose task this way.
To me this is a no-brainer.