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."

31 comments

  1. No no no! by Anonymous Coward · · Score: 0

    You should be writing your video codecs for LINUX, so we don't have to pay for ANYTHING when we leech movies.

    1. Re:No no no! by kzadot · · Score: 1

      Hmmm.. All the codecs I needed to make mplayer work, end in .dll and live in /usr/lib/win32. What could this mean?

      Ok... Pointers to "How to write codecs for linux" then please?

    2. Re:No no no! by Trelane · · Score: 1

      V4L/V4L2 (Video 4 Linux, Video 4 Linux 2). Ask google about it.

      See also, ALSA and OSS.

      Regarding your Win32 bit, I dunno what the deal is on your machine. I only see win32 in conjunction with Mozilla source, Java, and various wines on my machine. That, and my distro doesn't know anything about 'mplayer'. Maybe this is a wine-wrapped Windows Media Player (which would definitely explain the reliance on DLLs). I use Xine, mpg123, and others.

      --

      --
      Given enough personal experience, all stereotypes are shallow.
    3. Re:No no no! by sir99 · · Score: 1
      Mplayer is another project like Xine, but tends to be more capable. I doubt any distros package it, something with the license I think. It's quite easy to build from source though.


      The DLLs are used to play files that it wouldn't know how to read otherwise. Personally, I like Mplayer a lot better than Xine.

      --
      The ocean parts and the meteors come down
      Laid out in amber, baby.
    4. Re:No no no! by Sibelius · · Score: 1

      Huzzah! Viva Magyarorszag!

    5. Re:No no no! by Trelane · · Score: 1

      Ja, I finally found it at freshmeat.

      It looks like it supports DLLs amongst other sorts of libs, so I guess it can directly import Windows-only codecs? Sounds like a nifty idea. Niftier idea, though, would be for the friggin' developers to develop for Windows and Linux. [Or just Linux. ;)

      --

      --
      Given enough personal experience, all stereotypes are shallow.
    6. Re:No no no! by domninus.DDR · · Score: 1

      No, I think the DLLs they mention are specific ones they have converted or something, I dont remember. But when I went to thier site to download (www.mplayerhq.com I think), they had (a link to) a specific package of codecs to go into /usr/lib/win32/. It had in bold/caps/italics that these codecs wouldnt work in win32.

  2. suggestion by tps12 · · Score: 5, Funny

    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)
    1. Re:suggestion by Anonymous Coward · · Score: 0

      Good going mods, just when he gets modded appropriately due to his trolling, he cracks jokes and you slashbots him up.

    2. Re:suggestion by Dahan · · Score: 2

      Sounds like you misunderstand moderation... you moderate posts, not people. His post is funny, so it should be modded as such. If he posts a troll, fine, mod it as troll. Seems like you're the slashbot, with your attitude of wanting to mod down anyone you disagree with or dislike.

  3. going to say the obvious by seann · · Score: 2, Funny

    Why not try to do a Linux version, with a linux capture source.
    You could even fake it, by maping /dev/videoIN to ~/.pr0n/rawvideofile
    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.
  4. Try DirectShow by Cecil · · Score: 3, Informative

    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.

  5. On Linux... by WasterDave · · Score: 5, Insightful

    Yeah, I know you want to do it on Windows, but hear me out - I'm doing this at the moment.

    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/~ostre 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.

    Make your codec spit out YUV4MPEG too then pipe it into mplayer http://www.mplayerhq.hu/homepage/, with some distinctly non challenging flags ... so something like "mycodec | mplayer -vo x11".

    Easy peasy, and no shithead API's.

    Dave

    --
    I write a blog now, you should be afraid.
  6. Do a static file transform first. by crapulent · · Score: 3, Informative
    It appears that you have little experience working with Windows. If this is the case, then I suggest you start out with a simple file transform application. Read an encoded AVI, write the decoded AVI out in a RAW format. This will give you the ability to view the output of your codec in a media player without having to delve too much into COM objects and all the other Windows programming stuff.

    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:

    This section describes how to write a transform filter, defined as a filter that has exactly one input pin and one output pin. To illustrate the steps, this section describes a hypothetical transform filter that outputs run-length encoded (RLE) video. It does not describe the RLE-encoding algorithm itself, only the tasks that are specific to DirectShow.

  7. Try contacting author of VirtualDub? by Anonymous Coward · · Score: 0

    VirtualDub - a very cool and very free Win32 video player - supports VFW, at least on the capture side. IIRC, VirtualDub started as a college project too. The author might be willing to share some tips to a fellow academic-type as to how he wrangled the VFW issue. If not, I bet he'd at least point you in the right direction. It's worth trying at least, it'll only take you a minute to send an email.

    Disclaimer: I am not associated with VirtualDub so I can't make promises on behalf of its author!

  8. Responses to everyone (9/3/02 21:00 PST) by Gldm · · Score: 1, Informative

    On writing for linux instead (anonymous 1, Seann):

    Problems with this are
    1. I don't use linux.
    2. I have no desire to use linux.
    3. I have some but probably not enough experience using linux in the past to get something like this to work.
    4. I'm not aware of any standard capture and playback API for linux, though I will look up video for linux for a possible later port.
    5. Even if I get it working on linux, 99% of the people who'd want to use it don't use linux for encoding.
    6. BSD rules. But it still sucks for video as much as linux. =)

    If you can show me a linux API that I can use in less than 300 hours of fumbling around that works with the wintv go, radeon vivo, and gainward geforce4 ti4400 vivo in my test systems as capture devices, then I'll consider it. If it involves delving through kernel rebuilds and obscure device creation and such, forget it.

    On using Directshow (Cecil, crapulent):

    I have researched this and am reasonably confident I CAN produce a directshow filter (since I've already made one for the basic transform that works). However, if you'd care to read my original post more closely, I mentioned that premiere, virtualdub, and avicap all used VFW, and NOT directshow. I do agree that propigating old standards is horrible and should be done away with, but if I want any kind of apps to be able to use this for testing and real world applications, I have to interface with them. They all use the VFW interface, unless you count Graphedit, and I won't even go there. If you can think of a stable encoding app that actually uses directshow filters, please let me know.

    On doing static transforms first (crapulent):

    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. Transforming isn't a problem.

    The problem comes from the "read an avi" part. I don't know how to use the API to get data from the avi, and that's my original question. As for directshow, no apps use it, so even if I wrote a filter, it would be useless for anything but accelerated decode in players, which is pointless without something encoded in the format first, which I can't do.

    I do actually have a working directshow filter right now that implements the base transform, but it only works with graphedit, which likes to crash every few seconds no matter what I'm using.

    On using transcode (WasterDave):

    This sounds interesting and useful. I will look into it, thanks. Oh and yes I do know what 4:2:0 YUV is. =)

    On emailing virtualdub's author (anonymous):

    I tried this once I think, maybe I'll give it another shot as I think it was a long time ago now.

    On huffyuv being slashdotted (anonymous):

    Good. It'll save me the trouble of driving over to berkeley and slapping him with a printout of his own code.

    Other stuff:

    I've come across this book
    http://www.amazon.com/exec/obidos/tg/detail/ -/0471 310158/qid=1031113475/sr=8-1/ref=sr_8_1/102-492848 4-5485757?v=glance&s=books&n=507846
    and ordered it. I hope it's helpful, but if anyone knows another book that is I can use all the help I can get at this point. If anyone from xiph's video project can give me some tips, I do visit your IRC server from time to time, and I'd really appreciate any help you can give. Ditto anyone from xvid, though I don't think you guys have an IRC server that I know of.

    --

    Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!

    1. Re:Responses to everyone (9/3/02 21:00 PST) by cpeterso · · Score: 2

      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.

    2. Re:Responses to everyone (9/3/02 21:00 PST) by Gldm · · Score: 1

      I mean random data as in values that fit the range (-128 to 127) that pixel values would fall into when stored as bytes in memory. So basicly snow. I'm sure if viewed it would look awful, but yes it will compress in a lossy codec, and just look awful. 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" so I'm not sure what I'm gonna do with it yet. I don't know how to protect myself. Oh and I have inter-frame compression, just not in the way current codecs like the mpeg family do. I have a completely different design.

      --

      Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!

    3. Re:Responses to everyone (9/3/02 21:00 PST) by Anonymous Coward · · Score: 0

      WDM capture apps

      http://www.iulabs.com/eng/index.shtml

      http://www.digtv.ws/html/virtualvcr/index.php

      http://faq.arstechnica.com/subcat.php?i=540

      Write your codec for WDM and use a VfW wrapper

      http://virtualdub.org/docs_vfwwdm

      http://faq.arstechnica.com/link.php?i=1287

  9. Try again (feeling less bloody minded). by WasterDave · · Score: 2

    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.
  10. Example by Anonymous Coward · · Score: 0

    Ogg Theoria: http://www.theora.org/theorafaq.html
    http://www.t heora.org/cvs.html
    Tada!

  11. How to timestamp your code by yerricde · · Score: 2

    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:

    1. Package your source distribution as a gzip'd tarball.
    2. Compute the MD5 or SHA-1 hash of that tarball.
    3. Send the ascii-armored hash to a digital notary, which will digitally sign it and date it.
    4. Save your hash.
    5. When accused of plagiarism, verify the notary's signature. Now you have proof that you sent that file's hash on that date, which proves in turn that you possessed the file on that date.
    --
    Will I retire or break 10K?
  12. 16-bit VfW Developer's Kit available at ... by Anonymous Coward · · Score: 0

    ... the Microsoft web site. While 16-bit, there appear to be C++ headers and source included.

    FTP

    1. Re:16-bit VfW Developer's Kit available at ... by Gldm · · Score: 1

      Thank you for this link. I had searched for it before but all the links I found had basicly said "VFW is dead, use DirectShow. -- Love, Microsoft."

      --

      Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!

    2. Re:16-bit VfW Developer's Kit available at ... by steveha · · Score: 2

      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
    3. Re:16-bit VfW Developer's Kit available at ... by Gldm · · Score: 1

      How'd you do that? I can't even really tell if huffyuv is 16bit or 32bit. Where do you check?

      --

      Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!

    4. Re:16-bit VfW Developer's Kit available at ... by steveha · · Score: 2

      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.

      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 .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.

      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
  13. linux api by oliverthered · · Score: 1

    The easiest way is to write a windows codec, Xine, mplayer &co can use windows codec.

    So windows is the standard API for linux ...

    --
    thank God the internet isn't a human right.
  14. This book may be helpful... by Anonymous Coward · · Score: 0

    Practical Digital Video With Programming Examples in C -- by Phillip E. Mattison
    ISBN 0-471-31015-8

    1. Re:This book may be helpful... by Gldm · · Score: 1

      Yup, it is so far. I got it a few days ago. I found it and ordered it between when I wrote the original post and when slashdot got around to putting it up. Thanks though.

      --

      Introducing the new Occam Fusion! Now with sqrt(-1) fewer blades!