Hi all,
Thanks for the wealth of info.
I made a couple mpegs and TOCs and it works fine. I decided to create GOPs of only a single frame to force the lack of interframe compression.
So it *almost* works in Gem, almost eh...
Well I can seek only forwards, not backwards.
Lets call the current frame Fc and the previous frame Fp:
if Fp < Fc seeking works fine if Fp > Fc the mpeg immediatly jumps to the first frame and sticks on the first frame for as long as this condition is true.
Maybe I need a 2 frame GOP to get bidirectionality?
I've been unable to seek any mpeg at all without using the mpeg3toc thing, Including my single frame GOP, they just scrub forward as you twiddle the frame number.
We'll I'm close anyhow. off to look at lvs-studio...
Thanks again,
B.
chris clepper wrote:
On Aug 30, 2005, at 10:05 PM, 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?
You want to avoid interframe compression at all costs. In order to grab a random frame in an interframe codec the nearest previous keyframe must be found and all interframes between it and the requested frame are decoded. You could get lucky and hit a keyframe or be very unlucky and hit the frame right before one.
Interframe compression techniques are used almost exclusively for final content distribution (web, DVD, ATSC). Acquisition and production codec never use this with the exception of HDV (which is MPEG2).
Aside: What id the different between mjpeg and photojpeg as a video codec?
mjpeg is motion-jpeg which is for interlaced two field video. Each field (50 or 60 per second) is a compressed with jpeg techniques.
ffmpeg reports my sequence of jpegs as "mjpeg"...
It is mistaken if your sequence is single progressive frames, which it almost certainly is.
cgc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list