none
Why does the System Device Enumerator report different list for the Video Compressor Category on a Windows 7 x64 for the 32 and 64 bit versions?

    Question

  • I have existing DirectShow code that works fine in 32-bit mode but will not work in 64-bit mode.  While trying to solve my problem I noticed that if I run both version (64 & 32) of graphedt.exe in the Windows 7 SDK and select the Video Compressors Categories I get different list of available filters.

    32-bit

    1. Cinepak Codec by Radius
    2. DV Video Encoder
    3. Intel IYUV codec
    4. Intel IYUV codec
    5. Microsoft RLE
    6. Microsoft Video 1
    7. MJPEG Compressor
    8. MSScreen 9 encoder DMO
    9. TechSmith Screen Capture Codec
    10. WMVideo8 Encoder DMO
    11. WMVideo9 Encoder DMO

    x64

    1. DV Video Encoder
    2. MJPEG Compressor
    3. MSScreen 9 encoder DMO
    4. WMVideo8 Encoder DMO
    5. WMVideo9 Encoder DMO

    I know that the Cinepak codec is only avaliable in 32-bit,  however the dll's for the Intel IYUV codecs, Microsoft RLE, and Microsoft Video 1 codecs do exist in the C:\Windows\System32 folder.  The TechSmith codec is a third-party codec that supports both 32 and 64 bit versions.  When I list the available codecs using the 64 and 32 bit versions of Windows Media Player 12 (uses Media Foundation), I get the same list for both version excluding the Cinepak codec. When I use the versions of DxDiag.exe I get the same lists as graphedt.exe.  Looking at the registry,  both codec version are registered for use by the Video Compression Manager.  The registry keys that register the codecs are found in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc and HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32 for 64-bit and HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\drivers.desc and HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32  for 32-bit.  Looking for the registry keys that are used by the System Device Enumerator, I found the keys HKCU\Software\Microsoft\ActiveMovie\devenum and "HKCU\Software\Microsoft\ActiveMovie\devenum 64-bit"  the 64-bit key is missing the key HKCU\Software\Microsoft\ActiveMovie\devenum 64-bit\{33D9A760-90C8-11D0-BD43-00A0C911CE86}. The GUID {33D9A760-90C8-11D0-BD43-00A0C911CE86} is CLSID_VideoCompressorCategory.  I then export the 32 bit version of the Video Compressor Category registry keys to a .reg file and changed the "devenum" to "devenum 64-bit" and installed the 64-bit keys with the modified .reg file.  The missing filters showed in the list on the 64-bit graphedt.exe.  When I tried to add the filters to a graph, graphedt reported that the filters were not registered.  The list of filters for Audio Compressors for both versions of graphedt.exe are the same and include the codecs register with the Drivers32 and drivers.desc registry keys.  Is there a reason that the 64-bit versions of the missing codecs are not registered?  My code uses some of the missing 64-bit codecs.  The TechSmith codec is registered for both versions and Windows Media Player 12 reports both versions but I can not enumerate it in 64-bit code.  Is there any way to update the registry to enable the missing filters excluding the Cinepak codec?

     

    Friday, April 22, 2011 9:53 PM

All replies

  • Actually the answer is pretty simple: x86 and x64 are separate worlds with their own DLLs, filters, registrtion. A 32-bit  DLL hosting a filter is not good for 64-bit process with a DirectShow graph and vice versa.

    http://alax.info/blog/tag/directshow
    Friday, April 22, 2011 10:00 PM
  • I am trying to use only the 64-bit versions of the filters.  The dll's for the 64-bit codecs exist but are not registered correctly for DirectShow to wrap them using the AVI Compressor filter in the qcap.dll (both versions of this dll exist).  My 32-bit version of my software works correclty and enumerates all the registered 32-bit codecs.  The same code compiled for x64 does not enumerate all of the registered 64-bit codecs.  The versions of Windows Media Player 12 report that the codecs are registered for both versions.  I am not trying to mix 32 and 64 bit codecs, I need the 64-bit version of DirectShow to behave like the 32 bit version of DirectShow and report all of the codecs registered in the "Video Compression Manager".  Both 64 and 32 version report the same audio codecs registered in the "Audio Compression Manager" excluding the Cinepak codec.  My program is a GIS application that would be enhanced by the extended amounts of memory available on x64 platforms.  The program captures frames from both usb and firewire camera sources as well as audio and also automates a video capture of the screen as a video during playback of the frames and other GIS data.  How do I get the 64-bit "Video Compression Manager" to register the codecs for use by DirectShow(x64)?
    Friday, April 22, 2011 10:26 PM
  • Roman's answer still stands.

    I sincerely doubt you have an x64 build of ancient codecs like Cinepak or MS-RLE...

    An x64 process can only load x64 DLLs so only x64 codecs are listed, regardless of whether they are DS filters, DMOs or WinMM codecs.

    I don't know what you mean by "The versions of Windows Media Player 12 report that the codecs are registered for both versions": what did you use to make WMP12 report anything?


    MVP :: DirectShow / MediaFoundation <http://www.riseoftheants.com/mmx/faq.htm>
    Friday, April 22, 2011 10:57 PM
  • Ben, a bit of a focus on Alessandro's sentence:

    An x64 process can only load x64 DLLs so only x64 codecs are listed, regardless of whether they are DS filters, DMOs or WinMM codecs.


    Your application (process) is either 32-bit or 64-bit. The DirectShow subsystem (graph itself, filters, codecs) you are using is loaded into process. As you might have known, 32-bit process can only use 32-bit DLLs, 64-bit process uses 64-bit DLLs only. This stipulates the difference: the codecs that are packages into 32-bit DLLs will be okay for your 32-bit process. They will be registered, listed whatsoever. Same thing with 64-bit codecs but completely independent from 32-bit ones.

    For a 64-bit process it's generally possible to start a child 32-bit process, which will be actually hosting a codec of interest, and use interprocess communication to connect the processes (master 64-bit process and slave 32-bit), but I am not aware of any implementation of this kind. Far easier, more reliable and without performance overhead is to have separate versions of codecs (filters), 32-bit and 64-bit.


    http://alax.info/blog/tag/directshow
    Saturday, April 23, 2011 6:12 AM
  • Alessandro Angeli wrote:
    >
    >Roman's answer still stands.
    >
    >I sincerely doubt you have an x64 build of ancient codecs like Cinepak or MS-RLE...
     
    There is a surprisingly large community still using Cinepak.  I did get the
    codec to compile in 64-bit, but it didn't work, and there was no one to pay
    for the debugging, so there it sits.  Ffdshow includes a reverse-engineered
    version of Cinepak, and it does work in x64.
    --
    Tim Roberts, timr@probo.com
    Providenza & Boekelheide, Inc.
     

    Tim Roberts, DDK MVP Providenza & Boekelheide, Inc.
    Sunday, April 24, 2011 9:13 PM
  • Allessandor, Roman, and Tim,

    I am not using the Cinepak codec, I am using MS-RLE and "MS Video 1" and "TechSmith Screen Capture Codec" (TSCC).  I have a 64-bit version of TSCC from TechSmith.

    If you run the 64-bit version of Windows Media Player 12, right click to view the menu File, View, Play, Tools, Help, and Show menu bar, then click Help, then click About Windows Media Player, a dialog is displayed which has a link "Technical Support Information".  If you click on this link a local file "wmpsupport.htm" is displayed.  When I do this on my machine, a section for "Video Codecs" is produced and contains the following:

     

    Video Codecs

    Type Name Format Binary Version
    ICM Microsoft RLE MRLE msrle32.dll 6.1.7601.17514
    ICM Microsoft Video 1 MSVC msvidc32.dll 6.1.7601.17514
    ICM Microsoft YUV UYVY msyuv.dll 6.1.7601.17514
    ICM Intel IYUV codec IYUV iyuv_32.dll 6.1.7601.17514
    ICM Toshiba YUV Codec Y411 tsbyuv.dll 6.1.7601.17514
    ICM TechSmith Screen Capture Codec tscc tsccvid64.dll 3.0.0.0
    ICM Huffyuv v2.1.1 HFYU    
    DMO Mpeg4s Decoder DMO mp4s, MP4S, m4s2, M4S2, MP4V, mp4v, XVID, xvid, DIVX, DX50 mp4sdecd.dll 6.1.7600.16385
    DMO WMV Screen decoder DMO MSS1, MSS2 wmvsdecd.dll 6.1.7601.17514
    DMO WMVideo Decoder DMO WMV1, WMV2, WMV3, WMVA, WVC1, WMVP, WVP2 wmvdecod.dll 6.1.7601.17514
    DMO Mpeg43 Decoder DMO mp43, MP43 mp43decd.dll 6.1.7600.16385
    DMO Mpeg4 Decoder DMO MPG4, mpg4, mp42, MP42 mpg4decd.dll 6.1.7600.16385

     

    I know that WMP 12 is using Media Foundation, however the codecs MS-RLE and MS Video 1 are VCM codecs but it still list them.  When I use the 64-bit DxDiag, it list the following:

    Video Compressors:
    WMVideo8 Encoder DMO,0x00600800,1,1,wmvxencd.dll,6.01.7600.16385
    WMVideo9 Encoder DMO,0x00600800,1,1,wmvencod.dll,6.01.7600.16385
    MSScreen 9 encoder DMO,0x00600800,1,1,wmvsencd.dll,6.01.7600.16385
    DV Video Encoder,0x00200000,0,0,qdv.dll,6.06.7601.17514
    MJPEG Compressor,0x00200000,0,0,quartz.dll,6.06.7601.17514

     

    These lists should be the same for 64-bit.  This tells me that the codecs are registered correctly and that Media Foundation can us them but the DirectShow is not listing any of the codecs that are registered in the VCM.  I have looked in the "C:\Windows\System32" folder and confirmed that the dll's listed by WMP12 do exist. How do you get DirectShow to use the registered 64-bit codecs that WMP12 says are available?

     

    Thanks,

    Ben

     

    Monday, April 25, 2011 2:46 PM
  • Ben, WMP information is good but it's more a list of registrations and binary versions. What you provided in the starting post of the topic is closer to API (BTW this goes along with data I am aware of - VCM codec list enumerated by ICOpen API, Win32/x64 binaries for a try + source code).

    WMP's tech info list does not mean it would be actually able to play a file using this decoder, does it? And anyway this does not beat fundamental difference between 32-bit and 64-bit codecs outlined above: for a 64-bit process you will have to have 64-bit codec available through 64-bit DLL.


    http://alax.info/blog/tag/directshow
    Monday, April 25, 2011 3:13 PM
  • Roman,

    I used 32-bit version of graphedt to create an AVI file that uses MS-RLE compression.  I then opened the 64bit WMP12 and opened the MS-RLE encoded avi file and it played correctly.

    I downloaded both the 32 and 64 bit versions of EnumerateVcmCodecs, below are the results

     

    64

    E:\Downloads\Microsoft\DirectShow Forum>enumeratevcmcodecs64
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x656c726d (mrle)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msrle32.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x6376736d (msvc)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msvidc32.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x79767975 (uyvy)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msyuv.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x32797579 (yuy2)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msyuv.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x75797679 (yvyu)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msyuv.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x76757969 (iyuv)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "iyuv_32.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x30323469 (i420)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "iyuv_32.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x39757679 (yvu9)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "tsbyuv.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x63637374 (tscc)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "C:\Windows\System32\tsccvid64.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x75796668 (hfyu)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "huffyuv.dll"

    32

    E:\Downloads\Microsoft\DirectShow Forum>enumeratevcmcodecs32
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x656c726d (mrle)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msrle32.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x6376736d (msvc)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msvidc32.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x79767975 (uyvy)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msyuv.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x32797579 (yuy2)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msyuv.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x75797679 (yvyu)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "msyuv.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x76757969 (iyuv)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "iyuv_32.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x30323469 (i420)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "iyuv_32.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x39757679 (yvu9)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "tsbyuv.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x64697663 (cvid)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "iccvid.dll"
    szName
      fccType: 0x63646976 (vidc), fccHandler 0x63637374 (tscc)
      dwFlags 0
      dwVersion 0x0, dwVersionICM 0x104
      szDescription ""
      szDriver "C:\Windows\SysWOW64\tsccvid.dll"

     

    From the listing above the 64-bit version of MS-RLE does exist and it does work in WMP12(x64).  So why can't I use the MS-RLE in a 64-bit DirectShow Filter graph?

     

    Thanks,

    Ben

    Monday, April 25, 2011 3:39 PM
  • I repeated your test and my MS-RLE AVI was playable by both WMP x64 and GraphEdit x64. AVI Decompressor Filter which decoded video, is using internally ICM codec provided by msrle32.dll, which exists in two versions Win32 (in syswow64 directory) and x64 (in system32 directory).

    Your listing shows that you have both versions of the decoder too, so I would suppose that you x64 GraphEdit would play the file (it works for me).


    http://alax.info/blog/tag/directshow
    Monday, April 25, 2011 4:09 PM
  • I understand that the AVI Decompressor Filter is using the codecs internally,  I need to use the compressor for these filters.  So with the codecs existing in both 32 and 64 bit versions and registered as both, why aren't the 64 bit versions exposed as Video Compressors filters the same way the 32 bit versions are?
    Monday, April 25, 2011 5:43 PM
  • Windows Media Player is using MS RLE decoder for playback, GraphEdit uses decoder too (through AVI Decompressor Filter). There is no evidence that 64-bit subsystem provides MS RLE encoding part? I suppose that it just does not exist. Your reference to WMP does not count because it demos decoding part and decoding also works with GraphEdit and other applications.
    http://alax.info/blog/tag/directshow
    Monday, April 25, 2011 6:18 PM
  • You are correct. I still have not proved that the 64-bit compressors are supported, just the decompressors.  So why did the EnumerateVcmCodecs report a value of 0 for the dwFlags member of the ICINFO structure for both 32 and 64 bit versions?  Should the 32 bit version have a value that is not the same as the 64 bit version if compression is not supported?  Also, the documentation for the ICInfo call list the following as a description of the call:

    The ICInfo function retrieves information about specific installed compressors or enumerates the installed compressors.

    This states that is list installed compressors.  Is the documentation incorrect, should is state compressesors/decompressors instead?

     

    Monday, April 25, 2011 6:43 PM
  • I checked one step more, and I think now that MS-RLE compressor does exist, in 64-bit version too. It exists as ICM codec but probably is not registered/enumerated as DirectShow compressor. Why? Perhaps because it's a retired API and it was some decision to not rake over old ashes.

    If you re-download the utility mentioned above and run it with /o /c switches, it will show compressor choices (ICCompressorChoose API) which list MS-RLE as an option in both 32-bit and 64-bit versions.


    http://alax.info/blog/tag/directshow
    Monday, April 25, 2011 10:01 PM
  • I wrote my on dialog based Codec Enumerator and added a button to call ICCompressor and got the same results you did.  Below is the code that creates a display string for a codec and the results from my machine.  I also called ICOpen with modes ICMODE_COMPRESS, ICMODE_DECOMPRESS, and ICMODE_DRAW.  For MS-RLE and MS Video 1 compress is supported.  Why would MS disable the code for x64 when it already works in win32?  If they don't work for x64 because they are a retired API, then why support it in SysWOW64? Also notice in the Win32 results that the system32 versions of the DLL are reported instead of the SysWOW64 versions.

    Looking at the MSDN documentation, it looks like the "AVI Compressor Filter" is the filter that wraps the VCM codecs.  Is this the piece that is missing on x64?

    Is there any way to get someone at MS to look at the code and explain this issue?

     

    typedef struct ICInfoFlagsStrings {
     TCHAR *pName;
     DWORD value;
    } ICInfoFlagsStrings;
    
    static ICInfoFlagsStrings icinfostrs[] = {
     { _T("Quality"), VIDCF_QUALITY }
     ,{ _T("Crunch"), VIDCF_CRUNCH }
     ,{ _T("Temporal"), VIDCF_TEMPORAL }
     ,{ _T("Compress Frames"), VIDCF_COMPRESSFRAMES }
     ,{ _T("Draw"), VIDCF_DRAW }
     ,{ _T("Fast Temporal Compression"), VIDCF_FASTTEMPORALC }
     ,{ _T("Fast Temporal Decompression"), VIDCF_FASTTEMPORALD }
    };
    
    CString FlagsToString(DWORD value)
    {
     int i;
     CString rv;
    
     for (i=0;i<_countof(icinfostrs);i++) {
      if (value & icinfostrs[i].value) {
       if (!rv.IsEmpty())
        rv += _T(" | ");
       rv += icinfostrs[i].pName;
      }
     }
     return rv;
    }
    
    static int fccType = ICTYPE_VIDEO;
    
    CString CEnumerateVCMDlg::GetCodec(int ndex)
    {
     HIC hIC;
     ICINFO icinfo;
     CString rv,fcct,fcch,flg;
    
     if (ICInfo(fccType, ndex, &icinfo)) {
      hIC = ICOpen(icinfo.fccType, icinfo.fccHandler, ICMODE_QUERY);
      if (hIC) {
       ICGetInfo(hIC, &icinfo, sizeof(icinfo));
       ICClose(hIC);
      }
      fcct = FourCC_Type(icinfo.fccType);
      fcch = FourCC_Type(icinfo.fccHandler);
      flg = FlagsToString(icinfo.dwFlags);
      rv.Format(_T("szName: %s\r\n")
       _T("FourCC Type: 0x%08x %s\r\n")
       _T("FourCC Handler: 0x%08x %s\r\n")
       _T("dwFlags: 0x%08x %s\r\n")
       _T("dwVersion: 0x%x\r\n")
       _T("dwVersionICM: 0x%x\r\n")
       _T("szDescription: \"%s\"\r\n")
       _T("szDriver: \"%s\"\r\n")
       ,icinfo.szName
       ,icinfo.fccType,fcct
       ,icinfo.fccHandler,fcch
       ,icinfo.dwFlags,flg
       ,icinfo.dwVersion
       ,icinfo.dwVersionICM
       ,icinfo.szDescription
       ,icinfo.szDriver);
      hIC = ICOpen(icinfo.fccType, icinfo.fccHandler, ICMODE_COMPRESS);
      if (hIC) {
       ICClose(hIC);
       rv += _T("Can Open for Compress\r\n");
      } else {
       rv += _T("Can NOT Open for Compress\r\n");
      }
      hIC = ICOpen(icinfo.fccType, icinfo.fccHandler, ICMODE_DECOMPRESS);
      if (hIC) {
       ICClose(hIC);
       rv += _T("Can Open for Decompress\r\n");
      } else {
       rv += _T("Can NOT Open for Decompress\r\n");
      }
      hIC = ICOpen(icinfo.fccType, icinfo.fccHandler, ICMODE_DRAW);
      if (hIC) {
       ICClose(hIC);
       rv += _T("Can Open for Draw\r\n");
      } else {
       rv += _T("Can NOT Open for Draw\r\n");
      }
     }
     return rv;
    }
    
    

    Results on x64

    szName: MS-RLE
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x454c524d MRLE
    dwFlags: 0x00000007 Quality | Crunch | Temporal
    dwVersion: 0x104
    dwVersionICM: 0x104
    szDescription: "Microsoft RLE"
    szDriver: "C:\Windows\system32\msrle32.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: MS-CRAM
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x4356534d MSVC
    dwFlags: 0x00000005 Quality | Temporal
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Microsoft Video 1"
    szDriver: "C:\Windows\system32\msvidc32.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: MS-YUV
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x59565955 UYVY
    dwFlags: 0x00000000
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Microsoft YUV"
    szDriver: "C:\Windows\system32\msyuv.dll"
    Can NOT Open for Compress
    Can Open for Decompress
    Can NOT Open for Draw


    szName: MS-YUV
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x59565955 UYVY
    dwFlags: 0x00000000
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Microsoft YUV"
    szDriver: "C:\Windows\system32\msyuv.dll"
    Can NOT Open for Compress
    Can Open for Decompress
    Can NOT Open for Draw


    szName: MS-YUV
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x59565955 UYVY
    dwFlags: 0x00000000
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Microsoft YUV"
    szDriver: "C:\Windows\system32\msyuv.dll"
    Can NOT Open for Compress
    Can Open for Decompress
    Can NOT Open for Draw


    szName: IYUV codec
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x56555949 IYUV
    dwFlags: 0x00000000
    dwVersion: 0x0
    dwVersionICM: 0x104
    szDescription: "Intel IYUV codec"
    szDriver: "C:\Windows\system32\iyuv_32.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: IYUV codec
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x56555949 IYUV
    dwFlags: 0x00000000
    dwVersion: 0x0
    dwVersionICM: 0x104
    szDescription: "Intel IYUV codec"
    szDriver: "C:\Windows\system32\iyuv_32.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: Toshiba YUV411
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x31313459 Y411
    dwFlags: 0x00000000
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Toshiba YUV Codec"
    szDriver: "C:\Windows\system32\tsbyuv.dll"
    Can NOT Open for Compress
    Can NOT Open for Decompress
    Can NOT Open for Draw


    szName: TSCC
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x63637374 tscc
    dwFlags: 0x00000004 Temporal
    dwVersion: 0x30000
    dwVersionICM: 0x104
    szDescription: "TechSmith Screen Capture Codec"
    szDriver: "C:\Windows\System32\tsccvid64.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: Huffyuv
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x55594648 HFYU
    dwFlags: 0x00000000
    dwVersion: 0x20001
    dwVersionICM: 0x104
    szDescription: "Huffyuv v2.1.1"
    szDriver: "C:\Windows\system32\huffyuv.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw

     

    Results on Win32

    szName: MS-RLE
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x454c524d MRLE
    dwFlags: 0x00000007 Quality | Crunch | Temporal
    dwVersion: 0x104
    dwVersionICM: 0x104
    szDescription: "Microsoft RLE"
    szDriver: "C:\Windows\system32\msrle32.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: MS-CRAM
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x4356534d MSVC
    dwFlags: 0x00000005 Quality | Temporal
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Microsoft Video 1"
    szDriver: "C:\Windows\system32\msvidc32.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: MS-YUV
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x59565955 UYVY
    dwFlags: 0x00000000
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Microsoft YUV"
    szDriver: "C:\Windows\system32\msyuv.dll"
    Can NOT Open for Compress
    Can Open for Decompress
    Can NOT Open for Draw


    szName: MS-YUV
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x59565955 UYVY
    dwFlags: 0x00000000
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Microsoft YUV"
    szDriver: "C:\Windows\system32\msyuv.dll"
    Can NOT Open for Compress
    Can Open for Decompress
    Can NOT Open for Draw


    szName: MS-YUV
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x59565955 UYVY
    dwFlags: 0x00000000
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Microsoft YUV"
    szDriver: "C:\Windows\system32\msyuv.dll"
    Can NOT Open for Compress
    Can Open for Decompress
    Can NOT Open for Draw


    szName: IYUV codec
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x56555949 IYUV
    dwFlags: 0x00000000
    dwVersion: 0x0
    dwVersionICM: 0x104
    szDescription: "Intel IYUV codec"
    szDriver: "C:\Windows\system32\iyuv_32.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: IYUV codec
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x56555949 IYUV
    dwFlags: 0x00000000
    dwVersion: 0x0
    dwVersionICM: 0x104
    szDescription: "Intel IYUV codec"
    szDriver: "C:\Windows\system32\iyuv_32.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: Toshiba YUV411
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x31313459 Y411
    dwFlags: 0x00000000
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Toshiba YUV Codec"
    szDriver: "C:\Windows\system32\tsbyuv.dll"
    Can NOT Open for Compress
    Can NOT Open for Decompress
    Can NOT Open for Draw


    szName: Cinepak Codec
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x64697663 cvid
    dwFlags: 0x0000002f Quality | Crunch | Temporal | Compress Frames | Fast Temporal Compression
    dwVersion: 0x10000
    dwVersionICM: 0x104
    szDescription: "Cinepak Codec by Radius"
    szDriver: "C:\Windows\system32\iccvid.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw


    szName: TSCC
    FourCC Type: 0x63646976 vidc
    FourCC Handler: 0x63637374 tscc
    dwFlags: 0x00000004 Temporal
    dwVersion: 0x30000
    dwVersionICM: 0x104
    szDescription: "TechSmith Screen Capture Codec"
    szDriver: "C:\Windows\SysWOW64\tsccvid.dll"
    Can Open for Compress
    Can Open for Decompress
    Can Open for Draw

     

     

     

     

     

     

     

     

     

    Monday, April 25, 2011 10:39 PM
  • Is there any way to get someone at MS to look at the code and explain this issue?

    There is a first time for everything but, considering that MS has deprecated WinMM 13 years ago and they've been trying to kill off DirectShow for the last 6 years, I wouldn't hold my breath.

    Why would MS disable the code for x64 when it already works in win32?

    Unless the code was written with Win64 in mind (which can not be the case since the code was initially written for Win16), it can not just be recompiled from x86 to x64 but it must be ported and it takes some effort and plenty of testing and it would be quite surprising if somebody at MS would actually care to invest in it for a legacy product from the computer equivalent of the Dark Ages.

    If they don't work for x64 because they are a retired API, then why support it in SysWOW64?

    They already had a working Win32 version, so why not include it? After all, all existing encoding applications relying on those old codecs can only be Win32 processes, so only Win32 processes need to be supported for backward compatibility. New Win64 applications are not supposed to keep encoding in those old formats and so only decoding of legacy content is required.

    Looking at the MSDN documentation, it looks like the "AVI Compressor Filter" is the filter that wraps the VCM codecs. Is this the piece that is missing on x64?

    The AVICompressor exists and works in both Win32 and Win64. However, it can only enumerate and use VCM encoders that actually exist so, if a codec does not support encoding in Win64 or if MS decided to kill-bit it internally because they did not think it was production-ready, the filter can not use it.

    But all of this is just speculation and only the MS guys know why, Regardless of why, you can only use what the SysDevEnum lists and it (AFAIK) does not make mistakes (regardless of what we may think of its choices).


    MVP :: DirectShow / MediaFoundation <http://www.riseoftheants.com/mmx/faq.htm>
    Tuesday, April 26, 2011 12:48 AM
  • The AVICompressor exists and works in both Win32 and Win64. However, it can only enumerate and use VCM encoders that actually exist so, if a codec does not support encoding in Win64 or if MS decided to kill-bit it internally because they did not think it was production-ready, the filter can not use it.

    I searched the registry for all references to {D76E2820-1563-11CF-AC98-00AA004C0FA9} the CLSID for the AVI Compressor,  it is only registered in the Wow6432Node nodes of the registery.  It is referenced in the node HKEY_CURRENT_USER\Software\Microsoft\ActiveMovie\devenum\{33D9A760-90C8-11D0-BD43-00A0C911CE86}, this is the list of 32 bit video compressor codecs available to the system ({33D9A760-90C8-11D0-BD43-00A0C911CE86} = CLSID_VideoCompressorCategory).  To me, this means that the Win64 version of the AVICompressor is not registered.  I tried to manually register it as well as adding entries in HKEY_CURRENT_USER\Software\Microsoft\ActiveMovie\devenum 64-bit\{33D9A760-90C8-11D0-BD43-00A0C911CE86}.  After adding these registry keys, the missing codecs are listed in graphedt.exe but when i try to add them to a graph I get an error.

    80040111: ClassFactory cannot suppy requested class (Exception from HRESULT: 0x80040111 (CLASS_E_CLASSNOTAVAILABLE)).

    Without a Win64 AVICompressor would it be possible to write filters that wrap the VCM encoders to get the functionality I need on Win64?

    Tuesday, April 26, 2011 2:35 PM

  • Without a Win64 AVICompressor would it be possible to write filters that wrap the VCM encoders to get the functionality I need on Win64?

    Yes you can make your own native DirectShow filter which implements compression and would internally use ICM codec.

    http://alax.info/blog/tag/directshow
    Tuesday, April 26, 2011 2:40 PM
  • Do you know of any example directshow codec filters I could use as a reference?

    Tuesday, April 26, 2011 2:53 PM
  • Do you know of any example directshow codec filters I could use as a reference?

    For a compression filter, with a single compressed format (as opposed to AVI Compressor which is rather a layer to expose all VCM codecs as DirectShow video compressors) you will be fine with a transformation filter.

    The closest SDK sample is EzRGB24. It takes some video input, and delivers output - which is basically all you need from the start. Your filter will also want to accept some uncompressed video and will deliver MS-RLE video. You will choose to register it as  compressor, as a regular filter, or leave as private filter to be added to graph manually.

    Internally it will be able to use ICOpen and friends to take advantage of existing legacy codec.


    http://alax.info/blog/tag/directshow
    Tuesday, April 26, 2011 2:59 PM
  • I stand corrected: there is a qcap.dll in %WinDir%\System32 (where the AVICompressor is supposed to live), as well as several copies in %WinDir%\WinSxS\amd64*, but you're right and the x64 AVICompressor is not registered. The VFWCapFilter (also from qcap.dll) is also missing from the x64 registry. It looks like the decided to drop support for WinMM in Win64 except for playback of legacy content.

    If you really need to encode to MS-RLE in an x64 app, I guess your only option is to write a transform filter or (easier) a DMO to wrap the VCM codec, assuming the encoding part of the x64 codec actually works.

     


    MVP :: DirectShow / MediaFoundation <http://www.riseoftheants.com/mmx/faq.htm>
    Tuesday, April 26, 2011 7:13 PM
  • I have been looking at writing a DMO wrapper to VCM codecs.  I guess this is my only option.  I don't understand why they continued support of the ACM audio codecs using the ACM Wrapper Filter in x64 and not the video.  They are supporting the VCM video codecs in Media Foundation x64 and win32.  The AVICompressor wrapper can't be that complicated of code such that it would need to be drastically changed to support x64.  The x64 codecs are registered and work, WMP12 x64 would not be able to use them if they didn't work.  I've also considered using Media Foundation, but I have to support XP, Vista and Win7.  I am currently using DirectShow to capture frames from USB video capture devices, firewire capture devices, and firewire video camcorders in real time.  The second use of DirectShow is to capture an avi or wmv using a screen capture source filter from the playback of the captured frames.  The playback also includes GIS data so I not just capturing a playback of the captured frames.  Media Foundation is not supported on XP, and from what I've been reading the Vista version is limited as well.  Reading the white paper "Migrating form DirectShow to Media Foundation" (http://msdn.microsoft.com/en-us/library/aa468614.aspx) the section on Video Capture states "For video capture, continue to use DirectShow.". I've been searching the web for DMO source code and found Roman's DmoBrightnessContrastSample and Ernzo's "MPEG-4 Encoder/Decoder DMO based on XvidCore", if you know of any other examples it would be helpful.

    Thanks

    Tuesday, April 26, 2011 9:03 PM
  • Unless your app needs to address more than 2 GiB of virtual mem at a time, why are you wasting time on Win64? A Win64 app is not going to run noticeably faster or be better in any way, even more so a multimedia app, since porting of multimedia components to Win64 has beenn lagging behind so far.

    Anyway, a DMO is simply a COM object that implements IMediaObject and it is synchronous component like a VCM codec, so the IMediaObject methods map easily to the ICM messages:

    Lock: each method must be synchronized and this locks/unlocks the same lock used for synchronization
    
    GetStreamCount: 1
    
    AllocateStreamingResources: do nothing
    FreeStreamingResources: do nothing
    
    GetInputMaxLatency: E_NOTIMPL
    SetInputMaxLatency: E_NOTIMPL
    
    GetInputType:
      DMO_MEDIA_TYPE
      {
        majortype      = MEDIATYPE_Video;
        subtype       = MEDIASUBTYPE_RGB24;
        bFixedSizeSamples  = TRUE;
        bTemporalCompression = FALSE;
        lSampleSize     = 0;
        formattype      = GUID_NULL;
        pUnk         = NULL;
        cbFormat       = 0;
        pbFormat       = NULL;
      }
      if the output type has already been set:
        VIDEOINFOHEADER vihInput, vihOutput;
        vihInput.bmiHeader.biSize     = (DWORD)sizeof(vihInput.bmiHeader);
        vihInput.bmiHeader.biWidth     = vihOutput.bmiHeader.biWidth;
        vihInput.bmiHeader.biHeight    = vihOutput.bmiHeader.biHeight;
        vihInput.bmiHeader.biPlanes    = 1;
        vihInput.bmiHeader.biBitCount   = 24;
        vihInput.bmiHeader.biCompression  = BI_RGB;
        vihInput.bmiHeader.biSizeImage   = 0 or size of bitmap;
        vihInput.bmiHeader.biXPelsPerMeter = 0;
        vihInput.bmiHeader.biYPelsPerMeter = 0;
        vihInput.bmiHeader.biClrUsed    = 0;
        vihInput.bmiHeader.biClrImportant = 0;
        vihInput.rcSource    = { 0,0, 0,0, } or { 0,0, vihInput.bmiHeader.biWidth,vihInput.bmiHeader.biHeight, };
        vihInput.rcTarget    = { 0,0, 0,0, } or vihInput.rcSource;
        vihInput.dwBitRate    = 0;
        vihInput.dwBitErrorRate = 0;
        vihInput.AvgTimePerFrame = vihOutput.AvgTimePerFrame;
        lSampleSize = vihInput.bmiHeader.biSizeImage;
        formattype = FORMAT_VideoInfo;
        cbFormat  = (ULONG)sizeof(vihInput);
        pbFormat  = &vihInput;
    SetInputType:
      ICM_COMPRESS_QUERY(VIDEOINFOHEADER::bmiHeader,output ? &output->bmiHeader : NULL);
      check that VIDEOINFOHEADER::rcSource/rcTarget are correct and AvgTimePerFrame > 0 and, if output, == output
    GetInputCurrentType:
    	input ? input
    GetInputSizeInfo:
      input ? input->bmiHeader.biSizeImage : DMO_E_TYPE_NOT_SET; lookahead = 0, align = 1
    GetInputStreamInfo:
      DMO_INPUT_STREAMF_WHOLE_SAMPLES | DMO_INPUT_STREAMF_SINGLE_SAMPLE_PER_BUFFER | DMO_INPUT_STREAMF_FIXED_SAMPLE_SIZE
    
    GetOutputType:
      DMO_MEDIA_TYPE
      {
        majortype      = MEDIATYPE_Video;
        subtype       = FOURCCMap('MRLE');
        bFixedSizeSamples  = FALSE;
        bTemporalCompression = FALSE;
        lSampleSize     = 0;
        formattype      = GUID_NULL;
        pUnk         = NULL;
        cbFormat       = 0;
        pbFormat       = NULL;
      }
      if the input has already been set:
        ICM_COMPRESS_GET_FORMAT(&input->bmiHeader,NULL) /// to discover the size of the BITMAPINFO
        ICM_COMPRESS_GET_FORMAT(&input->bmiHeader,&VIDEOINFOHEADER::bmiHeader) /// to fill in the BITMAPINFO
    SetOutputType:
      input ? ICM_COMPRESS_QUERY(input,VIDEOINFOHEADER::bmiHeader) : check it yourself;
      check that VIDEOINFOHEADER::rcSource/rcTarget are correct and AvgTimePerFrame > 0 and, if input, == input
    GetOutputCurrentType:
    	output ? output
    GetOutputSizeInfo:
      input && output ? ICM_COMPRESS_GET_SIZE(input,output) : DMO_E_TYPE_NOT_SET; align = 1
    GetOutputStreamInfo:
      DMO_OUTPUT_STREAMF_WHOLE_SAMPLES | DMO_OUTPUT_STREAMF_SINGLE_SAMPLE_PER_BUFFER
    
    DMO_OUTPUT_DATA_BUFFER frames[5];
    size_t first = 0, valid = 0, count = sizeof(frames)/sizeof(*frames);
    bool discontinuity = true;
    
    GetInputStatus: valid < count ? DMO_INPUT_STATUSF_ACCEPT_DATA : 0
    ProcessInput:
      if(valid > count) return DMO_E_NOTACCEPTING;
      pBuffer->AddRef();
      frames[(first + valid) % count] = args;
      ++valid;
      return S_OK;
    Discontinuity:
      if(valid > count) return DMO_E_NOTACCEPTING;
      frames[(first + valid) % count].pBuffer = NULL;
      ++valid;
      return S_OK;
    Flush:
      while(valid > 0) {
        if(frames[first].pBuffer) frames[first].pBuffer->Release();
        first = (first + 1) % count; --valid;
      }
      discontinuity = true;
      
    ProcessOutput:
      /// TODO: ICM_COMPRESS_FRAMES_INFO?
      do {
        if(discontinuity) { ICM_COMPRESS_BEGIN; discontinuity = false; }
        if(valid < 1) return S_FALSE;
        if(frames[first].pBuffer == NULL) {
          discontinuity = true;
          first = (first + 1) % count; --valid;
        } else {
          ICCOMPRESS icc = { 0 }; DWORD dwFlags;
          icc.lpbiOutput = &output->bmiHeader;
          icc.lpOutput  = pOutputBuffers[0].pBuffer.GetBufferAndLength();
          icc.lpbiInput = &input->bmiHeader;
          icc.lpInput  = frames[first].pBuffer.GetBufferAndLength();
          icc.lpdwFlags = &dwFlags;
          icc.lFrameNum = ...;
          ICM_COMPRESS(&icc,(LPARAM)sizeof(icc));
          frames[first].pBuffer->Release();
          pOutputBuffers[0].dwStatus   = DMO_OUTPUT_DATA_BUFFERF_TIME | DMO_OUTPUT_DATA_BUFFERF_TIMELENGTH;
          pOutputBuffers[0].rtTimestamp = frames[first].rtTimestamp;
          pOutputBuffers[0].rtTimelength = frames[first].rtTimelength;
          if(dwFlags & AVIIF_KEYFRAME) pOutputBuffers[0].dwStatus |= DMO_OUTPUT_DATA_BUFFERF_SYNCPOINT;
          first = (first + 1) % count; --valid;
          break;
        }
      } while(true);
    

    MVP :: DirectShow / MediaFoundation <http://www.riseoftheants.com/mmx/faq.htm>

    Wednesday, April 27, 2011 6:58 PM
  • First, thanks for the code example it helps greatly.  The application is a GIS app using high resolution satelite imagery, 2GB is small compared to the size of the imagery files.  The multimedia aspect is a small but important part of the overall app.  The multimedia is captured in real time while drawing the imagery as well as overlays.  The drawing of the imagery and overlays is controlled by input from a GPS.  So having more than 2GB of memory would allow for faster processing of the multimedia data.  It is not uncommon to utilize the multimedia capture for over 8 hours without stopping.

    About the code, should I use ICSeqCompressFrameStart, ICSeqCompressFrame, and ICSeqCompressFrame instead of ICCompress? Which mode should I use, ICMODE_COMPRESS or ICMODE_FASTCOMPRESS?

    Thursday, April 28, 2011 2:06 PM
  • I don't know exactly what the macros do: I indicated the IC messages in my pseudo-code, which you can send directly without bothering with the macros.

    The fast mode sacrifices quality to maintain real-time speed. Even if you need real-time, I don't think you need the fast mode, since I don't see how that can apply to the MC-RLE encoder and a modern CPU should barely break a sweat with MS-RLE anyway. But you need to test it yourself.


    MVP :: DirectShow / MediaFoundation <http://www.riseoftheants.com/mmx/faq.htm>
    Sunday, May 1, 2011 1:41 AM
  • Hey Ben,

    i am running on same issue, i want to use x264vfw filter with 64 bit.

    have you developed wrapper to use it with 64 bit?

    Friday, May 11, 2012 5:38 AM
  • Bumping this thread. I'm running into the same problem here: I need to use the 64-bit version of a codec with DirectShow in a 64-bit app, but it's not listed in the Video Compressors category in GraphEdit. Did anyone end up finding a solid solution or workaround to this problem? Or is the standing answer still that it's a decision by MS and we're out of luck?
    Wednesday, August 6, 2014 6:24 PM
  • The standing answer explains why this is not a problem and is a behavior by design instead.

    http://alax.info/blog/tag/directshow

    Wednesday, August 6, 2014 7:11 PM