Quote:
Originally Posted by geekmaster
I agree that option b is "better" for a TOOL. My "codec" (dither and bitpacking) was designed to be rendered by extremely small and simple C code useful for a monolithic tutorial. Packing 8-bits/byte was really just a tiny evolution from packing two 4-bit pixels already used in the animation demos.
My video transcoder and player are just a tiny evolutionary step beyond my existing animation demos, designed to be easy to understand and reuse. Rather than designing a new container, a "real" player should just squeeze them into an output "driver" of a standard player (like ffmpeg or mplayer) that can play standard media containers (like MKV). But then of course, my super-simple codec just happens to compress extremely with with gzip because the dithering aligns to 8-bit (character) boundaries.
|
So in a nutshell, You think providing a stand-alone application is a good idea.
One that is the evolution of other stand-alone demos, which individually provide the capability to parse either standard media at really low rates and/or specially encoded media at device specific rates.
I'm not afraid getting my hands dirty on some "faux gui" work in the medium term. after all there is a video driver for petes sake, putting stuff on the screen is not a problem.
I am all for this. I personally would like to see more esoteric uses of the medium - I'm thinking real-time fft (on a 3!) and resulting graphics
but that is another story and my headache. Thanks for the input, I'm feeling more confident this is actually attainable and possibly useful, and certainly impressive.
Time to get the welding gear out for some wave action