delta frame in uncompressed avi?

[compusic]

I just use flash 8 to export uncompressed avi file(24bit color). but after import such avi files into premiere pro 2 or final cut pro 5, btw the hardwares are top ones, both systems respond very slowly, it seems the systems are not powerful enough to handle those files. on pc system, after Premiere trying to playback the file for some times, it's often said "memory is too low".

After some checking, I have found that the avi files have only one keyframe and all the others are delta frames. that's the cause!!! since I compare with other uncompressed avi files with all the frames are key frames. all-key-frames avi files have no such problem! I think the editing softwares have to calculate every frame except the first one - the key frame, and that put a very heavy load to the system, is it right?

here is the question, is avi file with delta frames really uncompressed or lossless?

This reminds me another thing. that's HDV Intermediate Codec.

there's no editing system can deal with native HDV native codec easily, it's usually converted to HDV Intermediate Codec, something like a uncompressed all-key-frame format. is it right?

btw, anyone know how to let Flash 8 export all-key-frame avi? even I set all the frames to key frames in Flash 8, the file exported still has only one key frame, and all the others delta frames.

thanks in advance.

[stegre]

I think it probably IS all uncompressed keyframes, but the other apps are confused because of different ways of representing the fact that it's "uncompressed". Open and re-save your file with VirtualDub or VirtualDubMod - do not use "Direct Stream Copy" - use "Full Processing" instead - but set the Compression to "uncompressed" (it'll actualy be just about as fast either way and WILL be a lossless operation). Then try working with the new file instead.

[compusic]

I'm sure the avi that Flash exported has only one key frame, others are delta frames, such frames have only difference from the key frame. maybe in such a way this avi is also lossless compressed. the problem is the editing softwares have to calculated those delta frames when playback, and which put a very heavy load on cpu. It's similar to editing native HDV codec file.

I just want to find a way to let Flash export I-Frame-only avi, don't want to use the open-and-save methods to convert every file once again. since I have too many such files. anyway thanks for your suggestion.

I think it probably IS all uncompressed keyframes, but the other apps are confused because of different ways of representing the fact that it's "uncompressed". Open and re-save your file with VirtualDub or VirtualDubMod - do not use "Direct Stream Copy" - use "Full Processing" instead - but set the Compression to "uncompressed" (it'll actualy be just about as fast either way and WILL be a lossless operation). Then try working with the new file instead.

[stegre]

No, look here. Below is a listing showing two nearly identical AVI files, deltaframes.avi and keyframes.avi. I actually reproduced your problem, i.e. the former "incorrect" one was originally made using SWF export. The latter one is "fixed". They only differ by only three bits, namely the bits that mark frames 2, 3 and 4 as keyframes in the AVI index area. The frame contents themselves are identical uncompressed images; they are really all "keyframes". So it's really an SWF export bug that marked them wrong.

http://www.headbands.com/gspot/misc/deltaframes2.png

http://www.headbands.com/gspot/misc/keyframes2.png

http://www.headbands.com/gspot/misc/files.png

You would only need to patch three bytes (that's in my case; "one for each frame but the first", in general) to fix your files, "in place" and instantly (that's not many bytes) and losslessly. But without those bits, the editing apps you are using are getting hopelessly bogged down. The same thing happens when you try to "seek" in a file with one keyframe, even just to view it.

I don't know of an app that will perform the instant fix you need, namely rewriting the index "in place" with every frame marked as a keyframe. Perhaps another forum member knows of something that might do the trick. It's certainly possible in theory and would be extremely quick.

VirtualDub and VirtualDubMod apparently do have the "smarts" to do this. They actually have a "re-create index option" checkbox. So they are capable of re-creating the index chunk altogether, from scratch.

But apparently, when I enabled that checkbox it still failed to do anything useful at all if the existing index that is there "looks valid". But then I manually chopped the index off the end of "deltaframes.avi" altogether, resulting in the file you see as "no_index.avi", above. When I reloaded that into each of the above two apps, they both instantly recreated a correct index: all keyframes. VirtualDubMod does it "silently" and VirtualDub does it with a warning first but the result was the same. In fact it's exactly what you need. The frames are all untouched but now they're all keyframes. But to use that trick you'd need a utility to first cut jut the right amount off the end of each file.

I don't know why VirtualDub and VirtualDubMod apps apparently ignore "rebuild index" unless the index is corrupt or missing - you'd think the apps would just rebuild it if you "asked". Or at least they'd have another option called "force rebuild of index". That would solve your problem. But as far as I can see, at least those two apps won't do it. Again, maybe some forum member can suggest something that will.

All three of my test files are zipped together here in an 8KB zip (http://www.headbands.com/gspot/misc/delta_key_files.zip)(not a typo: those three AVI's, 2.7MB total, zipped down a single 8KB zip - nice, huh? ;) Anyway, you can d/l that and feel free to check out any of the above yourself.

[compusic]

Opps... you are right I think. thanks a lot.

we can tell whether a frame is key frame by looking at its size, right? since all the delta frames have the same size as key frame (and we can also calculate how large a uncompressed frame should be), then we know in fact they are all key frames, right?

I just used latest version virtualdub to open-and-save the avi, in full processing mode, and the new file is all-key-frame, the index is rebuilt! but the size is a little different from the origional one. btw, I can't find the option "re-create index option". maybe we are using different version?

another question, I'm not sure whether uncompressed avi should use RGB color mode only?

well, now we can make sure that Flash has bugs. and further more, I just find maybe another bug. if Flash export uncompressed avi in 32 bit color depth, the size of the file is strange, it's very larger than what it should be.

[setarip_old]

I can't find the option "re-create index option"That's because it's fairly well hidden ;>}

When you select "Open Video File" from the "File" dropdown menu, put a checkmark next to "Popup extended open options"...

[compusic]

Hi, setarip_old, thanks.

even after I checked the "re-derive keyframe flag" option, I think it's the same as "rebuild index", in direct stream copy mode, the exported avi still has only one key frame. :mad:

It seems only in full processing mode, the frame type index will be rewritten.

then as for open-and-save a uncompressed avi, do the two modes - "direct stream copy" and "full processing" result in the same video data (excluding the frame index)?

[stegre]

even after I checked the "re-derive keyframe flag" option, I think it's the same as "rebuild index", in direct stream copy mode, the exported avi still has only one key frame. :mad: Yes, that's the box I was referring too, and yes, that's exactly what I was saying. Seems it does nothing if the index is OK. Perhaps it means "do you also want to re-derive keyframes if the index must be rebuilt?". I remember Avery Lee discussing that building an index was easy but getting keyframe flags was not (well, in this case it is). But anyway, that would explain why the option wouldn't "re-derive" any keyframes unless I manually chopped off the index as I described above. Then it rebuilds the whole index and adds the proper keyframe flags to it as well.

It seems only in full processing mode, the frame type index will be rewritten. Yes, that's what I was saying in my first post. Because then it's "encoding", so in general it has to make a whole new index. The fact that "encoding" uncompressed RGB into uncompressed RGB, which amounts to just lossless byte-for-byte copying, is besides the point as far as it's concerned.

then as for open-and-save a uncompressed avi, do the two modes - "direct stream copy" and "full processing" result in the same video data (excluding the frame index)?Yes, I think it is for this purpose you could say "yes" to that, though I haven't confirmed it's absolutely byte for byte identical. Any differences would be incidental things in the header - the frame data itself I'm sure will be indentical, and that's really what matters.

I mean, yes, usually you should think of "direct stream copy" as "fast and lossless" and "full processing" as "slow and lossy". But for an uncompressed AVI, it's really just reading and writing the same data, they should be functionally equivalent operations.

Anyway, on entirely different note, I found a way you can get around the Macromedia bug and avoid this whole issue. Just don't choose "uncompressed", but when it asks you for an encoder in the next dialog choose "uncompressed". Sounds confusing but look at the screenshot below. I think this is a good workaround for the bug - it worked fine when I tried it.

http://www.headbands.com/gspot/misc/export.gif

[compusic]

Hi,stegre, thanks a lot for your smart method.

that method also solves the problem of the strange size of 32bit color avi.

[squid_80]

Yes, that's the box I was referring too, and yes, that's exactly what I was saying. Seems it does nothing if the index is OK. Perhaps it means "do you also want to re-derive keyframes if the index must be rebuilt?".
It's not bypassed because the existing index is OK, it's skipped because the source video is uncompressed.