hello,
Am Mittwoch 31 August 2005 09:29 schrieb IOhannes m zmoelnig:
B. Bogart wrote:
Thanks for the suggestions.
I'm not sure about using a mpeg for the following reasons:
#1. was does the interframe compression thing work, in other words how does it compare when seeking to a quicktime with photo-jpg codec?
without buffering pre-calculated b-frames or p-frames, you can not seek to them, only to the i-frames which always contain a fully coded picture. the b and p frames only save the difference to that picture.....
#2. I'm damn confused about the seeking (see below)
as chris has pointed out, interframe compression can be a crux. however: solution a: make each frame a keyframe (should be possible with the encoder of your choice) solution b: don't care about keyframes at all, use an external tool to create a TOC of your mpeg, so that the decoder knows where to look for keyframes (mpeg3toc of the mpeg3-utils package) and load the toc-file into Gem and seek the file.
usually you dont need a toc to seek to the i frames. in an mpeg stream, a sequence is stored in a gop, a group of pictures. that one looks like: IBBPBBPBB and always repeats. inside the reader it should be possible to address the gop's directly, so that you can directly seek to the next / previous i-frame. b-frames are bi-directional encoded, meaning that you can seek to them as well, as long as you have the previous frames "at hand", but still they require some more decoding work than plain i-frames.
for example, there is a nice software tool to cut endcoded mpeg videos without recompressing them. of course, you can only cut at the boundaries of a gop, thus it is called gopchop: http://outflux.net/unix/software/GOPchop/ maybe that gives some ideas how a seek could be implemented....
of course, solution b is more cpu and disk intensive, so you might still want to avoid it. it relies on libmpeg3 (imo libmpeg1 is unusable anyhow)
mfg.ads.r IOhannes
greetings,
chris