DCT and XviD

[serbersan]

Syskin you have a private message that you haven't read

[Wbtz]

Hey -h thanks. So all I have to do it use xvid_stat to get what i want without modifying the source code yah?
Cool! thanks!

[Wbtz]

Hello,

Have even more newbie questions. Sorry but my supervisor asked me to find out the answers myself. I am quite unfamiliar to mdular C/C++ projects.

-h, my supervisor is insistent that I write each macroblock to an individual bitstream. I concern is where I should modify the source (which file to modify) as i am totally lost in the source. My guess is that the file to modify is mbcoding.c? Do i also need to modify the functions in encoder.c for each of the different types of frames? (I think i will use the macroblocks after compression by RLE and VLC) What form would the macroblock take in now? It is no longer a matrix of coefficients right? Any demarcations of the end or start of a macroblock?

You mentioned that each macroblock is stored in memory before writting to the bitstream and this is writting is done by another application (perhaps like virtualdub?) Does this mean everytime I modify the source. I compile it then use virtualdub to encode a video to test?

Lets say I have modified the source code of xvid. How do I compile to test it using Visual C++ or lets say on Sun? I just know its got something to do with the "build".

I am clueless about how I should even start modifying the code and debugging it. Appreciate it if someone could shed some light. Thanks!!

[-h]

-h, my supervisor is insistent that I write each macroblock to an individual bitstream.

This will slow down encoding 10-fold due to file system overhead. But he'll find that out :)

My guess is that the file to modify is mbcoding.c?

Yes, each macroblock can be written individually from MBCoding(). However since macroblocks don't fit into a fixed number of bytes, along with each macroblock you will have to store the number of bits actually used to store it. That way, you know when the macroblock is finished and you can load the next one.

Do i also need to modify the functions in encoder.c for each of the different types of frames?

If you want a single file which contains frame headers and such, then files for each macroblock, you will have to alter encoder.c to suit. The individual frames should be OK, you'll just have to worry about the parts which call Bitstream..() functions, like BitstreamWriteVolHeader(), BitstreamPutBits(), etc., anything that does that is writing to the bitstream, and you would have to trap that and redirect it to a file.

I won't kid when I say this is a tremendous amount of work.

(I think i will use the macroblocks after compression by RLE and VLC) What form would the macroblock take in now? It is no longer a matrix of coefficients right? Any demarcations of the end or start of a macroblock?

There are no markers as to the start and end - it is just a stream of bits.

You mentioned that each macroblock is stored in memory before writting to the bitstream and this is writting is done by another application (perhaps like virtualdub?) Does this mean everytime I modify the source. I compile it then use virtualdub to encode a video to test?

You can if you'd like, but the file writing you're talking about should be done inside xvidcore itself. VirtualDub will have nothing to do with it, as it will just store in an avi the buffer that xvidcore returns to it. In your case, since everything that would normally go into the buffer is going to separate files, there will be nothing for VirtualDub to write.

Lets say I have modified the source code of xvid. How do I compile to test it using Visual C++ or lets say on Sun? I just know its got something to do with the "build".

In Visual C++, you just need to open the .dsp file in xvidcore/build/win32/ and compile like a normal VC++ program. That will create core.lib, a library file (not a program). To then use it, you have to compile another program which makes use of that core.lib file. That program could be the vfw dll, or xvid_stat.

It can be compiled on Sun thanks to portab.h and the separate makefiles, but I have no idea as to how. I've never used a Sun. Well I have, but never in development.

-h