Slashdot Mirror
Writing Video Codecs for Win32?
Gldm asks: "I've been working on a video codec as part of a college computer science project, but I've been stuck at an impasse for several months now: I can't figure out how to get video data from the OS to compress or test anything with. All the software applications I have (Premiere, Virtualdub, and AVIcap) want to use Microsoft's Video For Windows API, but I can't find any books on how to get a codec to interface with it. I've tried Microsoft's own docs, but they're not very helpful. The only example source I've found is huffyuv
but it's written and commented so poorly, I can't understand it. I've tried emailing the author but he never replied. I thought it would be simple to do this but apparently VFW is some kind of ancient byzantine labyrinth of messages and function calls and data types I don't understand. If anyone knows a book on the VFW API that still exists and maybe something that very clearly explains exactly how you go about building a DLL please let me know. Or if you have experience programming for this API please please email me."
"I've tried asking my CS department for help, but they barely acknowledge the existence of GUIs and usually have us do everything in SunOS on their ancient 50mhz machines using gcc, which is not practical for this project. Nobody in the department knows any Windows programming and I've been unable to teach myself how to do it. I'm really frustrated because all I need is some kind of pointer to the pixels in a frame, its size and color format, and a pointer of where to put the compressed output."
Homework questions are traditionally posted to Usenet. Try comp.lang.c++, for starters. Don't forget to include a note that you don't read the newsgroup regularly, so would appreciate being CCed via email, so you won't miss any responses. Good luck!
Karma: Good (despite my invention of the Karma: sig)
Why not try to do a Linux version, with a linux capture source. /dev/videoIN to ~/.pr0n/rawvideofile
You could even fake it, by maping
and then create the appropreate compressor from there on.
and when your done
write a video driver to replace the device you made
or some jazz.
I'm a big retard who forgot to log out of Slashdot on Mike's computer! LOOK AT ME.
It's (kindof) a part of Microsoft's DirectX, and is definitely the next generation of Video Codecs. Please, don't proliferate the horrible VFW API any further. Do yourself and everyone else a favour and move to DirectShow.
Microsoft's page is here, and you might also find some useful stuff at this website.
Random and weird software I've written.
Yeah, I know you want to do it on Windows, but hear me out - I'm doing this at the moment.
e ich/transcode/ and I think the command line you want is something along the lines of "transcode -i /dev/dvd -y yuv4mpeg,null -o whatever". RTFM. Oh, the output is a format called YUV4MPEG, google for it, and open it in a hex editor, it's kinda obvious.
... so something like "mycodec | mplayer -vo x11".
For source, a program called transcode will turn just about anything into 4:2:0 YUV. If you don't know what 4:2:0 YUV is, go back to MSDN now.Transcode is at http://www.theorie.physik.uni-goettingen.de/~ostr
Make your codec spit out YUV4MPEG too then pipe it into mplayer http://www.mplayerhq.hu/homepage/, with some distinctly non challenging flags
Easy peasy, and no shithead API's.
Dave
I write a blog now, you should be afraid.
If you really want to write a codec, you don't necessarily have to use the VFW calls. The audio and video codec management under VFW is old stuff, from the 16 bit Win 3.1 days. It's supported through wrappers in DirectX/DirectShow. What you might want to do instead is create a DirectShow filter, specifically a Transform Filter. If you are not familiar with the DirectShow architecture, you will want to read up on this first. Once you are familiar with the terminology (graphs, filters, pins, etc.) then write a transform filter. You can derive it from a base class supplied in the SDK and this will take care of making a DLL that knows how to register itself, etc. The section Writing Transform Filters has all the details in a step-by-step list, including build directions. This page is found through the path MSDN Home > MSDN Library > DirectX > DirectShow > Using DirectShow > Writing DirectShow Filters. From the linked page:
Ok, so I'm feeling less bloody minded. Isn't a direct draw surface a directly addressable piece of memory? How about you get some example code for making the internal codecs render to a DD surface (almost certainly COM, if you're unlucky it may have to be via a dispatch interface), play it back a frame at a time and use that as input?
Dave
I write a blog now, you should be afraid.
I've got a working transform function that's been ok for several months now. I've tested it with random generated data, my athlon xp1800 manages about 150fps. I also wrote SMP support for it so my friend's dual athlon mp1900 gets about 340fps.
When you saying "random data", do you mean truly random images? That doesn't sound like a very typical use scenario. And wouldn't truly random data be impossible to compress?
Also, will your code eventually be available for other people to download and try out? Your project sounds very interesting. I started experimenting with image compression, with the idea of creating a video codec that did not use inter-frame compression. Eventually, some other hobby projects took higher priority, so I haven't done much more work.
cpeterso
I'd like to publish source eventually but I'm wary of having it stolen and then getting sued by someone else claiming it's "theirs"
Don't worry. Here's all you have to do to prove that you possessed a file:
Will I retire or break 10K?
VfW is 16-bit. That's one of the things that sucks about it.
I wrote a VfW video capture driver once, and the cleverest thing I did was to have it start up a 32-bit process to do all the real work.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
It's simple: if you are compiling anything VfW for Windows ME, 98, 95, or older, it's 16-bit code. If you are compiling for anything NT-based: NT, 2000, or XP, then it would actually be 32-bit code. But of course VfW is very deprecated.
.exe file that was built 32-bit. It was called something like "pump.exe". The 16-bit code simply called the function that starts up a new process, passing in the filename of the pump. Then I could pass messages to the pump, and it would handle them. The trickiest part was getting pointers that I could pass from 16-bit code to 32-bit code; all I remember right now is that I used the thunking tools to do that. Once I had the pointers I passed them in messages. I had one message that meant "capture a frame of video into this buffer here", for example.
You don't really need to check. If you wanted to check, you would have to check the include files that you are compiling with, and the makefile (see which compiler and what compile switches it is using).
If you were asking how I made part of the driver 32-bit, I had a special
For a codec, you probably don't want to do anything that complicated. I did it because I was writing a capture driver, and I really needed to be in 32-bit mode to talk to that particular hardware.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely