Getting the 'stats' from an avi

[Soepy]

Hey..

I'm trying to resize some divx avis (yes, I know recompressing's a no-no) to xvid. I was wondering if it's possible to get the stats from the divx, which would save me from doing a first-pass when compressing to xvid.

Maybe it's not clear. I have a divx.avi which I want to recompress to a smaller xvid (to fit on a CD; don't ask). This divx already has I B P frames and I want to use this information: from these frame types/sizes in the divx.avi I want to generate a xvid stats file. Using this generated stats file I can then create my final xvid, doing only the second pass.

Does a tool of this kind exist? Or can it be made? Does a divx compressed AVI contain information that could yield a useful stats file for xvid?

I'll make the tool if I get all the information needed ;)

S.

[communist]

Does a tool of this kind exist?
No - at least I dont know of any such tool.

[Soepy]

Allow me to brain storm a little. The stats file seems to contain the following info, one frame per line:

<type> <quant> <kblk> <mblk> <ublk> <length> <hlength>

type: i, b or p
quant: quantizer to be used for this frame
kblk: number of blocks compressed as Intra
mblk: number of blocks compressed as Inter
ublk: number of blocks marked as not_coded
length: total size of the frame
hlength: size of the header

AFAIK, obtaining the type of the frame, it's size and the number of blocks from an existing AVI is pretty trivial. Now I wonder if the rest of the information needed for a complete stats file can be derived from this?

Would it be OK to derive the quantizer from the type of the frame? For example, use a quantizer 2 for I and P, and 4 for B frames. What about only settings 1 type of block to be used? So the fields (kblk,mblk,ublk) will be one (X,0,0), (0,X,0) or (0,0,X)* depending on the frame type, with X being the number of blocks per frame. This leaves the header-length to be derived. This might be the only codec dependent information needed (the rest can be derived from the indexes in the AVI).

Correct me if I'm wrong.

S.

(maybe this is not the best place to discuss this, but since I didn't find any detailed info on the _text_ stats file in these forums, it might still be useful for somebody in the future)

* frames very small in size might be marked by not_coded

[stephanV]

If you fix the quantizer to 2 and 4 you will get wrong frame lengths, as it is based on what q2 gives for the frame length. Furthermore, setting P frames to only one type of block is completely wrong.

The method is wrong anyway since you are forcing DivX frame type decisions on XviD, which can be quite different from one another. And whats more, parsing the DivX file probably wouldnt be that MUCH faster than doing a 1st pass with XviD to justify all the things that you are messing with now. :)

[Soepy]

But how precise should the data in the stats file be? I mean, obviously the final (after 2nd pass) frame length can differ from the lengths mentioned in the stats file.

What information in the stats file is taken literally, and what information is merely used as a guideline?

[stephanV]

I doubt there is any non-vital information in the stats file. Frame types are probably copied, frame lengths are (probably) used for rate control, but block types I'm not sure off.

I still don't understand why you would wanna do this. It would hardly be any faster and highly sub-optimal.

[Soepy]

On my PC a first pass still takes 30+ minutes. Parsing an existing AVI to generate a stats file should take a couple of seconds, if there's no need to decompress the video.

The question should be: does it beat single-pass quality? If it doesn't, then it's definately pointless, but if it does, you get the single-pass speed with somewhat better quality.. Might still be interesting.

[stephanV]

Right, in your case it would be a lot faster, I'm just thinking in another way...

But, your way would completely throw off and frame type decision and rate control. If it would be better than single pass is highly doubtful, it might even be worse.

[Soepy]

Both frame type and rate control (frame size) will actually be preserved! The frame type of an existing divx/xvid AVI can definately be reused. And the current frame sizes do already identify simple / complex frames, so they should come in handy during a second pass. Scene changes will also be retained, since the original compression will have key frames at those points.

[squid_80]

But you're using different source material. That's why it would be better to start from scratch and run two passes.

[Soepy]

But you're using different source material. That's why it would be better to start from scratch and run two passes.

What do you mean by different source material? The AVI I want to extract the stats from is exactly the one I want to re-encode?

[ChronoCross]

He's kinda probably trying to reencode something he downloaded off the web. PErhaps it was too big for his tastes. That's the only situation in which a person will not have the source material and will be reencoding to 1 CD avi.

[squid_80]

What do you mean by different source material? The AVI I want to extract the stats from is exactly the one I want to re-encode?
The information that you're talking about extracting (frame size/types etc.) was generated by analyzing the original uncompressed source. You don't have that source, you only have the compressed output so those stats probably wouldn't be optimal for it.

[Soepy]

The information that you're talking about extracting (frame size/types etc.) was generated by analyzing the original uncompressed source. You don't have that source, you only have the compressed output so those stats probably wouldn't be optimal for it.

True.. Although, you must admit, they're very similar! A complex scene in the source (ie dvd or whatever it was) will probably still be complex in the compressed avi. So the frame sizes of the compressed avi are most likely still applicable.

Who knows exactly what information from the stats file is used in the second pass? (I don't think all of it; I saw some comments in the xvid code.) And also, is that information used literally or just as a guideline, ie. by providing wrong info, will you end up with an ugly encode, or with a corrupt one?

S.