well, as I have discovered, the MPEG1 spec (ITU-T H.262-2000) is freely
this is cool in any case.
was reading over this beast...
looks like a hassle to implement...
actually, once again (like JPEG), the decoder looks like a lot more work
than the encoder.
lots of options. some of the complexity of JPEG is removed, and new
complexity is added.
oh well, luckily in this case, I was more intending on an encoder, and if I
really wanted to be lazy, I could just emit pure I-frames (in effect, using
it as a crappy replacement for my current MJPEG AVI output).
with a decoder, it is almost a mystery that people don't reject all input
except that conforming to a specific set of options (or, actually, maybe
this was originally part of the idea?...).
if writing a decoder, would probably make sense to examine existing streams
to figure which options are typically used (for computers, I would suspect
4:2:0 progressive to be common).
me wondering partly, once again, why there can't just be a 'simple' video
all the same basic technologies, except far more minimalistic headers and
well, probably doesn't matter much (what gain would I get by rolling my own?
nothing is solved by this, would have to supply my own stupid player...).
well, maybe not too much worse than with MJPEG, where I keep ending up how
to explain to people how to get the files to play (and my output is large
and comparatively low quality...). seemingly people are bewildered by these
cryptic 'unknown codec' messages...
current idle/hypothetical thought:
stripped down hybrid of MPEG and JPEG.
so, what this could look like, about:
full-frame only (non-interlaced, no windowing/slices/...);
probably only I and P frames;
far more minimalistic headers;
I would probably make both huffman and quantizer tables customizable though
(not as simple, oh well). would do it like ogg-style codecs, namely, needed
tables are stuck at the start of the stream and possibly periodically
redefined (I have slight doubt as to the quality/ratio impact of using fixed
or, most useful, I just make a crude encoder (and, if I write a decoder,
rejecting anything not conforming to my strict and arbitrary rules...). (ok,
partly maybe it is just it being tedious reading the spec...).
well, this is just assuming I really have that much need.
I rarely need to get video out of my apps anyways, and for now, mjpeg avi's
none the less, I wanted the spec in the first place to hopefully output
something more useful (the other option, ogg/theora, looking to cause
similar confusion to mjpeg).
well, there is always worse...