f



misc: MPEG...

well, as I have discovered, the MPEG1 spec (ITU-T H.262-2000) is freely 
available.
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 
codec.
all the same basic technologies, except far more minimalistic headers and 
encoding rules.

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:
4:2:0, only;
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 
tables).


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 
work ok.

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...

or somerthing...



0
cr88192
7/23/2007 6:57:13 AM
comp.compression 4696 articles. 0 followers. Post Follow

1 Replies
401 Views

Similar Articles

[PageSpeed] 28

"cr88192" <cr88192@hotmail.com> wrote in message 
news:e2b88$46a451f0$ca83a8d6$28538@saipan.com...

> well, as I have discovered, the MPEG1 spec (ITU-T H.262-2000) is freely 
> available.
> this is cool in any case.
>
>
> was reading over this beast...
> looks like a hassle to implement...

I have been modifying the MPEG Software Simulation Group code.
They have MPEG-1 and MPEG-2 encode and decode source.
It is less highly optimised than ffmpeg is, but it's much smaller,
better commented, and easier to understand.

I have also found Brent Beyeler's bbtools to have parsing code
that's reasonably easy to understand and re-use. 


0
Pete
7/23/2007 2:40:42 PM
Reply: