ffdshow tryouts project: Discussion & Development

[foxyshadis]

I swear this thread generates more side threads than anything else in the forum. :p New hardware discussion. (http://forum.doom9.org/showthread.php?t=123809)

KZ, so there actually is a DXVA colorprimary flag? Is it part of VideoInfoHeader2?

Both RFEs have been filed: Use stream information with: ffdshow conversion to RGB (http://sourceforge.net/tracker/index.php?func=detail&aid=1686502&group_id=173941&atid=867363) and passing YUV along to video card (http://sourceforge.net/tracker/index.php?func=detail&aid=1686510&group_id=173941&atid=867363).

[Dr Pizza]

The C parts of libavcodec are definitely LLP64 clean: The only codec that uses (long) at all is the faad wrapper.
I'll take a look at the current source, maybe the situation isn't as grim as it was before.

[clsid]

"make 64BIT=yes" should select the appropriate blocks of assembly code. Note that I haven't been able to test it, but unless I forgot something or screwed up somewhere it should work.

The makefile should also be modified with different GCC parameters to set the correct target architecture. That hasn't been done yet.

[haruhiko_yamagata]

With:
ffdshow_rev1050_20070319_clsid_sse_icl9.exe
ffdshow_beta2a_20070322_clsid.exe
ffdshow_beta2_20070319_clsid.exe
.... using MPC+Haali splitter, I can't watch my anamorphic encodes(it doesn't stretch to correct AR) and also there's some green line in right border.
Using same ffdshow video presets I don't have that issue with:
ffdshow_beta1_20061211_clsid.exe
Any idea why?!It works for me. Which video renderer do you use?
Could you upload the sample?
What is the OS and version of the directShow?
What is the video card?

[haruhiko_yamagata]

@Devs:
Should the download links (in changelog and tryouts homepage) be updated to the new beta2a build?
Yes, please do so.

[haruhiko_yamagata]

To Haruhiko or whoever has a better understanding of MPEG2 decoding:

If I'm using ffdshow to decode DVDs I've noticed that the only events getting fired from the DVD Navigator are BeginFlush/EndFlush, but the video decoder pin doesn't handle those, so I don't think libmpeg2 or anything else is actually waiting for a keyframe after seeking - that might explain why there's still quite some macroblocking going on when seeking around on a DVD.

Incidentally, that also prevents my filter from just dropping the remaining buffered frames and makes it process them, which is quite wasteful - should we perhaps add an onFlush() method (like the existing onStop and onSeek) to TimgFilter(s) that gets called on BeginFlush(), or should we at least call onSeek() in that case?TvideoCodecLibmpeg2:: onSeek and TimgFilterAvisynth:: onSeek are called when we seek on mpeg2 ps/ts/vob and almost any files except DVD:p . It's a bug of the DVD decoding.
I don't think onFlush is necessary as long as DVD can be handled properly.

[Leak]

I don't think onFlush is necessary as long as DVD can be handled properly.
So by "handled properly" you mean onSeek being fired on the next incoming sample when the pin gets a BeginFlush? At least that would be my idea of working around this.

[haruhiko_yamagata]

So by "handled properly" you mean onSeek being fired on the next incoming sample when the pin gets a BeginFlush? At least that would be my idea of working around this.
I don't know. It's not that easy, I guess.
We have to study the code of MPC or DScaler.
I'm not willing to implement full DVD decoding feature.

[albain]

Sorry for the compilation errors : I messed up with the merge (modifications have been made on the files I have been working on, and the merge tool made some weird things...)

It is repaired now : revision 1064

Just one precision : those modifications imply that you have the last version of Windows SDK : v6.0, that includes headers for Vista.
Maybe it will still compile with older SDKs though...

[cc979]

with rev1064

the baseclasses are un-compilable with gcc
tried updating to vista's sdk and converting the libs ... to many errors

like
d:/msys/1.0/dx/Include/objbase.h:1003: error: '__in' was not declared in this scope
d:/msys/1.0/dx/Include/objbase.h:1004: error: '__in' was not declared in this scope
d:/msys/1.0/dx/Include/objbase.h:1005: error: '__in' was not declared in this scope
d:/msys/1.0/dx/Include/objbase.h:1006: error: '__deref_out' was not declared in this scope
d:/msys/1.0/dx/Include/objbase.h:1006: error: initializer expression list treated as compound expression

its beyond me, any clues anyone?

[KillerZero]

[QUOTE=foxyshadis;974086]KZ, so there actually is a DXVA colorprimary flag?
obviously yes.

Both RFEs have been filed: Use stream information with: ffdshow conversion to RGB (http://sourceforge.net/tracker/index.php?func=detail&aid=1686502&group_id=173941&atid=867363) and passing YUV along to video card (http://sourceforge.net/tracker/index.php?func=detail&aid=1686510&group_id=173941&atid=867363).

You filled it wrong.
1) ffdshow always use Rec601 when does SW RGB conversion.
2) more important than DXVA_VideoPrimaries (which set color of RGB values) is DXVA_VideoTransferMatrix (which set which matrix should be used for YV12-->RGB conversion)
Both these values should be set.

[Inventive Software]

@Devs: Can I suggest a separate branch for a Vista so as not to break compilation, so to speak? Vista's screwy already without helping to break other operating systems. ;)

[albain]

with rev1064

the baseclasses are un-compilable with gcc
tried updating to vista's sdk and converting the libs ... to many errors

like
d:/msys/1.0/dx/Include/objbase.h:1003: error: '__in' was not declared in this scope
d:/msys/1.0/dx/Include/objbase.h:1004: error: '__in' was not declared in this scope
d:/msys/1.0/dx/Include/objbase.h:1005: error: '__in' was not declared in this scope
d:/msys/1.0/dx/Include/objbase.h:1006: error: '__deref_out' was not declared in this scope
d:/msys/1.0/dx/Include/objbase.h:1006: error: initializer expression list treated as compound expression

its beyond me, any clues anyone?

Does it compile correctly under MSVC ?

I am using the base classes from ffdshow with the last windows sdk and I didn't have this problem (using MSVC)

I didn't try with gcc : gcc does not work in Vista for now

Concerning the idea of opening a separate branch for Vista, I hope that this could be avoided, because it will split the work of developers.

Things can be done to avoid compilation problems, by using preprocessor macros basing on the OS version. However the last SDK (the one for Vista) should be working under XP

[cc979]

@albain
i don't use MSVC or vista, before i tried updating the mingw headers & libs it did'nt work either

as mingw as its own win32 headers it clashes/or is incompatible with new the windows sdk v6 - mingw headers might get updated later

not sure what to do now - as it a bit over my head

is it possible to alter your edits to keep gcc compatiblity?

or maybe edit it to work with latest dx sdk(feb 2007) but not platform sdk as its that whats breaking gcc - the latest dx sdk is ok with gcc as i used it rev1058 no problem

cheers

[albain]

OK I will try to think about a workaround : maybe by copying the needed content of those headers into a dedicated ffdshow header file.

Maybe your solution is to put your mingw headers directories before windows sdk ones.

Before doing anything, could you try this :
copy functiondiscoverykeys.h and Mmdeviceapi.h to your mingw include directory and remove any references to Windows SDK and compile ffdshow ?

If it does not work, my bet is to extract the used interfaces in my modifications

[cc979]

just tried include them 2 headers but it errors with

d:/msys/1.0/dx/Include/functiondiscoverykeys.h:11: error: expected constructor, destructor, or type conversion before '(' token

d:/msys/1.0/dx/Include/Mmdeviceapi.h:126: error: 'PROPERTYKEY' does not name a type

d:/msys/1.0/dx/Include/Mmdeviceapi.h:198: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:198: error: expected ',' or '...' before 'pwstrDeviceId'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:204: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:204: error: expected ',' or '...' before 'pwstrDeviceId'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:208: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:208: error: expected ',' or '...' before 'pwstrDeviceId'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:212: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:212: error: expected ',' or '...' before 'flow'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:220: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:220: error: expected ',' or '...' before 'pwstrDeviceId'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:343: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:343: error: expected ',' or '...' before '&' token
d:/msys/1.0/dx/Include/Mmdeviceapi.h:353: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:353: error: expected ',' or '...' before 'stgmAccess'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:359: error: '__deref_out' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:359: error: expected ',' or '...' before '*' token
d:/msys/1.0/dx/Include/Mmdeviceapi.h:363: error: '__out' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:363: error: expected ',' or '...' before '*' token
d:/msys/1.0/dx/Include/Mmdeviceapi.h:476: error: '__out' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:476: error: expected ',' or '...' before '*' token
d:/msys/1.0/dx/Include/Mmdeviceapi.h:480: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:480: error: expected ',' or '...' before 'nDevice'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:573: error: '__out' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:573: error: expected ',' or '...' before '*' token
d:/msys/1.0/dx/Include/Mmdeviceapi.h:654: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:654: error: expected ',' or '...' before 'dataFlow'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:662: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:662: error: expected ',' or '...' before 'dataFlow'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:670: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:670: error: expected ',' or '...' before 'pwstrId'
d:/msys/1.0/dx/Include/Mmdeviceapi.h:676: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:676: error: expected ',' or '...' before '*' token
d:/msys/1.0/dx/Include/Mmdeviceapi.h:680: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:680: error: expected ',' or '...' before '*' token
d:/msys/1.0/dx/Include/Mmdeviceapi.h:803: error: '__in' has not been declared
d:/msys/1.0/dx/Include/Mmdeviceapi.h:803: error: expected ',' or '...' before '&' token
make[1]: *** [baseclasses_all.o] Error 1
make[1]: Leaving directory `/home/User/svn/ffdshow-tryout/ffdshow-tryout/src/baseclasses'
make: *** [lib] Error 2


maybe you could try - if not defined them to headers compile for xp or gcc, or something - but looks like it could be tricky problem

cheers

[albain]

Okay, I know why : there are more than those 2 headers, but if I create a new header with only the needed interfaces and constants, it should work

[cc979]

would there be copyright issues distributing ms headers - if remember milan_cutka told me something about it on sourceforge somewhere

[clsid]

The baseclasses in ffdshow are also Microsoft code. So it shouldn't be a problem.

Albain, please create the custom header. Then I could postpone my hardware upgrade a little while till after the Intel price drops :)

[cc979]

i think i got the baseclasses compiled by compiling it on its own but when try build the rest

i get this error
../subtitles/Tstream.h: In member function 'virtual long int TstreamFile::length() const':
../subtitles/Tstream.h:97: error: 'filelength' was not declared in this scope
TbitrateDlg.cpp: In member function 'virtual void TbitrateDlg::init()':
TbitrateDlg.cpp:54: error: 'filelength' was not declared in this scope
make[1]: *** [ffdshow_dialog_all.o] Error 1
make[1]: Leaving directory `/home/User/svn/ffdshow-tryout/ffdshow-tryout/src/dialog'
make: *** [lib] Error 2


not sure what this one is ?

[albain]

I am on it

Sorry to make you stuck guys ;-)

[foxyshadis]

2) more important than DXVA_VideoPrimaries (which set color of RGB values) is DXVA_VideoTransferMatrix (which set which matrix should be used for YV12-->RGB conversion)
Both these values should be set.

Since most of the values map directly to a VUI SEI, I figured supporting any given field would be about as hard as supporting all at once, so most important doesn't really matter.

[_xxl]

Compiling...
ToutputAudioSettings.cpp
src\settings\filters\ToutputAudioSettings.cpp(109) : error C2664: 'IMMDevice::GetId' : cannot convert parameter 1 from 'char_t ** ' to 'LPWSTR * '
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
src\settings\filters\ToutputAudioSettings.cpp(144) : error C2664: 'IMMDevice::GetId' : cannot convert parameter 1 from 'char_t ** ' to 'LPWSTR * '
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
src\settings\filters\ToutputAudioSettings.cpp(158) : error C2665: 'strncpy' : none of the 2 overloads can convert parameter 2 from type 'LPWSTR'
C:\Program Files\microsoft visual studio .net 2003\vc7\include\string.h(135): could be 'char *strncpy(char *,const char *,size_t)'
h:\beta\trunk\src\char_t.h(39): or 'wchar_t *strncpy(wchar_t *,const wchar_t *,size_t)'
while trying to match the argument list '(char_t [255], LPWSTR, int)'
src\settings\filters\ToutputAudioSettings.cpp(167) : error C2665: 'strncpy' : none of the 2 overloads can convert parameter 2 from type 'LPWSTR'
C:\Program Files\microsoft visual studio .net 2003\vc7\include\string.h(135): could be 'char *strncpy(char *,const char *,size_t)'
h:\beta\trunk\src\char_t.h(39): or 'wchar_t *strncpy(wchar_t *,const wchar_t *,size_t)'
while trying to match the argument list '(char_t [255], LPWSTR, int)'
Twindow.cpp
src\dialog\Twindow.cpp(146) : error C2065: 'MIIM_STRING' : undeclared identifier
TffdshowDecAudio.cpp
src\TffdshowDecAudio.cpp(101) : warning C4355: 'this' : used in base member initializer list
src\TffdshowDecAudio.cpp(108) : warning C4355: 'this' : used in base member initializer list
src\TffdshowDecAudio.cpp(512) : error C2664: 'IMMDeviceEnumerator::GetDevice' : cannot convert parameter 1 from 'char_t [255]' to 'LPCWSTR'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
src\TffdshowDecAudio.cpp(531) : error C2664: 'IFilterGraph::AddFilter' : cannot convert parameter 2 from 'const char [24]' to 'LPCWSTR'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
Generating Code...
I get this errors when compiling with msvc2003 + Microsoft SDKs 6, also #define POINTER_64 __ptr64 // <<---- ORROR !!!

typedef void *PVOID;

typedef void * POINTER_64 PVOID64; this issue.

[albain]

Ok, I have made the new header file, and it compiles correctly.
I will do some more tests before committing the changes...

Concerning your compilation errors on MSVS 2003, I am checking this right now. Did you compile it using unicode or ansi ?

[Blight]

Can you please add "zplayer.exe" to the list of allowed players in the installer?
(it isn't listed in the "beta2a" clsid release)

[haruhiko_yamagata]

Can you please add "zplayer.exe" to the list of allowed players in the installer?
(it isn't listed in the "beta2a" clsid release)
It is included in beta2a. The installer load the current settings, so I guess it's your settings. Did you edit the list?

[haruhiko_yamagata]

So by "handled properly" you mean onSeek being fired on the next incoming sample when the pin gets a BeginFlush? At least that would be my idea of working around this.
IPin::NewSegment holds the critical session m_csReceive, while IPin::BeginFlush and IPin::EndFlush can not (must not) hold it. This is a big difference. If onSeenk is called from EndFlush, it can't be stable.

[_xxl]

Did you compile it using unicode or ansi ?
Ansi.

[_xxl]

Compiling...
stdafx.cpp
C:\Program Files\Microsoft SDKs\Windows\v6.0\Include\propkey.h(35) : error C2146: syntax error : missing ';' before identifier 'PKEY_Audio_ChannelCount'
C:\Program Files\Microsoft SDKs\Windows\v6.0\Include\propkey.h(35) : error C2501: 'PKEY_Audio_ChannelCount' : missing storage-class or type specifiers
...
\Include\propkey.h(358) : fatal error C1003: error count exceeds 100; stopping compilation

Build log was saved at "file://h:\beta\trunk\release_unicode\BuildLog.htm"
ffdshow - 102 error(s), 0 warning(s)
Now I get new errors.
MSVC 2003 + SDK 6 + unicode/ansi.

[albain]

I have just committed the changes : there is a new header file called IffMMDevice.h + corrections brought

It compiles correctly on both unicode and ansi without using windows sdk 6.0 headers

Again, sorry for that

If it still doesn't work, I will revert all the changes

[haruhiko_yamagata]

@albain
I'm trying to compile using MSVC8 and "Microsoft Platform SDK for Windows Server 2003 R2".
A few symbols are not defined.
PROPERTYKEY
__RPC__in
__RPC__out
If it still doesn't work, I will revert all the changes
I can wait :D .

[albain]

And what about this one ? (revision 1067)

Thanks

PS : I have renamed my v6 SDK directory and used the old one to confirm the fix. By this way I use the old SDK

[haruhiko_yamagata]

One error left.
REFPROPVARIANT is not defined.
c:\ffdshoww10\trunk\src\iffmmdevice.h(345) : error C2061: error : identifier 'REFPROPVARIANT'

[albain]

Finally ! I have compiled it with my old sdk and it is okay

[Leak]

IPin::NewSegment holds the critical session m_csReceive, while IPin::BeginFlush and IPin::EndFlush can not (must not) hold it. This is a big difference. If onSeenk is called from EndFlush, it can't be stable.
I was more thinking of just setting a flag in Tfilters so onSeek() gets called on the filter chain right before the next frame is handed down to the filters (in Tfilters' process, IIRC) - that should work almost as well, without the synchronization issues.

np: One Second Bridge - Take Me To The Moon (One Second Bridge)

[haruhiko_yamagata]

Finally ! I have compiled it with my old sdk and it is okay
Linker error "_PKEY_Device_FriendlyName". Maybe I should install v6 SDK. That does not matter as long as the output ax is compatible.

// EDIT GCC still have many errors.

[cc979]

@albain something still broke with rev1068

gcc -c -DRELEASE -mno-cygwin -mdll -fno-rtti -mthreads -pipe -D_WINGDI_ -DUCLIBCPP -D_GLIBCPP_HAVE_MBSTATE_T -D_WIN32_IE=0x0500 -mmmx -w -DNDEBUG -UDEBUG -DFFDEBUG=0 -I. -I.. -Iuclibc++ -Ibaseclasses -I../baseclasses -IimgFilters -I../imgFilters -Implayer -I../mplayer -Isettings -I../settings -Isettings/filters -I../settings/filters -Icodecs -I../codecs -Isubtitles -I../subtitles -Iconvert -I../convert -Idialog -I../dialog -IaudioFilters -I../audioFilters -Icygwin -I../cygwin -Iffmpeg -I../ffmpeg -Iacm -I../acm -Ixiph -I../xiph -Ifilters -I../filters -Imuxers -I../muxers -I/dx/Include -L/dx/MingLib -ldx9 -O2 -march=pentium-mmx -mtune=i686 -fomit-frame-pointer -finline-functions -finline -frename-registers -fweb -funit-at-a-time -MMD -o baseclasses_all.o baseclasses_all.cpp
../IffMmdevice.h:464: error: '__in' has not been declared
../IffMmdevice.h:464: error: expected ',' or '...' before 'pwstrDeviceId'
../IffMmdevice.h:470: error: '__in' has not been declared
../IffMmdevice.h:470: error: expected ',' or '...' before 'pwstrDeviceId'
../IffMmdevice.h:474: error: '__in' has not been declared
../IffMmdevice.h:474: error: expected ',' or '...' before 'pwstrDeviceId'
../IffMmdevice.h:478: error: '__in' has not been declared
../IffMmdevice.h:478: error: expected ',' or '...' before 'flow'
../IffMmdevice.h:486: error: '__in' has not been declared
../IffMmdevice.h:486: error: expected ',' or '...' before 'pwstrDeviceId'
../IffMmdevice.h:609: error: '__in' has not been declared
../IffMmdevice.h:609: error: expected ',' or '...' before '&' token
../IffMmdevice.h:619: error: '__in' has not been declared
../IffMmdevice.h:619: error: expected ',' or '...' before 'stgmAccess'
../IffMmdevice.h:625: error: '__deref_out' has not been declared
../IffMmdevice.h:625: error: expected ',' or '...' before '*' token
../IffMmdevice.h:629: error: '__out' has not been declared
../IffMmdevice.h:629: error: expected ',' or '...' before '*' token
../IffMmdevice.h:742: error: '__out' has not been declared
../IffMmdevice.h:742: error: expected ',' or '...' before '*' token
../IffMmdevice.h:746: error: '__in' has not been declared
../IffMmdevice.h:746: error: expected ',' or '...' before 'nDevice'
../IffMmdevice.h:839: error: '__out' has not been declared
../IffMmdevice.h:839: error: expected ',' or '...' before '*' token
../IffMmdevice.h:920: error: '__in' has not been declared
../IffMmdevice.h:920: error: expected ',' or '...' before 'dataFlow'
../IffMmdevice.h:928: error: '__in' has not been declared
../IffMmdevice.h:928: error: expected ',' or '...' before 'dataFlow'
../IffMmdevice.h:936: error: '__in' has not been declared
../IffMmdevice.h:936: error: expected ',' or '...' before 'pwstrId'
../IffMmdevice.h:942: error: '__in' has not been declared
../IffMmdevice.h:942: error: expected ',' or '...' before '*' token
../IffMmdevice.h:946: error: '__in' has not been declared
../IffMmdevice.h:946: error: expected ',' or '...' before '*' token
../IffMmdevice.h:1069: error: '__in' has not been declared
../IffMmdevice.h:1069: error: expected ',' or '...' before '&' token
make: *** [baseclasses_all.o] Error 1

must be a difference between msvc and gcc

cheers

[haruhiko_yamagata]

I was more thinking of just setting a flag in Tfilters so onSeek() gets called on the filter chain right before the next frame is handed down to the filters (in Tfilters' process, IIRC) - that should work almost as well, without the synchronization issues.

np: One Second Bridge - Take Me To The Moon (One Second Bridge)
EndFlush may be called while ffdshow is decoding the last sample of the current segment. In that case,I'm afraid the filter will buffer the last frame of the current segment as the first frame of the coming segment.

[haruhiko_yamagata]

If GCC cannot build Vista application, conditional compilation is the choice. It's not good idea to revert your changes, IMO.

#ifdef __GNUC__

#else

#endif

[haruhiko_yamagata]

This SDK is designed for use with Windows Vista (which includes Framework 3.0). The Windows SDK for Vista also supports creating applications for Windows XP, Windows Server® 2003 SP1, and Windows Server 2003 R2.

This release of the Windows SDK is compatible with Microsoft® Visual Studio® 2005 and the Visual Studio 2005 extensions for .NET Framework 3.0 (WCF & WPF), November 2006 CTP.
Is the object compatible with Windows 2000? We may consider dropping Windows 9x, but I still want to support Windows 2000.

Is MSVC7 compatible with this SDK?

None the less, supporting Vista is important too. Conditional compilation should be something like...

#ifdef __GNUC__
#undef VISTA_SPDIF
#endif

#ifdef VISTA_SPDIF

#else

#endif

[albain]

Ok, I will add those conditional compilation macros

[foxyshadis]

Vista SDK is compatible with 2000 (and some still for 98), as long as you don't use XP-specific APIs, but Microsoft no longer does more than minimal testing with EOL'd OSes, so they don't get mentioned. That was my experience with simpler apps, haven't compiled ffdshow in a week or two.

[albain]

I hope that a better integration of Vista sdk with gcc is possible.

Anyway, I have just committed changes with conditional compilation of Vista features

As proposed, the preprocessor macro VISTA_SPDIF has to be defined in order to compile those features.
It is always disabled for gcc.

Revision 1069

Cheers

[cc979]

is there a lot of extra stuff on sdk v6, compared to dx sdk feb07 (as it does support dx10)

ps. ffdshow builds fine now with gcc

cheers

[cc979]

just been testing the .ts clip from
http://forum.doom9.org/showpost.php?p=974692&postcount=539

it something expands correcting in vlc but in mpc with ffdshow/vmr9 it expands vertical, weird?

[clsid]

Compiled with MSVC2003 and Platform SDK 5.2 (2003 R2):

VISTA_SPDIF defined:

ffdshow error LNK2019: unresolved external symbol _PKEY_Device_FriendlyName referenced in function "protected: class std::hash_map<class DwString<wchar_t>,class DwString<wchar_t>,struct std::hash<class DwString<wchar_t> >,struct std::equal_to<class DwString<wchar_t> >,class std::allocator<class DwString<wchar_t> > > __thiscall ToutputAudioSettings::getDevices(void)" (?getDevices@ToutputAudioSettings@@IAE?AV?$hash_map@V?$DwString@_W@@V1@U?$hash@V?$DwString@_W@@@std@@U?$equal_to@V?$DwString@_W@@@3@V?$allocator@V?$DwString@_W@@@3@@std@@XZ)


VISTA_SPDIF not defined:

compiles succesfully!

[haruhiko_yamagata]

just been testing the .ts clip from
http://forum.doom9.org/showpost.php?p=974692&postcount=539

it something expands correcting in vlc but in mpc with ffdshow/vmr9 it expands vertical, weird?
My result with MPC's internal source filter is,
vmr7/9 beta1 OK,beta2a OK,ffdshow-20051129 OK,DScaler NG,MPC NG
overlay beta1 NG,beta2a NG,ffdshow-20051129 NG,DScaler NG,MPC NG

ffdshow used libmpeg2. MPC means MPC's internal decoder.
NG means no AR change during playback.
Do you mean vertically streched during playback?
What is the video card?

[cc979]

i have a nvidia 6800 card btw

mpc setting repeat for ever
on first play there is no AR change, then after the repeat it on the change it stretchs vertical

i have taken snapshots using mpc they saving with the corrected AR changes - so maybe it is mpc that has the problem

[cc979]

using windows media play with the same clip, on AR change the window remains the same but the video shrinks vertical(with black borders) to the correct AR

[cc979]

the screenshots and printscreens, so show whats happening
http://www.mytempdir.com/1267661