How to show an image by a new window by providing char sequence?

Hello guys,

in order for me to understand videostreams correctly, i need to know if threre is a way to not save a file into lets say .PNG et ceter and to then open it, but to open a live window that shows a char * sequence in memory, which contains picture data. Is that even possible to do somehow?

Thats what i meant: (Pseudocode)
char buf[10e5];
recv_bytes(buf, 10e5);
displayPictureBySeq(buf, 10e5);

i then expect displayPictureBySeq to open a window which displays the picture.
If buf changes, the changes to the Window should be written to the display like a video.

Does somebody know the answer for this?

Thank you for your help in advance

Last edited on
Image formats like JPEG and PNG do not store "raw" pixel data. In order to get the amount of data down to a "manageable" size, they use compression. Video formats are even more complex, because they use similar techniques as JPEG or PNG for intra-frame (within a frame) compression, but additionally use inter-frame (in-between subsequent frames) compression techniques!

So, if your char* array contains JPEG or PNG data (or some sort of video data), then that is not "raw" pixel data, but a compressed bit-stream! This must be decompressed first, using the matching decoder, in order to restore the original "image pixels" (or video frames).

In order to get an idea of how image compression works, have look at the JPEG encoding here:

Because image formats like JPEG and PNG are very complex (and video formats even more so!), you certainly do not want to implement the required decoder (de-compressor) in your own code, but rather use one of the existing and well-tested libraries...
Last edited on
If creating a Win API specific app there are Windows libraries for dealing with compressed image data. GDI can't do it, GDI+ can. So can DirectX.

There is also the Windows Imaging Component.

Using "generic" 3rd party libraries, kigar linked to a couple, makes it easier to cross-platform an app.
Just showing pixel data on screen in Windows is dead simple.
Basically you just call StretchDIBits.

It is writing a codec that would present a bigger challenge. Of course you don't have to implement it on your own, but that's the most interesting part of the project, at least in my opinion.

I don't think it would be insurmountable, especially given that you control both encoding and decoding. You could, for example, choose to implement only the most essential parts of H.264 or a simpler codec and get a workable result.

If one set out to "implement the whole standard" they might find their work cut out.
Last edited on
Topic archived. No new replies allowed.