return values of dgdecode.dll

[Doom9]

I'm trying to write a .NET wrapper for DGDecode. I'm mainly using the GetPic and GKnot source code as examples. I noted that openMPEG2Source returns a pointer to a VIDEOINFO struct, but I seem to be unable to find it on MSDN. All I get is a DShow element (http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/htm/videoinfostructure.asp) that doesn't have properties like width and heigth so I figure it can't be that. So where can I get a definition of the return value of openMPEG2Source?

Similarly, what is the format of the char buffer that getRGBFrame returns?

[neuron2]

VideoInfo is an Avisynth concept. Refer to the avisynth2.h header file for its definition.

There is a zip file in the DGDecode 1.3.0 source zip called GetPic.zip. It is a simple code showing how to use getRGBframe to create a standard BMP file of a specified frame, given a D2V file. From that you can determine the buffer layout.

The DGVfapi source code may also be useful, because it uses the same interface.

[Doom9]

It is a simple code showing how to use getRGBframe to create a standard BMP file of a specified frame, given a D2V file.Unfortunately I already had a look at that but seeing that it uses its own way to write a bitmap rather than the GDI CreateBitmap function (where the format of the color data buffer is defined), I still have no way of knowing in what way that char buffer contains color information. From the horizontal flip in the main method I conclude that the color information is placed line by line and that we're dealing with 3 bytes per pixel, but there's no way of knowing in which order one line is written.. could be pixel1R, pixel1G, pixel1B, pixel2R, pixel2G, pixel2B, etc, or any permutation of the RGB order.. or all R, G, and B components after another.

So any additional information would be really helpful.

I also have a followup regarding the VIDEOINFO structure.

Gknot 0.35 defines the return value of openMPEG2Video as a pointer to the following struct:


TVideoInfo = record
width, height, // width=0 means no video
fps_numerator, fps_denominator, num_frames: integer;
pixel_type: word; // UNKNOWN=0, YUY2=2, BGR24=3, YUV422=32
audio_samples_per_second, // 0 means no audio
num_audio_samples: integer;
stereo, sixteen_bit, field_based: boolean;
end;
This does by no means match what's defined in avisynth2.h, where that struct contains different type definitions (e.g. fps_numerator is unsigned), and some variables that are simply not there in GKnot. And none of the properties definied in the header file are there either. So how can this still work?

[Doom9]

I managed to open a d2v using the following VIDEOINFO struct

[StructLayout(LayoutKind.Sequential)]
public struct VIDEOINFO
{
public int width, height;
public uint fps_numerator, fps_denominator;
public int num_frames;
public int pixel_type;
public int audio_samples_per_second, sample_type, num_audio_samples, nchannels;
}
which is quite different from what GKnot uses (I basically left out all the methods defined but kept everything else and matched the variable types used to types available in C#).

I also managed to read out a frame but the colors are off. I assumed that the R, G and B values for each pixel would be placed immediately after another (pixel1R pixel1G pixel1B pixel2R pixel2G pixel2B ... pixelNR pixelNG pixelNB)

Here is the result of my reader:
http://forum.doom9.org/dgdecode.png
and here is the same frame as read out by GKnot (or via AviSynt)
http://forum.doom9.org/avisynth.png

Initially my frames were rather green, but it turned out I accidentally switched the G and B components. My guess it something is wrong with the R component but I can't quite pinpoint the source of the error.

I have attached the source code of my d2v reader.

[Doom9]

ahh never mind the colors.. I swapped R and B components and now it looks like it should.

So, in conclusion, getRGBFrame returns the data as an ascii char (8 bit per character)/byte array, the 3 color components of a pixel grouped together, starting with B, then G then R. Is that order intentional considering the method has RGB in its name? It seems this reordering of the color components is also done in GKnot (it was the comment about RGB -> BGR reordering that got me to try reordering in my code)

[neuron2]

Sorry, I've been out all day.

Yes, that struct will work. You're missing some more fields at the end, like image_type, but if you don't need them...

Yes, the pixels are as you discovered. The reversal I assume stems from big-endian/little-endian differences.

>I have attached the source code of my d2v reader.

Don't you have the power to approve it? :)

[Doom9]

Don't you have the power to approve it?I figured there's no need for the attachment anymore seeing that I solved the problem.. but it'll be available as part of the MeGUI source package eventually. For now I still have a performance issue to solve.. I'm marshalling byte per byte, so I have horizontal*vertical*3 marshalling operations and marshalling is not exactly the most efficient operation in the managed world. But I guess I better turn to the Interop newsgroup to find a more efficient way to turn my IntPtr return value from getRGBFrame into a byte[] using one single marshal operation, and then figure out a way to construct an image from that byte buffer.

[Doom9]

Interestingly enough, BRG is the format GDI uses. I managed to directly create a managed Bitmap from the pointer dgdecode returns (well, there's a wrapper pointer but that's it). So basically I get from char* to Bitmap in 3 lines of code, where one line is the declaration of the external dll function.