Log in

View Full Version : ffdshow development


Pages : 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Neo Neko
21st December 2003, 07:45
Originally posted by bond
aspect ratio

atm first mpeg-4 codecs (3ivx and xvid) offer the possibility to store a par in the mpeg-4 bitstream

You forget ffmpeg which was the first IIRC.

Originally posted by bond
would be great if ffdshow could also supports this :)

ffmpeg supports it. Has for a long time. So ffdshow should be no problem. Save for directshow foybles. Oh also ffvfw which is based on ffmpeg and being integrated in ffdshow atm supports AR.

bond
21st December 2003, 11:43
Originally posted by Neo Neko
you forget ffmpeg which was the first IIRC.
Oh also ffvfw which is based on ffmpeg and being integrated in ffdshow atm supports AR.ah yes :)

ffmpeg supports it. Has for a long time. So ffdshow should be no problem. Save for directshow foybles.hm would be really great

note that the nero digital decoder already automatically plays ffvfw, xvid or 3ivx ar avis with the right ar (dunno if it does software resize internally, would be bad tough)
the 3ivx decoder supports it if these get muxed into .mp4
i dunno what is responsible for resizing in matroska, but i know that it was only possible when overlay mixer was enabled in ffdshow, which doesnt seem to work with mp4 tough
dunno about ogm

would be great if we could get a nice automatic anamorphic decoding support in ffdshow :)

Blight
21st December 2003, 20:21
Milan, any chance you can support QDesign Audio in the FFDShow Audio Filter. This sound format is used in quite a few QuickTime file and it would help if it were supported. I think MPlayer supports it by hooking into the quicktime libraries, so it may be possible to get the code there.

avih
21st December 2003, 23:35
@blight:
what format exactly are you talking about?
i've been using QDesign mp2 for captures (low cpu overhead), and it seems to play without any decoder installed on all (starting from win98) win platforms...

why would you need it on ffdshow, except for platforms on which ffdshow works and the default win32 codecs don't??

Blight
23rd December 2003, 10:23
avih:
We're talking about two different things... I'm talking about the QDesign Audio codec that resides in quite a few of the quicktime trailers. It's some audio format of their own design. I think the company also makes an MP2/3 encoder of some sort, but it's not what I'm referring to.

dimzon
23rd December 2003, 10:43
Hi!
Today I first time try mp4 container :)
Semms like found new bug :)

I have installed
3ivX 3.4.5
ffdshow 20031128 (all supported codecs is on)
CoreAAC decoder

Surprizly when i trying to play mp4 file (created myself using mp4ui tool) i detected that videostream has fourCC=mp4v and 3ivX Video Decoder is used to decode them :(

Than I downgrade my ffdshow to 20030523 and detect that videostream fourCC still =mp4v but ffdshow used for videodecoding...

I think it's a bug twice - 20030523 has'nt other MP4 option but tryes to decode mp4v and 20031128 hasother MP4 option but don't decode mp4v :(

Sorry for my poor english

BoNz1
24th December 2003, 03:51
@ dimzon, this is no bug simply check allow unsupported decoders in 3ivx mp4 splitter.

dimzon
24th December 2003, 12:00
Originally posted by BoNz1
@ dimzon, this is no bug simply check allow unsupported decoders in 3ivx mp4 splitter.
Wrong! I have this options checked. 20030523 will decode mp4 and 20031128 does not :(

bond
24th December 2003, 13:01
yep, i also already reported this mp4 bug in the latest athos compile version

dimzon
24th December 2003, 14:01
2Athos

How about moving to openwatcom (www.openwatcom.org) instead Intel?
Some times ago watcom C/C++ was the best for performance...

BoNz1
24th December 2003, 19:11
Originally posted by dimzon
Wrong! I have this options checked. 20030523 will decode mp4 and 20031128 does not :(

Alright my bad then, I suppose it is a bug.

athos
25th December 2003, 02:21
Originally posted by dimzon
2Athos

How about moving to openwatcom (www.openwatcom.org) instead Intel?
Some times ago watcom C/C++ was the best for performance...

Thanks, I'll take a look. I have stop using the Intel compiler for ffdshow (except for the version where I could not get gcc to compile) becuase I have had some problems with crashes. I think this has to do with some nonstandard code in the VC++ parts of ffdshow, as it has been the same for several versions of ICL.

Leak
26th December 2003, 15:21
By the way, Athos - have you heard anything from Milan in the last few months? The last CVS checkin to ffdshow has been sometime in the mid of October, which makes it look a bit dead to me... :(

(Case in point - files produced with XviD 1.0 beta with "packed bitstream" set play back with frames in the wrong order as IIRC syskin mentioned in this thread already.)

np: Rechenzentrum - Nelson Reshoot (Director's Cut)

Koepi
26th December 2003, 15:40
syskin just stated that the order is correct, just the timing isn't if there are packed bitstream bframes >1 in a row.

Regards
Koepi

athos
28th December 2003, 23:17
Originally posted by Leak
By the way, Athos - have you heard anything from Milan in the last few months? The last CVS checkin to ffdshow has been sometime in the mid of October, which makes it look a bit dead to me... :(

no i havent heard anything :\ i hope he doesnt disappear like nando did..

bond
28th December 2003, 23:22
:scared:

LigH
28th December 2003, 23:39
My last eMail reply (I contacted him to tell him about the orange-blue bug) was received at the 30th of October - he told me he might know where the reason is (I guessed: rounding bugs fixed since DivX 5.0.3), and if I could provide some samples, he would change the CVS accordingly. No reply since then...

Defiler
30th December 2003, 20:36
What is currently considered the most-compatible version of ffdshow for XviD 1.0 beta playback? Is there any reason to use the November 28th, 2003 build, for example?

arno
30th December 2003, 21:08
Originally posted by Defiler
What is currently considered the most-compatible version of ffdshow for XviD 1.0 beta playback? Is there any reason to use the November 28th, 2003 build, for example?

I still use the one from November 2002(!) (13-11-2002 build). This because:
- the later official alpha-builds have either non-working mplayer postprocessing or broken nic's postprocessing, which is really required for good quality video.
- the latest Athos-builds have terrible performance (on my 1.2GHz Duron). Motion isn't smooth in a lot of scenes, which really irritates.
- the build from November 2002 seems to run fine here with almost all my DivX/XviD movies, even XviD1.0beta1 through 3. Only odd resolutions tend to cause problems.

Note that XviD's "packet bitstream" still doesn't work with ffdshow, although I still don't see the real benefit of this feature.

Soulhunter
30th December 2003, 21:53
no i havent heard anything :\ i hope he doesnt disappear like nando did..
Maybe they made a fusion and start a secret underground project... :D :D :D

Bye

iago
30th December 2003, 23:18
Maybe they made a fusion and start a secret underground project... :D :D :DLOL! If only they did! That'd be something terrific, I bet! :D

Btw, I have been using the latest alpha for some time without any problems on a slow machine (celeron 900), but without any post-processing either.

regards,
iago

Doom9
30th December 2003, 23:30
I've been in touch with milan regarding the codec comparison (ffvfw) and his last mail was sent a week before Christmas. He was sick then.. and with the holidays maybe he's just out of touch until he's back to work (or school.. I don't know what he does).

Vanos_b
31st December 2003, 15:50
For quiet some time now (builds after 2003-05-23), I've encountered a strange situation where if I resize (Aspect 4:3 for the image) with "Keep aspect ratio" checked (so the AR for the picture doesn't change) the picture is stretched to all the image. I resize only to be able to show the subtitles (with ffdshow) on the black border below a movie with ar 16:9 or 2.35:1, so it's not actually resizing, it's more like adding black borders, and I can manually set the AR of the picture so that the image looks ok and I have black borders too but it's nice to have it done by itself. That build and some before (but not all) worked fine for me; is there any other way to achieve this in the later builds?

Regards

oddball
2nd January 2004, 19:00
Are there any silent install switches for ffdshow? I'd like to install it using a custom XP ISO.

oddball
2nd January 2004, 22:53
OK this is a problem. ffdshow 20030523 uses NSIS as an installer but the /S switch does not work so no silent install. I tried to decompress the installer exe (as it's compressed with UPX 1.23) in order to see if that was causing the switch not to work. However Milan for some insance reason has scrambled the UPX compression so you cannot decompress it with the UPX application. Why? It's a freeware tool so no need surely? It's not like it's gonna need a crack or anything. Slaps Milan about a bit for that one. I think I metnioned this before sometime a while back.

Anyhow until I can find a UPX 1.23 descrambler I can't test if that is what causes the /S switch to fail or whether Milan screwed the NSIS script up and caused it to not function (He may have even done it deliberatly although I see no reason why).

Developers eh? ;)

sekxx
3rd January 2004, 10:38
take the ffdshow.ax
and use it in your unattend install of XP...

athos
3rd January 2004, 13:50
the NSIS script is in the cvs, just check it out.

oddball
3rd January 2004, 21:59
Heh. I just got told off by the moderator for violating rule #4. Rules eh? ;)

BlindWanderer
4th January 2004, 09:58
as to the modified version of upx, i think i remember coming across one in my travels, once upon a time. but i think they were just changing the UPX section tag so it would be harder to figure out what compression application was used. but it might have used custom compression too. But a version of UPX that doesn't decompress [I]is/I] in violation of the UPX license.

athos
4th January 2004, 13:15
Well I'm just using the regular upx from http://upx.sourceforge.net/ and the regular NSIS too.

oddball
4th January 2004, 15:12
Well feel free to see if you can decompress Milan's last official alpha of ffdshow.

basje
12th January 2004, 14:18
Hi there,

I have been using ffdshow 20031128 for a while now and found a problem with the overlays.

I use zoomplayer to play my divx/xvid and that was set to use the normal overlay to play the files, which was fine with the previous version (20030523). However, after upgrading to the 20031128 version of ffdshow, my video began to stutter a lot.

Eventually I found out that by enabling the VMR9 overlay in zoomplayer the problem was solved. So there is an overlay bug in the 20021128 version.

Anyone else having this problem?

Greetz,

Bas
---------------
WinXP SP1
DX9
ATI radeon 7500 Mobility

Gaia
12th January 2004, 16:49
Originally posted by basje
[B]Hi there,

I have been using ffdshow 20031128 for a while now and found a problem with the overlays.

I use zoomplayer to play my divx/xvid and that was set to use the normal overlay to play the files, which was fine with the previous version (20030523). However, after upgrading to the 20031128 version of ffdshow, my video began to stutter a lot.

Eventually I found out that by enabling the VMR9 overlay in zoomplayer the problem was solved. So there is an overlay bug in the 20021128 version.

Anyone else having this problem?

Greetz,

Bas
---------------

You can't enable overlay mixer in 20031128 build. If you do it, ffdshow wount load.

Anyway you should use latest "offical" alpha build from Sourceforge.

bilu
12th January 2004, 16:53
What's the current status of SVQ3 decoding?

I tried this method but didn't work:
http://forum.doom9.org/showthread.php?s=&postid=413287#post413287

3ivx gets registered as splitter, but ffdshow doesn't show up as filter when the MOV is opened. Checked in the Filters info on Zoom Player.

Tested with ffdshow-20031128 and ffdshow-20031028 builds.


Bilu

Defiler
12th January 2004, 16:55
Originally posted by Gaia
Anyway you should use latest "offical" alpha build from Sourceforge. Sadly, the latest official build has problems with various unwholesome things like DivX4, OpenDivX, etc.

filewalker
12th January 2004, 17:31
@bilu

Sorenson playback works nice with latest ffdshow in Graphedit & Zoomplayer.

Here is a thread (http://forum.inmatrix.com/ikonboard/ikonboard.cgi?s=4002c8442ce7ffff;act=ST;f=7;t=2706;hl=svq3) about Sorenson in ZP forum. Maybe it helps you.

Cu filewalker

LigH
12th January 2004, 17:50
Someone in the german Gleitz / doom9 forum reported that videos encoded with DivX 5.1.1 get increasingly greener during a "GOP" (or do I have to call these "VOPs" here?), which is reset at the next I frame. This effect is visible at his standalone DVD/DivX player, as well as using one of the current ffdshow versions, but not with the DivX 5 playback filter.

This reminds me: Milan wanted to fix the "Orange-blue bug" since I wrote him the last time (several months ago); but since then, he was never seen again...

bilu
12th January 2004, 19:18
Originally posted by filewalker
@bilu

Sorenson playback works nice with latest ffdshow in Graphedit & Zoomplayer.

Here is a thread (http://forum.inmatrix.com/ikonboard/ikonboard.cgi?s=4002c8442ce7ffff;act=ST;f=7;t=2706;hl=svq3) about Sorenson in ZP forum. Maybe it helps you.

Cu filewalker

It did help, thanks :)

Only problem now is QDesign Audio, it stops me from using some QT trailers as AVS sources with DirectShowSource() :(


Bilu

filewalker
12th January 2004, 20:24
Only problem now is QDesign Audio, it stops me from using some QT trailers as AVS sources with DirectShowSource()

I really miss a decoder for QDesign Music 2 codec, too.:(
because with such an decoder we could play most .mov files in DirectShow based players...*dreaming*

Cu filewalker

bilu
12th January 2004, 20:51
Originally posted by filewalker
I really miss a decoder for QDesign Music 2 codec, too.:(
because with such an decoder we could play most .mov files in DirectShow based players...*dreaming*

Cu filewalker What you can do for now is:

1) Extract Video Track
2) Save Movie as Self Contained

I can watch the video part even on WMP9 now. But I still can use it as an Avisynth source! :angry:


Bilu

Kurosu
13th January 2004, 02:08
I've compiled ffvfw, ffdshow and associated tools from a recent ffdshow CVS check, using MS VC++ 7.0, Direct X 9.0a SDK, NASM 0.98.35 and NSIS 2.0beta3 (the only that would allow the installer to be built). I couldn't build the wm9 encode module, so I have just added the 20030927.

This was a "click and forget" encode: no CVS checkout of the various projects like ffmpeg on which ffdshow/vfw are based. However the asm files compiled fine with nasm.

Here are the files:
ffVfW (http://kurosu.inforezo.org/ffvfw-20041301.exe)
ffDShow (http://kurosu.inforezo.org/ffdshow-20041301.exe)

I haven't followed this thread in a very long time so I don't know if any fix was expected.

oddball
13th January 2004, 03:16
Video playback still jerks. I really hope the final build fixes that or it's not worth upgrading.

athos
13th January 2004, 11:47
Nice with other builders!

However, latest updates to CVS are still
ffdshow: 2003-10-17 13:59
ffvfw: 2003-10-14 15:05

Andy2222
26th January 2004, 14:08
Originally posted by Kurosu
I've compiled ffvfw, ffdshow and associated tools from a recent ffdshow CVS check, using MS VC++ 7.0, Direct X 9.0a SDK, NASM 0.98.35 and NSIS 2.0beta3 (the only that would allow the installer to be built). I couldn't build the wm9 encode module, so I have just added the 20030927.

This was a "click and forget" encode: no CVS checkout of the various projects like ffmpeg on which ffdshow/vfw are based. However the asm files compiled fine with nasm.

Here are the files:
ffVfW (http://kurosu.inforezo.org/ffvfw-20041301.exe)
ffDShow (http://kurosu.inforezo.org/ffdshow-20041301.exe)

I haven't followed this thread in a very long time so I don't know if any fix was expected.


WOHOO!

What build u used to for that? And what was the main diff. to the Athos or the latest 05/2003 build?

I just ask cause your build solved all the rezise/sharpen green problems for me discribed here: http://www.avsforum.com/avs-vb/showthread.php?postid=3265959#post3265959

The only problem is that build is so damm slow that i cant even rezise to 800x600 :(

@Athos maybe u can check that thread and see whats diff. from that to your releases cause that rezise green bug drives me crazy. Its prolly somethign in teh color conversion code.

For the WM9 u need the "wm_avcodec_interface_setup.exe" sample for the include.

PS: how many warnings u got with VC7++ and did u correct the 2 link errors in the IffDecoder (comment.c not included) and forgot the "PURE;" in the IffDecoder.h at "compat_findAutoSubflnm2" also the same compiling error with the "colorspace_mmx.inc" -> "./colorspace_mmx.inc" xvid compiles have :)

Is your compile teh debug or release or ICL? Since my compile has the same green rezise bug like Atho's. What includes/libs u have pls? I realy need a way to find whats diff. from your compile to my own and athos...

Andy2222
26th January 2004, 17:25
Any tips for the compiler settings in? What VC++ comiler settings u use? *blend or ppro or some other settings to boost the speed?

My own comiles are damm slow... :( have VC++ 6.0 with SP5 + processor pack.

arno
26th January 2004, 19:12
Originally posted by athos
Nice with other builders!

However, latest updates to CVS are still
ffdshow: 2003-10-17 13:59
ffvfw: 2003-10-14 15:05

I'm really sad about the fact that it seems that ffdshow is really stalled now. The latest official release is from May last year, and all other later Athos builds are broken in some way (postprocessing and/or bad performance (stuttering). As the number of incompatibilities with ffdshow and DivX5.1+ & XviD seems to increase I think on the short term a lot of users are forced to move to the DivX5 codec for the decoder part (as it also support XviD) :-(

p.s. Athos did you hear anything from Milan lately?

CruNcher
26th January 2004, 20:10
anybody knows by what this is caused ? maybe athos or kurosu


dxguid.lib(dxguid.obj) : error LNK2005: _IID_IDirectDrawSurface already defined in strmbase.lib(strmiids_guid185.obj)
dxguid.lib(dxguid.obj) : error LNK2005: _IID_IDirectDraw2 already defined in strmbase.lib(strmiids_guid184.obj)
dxguid.lib(dxguid.obj) : error LNK2005: _IID_IDirectDraw already defined in strmbase.lib(strmiids_guid183.obj)
dxguid.lib(dxguid.obj) : warning LNK4006: _IID_IDirectDrawSurface already defined in strmbase.lib(strmiids_guid185.obj); second definition ignored
dxguid.lib(dxguid.obj) : warning LNK4006: _IID_IDirectDraw2 already defined in strmbase.lib(strmiids_guid184.obj); second definition ignored
dxguid.lib(dxguid.obj) : warning LNK4006: _IID_IDirectDraw already defined in strmbase.lib(strmiids_guid183.obj); second definition ignored
Creating library Release_ICL/ffdshow.lib and object Release_ICL/ffdshow.exp
TffDecoder.obj : error LNK2001: unresolved external symbol _MEDIASUBTYPE_IYUV
TffDecoder_reg.obj : error LNK2001: unresolved external symbol _MEDIASUBTYPE_IYUV
TglobalSettings.obj : error LNK2001: unresolved external symbol _MEDIASUBTYPE_IYUV
TffDecoder.obj : error LNK2001: unresolved external symbol _IID_IMixerPinConfig2
TffDecoder.obj : error LNK2001: unresolved external symbol "protected: long __thiscall CVideoTransformFilter::AbortPlayback(long)" (?AbortPlayback@CVideoTransformFilter@@IAEJJ@Z)
TffDecoder.obj : error LNK2001: unresolved external symbol "public: virtual long __stdcall IffDecoder::compat_findAutoSubflnm2(void)" (?compat_findAutoSubflnm2@IffDecoder@@UAGJXZ)
TffdshowEnc.obj : error LNK2001: unresolved external symbol _MEDIASUBTYPE_None
bin\ffdshow.ax : fatal error LNK1120: 5 unresolved externals
Error executing xilink6.exe.

ffdshow.ax - 11 error(s), 3 warning(s)

gabest
26th January 2004, 20:33
dxguid.lib is only needed if you don't know how to use initguid.h, but if you use it and still link dxguid.lib then such problems can happen :)

Andy2222
26th January 2004, 20:39
Originally posted by CruNcher
anybody knows by what this is caused ? maybe athos or kurosu


dxguid.lib(dxguid.obj) : error LNK2005: _IID_IDirectDrawSurface already defined in strmbase.lib(strmiids_guid185.obj)
dxguid.lib(dxguid.obj) : error LNK2005: _IID_IDirectDraw2 already defined in strmbase.lib(strmiids_guid184.obj)
dxguid.lib(dxguid.obj) : error LNK2005: _IID_IDirectDraw already defined in strmbase.lib(strmiids_guid183.obj)
dxguid.lib(dxguid.obj) : warning LNK4006: _IID_IDirectDrawSurface already defined in strmbase.lib(strmiids_guid185.obj); second definition ignored
dxguid.lib(dxguid.obj) : warning LNK4006: _IID_IDirectDraw2 already defined in strmbase.lib(strmiids_guid184.obj); second definition ignored
dxguid.lib(dxguid.obj) : warning LNK4006: _IID_IDirectDraw already defined in strmbase.lib(strmiids_guid183.obj); second definition ignored
Creating library Release_ICL/ffdshow.lib and object Release_ICL/ffdshow.exp
TffDecoder.obj : error LNK2001: unresolved external symbol _MEDIASUBTYPE_IYUV
TffDecoder_reg.obj : error LNK2001: unresolved external symbol _MEDIASUBTYPE_IYUV
TglobalSettings.obj : error LNK2001: unresolved external symbol _MEDIASUBTYPE_IYUV
TffDecoder.obj : error LNK2001: unresolved external symbol _IID_IMixerPinConfig2
TffDecoder.obj : error LNK2001: unresolved external symbol "protected: long __thiscall CVideoTransformFilter::AbortPlayback(long)" (?AbortPlayback@CVideoTransformFilter@@IAEJJ@Z)
TffDecoder.obj : error LNK2001: unresolved external symbol "public: virtual long __stdcall IffDecoder::compat_findAutoSubflnm2(void)" (?compat_findAutoSubflnm2@IffDecoder@@UAGJXZ)
TffdshowEnc.obj : error LNK2001: unresolved external symbol _MEDIASUBTYPE_None
bin\ffdshow.ax : fatal error LNK1120: 5 unresolved externals
Error executing xilink6.exe.

ffdshow.ax - 11 error(s), 3 warning(s)


Long story.. u must have installed the dx9b sdk and compile a new strmbase.lib from the "C:\DX9BSDK\SAMPLES\C++\DIRECTSHOW\BASECLASSES" just load the baseclasses.dsw and compile both the release and debug version fresh.

Also u need add "C:\DX9BSDK\SAMPLES\C++\DIRECTSHOW\BASECLASSES" and "C:\DX9BSDK\INCLUDE" in the VC include directory at TOP. Means before the normal VC98 includes, just move it up.

Andy2222
26th January 2004, 20:44
Originally posted by Kurosu
I've compiled ffvfw, ffdshow and associated tools from a recent ffdshow CVS check, using MS VC++ 7.0, Direct X 9.0a SDK, NASM 0.98.35 and NSIS 2.0beta3 (the only that would allow the installer to be built). I couldn't build the wm9 encode module, so I have just added the 20030927.

This was a "click and forget" encode: no CVS checkout of the various projects like ffmpeg on which ffdshow/vfw are based. However the asm files compiled fine with nasm.

Here are the files:
ffVfW (http://kurosu.inforezo.org/ffvfw-20041301.exe)
ffDShow (http://kurosu.inforezo.org/ffdshow-20041301.exe)

I haven't followed this thread in a very long time so I don't know if any fix was expected.


BTW i found the error, the color conversion bug is caused my the libmplayer.dll. If i use the libmplayer.dll from athos releases i have that green color bug described. if i use the libmplayer.dll from Kurosu release i dont have that bug. Strange is that both releases are v2.3 but Athos is much bigger 420k and 74k? What compile settings u used Kurosu and where u got that new libmplayer from?

The color conversion bug is shown here and happen's with all ffdshow releases from 05-11/2003:
http://img17.photobucket.com/albums/v50/Andy2222/colorcheck.png

If i just copy Kurosu libmplayer.dll into the installed version of Athos the color bug is gone. Seems something is diff. with Kurosu version.