ffdshow development [Archive]

athos

18th April 2003, 19:17

Finally, I managed to make a working build of ffdshow. It seems I had managed to screw up DirectX 9 SDK :\

Anyway, ffdshow-20030418.exe was built from a fresh checkout of the CVS tree, V1 branch, which is supposed to be stable. Did some quick testing only.

Take note: the property page (config) will crash unless you have ffvfw installed. I think this is due to milan working on integrating these two projects (either that or i screwed something else up ;)). For this reason I will not put up this build on sourceforge.

You can download this build of ffdshow, as well as my latest build of ffvfw from http://athos.web1000.com/ffvfw.html. I am aware that some people are having trouble downloading from this site, so please feel free to help me out by mirroring this file. I will put up a build at sf.net when the ffvfw issue has been resolved.

Also note that sh0dan has compiled later builds of ffvfw, located at http://cultact-server.novi.dk/kpo/avisynth/avs_cvs.html and nitrogen has mirrors at http://homepages.pathfinder.gr/ffvfw and http://nitrogen.kicks-ass.net/ffvfw/. I only tested with my ffvfw-20030325 build, dont know what other ones work.

the changelog for ffdshow since 20030103:

2003-04-16 14:05 milan_cutka

getParamStr2, autoload preset by file extension,
IffProc::processRGB_2, working on resizing using IffProc

2003-04-15 10:05 milan_cutka

file helpGrab.txt was initially added on branch V1.

2003-04-15 10:05 milan_cutka

"ffvfw needed for JPEG" info

2003-04-15 09:21 milan_cutka

also look in ffdshow.ax folder for dynamic libraries

2003-04-15 09:20 milan_cutka

no message

2003-04-15 06:47 milan_cutka

quantStride

2003-04-14 08:50 milan_cutka

updated VC6 project

2003-04-14 06:50 milan_cutka

file aws_api.h was initially added on branch V1.

2003-04-14 06:50 milan_cutka

file aws.obj was initially added on branch V1.

2003-04-14 06:50 milan_cutka

file TimgFilterWarpsharp.h was initially added on branch V1.

2003-04-14 06:50 milan_cutka

file TimgFilterWarpsharp.cpp was initially added on branch V1.

2003-04-14 06:50 milan_cutka

file Cwarpsharp.cpp was initially added on branch V1.

2003-04-14 06:50 milan_cutka

file helpWarpsharp.txt was initially added on branch V1.

2003-04-14 06:50 milan_cutka

file Cwarpsharp.h was initially added on branch V1.

2003-04-14 06:50 milan_cutka

file warpsharp.html was initially added on branch V1.

2003-04-14 06:50 milan_cutka

aWarpSharp (binary only) by Marc FD, separated warpsharping
filters, updated libavcodec and libmpeg2, quantizer array for
libmpeg2 (inspired by mplayer), newver IffProc interface for ffvfw,
support for temporary (in memory) presets

2003-03-31 16:27 milan_cutka

no message

2003-03-31 16:24 milan_cutka

libpostproc 5-tap lowpass deinterlacer switch

2003-03-31 16:11 milan_cutka

edge bug workaround switch

2003-03-31 15:51 milan_cutka

no message

2003-03-31 14:14 milan_cutka

updated libavcodec, updated postproc

2003-03-31 06:46 milan_cutka

trying to simplify startup, updated libavcodec

2003-03-28 06:46 milan_cutka

IffProc3

2003-03-27 16:35 milan_cutka

va_end

2003-03-27 06:36 milan_cutka

libswscale version

2003-03-16 21:59 milan_cutka

no message

2003-03-13 09:35 milan_cutka

fixed tray icon menu preset selection

2003-03-13 08:54 milan_cutka

dlls moved to ffdshow.ax directory, xvid_malloc->pp_malloc in
libmplayer

2003-03-13 06:50 milan_cutka

updated libavcodec, libmplayer can be static or dynamic, fixed mpeg
decoding with libavcodec, quantizer display, updated swscaler, and
maybe more...

2003-02-18 17:00 milan_cutka

new macro in nsis 2 script

2003-02-18 16:37 milan_cutka

V1

2003-02-18 15:48 milan_cutka

removed read only checkbox from open file dialogs

2003-02-18 09:51 milan_cutka

V2 cleanup

2003-02-18 09:50 milan_cutka

V1 cleanup

2003-02-18 09:02 milan_cutka

optimized uncompressed YV12 input

2003-02-17 19:19 milan_cutka

xvid stride fix

2003-02-17 19:08 milan_cutka

V2

2003-02-17 18:32 milan_cutka

no message

2003-02-17 18:21 milan_cutka

no message

2003-02-17 18:18 milan_cutka

no message

2003-02-17 17:05 milan_cutka

faster YV12,I420 uncompressed input

2003-02-17 16:30 milan_cutka

moved bswap

2003-02-17 16:24 milan_cutka

updated libavcodec (more encoding code removed)

2003-02-17 15:28 milan_cutka

updated postproc and swscale

2003-02-17 13:59 milan_cutka

updated legal headers, removed 3 from classes names

2003-02-17 13:55 milan_cutka

V1 - stable branch

2003-02-17 13:45 milan_cutka

V1 - stable branch

2003-02-17 13:42 milan_cutka

V1 - stable branch

2003-02-17 13:39 milan_cutka

V1 - stable branch

2003-02-17 06:49 milan_cutka

no message

2003-02-13 14:35 milan_cutka

I'm not sure...

2003-02-12 14:20 milan_cutka

trying to get colorspaces work

2003-02-11 06:40 milan_cutka

no message

2003-02-05 15:02 milan_cutka

no message

2003-02-05 13:39 milan_cutka

better showMV, working on ...

2003-02-05 07:17 milan_cutka

can connect to mpeg2 decoder filters (cyberlink, intervideo),
working on colorspaces

2003-01-29 15:45 milan_cutka

no message

2003-01-28 15:58 milan_cutka

no message

2003-01-27 06:47 milan_cutka

no message

2003-01-24 15:46 milan_cutka

no message

2003-01-23 07:06 milan_cutka

no message

2003-01-22 17:19 milan_cutka

saving ffdshow settings to bytestream (no loading yet), alligned
alocator for lavc

2003-01-22 06:46 milan_cutka

ffdshow is partially working again

2003-01-21 15:09 milan_cutka

trellis quant not allowed for mjpeg

2003-01-21 06:40 milan_cutka

working on better support for multiple colorspaces 3 (not working
now)

2003-01-20 15:07 milan_cutka

virtual base destructor

2003-01-17 14:21 milan_cutka

working on better support for multiple colospaces 3 (ffdshow can't
be compiled right now)

2003-01-16 15:23 milan_cutka

no message

2003-01-16 07:01 milan_cutka

Twindow for TffdshowPage, DPRINTF from XviD, working on better
support for multiple colorspaces 2

2003-01-16 06:59 milan_cutka

no message

2003-01-15 15:01 milan_cutka

Twindow

2003-01-15 11:12 milan_cutka

Twindow

2003-01-15 11:11 milan_cutka

updated libavcodec, Twindow

2003-01-15 10:00 milan_cutka

removed #undef ARCH_X86 - was left from debugging

2003-01-07 15:48 milan_cutka

working on better support for multiple colorspaces

2003-01-07 09:26 milan_cutka

fixed vc6 compilation

2003-01-07 06:41 milan_cutka

updated libavcodec, preliminary avisynth scripts support, subtitles
font autosize
edit: link fixed

Doom9

18th April 2003, 20:15

@athos: the link either goes to a web1000 search site and one in 5 times I tried I ended up on a swedish site.

mwillberg

18th April 2003, 20:20

if you remove the last "." from the link it seems to work ok...

cult

18th April 2003, 20:23

same here :(

Swede

18th April 2003, 23:04

I've just put up a mirror of these 2 files at:
http://leffe.dnsalias.com/ffdshow-20030418.exe and
http://leffe.dnsalias.com/ffvfw-20030325.exe

Hope this helps.

Best

19th April 2003, 01:47

I still cant get MPEG1 and 2 playback to work:(
am I doing somthing wrong or is it stil broken?

bbq@KL

19th April 2003, 03:32

Oh yeah, even Avisynth is added to ffdshow now. Is it working or not?

Thank you.

kilg0r3

19th April 2003, 09:14

Oh yeah, even Avisynth is added to ffdshow now. Is it working or not?

How is it supposed to work?

Ok, just tried it. You can just enter the filters you want, and levae the clip position unspecified).

This could be a nice weapon agains the black locking issue, without having to modify the the stream during the encode. It was suspected that the phenomenon is caused by luma values which are invalid for TV display. If this is true, a simple 'limiter()' inserted in ffdshow should do the trick.

Very nice! THANK YOU MILAN!

kairen

19th April 2003, 09:16

i wasn't able to configure ffdshow on Win Xp
it give me an exception on ffdshow.ax,configure

thank you

kilg0r3

19th April 2003, 09:29

@kairen

Have you installed ffvfw? It is required.

kairen

19th April 2003, 09:43

yes, but it was the older version, i'll try the newer version

really thank you

kastro68

19th April 2003, 09:44

@Kilgor3
Do you know if the latest ffdshow solves some of the earlier qpel/b-frame smearing?

kilg0r3

19th April 2003, 10:57

@kastro68 My only sources of info are the doom9 forum and the changelog. sorry.

Didée

19th April 2003, 12:05

Doesn't work for me, grrr!

I had shodan's compile of ffvfw from 04-15 installed: "exception on ffdshow.ax,configure"
Re-installed ffvfw from 03-25: "exception on ffdshow.ax,configure"
I tried every mathematically possible mutation of de-installing, rebooting and re-installing ffvfw and ffdshow ...

:devil:

BUT, atm I'm sitting at my old Athlon-Classic machine. Could it be that ISSE extensions are required (compiler options?) ... ?

The good news is, that for the first time ever, the input pre-processing in ffvfw is working ;)

moko

19th April 2003, 13:21

Where did the divx3, ms mpeg-4 and mpeg-1/2 support gone in ffdshow? tried to check it in the decoding tab in ffvfw but it didn't help either.

sysKin

19th April 2003, 14:26

Hi,

I just wanted to confirm that smearing, which used to be visible when decoding XviDs with quarterpel enabled, is history.

Thanks!

unplugged

19th April 2003, 14:46

Originally posted by sysKin
I just wanted to confirm that smearing, which used to be visible when decoding XviDs with quarterpel enabled, is history.
Hmmm... not be too sure.
To me smearing hasn't gone, not even with quant. 2. :(
I'm using ffdshow-20030418 and ffvfw-20030415 and tested these with XviD videos made with the good uManiac's build 20030414 (in fact is an excellent :) build, one of my suspects is that ICL7 or ICLx with its "aggressive" optimizations is penalizing quality of Koepi's ones; maybe?).

But, I could strongly advise to download latest version of Envivio MPEG-4 player (www.envivio.com) v1.5, with this updated version latest XviD videos look perfect and even better decoded than internal xvid routine!! :D.
(previously converted from AVI to MP4 container with MP4creator.exe by MPEG4IP 0.9.8 tools)

Edit: love love love how well works now XviD ISO MPEG-4 compilance
I have performed videos using Qpel, chroma me, B frames, VHQ4 and with all the incredible stuff xvid has, and it compresses and looks damn good with MP4 player!!
Congratulations to all developers!

P.S.: waiting DivX 7.0 for a worth web comparison/review :D.

athos

19th April 2003, 15:32

Please note that this build works even without ffvfw installed, but not the config page. I think milan intends ffvfw and ffdshow to be independent, but like I wrote, he is working on making them able to work together. I probably checked out the CVS in the middle of his work. But at least we have a working build after 4 months ;)

There should be no need for SSE instructions, I compiled it with Code Generation: Blend in VC6 and -march=586 -Mcpu=686 in gcc, ie should work on all processors.

sysKin

19th April 2003, 15:44

Originally posted by unplugged
[B]Hmmm... not be too sure.
To me smearing hasn't gone, not even with quant. 2. :(
I'm using ffdshow-20030418 and ffvfw-20030415 and tested these with XviD videos made with the good uManiac's build 20030414 (in fact is an excellent :) build
Umaniac's builds use old 'xvid' iDCT which can't cope with qpel correctly. Set ffdshow's idct to 'xvid' and maybe it will halp, maybe not - that's why Koepi uses 'simple' idct in his builds, and xvid will only use 'simple' soon.
P.S.: waiting DivX 7.0 for a worth web comparison/review :D.Aaaagh you're being mean! ;) You are going to allow DXN to create and tweak their 'standard' as much as they want, and you'll compare it against poor XviD which has to stick to some old and ugly mpeg4? Mean mean mean ;PPPP

I could tweak mpeg4 a lot and improve compression with my bare hands ;P yet I won't because I can't create my own codec just like that. Anyway, what I mean is, it's reasonaby easy :) so please, compare xvid against other mpeg4 codecs :D

Radek

Koepi

19th April 2003, 16:18

Originally posted by unplugged
build, one of my suspects is that ICL7 or ICLx with its "aggressive" optimizations is penalizing quality of Koepi's ones; maybe?).

NO! no. no.

As I wrote on that particualar thread, those optimizations don't affect the quality at all.

EDIT: rant deleted. But PLEASE forgot what you read there. It's like I replied there, NO quality loss due to compiler optimizations.

Regards
Koepi

cdrips

19th April 2003, 21:07

I didn't know what to search for for this, so don't hurt me. I was just wondering if the 6/17 ffdshow will decode qpel or GMC. I know the alpha does, but not sure if it is just me or the old build which doesn't. Also, are there any filter like qpel or gmc that would mimic what these xvid options do?

19th April 2003, 22:14

Originally posted by Koepi
EDIT: rant deleted. But PLEASE forgot what you read there. It's like I replied there, NO quality loss due to compiler optimizations.

Regards
Koepi
:( :scared: :( Why do I always read a post after the rant has been deleted! Poor me I never get to read a good rant :(.

ummon

19th April 2003, 22:54

I have the same Problem as moko. With the 20030418 version of ffdshow I can only select the Codecs played by xvid.dll everything that should be played by libavcodec is not selectable. Has anybody an idea why this happens? The older versions of ffdshow don't show this problem.
I use Win98SE, DirectX 9.0a, ffvfw-20030325

iago

20th April 2003, 00:15

@athos,

Thanks a lot for the new build.

Btw, latest ffdshow-20030418 OSD doesn't report QPEL frames I guess. Or is there something that I miss?

esby

20th April 2003, 02:06

Mmm I'm getting the same problem as Moko,
All i can encode to with ffvfw is:
Theora, Mpeg1 & Mpeg2

It's like if choosing an encoder discard the possibility
of using a default encoder profile,
one allowing div3 etc.

esby

drebel

20th April 2003, 03:10

Btw, latest ffdshow-20030418 OSD doesn't report QPEL frames I guess. Or is there something that I miss?
Confirmed with more than 5 qpel clips.The clips were encoded with umaniac's 14.04.03.No smearing though...

HarryM

20th April 2003, 05:24

This ffdshow build use forced-using xvid.dll for decoding. Logically- it can't q-pel smearing no more.
It using (only) external xvid.dll for decoding!

Kyo

20th April 2003, 08:22

whis a clip encoded with custom matrix (andreas_78) and qpel+ 2bframes I get this "evil" problem :(

See This Pic (http://pwp.007mundo.com/kyo/andreas+ffds.jpg)

The problem is gone when I check the "Use XviD"

CruNcher

20th April 2003, 09:52

@Kyo

thats a known dequantization problem with some custom matrices and libavcodec the same happens with Trbarrys SoftMatrix try to lower the quant values a bit and it should work XviD as decoder has no problems with it but ffdshow doesn't like it wich one now is doing it right thats a good question anybody knows the matrix specs ?

http://forum.doom9.org/showthread.php?s=&threadid=50673

20th April 2003, 11:39

Could someone merge this with this (http://forum.doom9.org/showthread.php?s=&threadid=48511) ?

EDIT by Koepi: Ok, done ;) Happy easter everyone!

cweb

20th April 2003, 14:07

Has anyone yet tested ffvfw to make analog captures using huffy-yv12 or
even mpeg2, using Virtualdub+vcr, or using VirtualVCR?

I think I'll have a go at it.. :)

cweb

20th April 2003, 14:17

I tried it with mpeg2 - Virtualvcr wouldn't capture
and gave me this error:

could not render filter
Smart Tee-> Compression Codec -> Flow Meter

I did use the highest possible bitrate and force yv12, so that might have something to do with the error :)

Edit: Back in the ffvfw codec I lowered the mpeg2 bitrate to 1470, changed the setting to Interlaced, and disabled force YV12.
I'll next try again but with the highest bitrate and see what happens.

Edit2: I raised the mpeg2 bitrate. Moving the Virtualvcr window
during the capture was more difficult - I guess more processing
power is going to the codec.
Now how do I play these 'avi's? They don't seem to playback
at all.. I used the default mpeg FOURCC, should I have used
something else?

Edit3: I read the ffvfw webpage and it's clear now. Only XviD
playback is supported so far. Ok, it will be interesting when
mpeg1 or 2 playback is added.

Next I'll try Virtualdub+VCR.

Valky

20th April 2003, 15:01

And has ANYONE had any divx-codec or mpg1 decoded with this one..?

athos

20th April 2003, 15:03

Originally posted by ummon
I have the same Problem as moko. With the 20030418 version of ffdshow I can only select the Codecs played by xvid.dll everything that should be played by libavcodec is not selectable. Has anybody an idea why this happens? The older versions of ffdshow don't show this problem.
I use Win98SE, DirectX 9.0a, ffvfw-20030325

I just checked and for me it's the opposite! But i think this is because i dont currently have xvid installed ... ;)

Check to see that libavcodec.dll is in the ffdshow dir.

HarryM

20th April 2003, 15:22

Originally posted by athos
I just checked and for me it's the opposite! But i think this is because i dont currently have xvid installed ... ;)

Check to see that lobavcodec.dll is in the ffdshow dir.

libavcodec.dll, maybe?

This library I have in ffdshow dir, but only XviD, Div4, DivX5 is selectable. For decoding is using xvid.dll. I cant deactivate 'use xvid.dll for decoding', it is forced!

I have Win98SE.

iago

20th April 2003, 15:30

Originally posted by drebel
... No smearing though... Yep, qpel smearing indeed seems to have gone when decoding with the latest ffdshow, and that's great!

ECY

20th April 2003, 18:16

did anyone get ffdshow-20030418 running on Win98 ?
There seems to be a problem that ffdshow can't use the "libavcodec.dll" on Win9x/me
can someone confirm this ?

Gaia

20th April 2003, 18:31

Originally posted by ECY
did anyone get ffdshow-20030418 running on Win98 ?
There seems to be a problem that ffdshow can't use the "libavcodec.dll" on Win9x/me
can someone confirm this ?

Works great with Win98se! So somenthing else is wrong.

ECY

20th April 2003, 18:43

Originally posted by Gaia
Works great with Win98se! So somenthing else is wrong.

you're sure you're not using XVID to decode ?
cause i get it running using the xvid option but not with libavcodec.dll

drebel

20th April 2003, 18:54

This ffdshow build use forced-using xvid.dll for decoding. Logically- it can't q-pel smearing no more.
It using (only) external xvid.dll for decoding!

No probs in Win2ksp3.Decodes all mpeg4 material without any codecs installed.Only a reliable (not damaged ang new) version of Libavcodec.dll is needed

GMC use is being reported fine...

Gaia

20th April 2003, 19:30

Sorry i was wrong, this really seems to be strange OS problem because i am forced to use Xvid as well and yes i have Libavcodec.dll in ffdshow directory.

Mistar Muffin

20th April 2003, 21:44

It seems that Mplayer pprocessing is broken in this release. Is it just me? (Win XP Pro SP1, Athlon 1.4ghz)

ummon

20th April 2003, 22:20

I just checked, all files including libavcodec.dll seem to be installed right. I also uninstalled XviD only with the result that Huffyuv and Raw video remain the only formats ffdshow can decode.
Seeing the other people having the same problems with Win9x/ME too I think libavcodec decoding under these OSs is broken. :( Regarding that milan said that he is currently changing ffdshow's COM interfaces, so that ffdshow, ffvfw and ffdub can cooperate, (http://forum.doom9.org/showthread.php?s=&threadid=42710&perpage=20&pagenumber=10) I guess the problem has something to do with the changes and will be hopefully fixed soon.
Or did anyone see a better solution than waiting and hoping for the next alpha?

Blight

20th April 2003, 22:23

I hope milan is still reading this, I've found two somewhat severe bugs (that exist prior to this release and still exist in it):

1. Using FFDShow as a post-processor along with VMR9 in a format that contain an internal AR flag (MPEG1/MEPG2, maybe WMV) will break the AR control for that format.
2. When trying to open the VMR9 property dialog, it will throw off a Division by Zero exception.

oddball

20th April 2003, 22:40

Are the options to playback MPEG2 in ffdshow a no go? I tried it and all I get is a blank screen and a blank screen with occasional colored blocks if I enable libmpeg2 as well.

Just curious as to why the options are there if they do not work. Or do they? Am I missing something?

Rober2D2

21st April 2003, 03:14

athos

21st April 2003, 10:45

I have looked around a bit in the ffdshow code to see if it would be easy to fix the ffvfw dependency. I will try to do it later today using a proper "debug" compile, but i feel a little uncomfortable even if i could fix it as i might just introduce new bugs. i'd rather see milan do it. from what i understand ffdshow is supposed to check to see if ffvfw is present, but right now it seems it assumes it.

Zarxrax

21st April 2003, 16:23

I was going to try the MakeAVIS utility, but when I run it I get an error "failed to initialize avisynth". Do you have to have Avisynth 2.5 or something?

athos

21st April 2003, 20:03

I made a new build today. As Web1000 seems very unreliable (I cant even get in myself now!) I have asked Swede to mirror this.

It is the same CVS checkout as the last build, since there have been no updates to the CVS since 20030416. Therefore libavcodec.dll, libmpeg2_ff.dll, libmplayer.dll and TomsMoComp_ff.dll are exacly the same, not recompiled.

This time I did use the flag /QaxW to let ICL use processor extension (MMX/MMX2/SSE) which might provide some speed increases for non-optimized filters. Most likely there be few or no noticable improvements from this. Also, the usage of these extensions are not required, so it should still work on older processors.

I also managed to get the config page working without ffvfw! However, this is done through a pretty ugly hack, it seems the problem was in a function that tries to load ffvfw.dll to see if it is present, and if so, returns "true", else "false". I simply changed it to always return "false". I think this will only affect the jpeg output of the Grab function, but there might be other bugs. You might want to wait for milan to do a proper fix for this bug.

To conclude: bugs in this release might be caused by me.

Edit: uploaded it to SourceForge (http://sourceforge.net/project/showfiles.php?group_id=53761&release_id=154364)

Gaia

21st April 2003, 20:31

Just a little note, if you're using Win98se/Me you're still forced to use Xvid decoding in this latest build.

Swede

21st April 2003, 20:41

Originally posted by athos
Edit: uploaded it to SourceForge (http://sourceforge.net/project/showfiles.php?group_id=53761&release_id=154364)
Ah, then you might not need my mirror but I'd put it there anyhow. http://athos.leffe.dnsalias.com/ is for your builds.

Animaniac

21st April 2003, 21:21

Is chroma level fixing going to be implemented again? I believe it was in a much older build, and I'd like to see it again. Luminance level fixing alone seems to cause a lot of image loss in bright sections of the video, and maybe chroma level fixing would fix that. I hate the white fuzz DirectShow filters cause. >.< Thanks and awesome work.

((( atom )))

22nd April 2003, 00:16

i still get smearing with ffdshow from 21.04.03 and simple idct using koepis build of 05.04.03 and ffvfw from 15.04.03.

does anybody know if the qpel-situation is solved under linux meanwhile? i personally don't use anything else for watching my movies and just for editing i don't care..

athos

22nd April 2003, 00:51

Update: I took a deeper look at the code, and I think I managed to do a better fix to the ffvfw problem, a fix which should allow ffvfw to be used if present. I have mailed my solution to milan. I also compiled using ICL7.1 which allows the compiler to create separate code for MMX, SSE and SSE2 and then choose at runtime which to use. There is also generic code for processor which have none of these. This should allow Pentium MMX/II/III and Athlon (with SSE) users to take whatever benefit this compiler can create. Previously it only created Pentium4 and generic code.

I screwed up when sending this file to sourceforge, so for now it is only available at http://athos.leffe.dnsalias.com

Good night everyone.

Edit: Up on sourceforge now.

Animaniac

22nd April 2003, 00:53

I'm not sure what to make of this, whether it is a bug or if is the correct behavoir. ffdshow seems to choose the YUY2 colorspace over YV12 colorspace even when video is encoded in YV12 (XviD). Is this what should expected? Thanks.

athos

22nd April 2003, 10:19

Good news: milan has fixed the Win98 vs libavcodec bug, will be in next release.

ECY

22nd April 2003, 12:01

wow that's great news.
hope it will be release soon

esby

22nd April 2003, 12:41

My problem with the config was gone with reinstalling ffvfw without theora & mpeg1/2 support.

But anyone experienced a '1 frame lag'
when using ffvfw as decoder.
Meaning it will put as first frame
the one it has somewhere in buffer. ( from last clip decoded)
and for the second the first that should be used, etc.?

(I noticed that with dvx5 decoding)

esby

MoonWalker

22nd April 2003, 13:16

Originally posted by Animaniac
I'm not sure what to make of this, whether it is a bug or if is the correct behavoir. ffdshow seems to choose the YUY2 colorspace over YV12 colorspace even when video is encoded in YV12 (XviD). Is this what should expected? Thanks.

Are you using DVobSub for subtitles?? If so, try changing the colorspace order at the config tab of DVobSub..

MoonWalker

sapient

22nd April 2003, 13:47

Hi,

The new version of ffdshow has all the codecs (except the last 2) greyed out. I have win98, and I haven't installed ffvfw, divx or xvid. All previous versions worked without any of those installed, making ffdshow all anyone needed if he only wanted to watch and not encode mpeg4 clips. Why the change?

sapient

Animaniac

22nd April 2003, 16:15

Originally posted by MoonWalker
Are you using DVobSub for subtitles?? If so, try changing the colorspace order at the config tab of DVobSub..

MoonWalker

Hm you were right, the order was backwards there, but it still chooses YUY2. I didn't think that it would affect the video when subtitles aren't present. I'm also using Tobais's SubTitDS. That filter seems to always load, could it be the problem?

Edit: Yeah, uninstalling that fixed it. DVobSub can handle OGMs on it's own now, so that's great. Thanks.

athos

22nd April 2003, 17:21

Originally posted by sapient
Hi,

The new version of ffdshow has all the codecs (except the last 2) greyed out. I have win98, and I haven't installed ffvfw, divx or xvid. All previous versions worked without any of those installed, making ffdshow all anyone needed if he only wanted to watch and not encode mpeg4 clips. Why the change?

sapient

If you read just a few posts up you will see that this is a known problem with ffdshow and win98, and it has been fixed and will be in the next release.

Alxemi

22nd April 2003, 21:00

Hi all
I´ve been reading the forum and i´m a little confused..
I use win98 and i know the libacodec bug, the question is
It´s because this bug i can´t change the IDCT (forced to Xvid)?
The Qpel improvement in xvid decoding is only active using Simple IDCT, is´nt it?

Thank you all, and especially to ffdshow/ffvfw developers

Alxemi

22nd April 2003, 21:14

I have mirrored ffdshow-20030422, maybe it helps somebody

http://alxemi.cjb.net//ffdshow-20030422.exe

CruNcher

23rd April 2003, 19:33

im useing the new ffdshow-20030422.exe and experienced a strange problem with an older XviD encode 0.9 release stable simple profile it only displays Grey no picture only Grey could somebody test his old 0.9 encodes ? viewing through xvid.dll unstable works fine but ffdshow fails

Edit: Ok got around the problem useing ffdshows autodetect feature thx Cult for the tip :)

athos

24th April 2003, 21:23

I put up a new build on SF:
fixed dll checking = ffvfw not required, libavcodec works under Win9x

Alxemi

24th April 2003, 22:06

Great News!

I confirm that libavcodec is fixed. Now I´ll make QPEL comparisons :o)

Thank you athos and all developers

gamr

25th April 2003, 02:41

divx5 decoding under win2k (with and without use xvid ticked) not working. divx 5.02 installed, when i untick all the divx's it plays fine again. was working with 20030418.

on a lighter note, xvid works well :)

Edit: fixed, autodetect had to be ticked (unticked it playing with xvid goodies)

TNM

25th April 2003, 07:21

Originally posted by athos
I put up a new build on SF:
fixed dll checking = ffvfw not required, libavcodec works under Win9x
I couldn't access sourceforge :( Is there any other place where I can get this new build ? Thanks :)

kilg0r3

25th April 2003, 12:11

I would really love to see adaptive postprocessing implemented into ffdshow. IMO this is about the only advantage the rv9 has over xvid and the like.

Adaptive PP would mean that the strength of PP is tied to the amount of compression applied to a frame, which is indicated by the quantizer. So there is no need for difficult calculations involving resolution, motion and bitrate.

It would have to take into account the difference between b-frames and p-frames because b-frames usually look better at higher quants (never understood why btw). This could be accomplished by a simple offset parameter.

I like the idea:)

milan

25th April 2003, 12:22

But this is already present in ffdshow. Quantizer array is passed to postprocessing routines (both mplayer and Nic's) and it's their responsibility to properly use it. mplayer postprocessing routines even handle the b frames differently.
However, the quantizers for whole frame are constant unless you use some adaptive quantization during encoding which AFAIK common in MPEG2 and available in XviD and ffvfw, but not widely used.

Or do you mean that more image processing routines (like sharpenning) should be controlled by quantizers?

kilg0r3

25th April 2003, 14:35

It is _very probable_ that I am just making a fool of my self again.

I always thought that the amount of PP applied to a frame depends only on the values entered in the config dialog. In this case a frame with mean quantizer 2 would have been post processed in the same way and to the same degree as a frame with a mean quant of say 8. If this is not the case, I should better shut up and start actually using and experimenting with PP.

I have not really used PP very much, but I remeber having strange problems with it. For example, instead of making blocks less visible, it caused them to flicker.

Does anybody know what's the difference between mplayer's and Nic's PP on the one hand and RealOne's on the other. IMHO the PP of R1 hides blocks much better than the other two. :confused:

milan

25th April 2003, 14:45

The "processing strength" slider on the postprocessing page controls how ffdshow modifies the quantizer array before passing it to postprocessing routines. This is primarly targeted for mplayer postprocessing routines, because Nic's postprocessing has X and Y threshold controls. Mplayer postprocessing routines have some other parameters (not exposed in GUI currently), but my tests showed, that it's not possible to fine control, for example, the deblocking using them.

I'm not using Real so I can't compare its postprocessing to ffdshow's.

kilg0r3

25th April 2003, 15:18

Thanks for the explanations. :)

Rober2D2

25th April 2003, 17:49

I have made some test with Xvid + BFrames + Packed bitstream.

ffdshow version: 21-04-2003
xvid: Koepi 05-04-2003

Packed bitstream problem seems to be semi-solved now. Frames are displayed in correct order when xvid library is used to decode.

It is not completely solved without xvid, as ffdshow already makes a mess with frames order. Anyway I noticed an improvement as it doesn't happen with every sequence containing b-frames (It seems that is solved for some cases only)

Valky

25th April 2003, 18:12

Hmm..this latest build very well with divx and xvid codecs. Mpeg1 doesn't still work.

But something weird is happening..how come all my encodings and other movies look so much better now? I mean I have some poorly made films with older divx 3.11 movies where I know there is lot of trash on some scenes. I was going to test these blur/soften -filters, but all the movies look better already..I dont say that this is a bad thing, but it's almost like there is already some luma soften used even without any post processing?

Also the default PP-strength is set to 256 by default instead of 100. Any reasons for that? And I also noticed that using soften or luma soften in blur/soften section they all need much higher values to do anything than previous ffdshow I had from 2002. They are working, but e.g. Luma soften in previous version began to blur too much at settings above 100, but now movies are still watchable at setting 1500.

So what was the ratio compared to previous version from last december?

My main concerns is however, why all movies so look good now? (I can't believe I am actually complaining about this) :)

It's like there is some heavy post processing hiding somewhere inside the software..

CavalloPazzo

26th April 2003, 09:02

What about internal XVID deblocking? As anyyone tested it?I've done a little test and I like it: it seems it only smooth where it's necessary. I've tried to reach the same results with nic PP changing the X and Y Thr. value, but without success. It smooth more and sometimes has more blocks.
Is it possible to include that algo?
Could it be possible to use, for example deblocking from Nic and deringing from mplayer? I'm asking this because I found Nic's method better for deblock, but too aggressive for deringing, and it's not possible to configure deeringing with Nic.
I know Milan is working on FFVFW, and I know feature request is probably very long, so thanks anyway for your great work.

26th April 2003, 10:17

Originally posted by kilg0r3
I have not really used PP very much, but I remeber having strange problems with it. For example, instead of making blocks less visible, it caused them to flicker.
I've had this too. I simply switched to Nic's instead. For anime I usually overpostprocess like a bitch cause it doesn't really matter anyway (not much detail to be lost), but mplayer's PP really coughs on that. The deblocking gives flickering blurred macroblock edges on seemingly random places, while Nic's just gives a smooth postprocessed picture. Btw milan, I love the AVISynth function, I now have a Conv3D in my ffdshow by default! :D

codecmax

28th April 2003, 17:04

OK guys, I managed to download ffdshow-20030424 and I am wondering if this is the best codec for playing video files now?

I am kind of confused over whether if there is a need for the FFVFW now or if there is another version in a few days time.

I like many others would like the best way to get the best video. So any help rendered is much appreciated. :D

Psych

28th April 2003, 19:18

Is it just me being stupid, or is that even when ffdshow is set for all raw video, it doenst come up in bplayer's filter list?
this is a real pain since for some reason all my mpeg's play upside down in here, and ffdshow's flip would be the solution...
is this a bug in bsplayer or ffdshow?

athos

28th April 2003, 19:34

Originally posted by codecmax
OK guys, I managed to download ffdshow-20030424 and I am wondering if this is the best codec for playing video files now?

I am kind of confused over whether if there is a need for the FFVFW now or if there is another version in a few days time.

I like many others would like the best way to get the best video. So any help rendered is much appreciated. :D
IMO ffdshow is the best decoder for mpeg-4 files. It is fast, has lots of options, postprocessing etc and it handles all mpeg-4 (divx345+xvid etc). ffvfw is _not_ needed with this latest release.

oddball

1st May 2003, 16:03

I'd like to see something changed in the way ffdshow does it's resize. Currently you can set it to resize if it meets a specific criteria, like being larger than 640x480 etc. The problem is that if you set this with widescreen sources it messes up the aspect ratio. To give an example.

Movie is 704x384. I wish to resize it to 640x while maintaining aspect ratio. Now I can manually set that using a resize option but I have to work it out and it's a pain. If resize is left at default of 640x480 the aspect will look wrong for this movie ratio.

What I would like to see is an extra resize option that does a resize on the horizontal that you can specify like 576x or 640x and ffdshow auto resizes the vertical resolution to maintain aspect ratio.

Am I making any sense here?

It would save me messing about all the time with resize settings.

Blight

2nd May 2003, 12:09

oddball:
There is a maintain AR setting in that resize dialog...

So, while you may resize a 320x160 to 640x480, it will in reality be resized to 640x320

oddball

3rd May 2003, 02:13

Ah. I didn't realise it had any effect on resize. I always wondered what that option was for thanks ;)

Still would love a better less CPU intensive way to do black borders at some point in the future ;)

Oh and the crop and zoom tool never seems to work the way I think it's gonna work. Lets say for instance you have a movie where some bozo encoded the black boarders. For widescreen TV output it's a pain the butt as it looks wrong on the TV. In DiVXG400 it has an option 'Cut sides to horizontally fill at least 100% of the screen'. Which works great without pulling any CPU load. It crops the black bars automagically top and bottom and spits it out on the overlay correctly.

In ffdshow if you crop it seems to pull the image up and down but not crop the bars in the way I expect. It's very fiddly indeed.

Chibi Jasmin

3rd May 2003, 15:47

Originally posted by oddball
Still would love a better less CPU intensive way to do black borders at some point in the future ;)

Like DivXG400 does it :-) My words...

kastro68

3rd May 2003, 18:12

I noticed that the postprocessing for the 24-4-2003 ffdshow is not as strong as that of the 3-1-2003 ffdshow.

Using the 24-4-2003 ffdshow with postprocessing all the way up and with a processing strenght of 512 I hardly notice any PP taking place unless Nic's PP is ticked.

I'm not complaining, I'm just wondering if it may be a bug, or if PP has been deliberately watered down.

Have a nice day.

simon.mittag

4th May 2003, 04:58

Originally posted by kilg0r3
How is it supposed to work?

Ok, just tried it. You can just enter the filters you want, and levae the clip position unspecified).

This could be a nice weapon agains the black locking issue, without having to modify the the stream during the encode. It was suspected that the phenomenon is caused by luma values which are invalid for TV display. If this is true, a simple 'limiter()' inserted in ffdshow should do the trick.

Very nice! THANK YOU MILAN!

avisynth in ffdshow works fine for built in avisynth commands for me, however it behaves erratic when I try to load a plugin.

scripts that otherwise work as avs files fail with "unexpected error"

I observed that once entering only the load plugin statement into the script, commencing and pausing playback to allow it to load, then entering a second line running the plugin command seems to work.

Are there some problems with dynamic binding of the dll at runtime?

Anybody else tried that so far? I had problems like that with AutoCrop and WarpSharp plugins for 2.5

simon.mittag

4th May 2003, 11:26

I can make the description a little more precise after further testing.

I actually CAN run the AutoCrop plugin when applying the filter to an already running movie clip, meaning entering the AutoCrop(1) statement into the ffdshow dialog at playback time and hitting apply produces a working crop.

What doesn't work is starting playback when that value is already configured in the ffdshow tab - it then throws exception when I hit play in zoomplayer. seems something goes wrong with the ffdshow avisynth source filter at startup time?

Milan, Glenn, any ideas? Since it runs afterwards it can't be that grave an issue?

regards,

Simon

athos

4th May 2003, 11:55

This might have something to do with the dynamic loading of dlls, as this was the cause of the libavcodec problems and the ffvfw trouble.

simon.mittag

6th May 2003, 03:19

Milan told me he is currently working on the avisynth plugin loader for ffdshow and I hope he will post us his test results when he's finished.

int 21h

12th May 2003, 02:14

Any chance we'll see the new Sorenson additions to ffmpeg in ffdshow?

simon.mittag

12th May 2003, 02:44

I am not yet sure when any possible next release for ffdshow will be, we'll have to wait for Milan.

Blight

12th May 2003, 22:40

VP31 decoding from ffmpeg could be useful too, ther TrueMotion one kinda sucks. Also, there's quirks in the huffyuv decoder which merit a look-over.

rjamorim

14th May 2003, 18:10

Originally posted by int 21h
Any chance we'll see the new Sorenson additions to ffmpeg in ffdshow?

Isn't Sorenson limited to the MOV container - that doesn't use dshow for playback (uses QT instead)?

Or is there something I don't know? :confused:

Blight

14th May 2003, 18:50

Parhaps someone should write an MOV parser... there is one for QuickTime v2 that comes with windows, but I doubt it applies anymore.

LigH

20th May 2003, 09:42

I always thought "a codec is a codec - no matter which kind of container format you wrap around". I remember early MOV <=> AVI converters which quite blindly exchanged the surrounding containers; so it was indeed possible to have a video format in an AVI where no VfW codec or DirectShow filter existed for.

From this point of view, it is no problem to have Sorenson video in an AVI. No matter how hard it could become to play it back... :D Probably, I wouldn't mind if Sorenson would create some software for Windows PCs, just as cross-platformed as 3ivx. But I doubt that this would definitely be my first choice then: On a 1800 MHz P4 it was almost impossible to play back the "Matrix Reloaded Final Trailer", created in Sorenson 3 Pro at 1000x540 pixels.

I transcoded it to MPEG2 to watch it on TV instead... And this did not work using the QuickTime 2 DirectShow import filter in AviSynth: I had to try the QuickTime VFAPI plugin and the VFAPI import snippets for AviSynth, and even had to pull down the frame rate by 25 (ever seen a movie at 600 fps?).

gabest

20th May 2003, 16:37

Originally posted by Blight
Parhaps someone should write an MOV parser... there is one for QuickTime v2 that comes with windows, but I doubt it applies anymore. Actually, the parser should be still fine for any mov. A few weeks ago I started to write a qt video decoder using the sdk, but the decompressor calls always failed for the incoming "svq3" data. With other encoding types I had success (mainly with "all-keyframe" types), but not with this sorenson codec.

20th May 2003, 17:05

Originally posted by gabest
Actually, the parser should be still fine for any mov. A few weeks ago I started to write a qt video decoder using the sdk, but the decompressor calls always failed for the incoming "svq3" data. With other encoding types I had success (mainly with "all-keyframe" types), but not with this sorenson codec.
Well that's where a new ffdshow would come in handy :D.

Blight

20th May 2003, 22:06

I'm not sure that the QT parser from QTv2 is still working as Apple inserted a lot of other video stream support and may have restructured the format beyond backward compatibility, can't really tell for sure.

But if FFMPEG can decode the contnet, perhaps it's possible to do. As far as writing your own QT Decoder, I know that Sorenson have some sort of licensing deal with Apple that their codec won't be used outside of their own player. Perhaps that is why it doesn't decode for you, it detects that your program instance is not valid.

raistlin2k

21st May 2003, 09:55

Actually, you can use MPC for playing QT WITHOUT installing Quicktime player :)

And I added those QT - filters to Media Center 9, so you can play QT there as well without Quicktime installation!

Isn't this enough quicktime-support?

Raist

HughMagoo

22nd May 2003, 14:33

I need a little help. I've searched around, but found no hints. I'm using the latest alpha.

1) when using the Resize function in conjunction with VMR9 and quick pans or scene changes, I am seeing lots of tearing, like the picture is broken in a line from left to right.

I've tried setting D3D vsync on to see if that has any effect, and I have also tried different Nvidia Dets, as well as Omega drivers. Nothing seems to work. my refresh rate is 60Hz. I don't know what has changed recently, but I am sure I wasn't seeing this tearing before.

2) when using Raw Video processing, the Info screen in the ffdshow panel says output 25.0fps... for every file with different fps. is this usual?

3) I'm not exactly sure about what colorspaces I should accept for Raw Video Processing, and what colorspaces I should output to, in the ffdshow codecs panel. gf4ti4600 --> YV12 forced for both?

thanks for any help.

Stux

22nd May 2003, 18:42

the MS QT parser only support QT v1 and v2

since Apple is up to QT6, that's fairly out-of-date

QT3 introduced compressed movie header
QT4 introduced vbr audio tracks

etc

the 3ivx Media Splitter handles more modern (simple) mov files, but only for mpeg-4 variants (ie not sorenson)

athos

23rd May 2003, 17:31

New build is up on SF. This time I skipped ICL7 and used the regular MSVC++6 compiler, as the builds since 2002-12-13 has caused Explorer to crash when building thumbnails for video files in thumbnail view. This one doesnt seem to do that, at least not yet. Please post your findings regarding stability and possible performance loss (or gain?).

kastro68

23rd May 2003, 18:07

@athos
Thanks. I'll give it a try

@gabest
are you the same person that wrote vobsub and Media player classic?
Do you know where I can go to post suggestions and bugs for MPC?

I like doom9. I actually get to meet and chat to the people that develop and maintain the software that I use. It's a bit like meeting a celebrity :)

athos

23rd May 2003, 18:10

Originally posted by kastro68
@gabest
are you the same person that wrote vobsub and Media player classic?
Do you know where I can go to post suggestions and bugs for MPC?

yes it is the same person, check out the MPC thread:
http://forum.doom9.org/showthread.php?s=&threadid=29798
Originally posted by kastro68
I like doom9. I actually get to meet and chat to the people that develop and maintain the software that I use. It's a bit like meeting a celebrity :)
indeed ;)

kastro68

23rd May 2003, 18:31

Hi,

I just tried the latest ffdshow, and it works fine with WMP 6.4 but it crashes Media player classic. I just gave it a reboot.

I'll try reinstall former ffdshow now and see if MPC still crashes.

I just reinstalled ffdshow-20030424.exe and both wmp and MPC work fine with this. I uninstalled it and installed ffdshow-20030523.exe again and MPC crashes. WMP works fine though

Can anyone confirm same problem? If not, I'll post more details.

gabest

23rd May 2003, 18:37

Looks fine to me. Running MPC v6450.

kastro68

23rd May 2003, 18:40

Oh. I was running MPC 6.4.4.2

Sorry gabest, I just checked your site yesterday and it still had the old version up. You must've updated MPC very very very recently :)

@Gabest: Are you pulling my leg? :) I just came back from your site. I guess you didn't update your MPC files yet. Any chance I can get a copy of MPC 6.4.5.0 early?

kastro68

23rd May 2003, 18:49

MPC 6.4.5.0 is up now

Thanks.

Feedback: I don't experience any problems with latest ffdshow and MPC6450

Defiler

23rd May 2003, 19:07

Does the new (kinda) double-precision IDCT support SSE2 extensions?

Defiler

23rd May 2003, 19:13

Also.. I (still) see negative numbers in the "CPU Usage" OSD sometimes.

kastro68

23rd May 2003, 20:34

Hi,

I think there may be a possible bug with ffdshow-20030523 while 'Luma Smoother' feature of 'Blur & NR' it causes both MPC6450 and WMP to crash. I haven't found anything wrong with any of the other 'Blur&NR' features...just the luma smoother.

Thanks

Edit: Chroma smoother causes MPC and WmP to crash too.

HarryM

24th May 2003, 04:54

23052003 dont works on win98SE (for me).
24042003 works fine.

athos

24th May 2003, 11:15

Originally posted by HarryM
23052003 dont works on win98SE (for me).

What error messages do you get?

HarryM

24th May 2003, 12:18

Originally posted by athos
What error messages do you get?

Freezes without error messages. ZoomPlayer and MPC dont work with ffdshow 23052003!
Interest- WMP6.4 works(?)

Maybe cause in VMR7 (VMR7 is default renderer for win9x, best choice for win9x) using. If I switch for VMR9 (in ZoomPlayer), all is O.K.
But VMR9 works forced only in YUY2 (for me), degrades slightly quality and consumes much more CPU power...
:(

HughMagoo

24th May 2003, 13:31

I noticed that the tearing that I was noticing with resize in ffdshow and VMR9 is only when using YV12 output. I have not noticed the tearing effect with YUY2 output. If I enable almost all the output colorspaces, ffdshow uses YUY2 in all cases I have seen so far. So perhaps that is the best for my system? GF4ti4600, running nView

limited testing so far, but 23052003 seems to be a big improvement over 24042003 on my system. I use ZoomPlayer, and have not experienced any problems so far with Overlay or VMR9 modes and the new ffdshow.

HarryM

24th May 2003, 15:37

Originally posted by HughMagoo
I noticed that the tearing that I was noticing with resize in ffdshow and VMR9 is only when using YV12 output. I have not noticed the tearing effect with YUY2 output. If I enable almost all the output colorspaces, ffdshow uses YUY2 in all cases I have seen so far. So perhaps that is the best for my system? GF4ti4600, running nView

limited testing so far, but 23052003 seems to be a big improvement over 24042003 on my system. I use ZoomPlayer, and have not experienced any problems so far with Overlay or VMR9 modes and the new ffdshow.

Yes, VMR9 is more 'compatible' (it seems to me), but often use YUY2 for output.
I prefer VMR7 personally.

If you use Win2k/XP, your default overlay renderer is VMR9.
If you use Win9x/Me, your default overlay renderer is (old, good) VMR7.

faxmactor

25th May 2003, 08:00

Originally posted by HarryM
23052003 dont works on win98SE (for me).
24042003 works fine.

I have Win98 SE Hungarian.

The last one working eas 20021223
I haven't been able to use ffdshow sine 20030103...
I was unable to use 20030423 as well. :(

(On WinXP, it worked well)

At last, ffdshow-20030523 works on my Win98!! :p

But now I see from your post, that it still has problems with Win9x... :(

Will this issue ever be solved? The developers must have aware of this problem for almost half a year now. When a new ffdshow build released, it is still like gambling that it works or not on Win9x. Since it is kind of "random" I can imagine that it is quite difficult to track this bug down, but it would be just about time :scared:

faxmactor

25th May 2003, 08:07

Ah, sorry everyone, now I see HarryM, you had crashes on Win98, not that general problem, that even prevented ffdshow to get registered in Windoze.

Blight

25th May 2003, 19:09

HarryM:
you're wrong there matey...

VMR7 only exists under WinXP, there is no way you can get it under any other OS. What you get is Overlay and not VMR7. On my GF4, VMR9 has better scaling than overlay (using the 30.82 drivers, the 4x.xx drivers are buggy and give either aliasing or a slightly blurred image).

BTW, While "Theora" is listed as a codec, VP31 AVI files won't decode using ffdshow.

HarryM

25th May 2003, 20:52

Originally posted by Blight
HarryM:
you're wrong there matey...

VMR7 only exists under WinXP, there is no way you can get it under any other OS. What you get is Overlay and not VMR7. On my GF4, VMR9 has better scaling than overlay (using the 30.82 drivers, the 4x.xx drivers are buggy and give either aliasing or a slightly blurred image).

BTW, While "Theora" is listed as a codec, VP31 AVI files won't decode using ffdshow.

Sorry, my mistake. I think, that

'Video Renderer' = 'VMR7' (direct YV12 decoding, I prefer this)

'Video Mixing Renderer 9' = 'VMR9'. (I don't like this, YUY2 decoding, much CPU power needed)

Sigmatador

25th May 2003, 22:37

@Milan
since the beginning there's a color bug with awarpsharp

Animaniac

26th May 2003, 12:41

Two things I noticed with the latest build:

-Turing Warpsharp on while the stream is play causes WMP to crash.
-Perspective correction now makes the colors all funky.

As far as performance in this build, I can't really tell, but by virtue of looking at the Info section of the filter properties, I would have to say it's slower on my (P4) system, since the frame rate seems to dip lower more frequently and the data in the Info pane refreshes at a lower frequency. With the older builds, explorer rarely crashed when generating thumbnails.

sysKin

26th May 2003, 14:22

Hi,

Just to mention that I have some stability problems with this latest ffdshow. It crashed once when I enabled postprocessing, once when I seeked, several times when I opened a file.

I can only say much about the last example: I could open some files, couldn't open others. All were xvids with bframes, with dx50 fourcc. It crashed because of access violation at some big unrolled mmx function.
Changing decoder from libavcodec or xvid allowed to open the file.

My cpu is athlon xp, I'm using w2k (with service pack) and DX 8.0. Video is geforce2mx400 running at detonators 44.03.

Thanks for excellent work!

Radek

PS. ah and also, this version is still unable to say "qpel" in OSD.

Defiler

27th May 2003, 07:25

If I enable the highest level of post-processing, then Nic's (default settings), with "Nic's first" selected, I get repeatable crashes when opening DivX / XviD files.

Also, the Chrominance filter under "Blur & NR" seems to crash quite rapidly.

Finally, I've been unable to get this new version to post-process raw video (from the Sonic Cineplayer DVD decoder). It claims that ffdshow denied the attempt to attach a pin. (Yes, I have raw video enabled.)

The third item could easily be something I am doing wrong, though.

sysKin

27th May 2003, 12:50

Originally posted by Defiler
If I enable the highest level of post-processing, then Nic's (default settings), with "Nic's first" selected, I get repeatable crashes when opening DivX / XviD files. You were faster, Defiler :))
Yes, I confirm: the crashes I was talking about are strictly related to chroma deringing using "Nic's" method (for me: first or not first, just enabled). As I said, it's access violation in the middle of mmx code.

Regards,
Radek

drebel

27th May 2003, 14:47

@Defiler
I had the same problem with April's version, thing which kept me away from using Cinemaster's video filter for a while.Good compatibility with Intervideo's filter (Platinum) serves me well ,for the time being .But due to my hardware limitations i can't enable more than one pp filter now.In a very strange way , TheaterTek was "lighter" than ZoomPlayer3 with ffdshow

Chrominance filter under "Blur & NR" seems to crash quite rapidly.
confirmed

Defiler

28th May 2003, 14:33

Is there any preliminary documentation for the Avisynth features of ffdshow? What I'm really interested in is being able to refer to the input ffdshow passes to Avisynth by name, so that I can use it with functions that require clip names.
For example:

blah=ffdshowSource()
AwesomeStuff(blah,bugs=0,good_acting=true)

Is this, or something like it, possible?
So far, I've only been able to use functions that do implicit last.

Edit: Also, I've been unable to make any functions that refer to the previous frame in the video. I take it this isn't supported?
Try this, for an example:
ScriptClip(last,"Subtitle(String(YDifferenceFromPrevious()))")
Doesn't work. It just reports one value, and never changes. (for me)

However, this example:
ScriptClip(last,"Subtitle(String(YDifferenceToNext()))")
Works properly, and continuously updates.

I suppose this makes sense. We can't keep a lot of raw video lying around in memory. Perhaps it could keep the last few frames when in Avisynth mode? That would make the Avisynth feature significantly more powerful, since many filters need to refer to the previous frame in order to make correct decisions about the next one.

28th May 2003, 14:40

Originally posted by Defiler
Is there any preliminary documentation for the Avisynth features of ffdshow? What I'm really interested in is being able to refer to the input ffdshow passes to Avisynth by name, so that I can use it with functions that require clip names.
For example:

blah=ffdshowSource()
AwesomeStuff(blah,bugs=0,good_acting=true)

Is this, or something like it, possible?
So far, I've only been able to use functions that do implicit last.
I think you can do that with something like:
input = nop()
Or anything else that doesn't do anything to your input. I'd have to check though.

Wilbert

28th May 2003, 14:50

Defiler

28th May 2003, 15:08

Originally posted by Wilbert
I'm probably misunderstanding you, but can you use ffdshowSource in an AviSynth script? How does AviSynth recognize the command ffdshowSource. Again, I'm probably just misunderstanding you. "ffdshowSource()" is a command I just made up, because I don't know the actual name for it. Heh.
You can't use ffdshow as the source for an external Avisynth script (..yet.. heh..) but you can execute Avisynth scripts on an ffdshow output stream, as post-processing.
Like this:
http://hellninjacommando.com/temp/ffdshow-avisynth.png

My question earlier is about whether you can refer to the input that Avisynth (inside ffdshow) gets from the ffdshow decoder by a clip name, or as an input function.

pandv

28th May 2003, 18:39

blah=ffdshowSource()
AwesomeStuff(blah,bugs=0,good_acting=true)

Is this, or something like it, possible?
So far, I've only been able to use functions that do implicit last.

I tested it with the last ffdshow version and this works:

myclip=last
myclip2=SwapUV(myclip)
myclip=GreyScale(myclip)
return myclip2

returns the clip swapped (and not greyscaled).

So, I supose the key is the first line:

myclip=last

pandv

Defiler

28th May 2003, 19:05

Cool. Good work.

Tri

29th May 2003, 01:00

Using the avisynth function of ffdshow, I wanted to apply deen to a clip if the framerate is smaller than 25. This function works perfect in a "normal" avisynth script:

LoadPlugin("F:\avisynth\deen.dll")
Function SmallFPS_Deen(clip)
{
clip = (Framerate(clip) <= 25.000) ? deen(clip,"a3d",1,10,12,3).Subtitle("active") : Subtitle(clip,"inactive")
Return clip
}
SmallFPS_Deen()

But in ffshow it always displays "active", so every video gets filtered by deen, which my system can't handle :). Is there some other way I can get this to work?

Defiler

29th May 2003, 03:01

Originally posted by Tri
Using the avisynth function of ffdshow, I wanted to apply deen to a clip if the framerate is smaller than 25. This function works perfect in a "normal" avisynth script:OK. This is really bizarre.
I'm using a 29.97fps file as a test, to see if I can figure out the problem you are having.

Function SmallFPS_Deen(clip)
{
clip = (Framerate(clip) <= 25.000) ? GreyScale(clip).Subtitle("active") : Subtitle(clip,"inactive")
Return clip
}
SmallFPS_Deen()This code displays "active" on the 29.97fps file (inappropriately), and makes it greyscale.

However, if I change the "25.000" to "15.000", the same video shows "inactive", and is in color. Maybe the framerate is being reported incorrectly?

So, I delete that script, and just do this:
Subtitle(String(Framerate()))

Guess what? It always reports 25.000, no matter the frame rate of the file I feed it. Even, hilariously, with a 120fps AVI file.

oddball

30th May 2003, 02:21

You know I mentioned about resize screwing up aspect ratios if you set it to resize anything above a certain specified size? And you know how you said that the option 'Maintain aspect ratio' would resolve it? Well it doesn't.
I have a 720x400 AVI and I wish to resize anything greater than 640x to 640x. You can set the resize amount. I set it to 640x480 which is fine if you have a 720x480 video size for instance. This resizes down correctly. However if you have a widescreen video like 720x400 it resizes it to 640x480 with black bars top and bottom. I could set it to 640x352 but if I do that and playback a 720x480 clip it would screw that up. The resize command does not work in the way expected.

So basically I want to see resize take into account the aspect ratio and resize accordingly. Using the last version of ffdshow and the maintain aspect option does not seem to work.

milan

2nd June 2003, 13:43

@Defiler
Fixed now.

milan

2nd June 2003, 13:44

@Defiler
Fixed now.

Everytime when ffdshow will be able to determine input video frame rate (and it can't do this always) it will pass it to avisynth.

Takuto

3rd June 2003, 17:23

Just found strange ZoomPlayer behavior with FFDShow from May 23 2003.
Zoom Player crashes every time, when it played DivX 3 content and minimized into taskbar. It happens only with this version FFDShow, only with DivX 3 and only in Zoom Player (tested also MPC and MP 6.4).

Maybe its bug of Zoom Player (btw I used v. 3.10 beta 1 standard), but with previous FFDShow builds all was OK.

Windows XP, DirectX 9.0.

Defiler

3rd June 2003, 17:35

Do you have Nic's post-processing enabled? If so, turn it off.

gabest

3rd June 2003, 17:36

Takuto

3rd June 2003, 18:33

Defiler: no, Nic postprocessing is not enabled. When I tried to enable it player crashes immediately.

But when I disabled any postprocessing at all, crashes disappeared.
Maybe some memory leak with DivX 3 postprocessing?

Defiler

3rd June 2003, 20:57

Originally posted by gabest
milan: Would it be possible to output VIDEOINFOHEADER2 structures too? I ask this because now that the matroska file format supports aspect ratio in the container format, it would be needed to pass the VIDEOINFOHEADER2::dwPictAspectRatioX/dwPictAspectRatioY fields towards the renderer just like the frame-rate is passed already. Oh yes! That would make my month.

gabest

4th June 2003, 02:33

Forget what I asked... it's already there in ffdshow! :)

HughMagoo

4th June 2003, 05:02

milan: Would it be possible to output VIDEOINFOHEADER2 structures too? I ask this because now that the matroska file format supports aspect ratio in the container format, it would be needed to pass the VIDEOINFOHEADER2::dwPictAspectRatioX/dwPictAspectRatioY fields towards the renderer just like the frame-rate is passed already.

this would probably explain why DVD content passes its aspect ratio through ffdshow, even though you might be resizing to a resolution like 1040x960 in ffdshow, and are using the "no aspect ratio correction". If we could always tell matroska what aspect ratio the encode is, and have that pass through ffdshow, for proper resize in the player, that would be great.

as it is currently, with everything but DVD I have to manually choose aspect ratio if I want to use a fixed resize resolution in ffdshow.

Defiler

4th June 2003, 06:26

I misunderstood what you were asking for then. Heh.

Lobuz

4th June 2003, 12:05

I just want to present recent experiences of playing xvid with ffdshow.

First I must admit it's great efficiency and speed even in HD resolutions.

But one thing is still working poorly - that is packed bitstream. In connection with qpel and b-frames there appeare strange gray halo spots. It could be easyli observed at testing clip from matroska thread. Without qpel or B-frames it seems to be ok. Aha, and there is a stuttering during the playback of that clip ( even if cpu is at 50% of load ).

And I have a small request if could be possible to make an intermediate buffer after decoder and before renderers. Sometimes the CPU load jumps and there is desync so that buffer could help at these situations.
I have plenty of free RAM so it could be used to reduce any jerkyness.

Regards
Lobuz

milan

4th June 2003, 12:22

The aspect ratio is now just passed in the VIDEOINFOHEADER2 to overlay mixer. It doesn't influence ffdshow internal resizing and ffdshow internal resizing doesn't influence the VIDEOINFOHEADER2 aspect ratio. I'd like to change this in (near) future.

Packed bitstream with qpel and b-frames is a known problem. I'll check if some bugs workaround option could solve this.

@gabest
I tested your matroska demuxer yesterday after reading that ffdshow always reports 25 FPS. Would it be possible for you to set the AvgTimePerFrame field in VIDEOINFOHEADER or can matroska handle variable frame rate and this would be impossible?

ChristianHJW

4th June 2003, 13:01

Originally posted by milan @gabest
I tested your matroska demuxer yesterday after reading that ffdshow always reports 25 FPS. Would it be possible for you to set the AvgTimePerFrame field in VIDEOINFOHEADER or can matroska handle variable frame rate and this would be impossible?

Yes, matroska can have variable framerate in principal, but not in the VfW compatibility mode. All the codecs ffdshow can decode and that can be stored in matroska for the time being, thats DivX, XviD, MPEG4V1/2/3 and DivX3 are all VfW based, and thus have a fixed frame rate.

IIRC the framerate is also easily accessable, as in VfW mode we store the complete BITMAPINFOHEADER in the KaxCodecPrivateDate field of matroska ....

EDIT / Correction :

There is no framerate in BITMAPINFOHEADER i was told, so we had created a new element called KaxVideoFrameRate for that weeks ago, and the specs say that every CFR ( Constant Frame Rate ) codec should use/set this field accordingly, making it manadatory for VfW mode also ...

Blight

4th June 2003, 16:53

Milan:
Since FFDShow can decode theora content, can you make it accept the VP31 sub-type & fourcc?

And now that 3ivx released a QuickTime splitter, it would be very cool if sorenson could be decoded.

Also, there's some bugs in the MPlayer post-processing... It flickers the video. Very noticable with HDTV content. Also, the whole effect as a whole seems weakened compared to previous versions of FFDShow.

Defiler

4th June 2003, 17:46

Originally posted by Blight
And now that 3ivx released a QuickTime splitter, it would be very cool if sorenson could be decoded.Hehe. You just want to get out of working on the Quicktime features of Zoom Player. I know your plan.. :D

milan

5th June 2003, 10:40

Since FFDShow can decode theora content, can you make it accept the VP31 sub-type & fourcc?

Are you sure that VP31 content can be decoded using theora routines?

And now that 3ivx released a QuickTime splitter, it would be very cool if sorenson could be decoded.

I didn't know that. I'll download this splitter immediatelly and see what can I do to use libavcodec SVQ1/3 decoding routines.

milan

5th June 2003, 14:18

Current progress:

1) theora decoder used by ffdshow is unable to decode sample VP31 clip

2) after few hack I was able to decode sample Animatrix mov clip using ffdshow. There is still a lot of work to be done, but thanks to libavcodec developers maybe we will have an opensourced SVQ3 directshow decoder filter.

BTW is there some AAC directshow decode filter which could be used with 3ivx quicktime demuxer?

BoNz1

5th June 2003, 14:30

Originally posted by milan
BTW is there some AAC directshow decode filter which could be used with 3ivx quicktime demuxer?

Yes, there is, check out this one, http://forum.doom9.org/showthread.php?s=&threadid=53863

Blight

5th June 2003, 15:12

milan:
There's the open-sourced one from corecodec team and the 3ivx audio decoder also does AAC. I believe Ahead software (makers of nero) also have one, but I haven't really seen it.

slavickas

5th June 2003, 19:55

Originally posted by milan
Current progress:

1) theora decoder used by ffdshow is unable to decode sample VP31 clip

vp3 and theora are quite different, but ffmpeg have own vp3 decoder i think (i don't have linux currently) by Mike Melanson

btw http://kyoto.cool.ne.jp/vp3/ is faster version of vp3 (at least decoder)

unplugged

5th June 2003, 22:12

I just want report that with latest build 23/05 the DScaler deinterlace/filter support plug-in doesn't work well as did previously.
Certain DLLs (like TomsMoComp.DLL) crashes ffdshow and most deinterlace filters have some flipped color tonality (blue instead of red...).
Instead all ok with 24/04 build.
I'm using filters from DScaler beta 4.1.6 (great great project, but... damn! no full line recording... yet :( :x)
Sorry if I miss something said in regard of this, haven't red the whole thread.

P.S.: Which could be one good deinterlacer plug-in (hey! I'm for 50fps! :D) to view MPEG-x recorded F1 Grand Prixes? (mixed high/low-motion)
For now I'm satisfied with Greedy2Frame...

avih

5th June 2003, 23:57

DScaler: for really fast action, i usually go for simple bob. it's the 'purest' deinterlacer.

Blight

7th June 2003, 20:19

here's a bug report...

Playing HDTV encoded XVID content (1920x800) with Nic's Post Processing active would crash FFDShow when trying to release the filter. No issues at 1280x720, so I'm guessing the 1920 width may be an issue.

Animaniac

8th June 2003, 04:51

Bug for XviD clips:

OSD always shows I for Frame Type
OSD cannot determine Frame Mean Quantization

simon.mittag

9th June 2003, 11:20

Milan,

about the new avisynth sourcefilter, can I please point your attention to this thread: http://forum.doom9.org/showthread.php?s=&threadid=37204&perpage=20&pagenumber=4

The Autocrop plugin needs seeking (requesting frames) to work. This seems to cause problems with ffdshow in raw mode. Is there anything You can think of to make that work?

thanks for your time,

Simon

PkmoNk

9th June 2003, 11:43

I just want to note I've also had playback issue with the new ffdshow filter and uninstalling still caused playback problems with some avi files. so i uninstalled EVERY A/V codec and filters even ffvfw, and restarted, then install KazaaLite Codec FULL without the divx5.05 and the new ffdshow and everything works fine again! :)

thop

9th June 2003, 16:04

Originally posted by PkmoNk
KazaaLite Codec FULL
:confused:

Blight

9th June 2003, 21:04

thop:
My analogy to PkmoNk's post is "So, my head was hurting real bad, so I took a gun, shot at my head, amazingly hit an tumor I didn't know I had and now my headache is gone".

simon.mittag

10th June 2003, 02:13

Blight :D :D :D

CruNcher

10th June 2003, 07:30

@ blight

buahahaha :rolleyes: :D :D

PkmoNk

10th June 2003, 11:24

Originally posted by Blight
thop:
My analogy to PkmoNk's post is "So, my head was hurting real bad, so I took a gun, shot at my head, amazingly hit an tumor I didn't know I had and now my headache is gone".

hey, I'm just trying to help out. It did solve my problems with playback. :rolleyes:

nadlabak

10th June 2003, 13:59

Hi,

sorry to interrupt this interesting discussion with my little wish...

Besides its great decoding capabilities, ffdshow is very powerful directshow video filter. I was always tempted to use it not only for video playback but also for video filtering during capture - deinterlace, crop and resize filters chained before video compressor are the most needed.

I was able to use it this way in Virtual VCR (and ffdshow is the only dshow resize filter that does not crash Virtual VCR when downscaling unlike the Moonlight bilinear scaler and Bicubic 1.3b filter) but ffdshow usability as a video filter has some shortcomings. Different settings for capture and playback operation can be achived by preset autoloading based on video size (full PAL - capture, any other resolution - playback). But raw video as the supported codec has to be enabled and ffdshow is then always loaded for any dshow video rendering happening on the system (in the selected color space). Video preview using Smart Tee filter in Virtual VCR could not be initialized when ffdshow is set as video prefilter, maybe because ffdshow is then running in two instances - one for prefiltering and second autoloaded for preview window.

It would be great if ffdshow could be compiled as a separate directshow video filter without decoding features with low merit (no autoloading) to be used for filtering purposes only and that could be installed on the same machine together with standard ffdshow filter used for video playback.

milan

10th June 2003, 14:06

I would prefer to maintain just one version of ffdshow. Would it be helpful to you if I would add possibility to select ffdshow's merit in its configuration dialog?

Blight

10th June 2003, 14:33

ChristianHJW:
You can't enable overlay mixer in FFDShow, it should be done on a Player level. As the overlay mixer breaks VMR9 support or any internal overlay mixer code in the player. Having it on by default would make ffdshow very unstable.

milan,nadlabak:
Not sure if it's possible, but if you can spawn two CLSIDs for FFDShow, one always RAW mode with a selectable merit and the other with never RAW mode and a very high merit. Each CLSID would have it's own registry tree.

That way you'd be using the exact same code base with only very minor checks to see which CLSID is running...

tcmjr

10th June 2003, 22:43

How can I get the best quality using ffdshow ?
I mean , which setting should I choose for best quality ?
lets say for playing dvix movies and xvid movies ?
I am using latest ffdshow (05/23) nvidia drivers 44.03 and win Xp.
Using both bsplayer and Zoom player
thanks.

ChristianHJW

11th June 2003, 07:56

Originally posted by Blight ChristianHJW: You can't enable overlay mixer in FFDShow, it should be done on a Player level. As the overlay mixer breaks VMR9 support or any internal overlay mixer code in the player. Having it on by default would make ffdshow very unstable.

Hmm .... thats sad :( . Seems we have to bug more player developers to support reading the mkv AR flag directly from the player .... |Blight| :D ?

EDIT : Can the player enable the overlay mixer in ffdshow if a .mkv is opened ?

BlackSun

11th June 2003, 08:04

JasonFly

11th June 2003, 17:47

I don't know if it has been report but I have a problem using ffdshow with andreas78 matrix.(this is a hi quality matrix)

The problem is a decoding problem(image is fine in VirtualDub) and seems related to ffdshow since the image is nice if decoded with Nic's decoder.

The problem happens on two encodes where I used andreas78 matrix and produce moving blocks in the image.(Looks like broken motion estimation)This happenned in a high motion scene with a complex motion of the hair of a person.

For these encodes,I used bframes(2-100-150-100) and vhq=1 but not qpel.Quantizers should be between 2 and 4 because the movie wasn't much compressed.

Sorry if this has already been reported.

Defiler

11th June 2003, 18:20

Does that matrix have a value lower than 16 in the top-left?

Lobuz

11th June 2003, 19:01

I don't know if it's useful but there are some optimisations to simple idct in mpeg2dec3 1.8 and lately in XviD too. So maybe it could serve to idct in ffdshow and gain a little more speed?

Regards
Lobuz

Blight

11th June 2003, 19:36

ChristianHJW:
ZP by default uses Overlay Mixer mode... VMR mode also works for AR as long as the filter passes the data in the VIDEOINFOHEADER2 structure.

JasonFly

11th June 2003, 19:50

Yes the matrix has vlaues lower than 16 in both the intra and inter matrix.

They look like this:

Intra:
8 13 15 19 ..
13 13 17 19 ..
15 17 19 ..
17 21 ..
21 ..
..

Inter:
8 11 13 15 ..
11 11 15 15 ..
13 15 17 ..
13 17 ..
17 ..
..

athos

20th June 2003, 13:48

I just wanted you to know that Milan is doing some heavy work on ffdshow right now. He has asked me to wait with putting up new builds on SF until he feels the state of the project is more stable. But there are some interesting development that I would like to try out, so I just might put up some private build, if Milan doesnt mind.. Here is the changelog since last alpha release:
2003-06-18 20:09 milan_cutka

mp3,mp2,ac3 decoding - ALL EXPERIMENTAL

2003-06-14 09:39 milan_cutka

updated vc6 projects

2003-06-14 08:00 milan_cutka

working on wma support (ffdshow.ax now contains an audio decoding
filter too)

2003-06-13 06:38 milan_cutka

msvidc

2003-06-12 11:29 milan_cutka

input bps in OSD, fix for mpeg1/2 decoding

2003-06-11 10:59 milan_cutka

second, raw video only, low priority filter

2003-06-11 06:46 milan_cutka

no message

2003-06-10 06:40 milan_cutka

working on better mpeg1/2 support

2003-06-09 16:04 milan_cutka

rgb gamma correction working in YUV (from mplayer's vf_eq2)

2003-06-09 13:35 milan_cutka

added skal's idct to libavcodec (almost untested, might be removed
if problems will occur)

2003-06-09 11:54 milan_cutka

updated libavcodec vc6 project

2003-06-09 11:23 milan_cutka

timestamps support in IffProc

2003-06-09 06:30 milan_cutka

subtitles use timestamps instead of frame numbers, timestamps
cleanup: mpeg1/2 now works a little bit better, possible new bugs

2003-06-06 06:44 milan_cutka

onSizeChange cleanup, SVQ1 support

2003-06-05 15:52 milan_cutka

experimental SVQ3 support, onSizeChange,onCSPchange

2003-06-05 14:10 milan_cutka

updated libavcodec

2003-06-05 08:05 milan_cutka

updated vc6 project

2003-06-05 06:42 milan_cutka

option to register ffdshow to selected media types only, resize
calculation cleanup

2003-06-04 08:04 milan_cutka

updated vc6 project

2003-06-04 06:30 milan_cutka

optional short osd message on keypress, XVID_CPU_ -> FF_CPU_, def
constants cleanup, remember selected item in codecs listview,
IffProc6 (removed backward compatibility)

2003-06-03 06:20 milan_cutka

YV12 simpleresize and warpedresize

2003-06-02 14:43 milan_cutka

use currect fps in avisynth filter

2003-06-02 12:02 milan_cutka

movies source codec from V1 branch to HEAD (this is HUGE commit,
but I don't know how to do this better)

2003-06-02 11:04 milan_cutka

file TfilterSettings.h was initially added on branch V1.

2003-06-02 11:04 milan_cutka

moved filters settings to separate files, TfilterSettings
descendants available globally

2003-06-02 08:31 milan_cutka

updated vc6 project

2003-06-02 06:43 milan_cutka

option to automatically select different IDCT for XVID, better way
to display subtitles below the video, frame sizes visualization,
displaying QPEL info again, nic's postprocessing accepts arbitrary
YUV chroma subsampling, "interlaced" resizing

2003-05-30 14:58 milan_cutka

3IVX, RMP4, DM4V

2003-05-30 14:44 milan_cutka

no message

2003-05-30 14:43 milan_cutka

3IV2 fourcc added

2003-05-30 12:42 milan_cutka

Visual Studio 6 project for building libmplayer.dll, fixed crash in
swscaler when copying images with equal negative strides

2003-05-30 11:12 milan_cutka

updated some code from mplayer,

2003-05-30 06:31 milan_cutka

separate swscaler blur and sharpen filters

2003-05-29 15:36 milan_cutka

updated libswscale and libpostproc, fast_memcpy

2003-05-29 11:30 milan_cutka

file dwstring.cpp was initially added on branch V1.

2003-05-29 11:30 milan_cutka

file dwstring.h was initially added on branch V1.

2003-05-29 11:30 milan_cutka

std::string -> DwString

2003-05-29 09:09 milan_cutka

fixed bad subtitles coloring introduced by previous commit

2003-05-29 08:17 milan_cutka

updated vc6 project

2003-05-29 07:00 milan_cutka

file image.cpp was initially added on branch V1.

2003-05-29 07:00 milan_cutka

file colorspace.cpp was initially added on branch V1.

2003-05-29 07:00 milan_cutka

file Tsubreader.cpp was initially added on branch V1.

2003-05-29 07:00 milan_cutka

file Makefile was initially added on branch V1.

2003-05-29 07:00 milan_cutka

file mem_align.h was initially added on branch V1.

2003-05-29 07:00 milan_cutka

file mem_align.cpp was initially added on branch V1.

2003-05-29 07:00 milan_cutka

cosmetic: XVID_CSP_ -> FF_CSP, xvid_malloc->aligned_malloc,... can
be compiled by gcc again, modifying string parameters and selecting
active preset via remote control framerate doubler works again,
fixed TomsMoComp chroma strides, underline and colored subtitles,
almost separate subtitle lines handling, little bigger trackbar
sliders

2003-05-27 15:32 milan_cutka

working on subtitles

2003-05-27 10:26 milan_cutka

warning fixes

2003-05-27 08:35 milan_cutka

file TsubreaderMplayer.cpp was initially added on branch V1.

2003-05-27 08:35 milan_cutka

file Tsubreader.h was initially added on branch V1.

2003-05-27 08:35 milan_cutka

file TsubreaderMplayer.h was initially added on branch V1.

2003-05-27 08:35 milan_cutka

working on subtitles parser deglobalization (currently broken)

2003-05-27 08:30 milan_cutka

fixed temporal smoother

2003-05-27 06:48 milan_cutka

hint generation and filter settings reset are now members of filter
setting struct, updated libavcodec

2003-05-26 11:56 milan_cutka

no message

2003-05-26 11:52 milan_cutka

don't display OSD lines which wouldn't fit to the image at the
bottom, always use full picture for OSD

2003-05-26 09:29 milan_cutka

memcpy -> TffPict::copy in bmp saving
So, we might see audio support, and perhaps working MPEG1/2 video soon!

20th June 2003, 14:08

-_- Does he really want to support everything and the kitchen sink?

thop

20th June 2003, 14:17

The Link

20th June 2003, 14:41

personally i'd prefer to have audio not decoded with ffdshow ... there are plenty of other filters for that available already. why reinvent the wheel when f.e. ac3filter already does a pretty good job? Why not? :)
My impressions of ffdshow are, that it is milan's "baby" and in its form some kind of "proof of concept". I think milan does it for fun and to broaden his knowledge (which must already have the state of a compendium). The best part of it is that he lets us participate in his engagement! Arguments like "it is bloated" don´t count here IMHO because of its singular position in the video segment. Since ffdshow is fully configurable I don´t see any reason against audio support!

Regards,
The Link

edit: typos

gabest

20th June 2003, 14:50

The thing is dshow would allow only one filter to be the reader, parser, decoder, effecter and the renderer. But the power of dshow hides in its modularity and it is better to keep parts separate to be easily replacable. So, I also say it would be better to have an audio-only filter too, but that's only my opinion :)

Leak

20th June 2003, 19:05

Originally posted by gabest
The thing is dshow would allow only one filter to be the reader, parser, decoder, effecter and the renderer. But the power of dshow hides in its modularity and it is better to keep parts separate to be easily replacable. So, I also say it would be better to have an audio-only filter too, but that's only my opinion :)

Well, as long as this even remotely works like the video codecs it should be just another checkbox in the config dialog to deselect if you prefer some other audio decoder... :)

np; Senor Coconut - Smoke On The Water (ChaChaCha) (Fiesta Songs)

athos

21st June 2003, 02:23

well ffdshow is originally a dshow implementation of libavcodec, which eventually got added some elements of mplayer, nics dshow filter, etc. i think milan wants to implement as much as possible of libavcodec.

i agree that it would be cleaner and probably more practical too have a separate audio filter, which like ffdshow handles mpeg-4 and maybe some day mpeg-1 and 2, would handle most of the audio streams we handle. but it is still somehow cool to have all this stuff in one filter, and most of it works great! like low cpu usage and lots of options to play around with.

Blight

21st June 2003, 06:26

MP1/2 playback is tricky. A lot of non-microsoft filters that try to replace the microsoft one seem to break MPEG1 playback or introduce noises, screw with seeking, etc... I hope by default it'll be off.

MP3 on the other hand would be good as the current implementation chokes on MP3 files with headers containing a bitmap (that may actually have something to do with the source filter, unsure). And also the current MP3 decoder returns the wrong duration value for VBR, which would be a nice fix.

I wonder how milan is doing on the quicktime front, last message he wrote was about getting ffdshow to decode Sorenson3.

The RAW mode filter split is a good call as it will allow DVD-Only processing settings without effecting standard media playback.

I'd also root for milan to go for mpeg2, but the moment he does that (or sorenson for that matter), he should stop putting binaries on SF (See XVID).

qwerpoi

23rd June 2003, 21:19

A couple of things about ffdshow:

First, as someone mentioned in this thread earlier, i believe there is a color bug with the aWarpSharp filter (I'm running the 20030422 build since every other one crashes on my Win98 pc, but I didn't see any fix in the changelogs for the other builds). When the filter is on, the color on the bottom of the screen is messed up, even when the chroma mode is none. This bug disappears when I open my file via avisynth and ffdshow raw mode (don't know if that is helpful info or not).

Secondly, does anyone use the autoloading presets in ffdshow? I've never used them because it always seemed a bit clunky to me (and ffdshow seems to crash on my system when I try to set the autoloading conditions). I think a more graceful interface would be integrating some presets in the right-click interface. What I mean is that when you right click the video in a player such as mpc or zoomplayer, you can see ffdshow in the right click menu (if it's decoding the video). Instead of clicking on it to bring up the config dialog, make an additional menu (like directvobsub) which allows you to either bring up the config dialog or choose from a fixed number of custom presets (I can't imagine needing more than 5 or so, such as DVD, high quality avi, low quality avi, maybe some cartoon presets). I hope someone understands what I'm trying to say, I think it would be pretty handy :).

Lastly, can someone explain to me how the avisynth option is supposed to work in ffdshow? Are you supposed to load plugins that are already in your plugins directory? Do you need a line to load the file via avisynth? This is a pretty embarassing question, but I ask because every time I try to do anything (even something as simple as loadplugin), the player will crash. Maybe I'm stupid and completely misunderstand what needs to be done, I would appreciate it if someone would post exactly what they have in the avisynth box for something simple like applying convolution3d or something. Thanks.

ChristianHJW

24th June 2003, 09:36

@milan : please join #matroska irc.corecodec.com again, DaveEL has new, better native MPEG4 MKV samples made and we should discuss how we wnat to support playback with b-frames from ffdshow now soon .....

athos

29th June 2003, 18:35

i compiled a private build today (milan has asked me to wait for a while with releasing new builds on SF) and I can tell you that ffdshow now decodes mp3/mp2/aac/ac3/wma1,2,7 and 8! He has also implemented a framerate doubler with motion compensation! (as discussed here (http://forum.doom9.org/showthread.php?s=&threadid=36361)). This is very cool IMO, works very well, but there are some minor flickering sometimes. Aside from that, I think it helps make the motions flow better.

I only tried mp3 decoding of the audio filters yet, and it seems to work great! I think it is based on libmad which is good, its the best quality mp3 decoding i know of. There are very few options for the audio filters yet, but I guess milan will be adding more options later, like the rest of ffdshow.

I will put up a new build when milan asks me to.

oddball

29th June 2003, 19:58

I'm just waiting for him to fix the Avisynth script loader so I can use Autocrop correctly. BTW is there an Avisynth plugin that can add black bars on all sides (while shrinking the image)? I'm wondering if there is anything less CPU intensive than ffdshows own black border option. Good for overscan compensation on anime fansubs.

Blight

29th June 2003, 20:56

oddball:
You can just zoom the video in/out using most players. (+ / - keys in zoom player).

Sirber

29th June 2003, 21:00

Just a little bug report:

When I play with postprocessing, MPC crash...

oddball

30th June 2003, 18:57

Blight: No for TV out on a Matrox G400 you can't. ;)

Tueurne

1st July 2003, 11:54

Just a question about idct :

in misc
simple use simple idct
xvid use walken idct
but what about normal and reference ? why kind of idct are used ?

Lobuz

1st July 2003, 13:23

I made some PSNR tests of ffdshow decoding of xvid file. It's here (http://forum.doom9.org/showthread.php?s=&threadid=56190&perpage=20&pagenumber=7). It shows that with latest build nic's postprocessing is somehow broken.
It was said earlier that it's crashing but it actually gives worse picture. It behaves better after setting X offset from 20 to 30 and that green garabage at clip start disappeare too.

Regards
Lobuz

simon.mittag

5th July 2003, 08:39

Originally posted by oddball
I'm just waiting for him to fix the Avisynth script loader so I can use Autocrop correctly. BTW is there an Avisynth plugin that can add black bars on all sides (while shrinking the image)? I'm wondering if there is anything less CPU intensive than ffdshows own black border option. Good for overscan compensation on anime fansubs.

This would be my biggest wish at the moment as well! The avisynth plugin loader in ffdshow (the custom source filter) does not seem to support getframe(x) in raw mode. this was discussed in the autocrop thread on the avisynth board a while ago. i contacted the autocrop author but he said there is nothing he can do as long as getframe(x) does not deliver him the frames requested.

in raw mode, getframe() seems to deliver only the current frame as opposed to the requested frame, which prevents autocrop from calculating the right cropping information as it needs several frames for that.

milan if you read this, can we have your comments on the situation please?

autocrop for RAW mode would finally enable me to use ffdshow as a full blown postprocessor for DVD playback that lets me do positioning with zoom player based only on the picture information without the bars. this is what i am looking at doing with my projector setup and screen fitting.

will requesting frames in raw mode ever work or is this a streaming problem that can't be solved?

regards,

Simon

P.S. the reason why i need raw mode is because i want to use the sonic 1.5 mpeg2 filters for decoding as I just love the crisp image they produce. im using ffdshow as a postprocessor after the sonic filter b4 the video renderer.

oddball

5th July 2003, 09:04

simon.mittag: Have you ever tried DiVXG400 in a Zoom Player manual filter? I have used it (It only works using the WinDVD playback filter for DVD though) and it lets you crop black bars in the overlay to TV out. Very good for non-anamorphic movies if you have a widescreen TV as it will provide a 'false' anamorphic squeeze.

This makes for a nicer looking zoom than my own TV provides.

Can provide the filter settings if needed.

Would love to get ffdshow as a post processing filter though with autocrop. Would be easier.

simon.mittag

5th July 2003, 11:31

oddball: no I haven't tried that particular filter. I agree though that ffdshow/avisynth would be easier.

I am unsure if RAW mode will ever allow for seeking, as I don't know if ffdshow just acts as "listener" to the current frame provided by the mpeg decoder filter.

Can someone comment on this please? Is RAW mode a slave (listening)mode?

regards,

Simon

pandv

6th July 2003, 17:46

A little and cosmetic bug for this awesome program.

Using ffdshow 2003-05-23, levels->show histogram shows nothing.

Bye.

Animaniac

7th July 2003, 10:12

athos, milan

Any news on when the next build will be availible? I'm itching to try the audio decoding. ^_^

Chibi Jasmin

8th July 2003, 11:36

Originally posted by oddball
simon.mittag: Have you ever tried DiVXG400 in a Zoom Player manual filter? I have used it (It only works using the WinDVD playback filter for DVD though) and it lets you crop black bars in the overlay to TV out. Very good for non-anamorphic movies if you have a widescreen TV as it will provide a 'false' anamorphic squeeze.

This makes for a nicer looking zoom than my own TV provides.

Can provide the filter settings if needed.

Would love to get ffdshow as a post processing filter though with autocrop. Would be easier.

Yes, please let me know, how you get ZoomPlayer in DVDMode (with WinDVD) to work with DivXG400!

oddball

8th July 2003, 17:02

First off you need WinDVD installed and DiVXG400 obviously. You may also need AC3filter installed.

Paste this into a text file

DefineFilter(iviaudio.ax)
DefineFilter(ivivideo.ax)
DefineFilter(DiVXG400.ax)
DefineFilter(AC3Filter.ax)
LoadFilter({E30629D1-27E5-11CE-875D-00608CB78066},Default WaveOut Device)
LoadFilter({70E102B0-5556-11CE-97C0-00AA0055595A},Video Renderer)
LoadFilter({A753A1EC-973E-4718-AF8E-A3F554D45C44},AC3Filter)
LoadFilter({CD8743A1-3736-11D0-9E69-00C04FD7C15B},Overlay Mixer)
LoadFilter({6E8D4A20-310C-11D0-B79A-00AA003767A7},Line 21 Decoder)
LoadFilter({0246CA20-776D-11D2-8010-00104B9B8592},InterVideo Video Decoder)
LoadFilter({9B8C4620-2C1A-11D0-8493-00A02438AD48},DVD Navigator)
LoadFilter({9D2935C7-3D8B-4EF6-B0D1-C14064698794},DiVXG400)
ConnectPin(DVD Navigator,Video,InterVideo Video Decoder,Video Input)
ConnectPin(DVD Navigator,AC3,AC3Filter,In)
ConnectPin(DVD Navigator,SubPicture,InterVideo Video Decoder,Subpicture Input)
ConnectPin(AC3Filter,Out,Default WaveOut Device,Audio Input pin (rendered))
ConnectPin(InterVideo Video Decoder,Video Output,DiVXG400,In)
ConnectPin(DiVXG400,Out,Overlay Mixer,Input0)
ConnectPin(InterVideo Video Decoder,~Line21 Output,Line 21 Decoder,In)
ConnectPin(InterVideo Video Decoder,~Subpicture Output,Overlay Mixer,Input2)
ConnectPin(Line 21 Decoder,Out,Overlay Mixer,Input3)
ConnectPin(Overlay Mixer,Output,Video Renderer,In)

save it in Zoom Players dvdgraph scripting folder. Rename the file from .txt to .dvdgraph

Now load Zoom Player. Got to the DVD setup menu and select custom filters. Choose the new script and you are done.

Edit it to suit but be aware that not all filters work in the same setup/manner.

EDIT: Hmm. It does not work for me anymore after having to reinstall XP etc. I even tried connecting the video out from the Intervideo filter to the DiVXG400 filter and it would not accept the pin whereas it did before no problem. Blah!

Chibi Jasmin

8th July 2003, 17:26

Originally posted by oddball
First off you need WinDVD installed and DiVXG400 obviously. You may also need AC3filter installed.

Paste this into a text file

DefineFilter(iviaudio.ax)
DefineFilter(ivivideo.ax)
DefineFilter(DiVXG400.ax)
DefineFilter(AC3Filter.ax)
LoadFilter({E30629D1-27E5-11CE-875D-00608CB78066},Default WaveOut Device)
LoadFilter({70E102B0-5556-11CE-97C0-00AA0055595A},Video Renderer)
LoadFilter({A753A1EC-973E-4718-AF8E-A3F554D45C44},AC3Filter)
LoadFilter({CD8743A1-3736-11D0-9E69-00C04FD7C15B},Overlay Mixer)
LoadFilter({6E8D4A20-310C-11D0-B79A-00AA003767A7},Line 21 Decoder)
LoadFilter({0246CA20-776D-11D2-8010-00104B9B8592},InterVideo Video Decoder)
LoadFilter({9B8C4620-2C1A-11D0-8493-00A02438AD48},DVD Navigator)
LoadFilter({9D2935C7-3D8B-4EF6-B0D1-C14064698794},DiVXG400)
ConnectPin(DVD Navigator,Video,InterVideo Video Decoder,Video Input)
ConnectPin(DVD Navigator,AC3,AC3Filter,In)
ConnectPin(DVD Navigator,SubPicture,InterVideo Video Decoder,Subpicture Input)
ConnectPin(AC3Filter,Out,Default WaveOut Device,Audio Input pin (rendered))
ConnectPin(InterVideo Video Decoder,Video Output,DiVXG400,In)
ConnectPin(DiVXG400,Out,Overlay Mixer,Input0)
ConnectPin(InterVideo Video Decoder,~Line21 Output,Line 21 Decoder,In)
ConnectPin(InterVideo Video Decoder,~Subpicture Output,Overlay Mixer,Input2)
ConnectPin(Line 21 Decoder,Out,Overlay Mixer,Input3)
ConnectPin(Overlay Mixer,Output,Video Renderer,In)

save it in Zoom Players dvdgraph scripting folder. Rename the file from .txt to .dvdgraph

Now load Zoom Player. Got to the DVD setup menu and select custom filters. Choose the new script and you are done.

Edit it to suit but be aware that not all filters work in the same setup/manner.

Thanx a lot...!

oddball

8th July 2003, 20:22

OK figured why it was not working. You need the Elecard MPEG decoder installed. It uses that even though the Intervideo is in the fiulter chain. Weird.

Get it here http://www.elecard.com/ftp/pub/mpeg/decoder/EMpgDec20.zip

Install it and use that filter and you should have no probs cropping black bars off 4:3 letterbox DVD's to create an artificial 'zoom' on a 16:9 TV.

It's rather neat :)

iago

9th July 2003, 01:30

Hello, I just wanted to note that libavcodec decoding still exhibits the smearing problem with xvid qpel encodes regardless of the IDCT type selected. Problem occurs both with XviD and Simple IDCT.

With codec's built-in XviD decoder, there's no smearing.

Nic's XviD Decoder also causes smearing.

regards,
iago

[latest ffdshow alpha (ffdshow-20030523) / latest XviD build by Koepi (24062003-1) / latest XviD build by uManiac (26.06.2003.1100)]

Animaniac

10th July 2003, 22:34

CVS comments show that ffdshow audio will have raw audio counterpart and have a built in equalizer and channel mixer!!! ffdshow is really going to become the one-stop A/V decoder! ^_^

oddball

15th July 2003, 23:33

I'm getting the same problem with DiVX 5.03 with smearing. I presume this is also because of qpel. It seems to happen randomly though. I thought that bug would have been squashed by now.

Mind you I've upgraded to an AMD XP chip and resintalled WinXP from scratch so I don't know how much that has to do with it. Also a new Geforce4 card. I hate bug tracking :)

simon.mittag

17th July 2003, 06:01

oddball... did you hear anything from milan regarding avisynth and autocrop? i haven't seen him here for a while but it probably doesn't make sense for all of us to start emailing him...

aydc

17th July 2003, 11:00

Hi all,

Could anybody please explain to me why mplayer postprocessing stopped working with the lastest releases? I used to rely on it rather than nic's because nic's pp seems to blur the image too much.

Or alternatively, could anyone please recommend me good postprocessing settings to use?

oddball

17th July 2003, 18:24

I dunno why but I seem to get random smearing and the odd static blocks with or without ffdshow in the equation. So it probably is not ffdshow causing my problem. If I play back the same scene after it smears it does not smear. Odd.

I dunno about autocrop. If Milan reads the ffdshow threads then I am sure he is on the case. Maybe...

Animaniac

17th July 2003, 20:27

Originally posted by aydc
Hi all,

Could anybody please explain to me why mplayer postprocessing stopped working with the lastest releases? I used to rely on it rather than nic's because nic's pp seems to blur the image too much.

Or alternatively, could anyone please recommend me good postprocessing settings to use?

Lobuz' PSNR table in this thread (http://forum.doom9.org/showthread.php?s=&threadid=56190&perpage=20&pagenumber=7) tests the 4-24 and 5-23 build of ffdshow. Nic's using default settings on the 4-24 produces the highest PSNR. The 5-23 seems to have problems with Nic's at lower thresholds.

kilg0r3

22nd July 2003, 08:33

1.

I would like to do the following in the avsynth box, or of possible somewhere else, in ffdshow. In order to get rid of the stepping/pixelation effects with intensive colors due to the low chroma res of YV12.

increase the chroma resloution (e.g. converttoyuy2), blur the chroma plane, merge luma of original with blurred chroma.

the problem is manly, how to define the video source.

2.
What does 'Add ffdshow video source' mean?

Best

22nd July 2003, 12:35

increase the chroma resloution (e.g. converttoyuy2), blur the chroma plane, merge luma of original with blurred chroma.

I belive if you uncheck YV12 as supported output colorspaces it would automaticly convert to yuy2.

oddball

22nd July 2003, 20:31

When will ffdshow support MPEG1/2 ?

ookzDVD

26th July 2003, 02:16

Build 2003-05-23,
I just found : enabling the xshapen "sometimes" will crash the MPC.

Soulhunter

27th July 2003, 23:30

ffdshow crash with "ConverToRGB32()" command in AviSynth-tab...!

Maybe read this thread > http://forum.doom9.org/showthread.php?s=&threadid=38304&perpage=20&pagenumber=2 <

I used:
WinME / ffdshow 23.05.03 / Avisynth is 2.5.2

This was the error code:

MPLAYER2 verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 018f:bff8e1ad.
Register:
EAX=c002fa54 CS=018f EIP=bff8e1ad EFLGS=00210212
EBX=0177ffbc SS=0197 ESP=0173feec EBP=01740188
ECX=00000000 DS=0197 ESI=00000000 FS=2acf
EDX=bff6682d ES=0197 EDI=bff69050 GS=0000
Bytes bei CS:EIP:
53 8b 15 f4 bc fb bf 56 89 4d e4 57 89 4d dc 89

Bye

Arcon

28th July 2003, 20:42

i just updated to 20030523 and use xvid.dll for decoding xvid. now i get some wrongly colored horizontal lines. i think that's what happens if one uses the wrong idct, but i chose xvid, not libavcodec as decoder, so the idct should be external and correct.

this effect only appears if i enable postprocessing (preset 4, nic's enabled). with the older build 20030424 i don't get this effect even with postprocessing enabled.

codec is xvid 24062003-1.

Soulhunter

28th July 2003, 21:21

Suggestion for additional Noise option;

I'm a big fan of ffdshow's noise option... It repruduces the original film-grain real good! :D
But I find there should be a option to scale between normal & uniform noise.
Normal noise adds less noise to dark arears and uniform noise adds to all arears the same amout...
For now I use mplayer-uniform-noise at a low amout 15/5 but in this way theres to much noise in dark arears, and not enough in bright ones... If I use normal-noise (not uniform) there's not enough noise in dark arears (for me)!
So I would find it nice to add a slider in the noise-option-tab to scale between uniform/normal noise.

Should look like this:
-----------------------------------------------------------
uniform noise 0% <-----I-----> 100% regular noise
-----------------------------------------------------------

0% = Uniform noise (dont take respect to the brightness/darkness of arears)

50% = Noise in very dark arears reduced to 50% in bright still 100%

100% = Noise only in very bright arears (Near like none in dark arears)

All % based of the noise amout you've choosen by noise strength-tab.

@All
Keep posting back ! :)

Bye

Ghim

29th July 2003, 00:03

Originally posted by Arcon
i just updated to 20030523 and use xvid.dll for decoding xvid. now i get some wrongly colored horizontal lines. i think that's what happens if one uses the wrong idct, but i chose xvid, not libavcodec as decoder, so the idct should be external and correct.

this effect only appears if i enable postprocessing (preset 4, nic's enabled). with the older build 20030424 i don't get this effect even with postprocessing enabled.

codec is xvid 24062003-1.

I had the same pb on a video and i simply changed X threshold from 20 to 30 in Nic postprocessing... It solved the problem for me...

Asmodian

29th July 2003, 03:39

had the same pb on a video and i simply changed X threshold from 20 to 30 in Nic postprocessing... It solved the problem for me...

Wouldn't that make the image rather blurry?
I have also noticed these problems (horizontal lines with wrong colors, especially at the ends -> green) with the 20030523 build of ffdshow (with Nic's PP at default thresholds). This build also crashes ZP in many different configurations and I haven't done the testing necessary to figure out exactly what causes the crash (but I am pretty sure it is something with this ffdshow because of when I would get a crash on video load and then turn off PP and the video would load, or I would just disable ffdshow and again the video would load – it seemed somewhat source dependent and sometime the PP didn’t cause problems). Has anyone else experienced a crash using this newest ffdshow?

Ghim

29th July 2003, 10:14

The image isn't that blurry at all... but the horizontal lines bug has really disappeard.

I also have experienced some random crashes with Nic's PP activated (I'm using ZP)...

kilg0r3

29th July 2003, 12:34

incresing the threshold values decreases pp strength

Ghim

29th July 2003, 13:06

I prefer this (X threshold 30) than a "horizontal line bug" or "no PP"...

Asmodian

29th July 2003, 22:09

incresing the threshold values decreases pp strength
Oops, I even knew that - I must have meant; doesn't increasing the threshold make the post processing less effective? :p
yes it is better to just turn up the threshold then have artifacts (pp created or from lack of pp), but this is a newly introduced problem that should be investigated (but work is very busy this week so I don't think I will be able to find the time to test). I also have quite a few videos compressed with xvid and divx (older builds) which play as solid gray video when decoded with libvcodec in the newest ffdshow but work fine if decoded with xvid.
I hope we can get to the bottom of this.

Didée

31st July 2003, 07:58

Originally posted by Asmodian
xvid and divx (older builds) which play as solid gray video when decoded with libvcodec
ffdshow/miscellaneous/Workaround ecoder bugs - [x]Autodetect

Know your tools

- Didée

Asmodian

1st August 2003, 00:37

Ah, I see - I usually don't change options in the miscellaneous tab, did the defaults recently change or did I just foolishly turn off autodetect workaround bugs (or were the defaults always autodetect off and I never needed it on before)?
Do you think this option would have an effect with regard to the crashing problem with nic's pp, or is it more likley that the crashing problem is not actually ffdshow's fault?

Takuto

1st August 2003, 23:45

I have small feature request to ffdshow. It mostly decorative, but I think it can be useful and its not too hard in realisation.

Can OSD be 'temporary'? For example, user enable param 'delay' in ffdshow config, sets it to 5 sec, and OSD will on-screen for 5 secs when video starts, then it gone (with cool effects 8)) ).
And can be FOURCC of file included into OSD table? Not only 'decoder' info, but FOURCC too.

I think its convinient - starting playback of file and in 5 secs get basic info about it without going in config page or into other apps.

An I want to say BIG thanks to Milan and all contributing in ffdshow.
Its really my favorite decoder.

HarryM

2nd August 2003, 08:57

I think over simple/Walken iDCT automatic switching at ffdshow decoding.

Can anyone this make depending on 'date of file'?

from dd.mm.yyyy to dd.mm.yyyy -> use simple iDCT!
from dd.mm.yyyy to dd.mm.yyyy -> use Walken iDCT!

dTb

2nd August 2003, 09:16

Originally posted by Asmodian
Wouldn't that make the image rather blurry?
I have also noticed these problems (horizontal lines with wrong colors, especially at the ends -> green) with the 20030523 build of ffdshow (with Nic's PP at default thresholds). This build also crashes ZP in many different configurations and I haven't done the testing necessary to figure out exactly what causes the crash (but I am pretty sure it is something with this ffdshow because of when I would get a crash on video load and then turn off PP and the video would load, or I would just disable ffdshow and again the video would load – it seemed somewhat source dependent and sometime the PP didn’t cause problems). Has anyone else experienced a crash using this newest ffdshow?

I've experienced much the same thing all centred around nic's post-processing being enabled when opening a file. Opening the particular file without the pp enabled it will play and the pp can then be enabled during playback. When I get a chance I'll see if I can isolate which files this occurs with and any similarities between them. No problems with the mplayer pp.

Edit: I'm only experiencing the crashing in Zoomplayer not the other problem.

HarryM

2nd August 2003, 12:26

Originally posted by dTb
I've experienced much the same thing all centred around nic's post-processing being enabled when opening a file. Opening the particular file without the pp enabled it will play and the pp can then be enabled during playback. When I get a chance I'll see if I can isolate which files this occurs with and any similarities between them. No problems with the mplayer pp.

Edit: I'm only experiencing the crashing in Zoomplayer not the other problem.

If you use W9x, the last 'good' ffdshow version for you is 24/04/2003.

Newer builds of ffdshow crash on Win9x. Only one choice is = VMR9 activating for playing. With WXP no problem.

Lobuz

3rd August 2003, 23:43

Is there a possibility to reduce CPU utilization while decoding mpeg4 even by the cost of the quality ( no pp ). I mean decoding only video with my old Pentium 200 is almost 100% fluent but with sound it's shaky. It could be useful to some portable devices and old PCs.

Regards
Lobuz

dTb

5th August 2003, 04:26

Originally posted by HarryM
If you use W9x, the last 'good' ffdshow version for you is 24/04/2003.

Newer builds of ffdshow crash on Win9x. Only one choice is = VMR9 activating for playing. With WXP no problem.

I'm using WinXP with the 23/5/03 alpha, I'm unsure what you mean by VMR9.

The problem occurs only with files with a fourcc of DIV3 as far as I can tell and I think I've narrowed it down to the Chroma Dering of Nic's pp. Most files can be opened when the pp is set on the fifth notch (ie. everything bar Chroma Dering) and then during playback the chroma dering can be enabled although for one file this didn't work. Just testing now, with only the chroma dering enabled via custom I get the same problem, file won't open in ZP.

Soulhunter

5th August 2003, 13:49

Suggestion for additional Noise option No.2;

Ive forgotten something in my last suggestion... :D
A second option to scale between standart and averanged noise would also be usefull!

Should look like this:
-----------------------------------------------------------
Averaged noise 0% <-----I-----> 100% regular noise
-----------------------------------------------------------

0% = Averaged noise (same as now with aktiv averaged)

50% = 50/50 blended (original and averaged)

100% = Regular noise (same as now without aktiv averaged)

Bye

HarryM

5th August 2003, 17:41

Originally posted by dTb
I'm using WinXP with the 23/5/03 alpha, I'm unsure what you mean by VMR9.

VMR9 = Video Mixing Renderer 9 (DirectX 9)

Asmodian

5th August 2003, 19:00

I am using WinXP with VMR9.

dTb

6th August 2003, 01:51

Yep using DirectX 9.0, maybe I should update to 9.0b.

I just noticed on the release notes for ffdshow-20030424 that post-processing was updated, it's possible the problem originates there. When I get the chance I'll try that and some previous alpha's to try and see if that's the case.

Soulhunter

9th August 2003, 00:07

>
ffdshow crash with "ConverToRGB32()" command in AviSynth-tab
<

Addition to my above shown post:

ffdshow v.2003.04.24 does not crash at playback, but the video is shown "wrong" (vertical green and pink lines in the pic) :confused:

Thats all for now...

Bye

MarkCoolio

13th August 2003, 14:48

Has someone already tried the 2003.07.11 release and seen if bugs are solved? I am currently downloading it and will test it soon too...

sekxx

13th August 2003, 15:07

escuse me Mark, but where did U find this release, i don't see it on sourceforge

MarkCoolio

13th August 2003, 15:17

Drop me a mail... I can send it to you then. Sorry have no download link. I received it by icq...

By the way: it includes ffdshow audio decoder part :)

Ghim

13th August 2003, 20:13

I hope there will soon be a public release...
I really want to try the new version with bugfixes and new functions (audio decoder) ...

MarkCoolio

13th August 2003, 20:25

Hi athos,

i see you online on this board right now.

Just a question: is the ffdshow version I have public? If not, I won't share it of course. Don't know where my mate had it from. But I searched for it today on official sites and did not find it there.

Please let me know. Thanks...

athos

13th August 2003, 20:50

the 20030711 release is not official, but you can spread it no problem. i compiled it, its just that milan asked me not to put it up on sourceforge. but anyone can download the source off the cvs on sf and compile it themselves, so its not like theres an NDA or anything ;) Actually, you might want to take a look in http://athos.leffe.dnsalias.com/

Ghim

13th August 2003, 22:43

I've seen some anoying PP that were in 20030523 fixed... great work !! (what's what I wanted the most...)

If I see some bugs (and that's the case) in 20030711 release, should I report them even if the release is not official and even if it's 1 month old ??

BoNz1

14th August 2003, 01:45

Under IDCT there is a new routine called Skal's IDCT. Not to sure exactly whether it is Walken or Simple or something else but I found on his site this http://skal.planet-d.net/coding/mp4.html at the bottom in the changelog:

02/03: v0.06: . Big decoder speed-up (MMX/SSE) with a new self-contained Sparse IDCT and an experimental IDCT-Add and IDCT-Put. Yeah! I broke the silly 1500 fps limit :). No real impact yet on the encoder.
02/03: v0.05: . Sparse IDCT (MMX/SSE) was not rounded correctly => "greenish" color bleeding was *very* visible. + removed some unnecessary code: Arithmetic coding, LZW codec, Symbol entropy, Gif-PCX-Tga I/O... I'll put it back if needed later. I'm now done with the quantization bugs I was mad about. pfeeewww... :) Next step is to fix the encoder!

So I guess it is different than both (or maybe it is made more for simple) :D anyhow it looks much better than the XVID IDCT in ffdshow IMO when decoding Walken content but still has a couple problems. Maybe if it was made specifically to decode Walken it would be perfect.

Animaniac

14th August 2003, 05:39

Is the "Autoselect" for the IDCT selecting the best/correct IDCT for Walken XviD content? Skal? Is it selecting simple for non-Walken?

CruNcher

14th August 2003, 06:04

@ athos
what for external includes are needed to build it ?

btw seemes their is a bug in this build thats causeing film (24 fps) content to be wrongly played, info shows 24.39 fps and its not fluid so use this build carefully

athos

14th August 2003, 10:11

Originally posted by Ghim
If I see some bugs (and that's the case) in 20030711 release, should I report them even if the release is not official and even if it's 1 month old ??
I guess it wont hurt, feedback is good.

Ghim

14th August 2003, 11:47

Here's a bug that wasn't here in 23/05/2003 build. I compiled the latest CVS source and it's still there... :

When vertical resolution isn't divisible by 8, and if Chroma Deblock (H) is enabled, ffdshow seems to crash...

Animaniac

15th August 2003, 03:23

Originally posted by Ghim
Here's a bug that wasn't here in 23/05/2003 build. I compiled the latest CVS source and it's still there... :

When vertical resolution isn't divisible by 8, and if Chroma Deblock (H) is enabled, ffdshow seems to crash...

I have a similar problem. ffdshow (newer than 23052003) crashes with dev-api-4 (720x426) material when Nic's PP active.

oddball

15th August 2003, 19:21

Has anyone figured out how to get AutoCrop to work with ffdshow correctly? All I get is a cropped video that is set within a 4/3 overlay. It does not crop the overlay for some reason so when outputting to a TV it shows the black bars still (But has cropped top and bottom only it's not zoomed it in the overlay if you get my meaning).

It's cropping but not actually CROPPING to the playback window.

athos

16th August 2003, 12:20

For those who dare, you might want to take a new look in http://athos.leffe.dnsalias.com/
...

Ghim

16th August 2003, 13:46

I tried 16/08/2003 build and 11/07/2003 and I got some bugs with both versions...
I sometimes seems to have a conflict problem with ffdshow audio decoder and Ms MPEG3 Decoder (I desactivated every audio decoding in ffdshow audio decoder). The video plays very choppy (with ZP at least).

I don't know how ffdshow audio decoder interract in this problem but it does... If I just manually unregister ffdshow audio decoder (with ZP filter manager), I got no more problem but no more sound too... I need to restart my computer to get back sound and I don't have the problem anymore... This is a proof ffdshow audio decoder is playing a role in this problem.

How is it that ffdshow audio decoder seems to interract in my audio graph when I desactivated every audio decoder in ffdshow config ??

Ghim

16th August 2003, 13:54

I'd like at least an option in the installer to disable the audio decoder installation (registering)...
This way, I won't have the problem I mentioned in my precedent post anymore...

Animaniac

16th August 2003, 19:39

Originally posted by Animaniac
I have a similar problem. ffdshow (newer than 23052003) crashes with dev-api-4 (720x426) material when Nic's PP active.

Still remains in 16082003. :(

The Audio Decoder still doesn't work after seeking (since 11072003).

Gaia

16th August 2003, 21:36

The Audio Decoder still doesn't work after seeking (since 11072003).

It works fine after seeking in my machine but i am using Win98SE...

I sometimes seems to have a conflict problem with ffdshow audio decoder and Ms MPEG3 Decoder (I desactivated every audio decoding in ffdshow audio decoder). The video plays very choppy (with ZP at least).

I didn't see anything like this in my short test with several players including ZoomPlayer. It can ofcource happend randomly i only tried it with few files.

Ghim

16th August 2003, 21:47

I forgot to tell... I'm using WinXP SP1.

oddball

17th August 2003, 11:07

New Athos builds cause jerky playback (Was hard to spot at first). It judders every half second especially on pans and stuff moving sideways slowly. This was happening when playing back a 25FPS XviD with AC3 sound (Even though it was disabled in ffdshow audio properties and AC3filter was handling it).

Using last official alpha the jerk is not there. It's not an audio interleave problem as that is set to 64ms (Which always works for me).

Owen

17th August 2003, 11:59

I have big problems with audio sync with 11072003 and DVD playback in Zoom Player using WinDVD 5 decoders. Even if no ffdshow filters are in use.
Playback of Xvid and Divx files is perfect.

Regards,

Owen

kastro68

17th August 2003, 18:14

Originally posted by oddball
New Athos builds cause jerky playback (Was hard to spot at first). It judders every half second especially on pans and stuff moving sideways slowly. This was happening when playing back a 25FPS XviD with AC3 sound (Even though it was disabled in ffdshow audio properties and AC3filter was handling it).

Using last official alpha the jerk is not there. It's not an audio interleave problem as that is set to 64ms (Which always works for me).

I seem to be experiencing a similar problem, but with *.asf music video files downloaded off the net. In my case, ffdshow reports the files as MP43 and wmv1 in the info tab. For a particular clip it plays smoothly with MPC up to 30 seconds, then after that same spot it starts lagging from 30 secs till the end of the clip. It consistently starts the lagging at the same spot each time. It only lags when I use Gabest's Media player classic 6459 with athos's most recently compiled ffdshow (at the time of this message)

Video playback works smoothly with windows media player 8 and 6.4.
I don't seem to be having any trouble with any other file type thus far.

I had to switch back to ffdshow-20030523.exe since it works smoothly with MPC. I'm not sure if it is an ffdshow issue or an MPC issue.

Soulhunter

17th August 2003, 22:26

Nice Work... :D

Here are some "bugs" I found in the ffdshow 2003.08.16

Video Filter:

Avisynth command ConvertToRGB32() does work now... :D
But changeing to Fullscreenmode does deaktivate it I think... Also when cahngeing back from Fullscreen to normal, it still deactivated. Only restarting the Player works... :(

Warpsharp (aWarpSharp) crashes the player... But ffdshow original warpsharp not!
When I change from original to aWarpSharp while playback, the scrren is full of green horizontal lines... :confused:

MJPEG decoding (Morgan_Multimedia_M-JPEG_V2_Codec) produces a small black boarder at the right side of the screen...

When I play a file, and DragDrop a second while playing, the player crashes...

Audio Filter:

WindowsMedia-Audio8 doesnt play... :confused:

Mixer:

Mono output plays the sound... Uhm... very-fast... :D

3/0 - 3 front plays it to slow...

2/1, 3/1, 2/2 quadro, 3/2, 2/0+SW, 3/0+SW, 2/1+SW, 3/1+SW, 2/2+SW and 3/2+SW doesnt play anything... !?!

But 2/0, 1/0+SW, DolbySurround-ProLogic and Dolby ProLogicII works fine... :)

But Dolby ProLogicII causes DeSync when I play Audio+Video...

Winamp PlugIns are working generally... My favorite is the 4Front Headphones plugin... (FU#*KN GREAT :D)

But some Winamp plugins (exspecialy ones with an config. GUI) cause a "hanging" of the player... (endless loading of the config. GUI)

I used different Audio & Video Files for testing (XviD/DivX5/MP3/MP2 etc.)

System stuff: WinME, DX9b, Detonator40.7x Driver

Thats all so far...

Bye

Soulhunter

18th August 2003, 13:58

SOME NEW BUGS I FOUND (ffdshow-2003-08-16)

----------------------------

ffdshow audio decoder + activated winamp plugin, shows an error in KERNEL32.DLL when you exit the player... (tested with different plugins)

----------------------------

Video playback (MPEG with different decoders) + audio playback (MP2/MPA with ffdshow decoder) the palyer shows an error message when a winamp-plugin is activated, and you exit the player or you try to skip...

This is the ERROR message:

MPLAYER2 verursachte einen Fehler durch eine ungültige Seite
in Modul <Unbekannt> bei c16e:018251df.
Register:
EAX=0056eae4 CS=018f EIP=018251df EFLGS=00010246
EBX=0056eae4 SS=0197 ESP=0053002c EBP=0053004c
ECX=005300d0 DS=0197 ESI=8195090c FS=2247
EDX=bff6682d ES=0197 EDI=005300f8 GS=0000
Bytes bei CS:EIP:

Stapelwerte:
bff66821 005300f8 0056eae4 00530114 005300d0 00530204 bff6682d 0056eae4 005300e0 bff7845a 005300f8 0056eae4 00530114 005300d0 018251df 005302bc

----------------------------

Video playback (MPEG with different decoders) + audio playback (MP2/MPA with ffdshow decoder) the palyer shows an blue-error-screen when a winamp-plugin is activated, and you try to skip...

----------------------------

I do some more tests tomorow...

Bye

IvS

19th August 2003, 09:47

ever thought those may be WINAMP PLUGIN bugs?

slxslxslx

19th August 2003, 10:52

Where can I download the newest version?I can not find the ffdshow-2003-08-16 in sourceforge

Assault

19th August 2003, 11:31

If you've read this thread carefully you would have found http://athos.leffe.dnsalias.com/ for downloading the latest ffvfw and ffdshow builds.

Assault

slxslxslx

19th August 2003, 12:19

my dns Server has something wrong. I can not get the true ip of the http://athos.leffe.dnsalias.com/.so I ask the question. Now I get the true IP of it. no problem now.thank you.

Soulhunter

19th August 2003, 16:10

@IvS: Ever thought those may be WINAMP PLUGIN bugs?

No, I dont think so... Because in Winamp they work without any errors (for long time now...) So I think its a problem in ffdshow... !?!

But I found some new bugs:
----------------------------

Cropping produces a green boarder around the image and gives an error message when closing the player (test was DivX/Xvid video different crop values)

Error message was:

MPLAYER2 verursachte einen Fehler durch eine ungültige Seite
in Modul KERNEL32.DLL bei 018f:bff8e1ad.
Register:
EAX=c002fa54 CS=018f EIP=bff8e1ad EFLGS=00010212
EBX=0056ff68 SS=0197 ESP=0052fd8c EBP=00530028
ECX=00000000 DS=0197 ESI=00000000 FS=1287
EDX=bff6682d ES=0197 EDI=bff69138 GS=0000
Bytes bei CS:EIP:
53 8b 15 f4 bc fb bf 56 89 4d e4 57 89 4d dc 89

----------------------------

Zoom function produces a green boarder around the image...(test was DivX/Xvid video different zoom values)

----------------------------

Bye

aydc

21st August 2003, 08:34

I downloaded the latest version, (200308xx) and I'm dismayed to see that the mplayer postprocessing that was broken in 200305xx is still broken. I prefer mplayer pp to nic's pp since it's simply better.

As a result of this, I'm not using ffdshow anymore. Latest beta DivX decoders have much better pp.

Are there no plans to implement mplayer postprocessing again?

Gaia

21st August 2003, 10:01

No, I dont think so... Because in Winamp they work without any errors (for long time now...) So I think its a problem in ffdshow... !?!

So what? Did Milan say all Winamp plugins work with ffdshow?

I know quite a few Winamp plugins that works with Winamp but not with any other programs that should support Winamp plugins...

Soulhunter

21st August 2003, 14:38

@Gaia "So what? Did Milan say all Winamp plugins work with ffdshow?"

Uhm...? No, but as this option is included in ffdshows audiofilter I thought it should ;)

If the option to use Winamp2 plugins is integrted... I think he wants that it works with all (or most) winamp plugins... So I wrote about the errors/bugs/problems I got...

Was this wrong...? :(

Bye

[PS: I got also lot of errors when useing WA2-plugins in bsplayer...]

Gaia

21st August 2003, 15:22

No no nothing wrong with reporting "bugs". I am just not so sure if they really are bugs like IvS said...

Soulhunter

21st August 2003, 22:27

@Gaia
I was also not "really" sure... But I thought its better to post this than not... The best way would be to let milan decide if its a real bug ;)

Bye

athos

22nd August 2003, 19:02

It's good that you are posting bugs, but please remember that all builds since 2003-05-23 or whatever the latest one on SF, are unofficial. Milan has asked me not to put anymore on sf for a while, so i just provide them here for those who are curious.
After all, anyone can download the source off the cvs and compile for themselves.

midiboy

28th August 2003, 23:17

Hi !

I hope this is the right place for posting a bug in ffdshow. I have tried every recent ffdshow build, even the "silent" builds from July and August of this year. The latest build that works correctly is the build from 24-04-2003. The 23-05-2003 build has the bug already.

I am running a dual screen configuration on a Radeon 9000 with Catalyst 3.6 drivers and Zoom player 3.1/3.2 beta. (overlay mixer renderer, no ffdshow processing settings activated)

With the 24.04.2003 build, playback of Divx/Xvid files in Zoom player works fine on both screens.

With the 23.05.2003 build and all silent builds since, the same files will freeze Zoom player right after start on my second screen. It still works fine on the first screen but this does not help me.

I am sorry if this is old news already and I hope newer ffdshow builds will correct this bug.

Thanks,
Alex

Danzel

29th August 2003, 06:26

What Windows are you using?
Because it seems that Windows 9x (95/98/ME) doesnt work with the more recent releases (I know my windows ME crashes).

Danzel.

HarryM

29th August 2003, 06:49

Originally posted by midiboy
Hi !

I hope this is the right place for posting a bug in ffdshow. I have tried every recent ffdshow build, even the "silent" builds from July and August of this year. The latest build that works correctly is the build from 24-04-2003. The 23-05-2003 build has the bug already.

I am running a dual screen configuration on a Radeon 9000 with Catalyst 3.6 drivers and Zoom player 3.1/3.2 beta. (overlay mixer renderer, no ffdshow processing settings activated)

With the 24.04.2003 build, playback of Divx/Xvid files in Zoom player works fine on both screens.

With the 23.05.2003 build and all silent builds since, the same files will freeze Zoom player right after start on my second screen. It still works fine on the first screen but this does not help me.

I am sorry if this is old news already and I hope newer ffdshow builds will correct this bug.

Thanks,
Alex

You must open media file WITHIN ZoomPlayer (I have disable automatic playing after open too, you don't use DCP-SP filter too!).

Click on media file, e.g. in Windows Explorer, causes freeze ZP during opening(?).

Most latest ffdshow builds is generally very problematic on Win9x. I don't know what for... :( But on WinXP no problem. Do anyone testing on Win9x?

Build 24042003 is stable for Win98SE, of course.

midiboy

29th August 2003, 09:08

What Windows are you using?

Hi Harry, Danzel,

I am using Windows XP of course, SR1 and all 60 patches installed that came out after SR1.

Ah ... yes, I double click on the media files in explorer, thereby starting Zoom player. I always work that way. Works fine with the earlier April build.

Thanks,
Alex

Soulhunter

26th September 2003, 20:48

Hmm...:(

Some news ???

Bye

oddball

26th September 2003, 23:33

Project seems a bit dead yup :)

easyfab

27th September 2003, 09:00

Originally posted by oddball
Project seems a bit dead yup :)

Go see the CVS on sourceforge and you'll see that milan work hard on it. The sources files changes very often(last changes 19 hours).
Perhaps the news functions are not stable enough for a public release.

athos

27th September 2003, 11:24

i checked the cvs yesterday, and it seems it does not compile currently, due to some work that milan is doing, so ill wait for that to be finished before i compile again.

Edit: new build is up @ http://athos.leffe.dnsalias.com/
Please note: this is an unofficial build, milan has not authorized it.

S_O

27th September 2003, 14:19

I tested the newest build and all the new codecs in there, with this results:
Sorenson Video 3, Cinepak, MS Video 1 and Real Video 1 are working perfectly.

With Sorenson Video 1/2 (SVQ1, Sorenson 2 is Sorenson 1 compatible and uses the same FourCC), Indeo 3.2 and sometimes MJPEG the colors are wrong (blue and yellow seem to be exchanged).

Vp3 and WMV 8 doesn´t work correctly, they´re artifacted (vp3 only sometimes, WMV 8 all the time).

I could test Asus Video 1/2, ATI VCR1 (have only VCR2 files), MS RLE and CYUV.

Soulhunter

27th September 2003, 20:08

THX athos !!! :D

CruNcher

27th September 2003, 22:20

thx athos finaly OSD bitrate display :D

Animaniac

28th September 2003, 01:03

Matroska AR handling via "Use Overlay Mixer" seems broken. With overlay on, the filter doesn't load, with overlay off, wrong AR. There seems to be a half-checked mode on the check box too, but that produces the wrong AR as well...

Calculon

28th September 2003, 01:04

Originally posted by Animaniac
Matroska AR handling via "Use Overlay Mixer" seems broken. With overlay on, the filter doesn't load, with overlay off, wrong AR. There seems to be a half-checked mode on the check box too, but that produces the wrong AR as well...

Same problem here.

Gaia

28th September 2003, 10:44

Yes latest unoffical build doesn't work if you enable overlay mixer.

Not with avi's, matroska files or ogm files.

LigH

28th September 2003, 19:59

Because downloads from dnsalias.com servers are so horribly slow and unreliable, I set up a mirror on my own server, as reported in this German thread (http://forum.gleitz.de/thread.php?threadid=4229) in the joint doom9.de/Gleitz forum (the newest versions won't be up until the end of the Indianapolis F1GP, because the downloads - just 2 MB! - will take half an hour for me as ISDN surfer...).

Please note: The German doom9/Gleitz forum may soon be transferred to a new board software, so I cannot guarantee that this link above will stay - please notify me in this case, I will then update the link.

bond

28th September 2003, 20:01

is there any special realmedia support available?

visigotik

28th September 2003, 21:47

Can anyone tell me what is the lastest safe version of ffdshow for windows 9x?

Gaia

28th September 2003, 22:39

Originally posted by visigotik
Can anyone tell me what is the lastest safe version of ffdshow for windows 9x?

Safe version? Your computer is not going to blow up no matter what build you use :) I am Win98se user and no problems with latest unoffical build so far except enabling overlay mixer doesn't work but it doesn't seem to be OS related problem...

ferrous66

29th September 2003, 17:25

Now that the latest unofficial build includes the Sorenson 3 codec, can you playback .mov files with ffdshow + 3ivx .mov splitter?

Stux

30th September 2003, 07:07

It works with our latest builds, not sure what happens with 4.0.4

There is no QDesign audio codec for DShow though. You're in luck if the audio track is AAC

Actually, I think its faster and higher quality that the real SV3 codec ;)

CruNcher

30th September 2003, 08:07

@Stux

are those problems solved in the next release ?
http://cruncher.mufflastig.com/XviD/test/interoperabilitytest.txt

Stux

30th September 2003, 08:15

Possibly

We believe the qpel decoding is quite robust now. GMC has been greatly improved and should be MPEG-4 compliant now. There still might be an edge flicker problem with b-frames from XviD (we haven't diagnosed this problem yet)

arno

30th September 2003, 12:44

I just tried the latest ffdshow build from Athos (Sep. 2003) and it seems that the most important thing that is still broken is that Mplayer postprocessing doesn't seem to work. Can anybody confirm this, or does anybody know workaround (except for using Nic's postprocessing)?

Soulhunter

30th September 2003, 16:55

Ohw, "ConvettoRGB32()" seem to crash again...

It shows a C++ error ! :confused:

But no matter, wanna make a new feature request...

Could it be possible to allow filters more than one time ?

Because the filter order has influence on the picture look,
and sometimes it would be helpfully to use the same filter twice...

[ PS: Remember the last request ? ;) - No one posted back ! :( ]

Bye

Die*wrek*show

30th September 2003, 18:10

Originally posted by visigotik
Can anyone tell me what is the lastest safe version of ffdshow for windows 9x?

Just use 4-24 for the time being if you are concerned about everything working perfectly.

LigH

2nd October 2003, 19:55

Update: My mirror of ffdshow, ffvfw and some XviD builds (up from 2003); now dynamically created via PHP:

http://www.ligh.de/software/mirrors.phtml

Gaia

4th October 2003, 17:15

@Athos

It might be not so good idea to make unoffical builds. Check out this site http://dvd.box.sk/

Highlights: Great new version of ffdshow. It's your unoffical build 20030927 with broken overlay mixer.

athos

4th October 2003, 17:53

Originally posted by Gaia
@Athos

It might be not so good idea to make unoffical builds. Check out this site http://dvd.box.sk/

Highlights: Great new version of ffdshow. It's your unoffical build 20030927 with broken overlay mixer.

Oh.. well the code is there on the SF CVS, so really anyone could just compile it at any time and put it up.

Edit: I mailed Milan to get his opinion.

Soulhunter

4th October 2003, 19:04

@athos
Oh.. well the code is there on the SF CVS, so really anyone could just compile it at any time and put it up.
Don't get me wrong here...

But do you really think that anyone is able to compile it self ? :confused:

Not all PPL are expert's in this stuff... (Me too... :D)

So please be compliant... :(

I allready spend 90% of free time in front of my PC... !!! :eek:

Learn how to do THIS also, would push this even more up... ! ;)

Bye

athos

4th October 2003, 20:52

well its not that difficult, when you have all the stuff installed, SDK's, cygwin, etc, you just need to know what to compile with cygwin and what to compile with Visual C++ and then it pretty much goes by itself.

Soulhunter

4th October 2003, 21:44

Yap ! Same stuff Ive heard about video compression 1year ago...

Its not that difficult, when you have all the stuff installed, DivX, VDub, etc, you just need to know how to use them (read some guides) then it pretty much goes by itself.

And now, hundred's hours later of Try&See method...

Ive to say "Yeah sure it does !" :p

Its just the thing that I wanna always do more stuff than Ive time for... :D

So this would be one more thing... ;)

Has anyone here also a "next to do" list ??? :D :D :D

Bye

wannabe

5th October 2003, 20:57

Hi

I read trough this thread. Im testing Koepi's XviD-24062003-1.exe's Quarterpel, with ffdshow-20030523.exe and ffdshow ffdshow- 20030927.exe.exe with IDCT: simple, normal, reference, xvid and Skal'IDCT. They are All bad, they all have the bad Qpel over-smearing effect. Yes even the xvid idct has it.

If i playback a 14052003 encoded clip with ffdshow (with simple iDCT) its Qpel is flawless.

The ony playback codec that could properly decode 24062003's Qpel is 24062003...

I would like to know if there is any chance in later developments that this problem ll be solved, so i can playback 24062003 with FDDSHOW ? Or i say better: Is there any chance that i could playback 24062003 and 14052003 with the Same FFDSHOW, with the same settings ?

Its pretty challanging to guess from a clip i got from the net, that if its encoded with 24062003 or 14052003 or some other build, in order to find the proper playback codec, or to find the proper iDCT. Within a few years nobody ll remember if one clip was encoded with this or that iDCT. So we would like to watch these old encodes, it would be really good if there would be some decoder filter that could playback ALL Qarterpel in the future, automatically deciding which iDCT to use.

Greetings

BoNz1

5th October 2003, 21:18

I think this isn't really a problem so much with quarterpixel. It seems at least in the dev-api-4 branch that this was a problem too. I thought it was an iDCT problem too but it turns out that there was a problem with the way the frames were being padded and when qpel was activated it seemed to amplify this smearing and noise than halfpel even though this was still ocurring with halfpel. When they fixed this, this went away at least for me. However, the ffmpeg guys are aware of this so libavcodec should have a workaround for it. Make sure you have the latest ffdshow and under miscellaneous select iDCT XviD and under workaround encoder bugs select autoselect. It should identify these movies encoded with the wrong frame padding and display it correctly and then no more smearing. I have checked this on some of my movies encoded with a build at a similar date to the one you are using and indeed this is the case.

wannabe

5th October 2003, 22:51

BoNz1:

IDCT: simple, normal, reference, xvid and Skal'IDCT. They are All bad, they all have the bad Qpel over-smearing effect. Yes even the xvid idct has it.

as i said i have the smearing problem with xvid idct too. its still better if i playback it with the 24062003 not FFDSHOW.

ffdshow-20030523.exe and ffdshow ffdshow- 20030927.exe.exe

And yes i use the latest ffdshows and i get this result.
Plz try to read carefully what i written next time.

So ppl someone, any ideas ?

BoNz1

5th October 2003, 23:11

I _DID_ read carefully you didn't. Check autoselect for Workaround Encoder Bugs, and use XviD IDCT and it should be fine.

wannabe

5th October 2003, 23:34

BoNz1:

I _DID_ read carefully you didn't. Check autoselect for Workaround Encoder Bugs, and use XviD IDCT and it should be fine.

Then u dont belive me then, i already told u that i use "XviD IDCT" and its NOT good. i also tried out autoselect, and everything else but it still NOT good. Altough its better than Simple or other iDCT's but its still not as good as if i would decode it with "24062003". Belive me, im not blind ;)

i also reported this thing at "XviD > XviD-19062003-1"

wannabe

5th October 2003, 23:44

i can prove it, i have a small 400KB clip, where u could see it, that it doesnt work with "xvid idct" or anything else in ffdsow with 20030927, and u could also try 24062003 to see its really better with its native codec.

but if you dont trust my files:) u can make a test yourself, on a very dark segment(its more visible on dark areas). Use the latest ffdshow and 24062003 for playback.

So it seems that the Walken iDCT that 24062003 uses is not compatible with ffdshow's xvid idct to me... Any ideas ?

BoNz1

6th October 2003, 02:30

Ok. I do believe you and believe me I have run across this problem a lot myself just do a search and you will see how many times I have bugged the XviD developers to fix this, ;). And they did fix it, in dev-api-4 quarterpixel works very nicely. But I stress that the problem is not quarterpixel it was bad frame padding. It was only being amplified by the use of quarterpixel. It would be really nice if someone could make a new XviD build and backport two things to dev-api-3 1) the bug in sad32v that was fixed on August 22 and 2) the bug in image.c that caused the wrong frame padding. The developers don't want public builds of dev-api-4 so I think it would be nice if someone could do this.

very dark segment(its more visible on dark areas). Use the latest ffdshow and 24062003 for playback.

Hmm, XviD and all other mpeg4 codec have always had this problem in dark areas with or without quarterpixel although you are right with quarterpixel it is definitely worse. I think Syskin had some ideas for fixing this bad behavior in dark scenes but I think he said we have to wait till after 1.0 :).

athos

6th October 2003, 11:56

milan gave his ok to me compiling builds, but he still wants to wait with putting new builds on sf.net.

wannabe

6th October 2003, 15:59

http://www.geocities.com/berreg21/24062003_with_Simple.JPG
http://www.geocities.com/berreg21/24062003_with_XviD.JPG
http://www.geocities.com/berreg21/24062003_with_24062003.JPG

I made some Still image captures about the problem, and it seems that its not fixed. And i cant repeat enough times, i used the latest FFDSHOW with "XviD iDCT" and its still not as good as with 24062003 with 24062003.

And look im not totally lamer, i know that MPEG4 is not too good in dark areas by default, but its a different problem.

PS: Pls see for yourself, but dont open the pages too many times because geocities transfer is limited for every hour, and i couldnt attach the pictures to the message because its not allowed anymore.

If the .jpgs wouldnt load first, hit CTRL+F5 a few times, geocities is slow...

Soulhunter

6th October 2003, 16:15

Nice to hear athos... !!! :D

PS: Have again some Idears...

1.) For my favorite ffdshow option "NOISE" !

Would be cool do adjust the noise's sharpnes...

-100 SoftNoise<------>NormalNoise<------>SharpNoise +100

Soften interpolates the noise and decreases the difference to the picture, and sharpen increases the difference...

Difference = NoiseResult - Original (Or so... :D)

2.) A luma/chroma separated unfilter option...

3.) A Inbuilt output-mode with corrected chroma upsampling... (as AviSynths ConvettoRGB32() !)

Bye

BoNz1

6th October 2003, 16:33

@ wannabe, I think I already explained why this problem is occuring and I do not think it is iDCT related at least not totally. And if there is a iDCT bug it is a bug in your XviD build and _not_ ffdshow. Like I said it is more likely a problem with frame padding and the ffmpeg guys are aware of it and there is a fix for decoding it but maybe it is not in the latest ffdshow build. If you want a build which will give nice quality using quarterpixel, do a checkout on the dev-api-4 cvs and build it. This will look much better when decoded with XviD in ffdshow. And I don't think you are a lamer believe me I thought this was iDCT related for a long time too, ;).

wannabe

6th October 2003, 19:09

if its not iDCT related then why does it look better with different iDCT's ?

Maybe you are right, but the artifacting that can be perceptible on the samples look exactly the same if i would playback a Koepi-14052003 encoded clip(that uses simple iDCT) with 24062003(that uses Walken iDCT) and that problem can be solved if i change iDCT in FFDSHOW...

BoNz1

6th October 2003, 19:58

Ok, it will look better with different iDCTs anyway. To verify this encode a small clip with divx5 (which uses walken) then play it back with simple and XviD iDCTs in ffdshow and you will see that XviD looks better. So, it is no wonder why XviD does look better it is just that none of them look that good that there is a problem, ;).

wannabe

6th October 2003, 20:13

Wonderful wonderful :) i understand everything now, but still i cant playback properly 24062003 with any other playback filter no matter what settings i use, so i guess if everybody knows, and understand everything someone should do something about it finally right ?

Tommy Carrot

6th October 2003, 22:32

Originally posted by BoNz1
@ wannabe, I think I already explained why this problem is occuring and I do not think it is iDCT related at least not totally. And if there is a iDCT bug it is a bug in your XviD build and _not_ ffdshow. Like I said it is more likely a problem with frame padding and the ffmpeg guys are aware of it and there is a fix for decoding it but maybe it is not in the latest ffdshow build. If you want a build which will give nice quality using quarterpixel, do a checkout on the dev-api-4 cvs and build it. This will look much better when decoded with XviD in ffdshow. And I don't think you are a lamer believe me I thought this was iDCT related for a long time too, ;).

It's not just iDCT, but fDCT related too, so it appears in the encoding first. The decoding just makes it worse, if the decoder uses different DCT algorithm for it.

AFAIK, the base of the artifact is, the DCT algorithm is floating pointed by nature, but the codecs uses integer implementation from it, because it's much faster. But this makes rounding errors, which are usually quite unvisible, but qpel amplifies them. I think it can be improved, but never totally fixed, because this is the nature of the DCT based codecs.

wannabe

7th October 2003, 16:10

Wow i understand everything even more thank you. But you all have to admit, that "24062003_with_24062003.JPG" looks the best, it looks how it should look properly playbacked, so its possible to achive a good quality playback like that... it can be done, its just the current FFDSHOW is not able to do it, because of whatever reason that i accept, BUT it would be possible, so someone please, correct it.

egyebkent meg en is szemelyesen :)

faxmactor

8th October 2003, 13:27

Originally posted by wannabe
egyebkent meg en is szemelyesen :)

Seems to me that there are quite a few separate small problems here, that come together and creates a real one.
I hope some of them will be solved if dev-4-api based XviD reaches a stable state. Or not :rolleyes:

I personally don't use Qpel, because of the possible future build incompatibilities (you can never be sure that the next one will be able to decode it properly)

Wow, lots of szemelyesens here. Tenyleg. :D

Tommy Carrot

8th October 2003, 14:02

Originally posted by wannabe
Wow i understand everything even more thank you. But you all have to admit, that "24062003_with_24062003.JPG" looks the best, it looks how it should look properly playbacked, so its possible to achive a good quality playback like that... it can be done, its just the current FFDSHOW is not able to do it, because of whatever reason that i accept, BUT it would be possible, so someone please, correct it.

Yes, i guess the native decoder is better (although i couldn't open the linked pictures), and there is no reason why ffdshow couldn't reach the same quality. But even the properly decoded qpel image will have additional noise compared to the hpel encoding (just not so annoying), and this is inevitable afaik.

egyebkent meg en is szemelyesen :)

Wow, lots of szemelyesens here. Tenyleg. :D
:D

wannabe

8th October 2003, 20:43

although i couldn't open the linked pictures

Geocities deleted them :( if a moderator or the proper person would allow me i would attach them to one of my messages for your pleasure.
I made one last mirror for the files, if some of you know a better place you could mirror after it goes down thnx. Dont click directly on the links, or "open in new window" because it wont work that way... use "Copy Shortcut", then open a new page in your netbrowser(ctrl+n), then paste in the link and it ll work.

http://www.geocities.com/buzikurva/24062003_with_Simple.JPG
http://www.geocities.com/buzikurva/24062003_with_XviD.JPG
http://www.geocities.com/buzikurva/24062003_with_24062003.JPG

Tommy: yeah there is no reason, but in fact ffdshows current playback features perform worse than the native codec, as u can see from above, so the developers should do something.

personally don't use Qpel, because of the possible future build incompatibilities

Well yeah, the problem is that the incompatibilitie comes from the different iDCT not Qpel, Qpel just amplifies them but if you have good eyes, you can spot the same artifacting without Qpel, just not that strong. So i guess there is no point in not using Qpel, the future decoders should support ALL previous builds.(Look for very dark scenes with keyframe changes in old build's and u ll see what i mean

Mug Funky

10th October 2003, 17:15

hey all.

i'm having some trouble with ffdshow decoding DV footage.

with type-1 files, it hangs after the first frame.

after deleting the ffdshow audio filter in graphedit, it plays back normally. just a heads-up, that's all :)

Enigmax

11th October 2003, 07:58

The videos reproduce without fluidity in my system with the last versions of FFDSHow :confused: .
Some idea?

Greetings

Soulhunter

11th October 2003, 23:18

So... What system ??? :D

PS: Info about your system specs would be good ! ;)

Bye

LigH

12th October 2003, 20:53

ffdshow beta 2003-09-27 introduced a color rounding bug: A playback of a DivX 5.0x encoded AVI showed an increasing color shift towards orange and blue at edges of areas; they are reset on each keyframe. ffdshow 2003-08-16 decodes fine instead. It does not depend on the selection of the iDCT.

Some small examples:
http://www.ligh.de/images/orangeblue1.png
http://www.ligh.de/images/orangeblue2.png

Sorry for the small size, the rest of the image is not suitable for a bublic board... :o

Enigmax

12th October 2003, 21:08

I have problems with ffdshow in a Atlhon 1800+ with 512 MB ram and graphical card GeForce4.
The reproduction of the video takes place by jumps :mad: .
With the version 23-05-2003 no problem.

Greetings

Alxemi

13th October 2003, 00:00

Wannabe... your jpgs are offline again... And I really want to take a look! :) send me the files and i will host them with no restrictions

oddball

13th October 2003, 06:36

I also have jerky video playback with recent builds of ffdshow and yes I am using a GeForce 4 too!

wannabe

13th October 2003, 19:16

Alxemi: okey, give me an email and i ll send u, they are small like 80K.

Alxemi

14th October 2003, 01:44

Once upon a time my email was here and now that it is not, i only want to use this space to give a huge THANK YOU to all the ffdshow developers!! Life is easier thanks to your work!

LigH

14th October 2003, 05:57

@ Alxemi:

You better should have sent your mail address via "personal message" to wannabe - now you will have to expect thousands of fan mails... :p (Not afraid of spam?) - Better edit your message?!

My mirrors:

- XviD (http://www.ligh.de/images/24062003_with_XviD.jpg)
- Simple (http://www.ligh.de/images/24062003_with_Simple.jpg)
- 24062003 (http://www.ligh.de/images/24062003_with_24062003.jpg)

Alxemi

14th October 2003, 11:43

Ligh: You are right about the spam, but i´m not worried about it, because of the REMOVETHIS a robot cannot use the address, it must be somebody that write it down.. The funny thing is that i think i sent the private message but it was late at night here... and you kinow, sometimes you don´t remember the things you have done just two minutes before xD, anyway thanks for the advise; i will remove the address just in case :D
With your mirror is not necessary another one but now that the work is done...
http://www.alxemi.cjb.net//d9samples
(the double slash is ok)

Regards

LigH

15th October 2003, 11:53

I wonder if anyone can confirm the "orange-blue" colorisation bug; it may only occur on some special material, I could not yet create a DivX file that showed the same effect, but could not yet try all encoder options.

For some strange reason I think that there is a tool which can tell details about encoded DivX-5 AVIs (which codec options were set upon encoding); am I right here?!

Soulhunter

20th October 2003, 18:00

Yet another feature request...

Could something like this (http://forum.doom9.org/showthread.php?s=&threadid=63361) be added to ffdshow ???

I mean the Unsmooth(AddGrain x,x,x,) method ! ;)

Maybe, regular Unsmooth() with different options too... !?!

Would love it, to see this thing in ffdshows filter-tab ! :D

Bye

LigH

23rd October 2003, 06:37

Still no interest in resolving the orange-blue bug? Is this the wrong place to post bugs, shall I contact someone else somewhere else?!

Okay, for your pleasure, one more image - this time a bit larger, but still only a cropped part (due to the explicit content of the rest):

http://www.ligh.de/private/nikita.jpg

And finally, I cut out some non-hardcore parts of the mentioned movies for download; but to protect my bandwidth, please contact me if you want to download them (1.5, 2, 3.5 MB). And remember: The effect is only visible using ffdshow Beta 2003-09-27.

BTW: I was absolutely unable to recreate this effect - I tried all combinations of options I could think of, but DivX 5.0.5 for the PC did not create one file causing the same effect. I'll have to contact the creator of these movies and beg for supporting us by telling us the details.

esby

23rd October 2003, 12:34

A dummy question...
Can ffdshow intecepts keys in its state of directshow filter?
-->
Toggling OSD display...no matter the player you are using
etc.
And allowing custom key code supposing no application is already intercepting them...

On another note, the osd could be customizable
like a sprintf sequence ( ...,"now displaying frame n°%i" ,nbframe)...

esby

Soulhunter

23rd October 2003, 19:29

@LigH

Sorry, but have never seen something like this before... :confused:

Are you sure that this is not a source related thing ??? :(

Bye

LigH

23rd October 2003, 20:28

Well, what do you mean by "source related"?

- Only those movies from that creator show such an effect, I could not yet find any other movie with the same problem (but I'll search for more).

- Only ffdshow 2003-09-29 Beta shows such an effect, older ffdshow filters or the original DivX 5 filter does not.

You see, it's only this combination; but all the movies from this creator (which I collected over months now) show the same bug, more or less obviously depending on the content, but safely reproducable.

athos

23rd October 2003, 20:31

Did you try different DCT?

LigH

23rd October 2003, 20:55

Didn't I write that?

It does not depend on the selection of the iDCT.

I just wrote an email to the creators. And I have a few URLs for downloading video snippets for you. I'll send you a PM so you can download them and check. Also I saved the ffdshow configuration to an ".ffpreset" file.
__

P.S.: About my system:

- AMD Duron 800
- ABIT KT7-RAID
- ELSA Gladiac GeForce2 GTS, 32 MB
- ELSA DetonatorX (6.13.10.4109)
- DirectX 9.0b (4.09.0000.0902)
- Desktop: 32bit TrueColor

Tommy Carrot

23rd October 2003, 21:04

It can be GMC related bug too. It's rarely used, maybe the implementation in divx5 is not totally compatible with the standard.

LigH

23rd October 2003, 21:08

But I created movies with all the 8 combinations of Pro features, and neither of them created a movie which showed the same effect.

Well - it could indeed be possible that this movie was not created using the DivX codec, but instead got the DX50 FourCC. Maybe it's XviD with 3 warp points, but ffdshow believes it is DivX 5 and only expects 1 warp point?!
__

Well, at least this is probably not true:

- The original AVI has the FourCCs "DX50/DIVX". (DShow/VfW)
- If you select "DX50" inside the XviD codec, it would have "DX50/xvid".

Furthermore, I just tried to recompress with XviD (latest Koepi build) with GMC and "DX50/xvid" FourCCs: ffdshow played fine.

I even changed the FourCCs to "DX50/DIVX": Same result, no problem.

Danzel

23rd October 2003, 23:24

If you recompressed it with XviD then that would of 'fixed' the problem, as your original stream would of been decoded with vfw and then re-encoded with xvid. So it wouldnt be the same stream anymore.

Have you tryed to change the FourCC of the Original Files to have XVID FourCC ? (without recompressing, just changing the FourCC).
And Then playing them then with FFDShow?

It could be its expecting different GMC, although I thought that information would be stored in the stream anyway.

Perhaps they are encoded with a buggy DivX 5?

Danzel.

CruNcher

23rd October 2003, 23:29

you could get the mpeg4 bitstream id to see wich encoder was used so you would have a clearer picture of the situation instead of trying to guess what was used by looking @ the riff header (fourcc) use http://www.geocities.com/filesDRF/DivXDRFAnalyzerV0951.zip for example
for me it looks like a problem @ the encoder level even if not much can be seen of the problem :rolleyes:

LigH

24th October 2003, 05:48

@ CruNcher:

Thank you very much - that's a kind of tool I missed a lot, I hope to see something clearer now!

(Unfortunately, the GeoCities link is off, but I found a few via Google: Lots of FTP links...)

{ EDIT: The GeoCities address is working, but you have to visit the homepage first, else download is blocked (anti-leeching). }

DivX DRF Analyzer v0.9.5 Report!
File Name: N:\Movies\ALS\nikita001.avi
FourCC: DX50
Codec: DivX501b484p
Resolution: [ Width: 320 Height: 240 ]
Frame Rate: 29.970 frames per second
The Video has 2997 frames [ 00:01:40 ]

Average Frame quality is HIGH [Average DRF/quantizer is 2.99]
Standard Deviation: Quality is MEDIUM [Std. Deviation is 1.01]
Image Resolution is LOW

The file has Packeted Frames!

There are SOME frame drops ( NO drops is better )

Recomended Resolution: [304x224] (Target DRF/quantizer=2.8)
The filesize should be larger!

Performance Caracteristics:
Macroblocks per frame: 300
The Width is multiple of 32

Kilobits per Second: 642.38
Kilobits per Frame: 21.43
Kilobits per Macroblock: 0.071
Bits per Pixel: 0.29

Frame Type Statistics :
I Frames: 0.80%
P Frames: 20.05%
B Frames: 49.15%
S Frames: 29.96%
N Frames: 0.00%
(More Advanced Codecs use B and S frames)
Frame Quality Statistics :

DRF=1&2: 1496 50.3%
DRF=3: 1 0.0%
DRF=4: 1472 49.5%
DRF=5: 0 0.0%
DRF=6: 1 0.0%
DRF=7: 0 0.0%
DRF=8: 2 0.1%
DRF=9: 0 0.0%
DRF>9: 0 0.0%
KeyF/DeltaF: 0.81%
KeyDRF<4: 23
KeyDRF=4: 1
KeyDRF>4: 0

AverageKeyDRF: 2.08
MAXDRF: 8
AverageDRF: 2.99
Deviation: 1.01

http://www.geocities.com/analyzerDRF/

Obviously, this must be a bug from a rather old DivX codec version. Are there any "rather complete" changelogs of DivX codecs available?

{ EDIT: http://www.divx.com/divx/divx_win_versions.php }

BoNz1

24th October 2003, 07:32

Anyone played around with the sorenson3 decoder? It works really nicely, I got the new high def Matrix Revolutions trailer to play in graphedit w/ 3ivx parser, CoreAAC, and ffdshow. Sweeet! The audio goes out of sync but I think thats the 3ivx parser. Anyway, the video looks awesome.

LigH

24th October 2003, 13:39

Obviously, several rounding bugs were solved towards DivX version 5.0.3 - maybe it was one of those. I could try to install DivX 5.0.1 over the weekend and check if it produces such "provoking" movies.

Until now, no answer from the creators, but as we could find out the version number using that analyser, we probably won't need their support anymore...

CruNcher

24th October 2003, 14:27

@LigH

hehe who were the creators i would guess KRC amateurs ;)
ups a nevermind even 320x240 is under KRCs niveou and i was kind not
to talk about those droped frames :P

LigH

24th October 2003, 22:14

:confused: What is "KRC"? Probably no popular abbrevation in Germany?

These are no cinematic movies - everything is original content, taken by hand cameras; so I can guess the reason of drop-frames. BTW: It is adult content...

CruNcher

24th October 2003, 22:56

BTW: It is adult content...

i never would come on that idea myself from you previous behavior:rolleyes: *looks arround* so this is privately recorded no professional stuff ? eh i think we better cut off that discussion now or doom9 will hang us :D *cough* nevertheless you could pm me the address where i can get this sample to take a look @ it eh the problem ofcourse even if it's solved ;)

Lobuz

27th October 2003, 02:16

@Athos
Any chances for new compile of ffdshow?

Regards
Lobuz

LigH

27th October 2003, 07:07

@ Lobuz:

Please remind that before a new ffdshow can appear, Milan Cutka or the ffmpeg developers must have been active; and after discovering several quite important problems, it may take a little longer to investigate and solve them.
__

@ Athos & others involved:

Did someone contact the useful addresses about our latest results, or shall I do that (then I'd like to be told where)?

athos

28th October 2003, 18:32

New builds are up:

ffdshow-20031028 (http://athos.leffe.dnsalias.com/ffdshow-20031028.exe) changelog (http://athos.leffe.dnsalias.com/ffdshow-changelog.txt)

ffvfw-20031028 (http://athos.leffe.dnsalias.com/ffvfw-20031028.exe) changelog (http://athos.leffe.dnsalias.com/ffvfw-changelog.txt)

NOTES:
I had to reinstall everything due to a crash, and believe me there are lots of SDK's and stuff to install and configure for this! Problem is: I could not compile libavcodec or mpeg2enc using gcc/nasm, and so I had to compile them using Intel C++ Compiler 7.1 with every imaginable optimization flag ;) This means they lack assembler optimizations, put perhaps the ICL can somewhat make up for this. On my system (P4-3.0Ghz) it doesnt seem to make too much difference on a quick check, but I suspect it will on slower systems.

Anyways: enjoy!

Gaia

28th October 2003, 18:47

Thanks :) Now you can enable overlay mixer.

Edit: You can't enable it. It still doesn't load if you enable it...

winman

28th October 2003, 22:46

@athos

Thank you very much for the new build.

I can confirm a substantial performance hit with the new build of ffvfw (atleast on my overclocked 2.2Ghz Athlon XP system).

Here is the result of a quick test of a 640x480 video.

MPEG4 One-pass CBR 10000Kbps with all extra option like ME off

62-99 fps 20030927
23-44 fps 20031028

With Full ME,Trellis and extras...

10-15 fps 20030927
1-2 fps 20031028

My favorite feature of the recent ffvfw, the speedy ffmpeg MPEG2 encoder, also take a similar perfomance hit. I hope you can get gcc/nasm working again because I really love the 2X-3X real-time MPEG2 encoding :)

athos

29th October 2003, 00:32

i will try to get it to compile using gcc/nasm, it is most likely something i misconfigured or so. my test was decoding using ffdshow, which doesnt take more than a few % cpu anyway.

Mr.Shine

29th October 2003, 04:49

Originally posted by Gaia
Thanks :) Now you can enable overlay mixer.

Edit: You can't enable it. It still doesn't load if you enable it...

Yes, there is a problem with overlay in ffdshow, since the first build where the "Use overlay mixer" checkbox started to have 3 states: checked, unchecked and grayed. In checked state, WMP will fail to render the file, the other 2 settings (unchecked and grayed) will disable overlay in WMP (I tried 6.4 only).

There are "cheats" to get it to use overlay, though. Uncheck "Use overlay mixer" in ffdshow and do one of the following: add a filter that installs itself after ffdshow in the directshow chain and allows for enabling overlay (e.g. DivXG400 in Extended Overlay mode - disadvantage is that DivXG400 only supports YUY2, so there will be an unnecessary color space conversion). This should work with any player, including WMP.
use BSPlayer and enable overlay there.
use MPC or ZoomPlayer and specifically tell it to use the Overlay Mixer instead of "System Default".I don't know what happens if you try to use VMR or VMR9, as my display drivers don't support VMR.

Blight

29th October 2003, 06:11

Athos:
It this another interm release or some sort of semi-authorized release?

I for one would like to see a feature freeze and see some bug squashing take place and a non-alpha/beta release out the door.

Right now FFDShow is in a state where some builds have some features working, while other builds have other features working and I can't even guess as to which version to recommend to users.

LigH

29th October 2003, 06:45

The Orange-Blue bug was not yet fixed; I think I should try to send a mail directly to Milan.

Gaia

29th October 2003, 10:08

Originally posted by LigH
The Orange-Blue bug was not yet fixed; I think I should try to send a mail directly to Milan.

Are you sure it's ffdshow bug? Not some problem in your amateur xxx movies? Because you're only person having it :)

Danzel

29th October 2003, 21:54

If you found which version of Divx was used to encode those clips then it would make testing a bit easier (and allow for g rated tests ;))

From the info that program gives you should be able to work out which version it was encoded with, perhaps we could even ask the DivX peeps if they know of any errors that they may of found that could of caused this problem (If its encoder related).

Danzel.

athos

29th October 2003, 23:08

Originally posted by Blight
Athos:
It this another interm release or some sort of semi-authorized release?

I for one would like to see a feature freeze and see some bug squashing take place and a non-alpha/beta release out the door.

Right now FFDShow is in a state where some builds have some features working, while other builds have other features working and I can't even guess as to which version to recommend to users.

Well I guess you would call it interm release. I asked milan, and he does not want me to put up these build on sf, but he does not have anything against me releasing them "privately". So they are in no way official, even as "alpha". Milan is in the middle of integrating ffvfw with ffdshow, and he also wants to get the colorspace conversion working the way. When this is done, I think he aims to put out a new release on SF, ie "official".

oddball

30th October 2003, 00:13

I am going to wait for official since Athos (No offence) your builds have jerky video.

oddball

30th October 2003, 00:24

One other thing. Someone mentioned something about G400 and colorspace. Would using DiVXG400 acount for the 'greening' problem when playing back XviD with libav? If I change it from libav to XviD the greenout problem goes away.

LigH

30th October 2003, 07:35

:confused:

@ Gaia:

The only one? athos downloaded my samples and could confirm it. If you want to check it too, write me a PM to confirm that you really want to watch such content... ;)

As I already told a few times: This bug only appears in this combination:

- ffdshow 20030927 or 20031028 (any other filter able to decode DX50 I have is not affected)
- movies from this source (maybe also others, but I could not yet find any more)
__

@ Danzel:

Would you be so kind as to look at the top of page 19 of this thread?

DivX DRF Analyzer v0.9.5 Report!
File Name: N:\Movies\ALS\nikita001.avi
FourCC: DX50
Codec: DivX501b484p
__

@ athos:

Discovering such a remarkable change in the decoding behaviour (even if it only regards very few and special files, but unfortunately so obviously) is worth to provide such "interim releases", in my opinion...

Danzel

30th October 2003, 10:28

@ligh haha, yeah i saw that.
but which version of DivX actually produced it, is that 5.01?

anyone have 5.01 installed / installer and would be able to see if it creates a stream with the same codec string?

Danzel.

wannabe

30th October 2003, 13:27

I downloaded the latest this "ffdshow-20031028.exe". And it still exhibits the -same- XviD iDCT problem mentioned before...

The option in Misc: "autoselect" doesnt work either.

LigH

30th October 2003, 13:35

Unfortunately, until today no reply from the creators. So I can only guess: Most probably DivX 5.01; and I'll have to install it to check if I can create more movies with that effect (currently, I have 5.0.5 installed, and there are no orange-blue problems; between 5.01 and 5.0.3, several rounding-bugs in DivX encoder were fixed).

LigH

1st November 2003, 17:55

Updates:
yablo found another movie, created with DivX 5.0.2, which shows the same effect. Another hint that just these fixed rounding bugs in the DivX encoder could be the reason...
Milan just answered, and he already has a strong suspect. He will soon be able to download my files and check if he thought right. Then the CVS shall become updated.

dillee1

2nd November 2003, 11:17

Originally posted by Blight
Athos:
It this another interm release or some sort of semi-authorized release?

I for one would like to see a feature freeze and see some bug squashing take place and a non-alpha/beta release out the door.

Right now FFDShow is in a state where some builds have some features working, while other builds have other features working and I can't even guess as to which version to recommend to users.

authorize or not doesnt applies to GPLed stuff,
as long as

- GPL is complied
- No law/patent is broken in his country due to distro of the binary.

The whole idea of GPL is everyone can get a hand of the source and tailor it to whatever he likes..... Apart from may be it's a "manner" to notice the original author about this, why would we care about authorisation?

eLupus

2nd November 2003, 13:53

What he meant was that these compiles are not compiled by the developer and have not been put up as a binary release on sourceforge. This is cause the code is going through major changes and Milan doesn't think t is ready for public release. This doesn't hinder anybody from compiling the source from cvs themself, but they should then be aware that it might not even be possible to use.

Regards
Joakim Plate

vlada

6th November 2003, 12:36

Hi, does anybody else have problem with the last 2 unofficial releases of FFDShow? If I install it and playback a movie, the player want use the FFDShow decoder, but any other asociated. If I make the player to use the FFDShow decoder, it crashes. The version from 2003/08/16 works O.K. What could be the problem? Thank You, Vlada
P.S. I have WinXP SP1/ATI 9200/Catalyst 3.7/DirectX 9.0b, I belive a pretty standard computer.

gabest

6th November 2003, 12:54

I just noticed yesterday evening that the latest from athos's site was broken. It set some crazy output resolution and the renderers refused to accept it (fortunatelly).

Kyo

7th November 2003, 03:05

Vlada

Just disable the "Use overlay mixer"

Owen

7th November 2003, 13:35

"Use overlay mixer" is off by default.
Why would anyone turn it on ???

ffdshow 20030927 works great. Ffvfw is comming along very nicely as well. Many thanks to the great Milan.
Thanks also to athos for compiling and hosting the builds.

I look forward to the next official release.

Owen

vlada

7th November 2003, 14:09

Overlay mixer - this will be probably the problem. I checked it, but to be honest I'm not sure what it exactly does. I belived, it uses overlay mixer to view the movie. I'll try to uncheck it and let You know if it was the problem. Tahnx, Vlada

Wilbert

7th November 2003, 16:01

People activate it when playing matroska files with a certain aspect ratio (other than 1:1).

7th November 2003, 23:15

yes, I have same problem.. newest builds seem to crash when trying to play anything...... i have no idea whats the problem..

7th November 2003, 23:17

ok, I found the problem.. if i disabled Nic's post-processing method, it doesn't crash anymore..

7th November 2003, 23:18

overlay mixer doesnt work though..

Soulhunter

7th November 2003, 23:45

@QQ

Ehm... :rolleyes:

Do you know about the function of this funny little "edit" button down there... ???

Bye

7th November 2003, 23:53

yea, i was going to edit my first post, but then i noticed i can't delete my 2nd and 3rd one (read - i thought of it too late).

sorry, im tired..

codecmax

10th November 2003, 19:17

Originally posted by Mr.Shine
Yes, there is a problem with overlay in ffdshow, since the first build where the "Use overlay mixer" checkbox started to have 3 states: checked, unchecked and grayed. In checked state, WMP will fail to render the file, the other 2 settings (unchecked and grayed) will disable overlay in WMP (I tried 6.4 only).

There are "cheats" to get it to use overlay, though. Uncheck "Use overlay mixer" in ffdshow and do one of the following: add a filter that installs itself after ffdshow in the directshow chain and allows for enabling overlay (e.g. DivXG400 in Extended Overlay mode - disadvantage is that DivXG400 only supports YUY2, so there will be an unnecessary color space conversion). This should work with any player, including WMP.
use BSPlayer and enable overlay there.
use MPC or ZoomPlayer and specifically tell it to use the Overlay Mixer instead of "System Default".I don't know what happens if you try to use VMR or VMR9, as my display drivers don't support VMR.

Well I tried using VMR9 with zoomplayer and the latest alpha FFDshow.

When I enabled Overlay mixer, whether fully checked or grayed, the result is the same, the sound would play, but there would be no picture.

Of course, not checking the box solved the problem.

The thing is overlay is very important for video playback, most of the videos I have seen are too dark, and the gamma,brightness and contrast controls are very important.

10th November 2003, 19:43

ffdshow includes other controls for processing picture, but yes, problem should be fixed - together with post-processing problem.

eLupus

10th November 2003, 19:48

You can't use overlay mixer with VMR9. VMR9 includes its own color controls, it does depend on support from the video card though. It doesn't surprise me that ffdshow will behave erraticly with overlay mixer enabled and when using VMR9.

Try using vmr9 in ZP with overlay mixer disabled, and bring up the color controls. If they work, your videocards driver supports color controls, otherwise you can try updating your drivers. For some stupid reason gamma is however not supported in vmr9, everything else should be though.

Regards
Joakim Plate

10th November 2003, 21:29

overlay mixer doesnt work with VMR7 or Old Renderer (as in MPC) either. It worked fine with all of them prior to some specific alpha which I can't recall now.

Owen

12th November 2003, 23:02

Come on people. What is all this fuss about overlay control and VMR9.
If you are using ffdshow, then use "picture properties" to adjust Gamma, Contrast, Brightness, Color etc and leave your overlay or VMR9 adjustments at default.
This works better anyway.
Adjusting overlay controls to fare away from defaults can degrade quality.

Owen

oddball

16th November 2003, 03:12

I have noticed that if I set XviD in ffdshow to decode DiVX5.x content I get an exception and the player crashes (Any player). This is no matter if I use Nic's or Koepi's XviD builds or any version of ffdshow that lets you change the decoder from the libavcodec.

Anyone else experienced this? The reason I prefered to use XviD as the decoder was to avoid the greenout bug. I am sure I have seen that occur on DiVX5 material as well as XviD using libavcodec.

athos

17th November 2003, 17:19

Good news, I think I solved the gcc/nasm problem. It seems it had something to do with Cygwin. Expect a proper release soon (still no official SF alpha though) unless I run into more problems.

Edit: Well libavcodec compiles with MingW's gcc/nasm dist, but not the rest. The two seems to have problems to coexist, and ffmpeg is written for cygwin. I guess I'll have to wait for an update to cygwin or something for this to work.

HarryM

18th November 2003, 19:34

@Milan, @Athos: I have one wish for future versions of ffdshow. Can you add support 'additional black bars' for up, bottom, left, right side separately? Actually only horizontal (left, right together) or vertical bars (up, bottom together) is supported.

I need this for precise vertical centering TV output at ATI Radeon (videos is situated a bit bottom with full TV overscan).

Pasqui

18th November 2003, 20:25

Originally posted by athos
ffmpeg is written for cygwin. I guess I'll have to wait for an update to cygwin or something for this to work.

As stated on FFmpeg website (http://ffmpeg.sourceforge.net/ffmpeg-doc.html#SEC24) , ffmpeg can be compiled with MinGW/Msys. i personnaly did it with success.

Cheers,

Pasqui.

athos

19th November 2003, 00:13

ok its not ffmpeg then, but some parts of ffdshow seems to be written for cygwin.

Blight

22nd November 2003, 04:26

Another issue (not sure with latest version) is that you can't have multiple versions of ffdshow decoding 2 xvid streams from the same media file at the same time.

Owen

28th November 2003, 02:41

I have some things for the ffdshow-ffvfw wish list.

1. RGB color correction (Preferably with Contrast, Brightness, Gamma for each RGB channel)

2. The ability to use the same filter more then once in the filter chain. (Could ffdshow be loaded twice to do this?)

Regards,

Owen

athos

28th November 2003, 20:00

New release: ffdshow-20031128.exe (http://athos.leffe.dnsalias.com/ffdshow-20031128.exe)
Changelog: ffdshow-changelog.txt (http://athos.leffe.dnsalias.com/ffdshow-changelog.txt)

Not much new in the changelog, but I managed to compile libavcodec, mplayer, libmad and libmpeg2 with MinGW/gcc/nasm to take advantage of the assembler stuff.

I could not compile ffvfw. I guess this is because milan is merging ffdshow and ffvfw, so we'll just have to wait until this is finished.

Edit: Updated installer to include ff_libmad.dll

Soulhunter

28th November 2003, 20:19

2. The ability to use the same filter more then once in the filter chain. (Could ffdshow be loaded twice to do this?)

Yeah... Ive already requested this, but with no feedback till now ! :(

PS: THX athos for the new release... ;)

Bye

arno

28th November 2003, 20:43

I just tried the latest Athos ffdshow release and there are still some things broken:
- Nic's postprocessing doesn't work at all. When used the player just crashes. I think this is broken since May, now.
- The mod16 fix (changelog) doesn't seem to work for a movie of mine: DivX3 with a resolution of 720x405.

thop

28th November 2003, 20:47

seems to work ok here, except that mplayer/nic postprocessing seem to have no effect at all, even if i put everything to the MAX.

Soulhunter

28th November 2003, 23:11

just tried the latest Athos ffdshow release and there are still some things broken:
And a other thing... ;)

The resizing function seems not to work correctly !!!

When I resize the picture to full screen (ffdshow intern) and use "keep original AR" it only zooms the picture inside the window... :confused:

Means, the size is changed, but I only see a part of it (inside the default window) !!!

Bye

winman

29th November 2003, 02:09

This version does not seem to decode the mp4v FourCC from 3ivx splitter...

BMan

29th November 2003, 14:26

Originally posted by oddball
I have noticed that if I set XviD in ffdshow to decode DiVX5.x content I get an exception and the player crashes (Any player).
same here, except it also crashes while set to libavcodec...and just with this new build...
i had got a similar problem with the 20030523 build on my old system, but seems to be working on my freshly installed windows now...

guess it's 0523 for me then...

BoNz1

30th November 2003, 08:23

athos, I heard milan got h.264 decoding in ffdshow. Would it be possible for you make a new build of ffdshow? I would do it myself but directx9sdk hates me :(

athos

30th November 2003, 14:50

Originally posted by BoNz1
athos, I heard milan got h.264 decoding in ffdshow. Would it be possible for you make a new build of ffdshow? I would do it myself but directx9sdk hates me :(

I checked this out from cvs 20031128, latest update to cvs was 20031017. i will make a new build if you tell me how to get h-264 support.

BoNz1

30th November 2003, 20:35

Ok, it looks like he hasn't updated the cvs yet so sorry I guess I jumped the gun a little but he did say that it is working so it should be in there soon I would think ;).

arno

1st December 2003, 10:35

It seems that since release 20030927, using the gamma-correction of "Picture Properties" causes an immediate crash of ffdshow (or at least the player its using). I think it has something to do with the optimization code used for it which is not compatible with my CPU. I have a Pentium III-500MHz. Athos, could you please have a look at it?

athos

1st December 2003, 12:43

I tried with the latest build, and gamma correction works just fine here (have P4). Did you try with the same build? For the build before i used Intels compiler, with which I have had some problems with crashing before (maybe I used some unstable flags or something).

arno

1st December 2003, 13:19

Originally posted by athos
I tried with the latest build, and gamma correction works just fine here (have P4). Did you try with the same build? For the build before i used Intels compiler, with which I have had some problems with crashing before (maybe I used some unstable flags or something).

What do you mean by "same build"? To be clear this is what happens
- I tried builds 20030927, 20031028, 20031128 which all don't work with gamma correction enabled on my my P3.
- previous builds ( <= 20030816) seem to work fine however.

p.s. : I reported it before. But are you aware of the fact that Nic's postprocessing is still broken (and now has been since the release of 20030523 ? I've tested this bug on several machines (PIII, K6 & Duron) and all cause an immediate crash of the player.

athos

1st December 2003, 15:24

ok, i thought it might have been a problem with the last build. nics pp works for me (doesnt crash, although i have a hard time seeing any difference to no pp, is this what you mean? that it doesnt do anything?). this must be a problem with the code, and not my compile, since all flags are targeted towards Pentium or better architecture, and thus P3 should be no problem.

perhaps we shouldnt draw to many conclusions though, as milan has asked me not to put up any official builds since 200305 for the reason that he doesnt feel it is in a stable state.

arno

1st December 2003, 15:47

Originally posted by athos
ok, i thought it might have been a problem with the last build. nics pp works for me (doesnt crash, although i have a hard time seeing any difference to no pp, is this what you mean? that it doesnt do anything?). this must be a problem with the code, and not my compile, since all flags are targeted towards Pentium or better architecture, and thus P3 should be no problem.

perhaps we shouldnt draw to many conclusions though, as milan has asked me not to put up any official builds since 200305 for the reason that he doesnt feel it is in a stable state.

With Nic's PostProcessing enabled it crashes ("This program performed an illegal operation ....") the player (tried with several players). Tested on both Pentium III-500MHz & AMD Duron 1.2GHz.

sysKin

3rd December 2003, 13:49

Hi everyone,

I have problems decoding xvid dev-api-4 with "packed bitstream" option, when there is more than one b-frame in the row.

In theory, ffdshow decodes all frames and puts them in correct order. In practice, they are not shown with constant framerate. I can't really tell which frame is shown for a fraction of the time and which gets shown longer :( (too fast) but if I use direcshowsource() in avisynth, AVS is able to fix the jerkyness by just showing one frame every 40ms...

I confirmed that all frames are decoded, by opening directshowsource() avs in virtualdubmod.

I tried 20030523 and Athos' 20031028 and got more or less the same result (more or less: the unnoficial new build was always jerky here, but it's much worse with packed bitstream).

I hope one of you can take a look, because XviD 1.0beta can create perfect packed bitstream videos :) and I'd like to use this option :)

Regards,
Radek

raistlin2k

3rd December 2003, 19:47

I have found a strange decoding bug in FFDShow:

I encoded a chapter of LOTR - The Two Towers using DivX 5.0.5 & XVID 1.0 beta to compare the quality. therefore I used FFDShow as Decoder to have the quality not being different because of different decoders.

Using FFDSHow 2003-05-23 I found a decoding error in the DivX movie. It must be a decoding of FFDShow because using DivX decoder the error is gone.

So I upgraded to FFDShow 2003-11-28. Voila, the error is gone in the DivX encoded avi, BUT IT APPEARS NOW IN THE XVID ENCODED, the same error at the same situation.

Strange!!

Well, I thought, no problem, let's enable XVID as decoder inside FFDSHow, but it seems that the aloha decoder cannot be used inside of FFDshow, it only works by disabling FFDshow completely, but then I have only XVID decoder without any post-processing.

I also tried DivX Decoder for decoding XVID & it works 100%, without any decoding errors, but the DivX Post-processing takes twice CPU-power.

I really hope that FFDShow will be fixed, so I can use it for all my DivX AND my Xvid encoded movies again.

Thanks
Raist

Danzel

4th December 2003, 05:31

@raistlin2k

Do you want to tell us what the decoding error is that you saw/got when using ffdshow?
If its a graphical error then perhaps you could try the xvid / simple idct (which ever one isnt selected).

Danzel.

raistlin2k

4th December 2003, 11:14

@Danzel

It's a graphical error, appearing in a zoom-out in chapter 30 of the LOTR -The two towers- DVD.

as already mentioned ,Selecting XVID IDCT in FFDSHow 28/11/2003 doesn't work, the player crashes. In FFDSHow 3/1/2003 the "Use XVID" is even greyed out, although XVID is installed properly, playback using only XVID (wthout ffdshow) works.

Perhaps the XVID decoder has changed in 1.0 beta so it doesn't work anymore inside ffdshow?

Raist

Vern Dias

6th December 2003, 13:51

More info on the broken gamma in the picture properties on several of the latest builds:

It is only broken when the Luninance Offset is not set to "0". In other words, you can't use both luminance offset and gamma at the same time.

Leaving either one set to default allows the other to be used.

Vern Dias

dimzon

8th December 2003, 13:01

Bug found at resize feature!

Seems like FFDShow does'nt keep original aspect ratio!
When I use 20030523 bild it work's fine!
I have 720*304 video
I set resize to 800*600 (my VideoCard does'nt work properly when width not mod 32)
Under 20030523 i got nice LETTERBOXED (black zones ot top and bottom) image with width scaled to 800 and video height is scaled proportionaly original aspect ratio (no aspect ratio changed)

Under last athos bild i got scaled to 800*600 image with aspect ratio changed to 4:3 (no letterboxing)

sorry for my poor english

arno

9th December 2003, 21:14

Originally posted by arno
With Nic's PostProcessing enabled it crashes ("This program performed an illegal operation ....") the player (tried with several players). Tested on both Pentium III-500MHz & AMD Duron 1.2GHz.

Dear Athos,

I did some additional testing: Completely removed ffdshow, removed registry keys, clean install of November 2003 build of ffdshow & only enabled postprocessing & checked Nic's. This is what happens with various settings:
- It works (no crash) when I (via "Custom) enable ALL postprocess settings except "Chroma Dering".

- The odd thing is when I use automatic quality control, it only does NOT crash when the slider is in the minimum setting (0, no postprocessing), it doesn't crash. The previous finding would suggest that it should work up to slider setting 6 (which doesn't enable chroma dering, which is enabled only with setting 7).

- It also works when I initially configure ffdshow to use mplayer postprocessing (or no postproc), and during movie play change it (back) to Nic's.

- It doesn't happen with *every* DivX movies. About 50% of my movies seems to suffer from this issue. The other part just runs fine. Although I'm unable to find out what the working/non-working movies have in common.

I'm puzzled, but I hope you can (finally) figure out what causes this problem and fix it.

dimzon

10th December 2003, 11:26

Originally posted by arno

- It doesn't happen with *every* DivX movies. About 50% of my movies seems to suffer from this issue. The other part just runs fine. Although I'm unable to find out what the working/non-working movies have in common.

Seems like DivX 5.0.5 with B-frames and GMC

arno

10th December 2003, 11:47

Originally posted by dimzon
Seems like DivX 5.0.5 with B-frames and GMC

Nope. Seems mostly DivX3.11 movies that cause the problem. And maybe even *exclusivly* DivX3.11 (no probs with DivX5 & XviD), although I'm not sure (yet).

dimzon

10th December 2003, 12:15

Originally posted by arno
Nope. Seems mostly DivX3.11 movies that cause the problem. And maybe even *exclusivly* DivX3.11 (no probs with DivX5 & XviD), although I'm not sure (yet).
Hmm. In my case it will never crush on DivX3.11
Maybe becoze I use not last ffdshow build (i use 200305xx)
I have huge DivX collection at home and I can test it more carefully at weekend.

I will try to do that,if I will find problem AVI and I will send the part of AVI and ffdshow settings to test issue...

sorry for my poor english, i'm russian...

dimzon

10th December 2003, 12:46

Originally posted by dimzon
Bug found at resize feature!

Seems like FFDShow does'nt keep original aspect ratio!

http://dimzon541.narod.ru/resize-bug.zip - screenshots (only 80K)

dapipa

14th December 2003, 11:19

hi!i've noticed that resizing bug a long time ago:ffdshow20030523 is the last build which keeps correct aspect ratio when resizing,at least on my computer:-(interesting is,when i set the aspect ratio manually to the value shown left of(i think)KEEP ORIGINAL ASPECT RATIO radio button,resizing works correctly...p.s.well,i'm not the only one:it isn't working on dimzon's computer too,but i didn't noticed his post before:-)

dimzon

15th December 2003, 12:20

Originally posted by dapipa
it isn't working on dimzon's computer too,but i didn't noticed his post before:-)
it is'n working at both my PC (at office and at home)

arno

15th December 2003, 15:09

Originally posted by arno
With Nic's PostProcessing enabled it crashes ("This program performed an illegal operation ....") the player (tried with several players). Tested on both Pentium III-500MHz & AMD Duron 1.2GHz.

I turns out that the Nic's PostProcessing crash-bug can only be triggered with BSPlayer somehow. I was confused because the gamma-correction crash-bug intervened my investigation.

I used MediaPlayer 6.4 for testing and this seems to work fine. Although I'm not sure whether to blame BSPlayer or ffdshow. It always used to work with BS Player (& older ffdshow versions), so for now I'm pointing the finger at ffdshow.

Athos, could you look into this issue with this new information (-> try to reproduce the bug yourself with BS Player?).

dimzon

15th December 2003, 15:17

Originally posted by arno
I used MediaPlayer 6.4 for testing and this seems to work fine. Although I'm not sure whether to blame BSPlayer or ffdshow. It always used to work with BS Player (& older ffdshow versions), so for now I'm pointing the finger at ffdshow.

Seem's like not exatly BSPlayer but YV12 color space...

mikeson

15th December 2003, 15:54

@milan:

As sysKin mentioned in previous page, is there a possibility you would implement decoding 'packed bitstream' in ffdshow? It would be really usefull IMHO. :)

BTW thanks for your great work! ;)

LigH

16th December 2003, 18:00

Just to remind you...

The "orange-blue" bug was not yet fixed, although Milan told me he though he found the reason (must have something to do with fixed rounding bugs during the development from DivX 5.0.1/2 towards 5.0.3++). The increasing color displacement during P frames (reset on each I frame) only occur when decoding material encoded with DivX versions up to 5.0.2 as far as we found out.

bond

18th December 2003, 15:40

@milan

1) it seems the latest ffdshow build from athos doesnt register the "mp4v" 4cc anymore (it still registers "MP4V")!
because of that ffdshow currently doesnt work with .mp4 files!

2) btw. it would be great if you could also add the NDIG 4cc, which is the official 4cc of the nero digital mpeg-4 codec!

3) shitowax from 3ivx reported that the video decoder also register the PCM mediatypes

bond

18th December 2003, 16:01

aspect ratio

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

there are two different possibilities to play this stored ar in a correct way in dshow:
1) use the nero video decoder filter (which comes with aheads tools)
2) with the 3ivx decoder after doing the following:
*) mux the 3ivx/xvid output avi with the 3ivx dshow muxer to .mp4
*) remux the video stream with the 3ivx dshow splitter to .avi
*) play the resulting .avi with the correct ar with the 3ivx dshow video decoder

would be great if ffdshow could also supports this :)

midiboy

18th December 2003, 16:48

Hi guys !

I really hope you can help or at least explain the problems I am having with ffdshow.

I have experienced major stuttering on file playback on my system which I could not get rid of, not even with reclock. My system is not too slow for mpeg4 playback, it consists of the following components:

Asus P4P800 Deluxe board, latest BIOS
Hyperthreading on ( tried without too )
P42.6C @ 3.2 Ghz ( tried without overclocking too )
Matrox P650 videocard
Sim2 HT300+ projector on second DVI
2x512MB DDR 400 RAM
2x Hitachi SATA harddiscs
Maudio 1010LT audiocard, SPDIF to receiver, latest driver

Windows XP SR1, all patches installed
Dirext X 9.0b
Zoom Player Pro 3.2 (using Overlay Mixer btw.)
Windvd 4.5 filters
elecard demux
ffdshow ( tried last "offical" and all the silent releases since)
AC3 Filter
reclock 1.2 ( tried earlier versions also )

Projector is able to natively display at 48, 50 and 60Hz, without upconverting to 60Hz so with reclock it should be able to achieve absolutely stutterfree playback.

However, it never worked. It sometimes works for a few minutes or seconds but sooner or later, major stuttering appears.

After trying everything else I could think of ( like disconnecting USB devices, reinstalling Windows with only above setup, etc. ) I deinstalled ffdshow and instead installed the 3ivx decoders from this site: 3ivx site (http://www.3ivx.com/download/index.html)

Guess what, stuttering disappeared immediately and completely. Now, I reinstalled ffdshow and the stuttering appeared again. I then deactivated all the codecs in the ffdshow setup and my system was again stutterfree.

Just as a sidenote: i have not (!) enabled any of the processing features of ffdshow, not one. The only thing I had ffdshow installed for was for it´s decoding abilities so the argument that my system is too weak and therefore stutters isn´t viable.

As I said, I have tried a lot of ffdshow versions. Even the official builds, like the 20030424 build caused stuttering, as did the latest silent releases.

Can anyone explain this please or even better, make ffdshow perform stutterfree ?? :cool:

Another problem, that only appeared after the 20030424 build and which I wrote about earlier in this thread is still there with the latest silent build by the way.

With the 20030424 build, video will correctly appear on both monitors of my videocard. With all the builds since, ffdshow will freeze Zoom player when video is opened directly on the second monitor. It works ok if the video opens on the first monitor and is being dragged to the second afterwards. Very strange, but reproducable each and every time not only on my Matrox card but also on an ATI Radeon card I had earlier.

Anyway, ffdshow is nice and free and all but I cannot use it if those bugs are not corrected.

Thanks for your help !
Alex

oddball

18th December 2003, 20:59

Oi Milan. How close are we to another official release? It's been over 6 months already. :)

BlindWanderer

18th December 2003, 23:13

first i would like to apologies for some of my noobish bug reports on SF (as i was a noob when i posted them).

what i would like to see is the ability to chain the ffdshow-audio and ffdshow-video together for avisynth scripts, so you can in fact do real avisynth script editing in ffdshow.

Also a little bug(?) i noticed in the avisynth part of ffdshow. avisynth isn't told the total number of frames even when ffdshow knows the number. (currently it reports the same number every time).

I happily await the next silent release in January.

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.

arno

26th January 2004, 23:03

Originally posted by Andy2222
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.

I just installed the Kurosu release aswell and guess what? Both the bad performance problem (stuttering) is fixed & Nic's Postprocessing method no longer crashes my player (BS player). Great! Thanks, man!

I think there's a serieus compiler problem with the Athos builds? Maybe Athos could talk to Kurosu about the possible cause(?)

Andy2222

26th January 2004, 23:58

Originally posted by arno
I just installed the Kurosu release aswell and guess what? Both the bad performance problem (stuttering) is fixed & Nic's Postprocessing method no longer crashes my player (BS player). Great! Thanks, man!

I think there's a serieus compiler problem with the Athos builds? Maybe Athos could talk to Kurosu about the possible cause(?)

I think the problems was caused by the mplayer.dll, maybe something little with big impact changed there. Im trying to build a new ICL8.0 build with the actual cvs. Compiling seems to work so far with some little modifications. If i tested the compile maybe i will post it here to for download.

Andy2222

27th January 2004, 07:07

oki some more infos about the green colro conversion bug. Its 100% caused by the /mplayer -> libmplayer.dll

If u compile the dll with VC6 or ICL 7.1/8.0 u dont have that bug but the rezisers are damm slow (about 50% slower) if u use the make in min-gw with gcc the speed is nice but that color bug appers.
Im not sure what exact cause the error maybe some stuff in the more optimized gcc version or some diff. linked libs?

Still no luck i tryed now compile the mplayerlib.dll with gcc from version 3.2.2 to 3.3.2 under mingw and cygwin with many diff. speed and -O options, with sse,mmx,3dnow disabled and i386 mode. I cant get a compile out wich dont produce that color bug.... The ICL7.1 ICL8.0 and VC 6.0 compiles work fine but even the fastest ICL8.0 compile is 50% slower than the gcc compiles....? I could realy use some advices? Also how can i get older version/revs from
cvs system? I tryed around with "cvs co -r ..." but only get the version i see on the webcvs system. Athos is it maybe also possibel to get the .configure file for ffdshow and the mplayer? Also where do i have to look to get a new mplayer.lib?

CruNcher

27th January 2004, 12:39

thx Gabest and Andy2222 for helping me out ok i could fix that dxguid problem but new linking errors arised :(

Creating library Release_ICL/ffdshow.lib and object Release_ICL/ffdshow.exp
TffDecoder.obj : error LNK2001: unresolved external symbol "public: __thiscall CVideoTransformFilter::CVideoTransformFilter(char *,struct IUnknown *,struct _GUID const &)" (??0CVideoTransformFilter@@QAE@PADPAUIUnknown@@ABU_GUID@@@Z)
TffdshowEnc.obj : error LNK2001: unresolved external symbol "public: __thiscall CVideoTransformFilter::CVideoTransformFilter(char *,struct IUnknown *,struct _GUID const &)" (??0CVideoTransformFilter@@QAE@PADPAUIUnknown@@ABU_GUID@@@Z)
TffDecoder.obj : error LNK2001: unresolved external symbol "public: virtual long __stdcall IffDecoder::compat_findAutoSubflnm2(void)" (?compat_findAutoSubflnm2@IffDecoder@@UAGJXZ)
Tffvfw.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TpresetSettings.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TDScalerSettings.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TffdshowEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
Ttranslate.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
CresizeAspect.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TffdshowPageEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
reg.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
Tffvfw.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TpresetSettings.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TDScalerSettings.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TffdshowEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
Ttranslate.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
CresizeAspect.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
TffdshowPageEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
reg.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::_Lockit::_Lockit(void)" (__imp_??0_Lockit@std@@QAE@XZ)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::logic_error::`vftable'" (__imp_??_7logic_error@std@@6B@)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::logic_error::`vftable'" (__imp_??_7logic_error@std@@6B@)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::logic_error::`vftable'" (__imp_??_7logic_error@std@@6B@)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int const std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::npos" (__imp_?npos@?$basic_string@DU?$char_traits@
D@std@@V?$allocator@D@2@@std@@2IB)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int const std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::npos" (__imp_?npos@?$basic_string@DU?$char_
traits@D@std@@V?$allocator@D@2@@std@@2IB)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned int const std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::npos" (__imp_?npos@?$basic_string@DU?$char_traits@
D@std@@V?$allocator@D@2@@std@@2IB)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::out_of_range::`vftable'" (__imp_??_7out_of_range@std@@6B@)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::out_of_range::`vftable'" (__imp_??_7out_of_range@std@@6B@)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) const std::out_of_range::`vftable'" (__imp_??_7out_of_range@std@@6B@)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xran(void)" (__imp_?_Xran@std@@YAXXZ)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xran(void)" (__imp_?_Xran@std@@YAXXZ)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xran(void)" (__imp_?_Xran@std@@YAXXZ)
Tsubreader.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xlen(void)" (__imp_?_Xlen@std@@YAXXZ)
TsubreaderMplayer.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xlen(void)" (__imp_?_Xlen@std@@YAXXZ)
TpresetEnc.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xlen(void)" (__imp_?_Xlen@std@@YAXXZ)
bin\ffdshow.ax : fatal error LNK1120: 9 unresolved externals
Error executing xilink6.exe.

ffdshow.ax - 37 error(s), 72 warning(s)

Andy2222

27th January 2004, 12:43

realy strange u have the latest "cvs update" and u using VC++ 6.0?

Can u make a screenhot of your includes/libs and also what compile settings u use aka wich linking settings? Or post it here. Its easy to see that some files got not liked/included but why...

ADD: ah i see u try compile the ICL release? What ICL u use 7.1 or 8.0? Maybe try the normal release first with teh vc 6 compiler.
For the ICL try also add the "libirc.lib" to the link lib modules.

CruNcher

27th January 2004, 12:59

yeah i figured it out now only those last link problems here and im done :)

xilink6: executing 'C:\PROGRA~1\PROGRA~1\VC98\Bin\link.exe'
Creating library Release_ICL/ffdshow.lib and object Release_ICL/ffdshow.exp
TffDecoder.obj : error LNK2001: unresolved external symbol "public: __thiscall CVideoTransformFilter::CVideoTransformFilter(char *,struct IUnknown *,struct _GUID const &)" (??0CVideoTransformFilter@@QAE@PADPAUIUnknown@@ABU_GUID@@@Z)
TffdshowEnc.obj : error LNK2001: unresolved external symbol "public: __thiscall CVideoTransformFilter::CVideoTransformFilter(char *,struct IUnknown *,struct _GUID const &)" (??0CVideoTransformFilter@@QAE@PADPAUIUnknown@@ABU_GUID@@@Z)
TffDecoder.obj : error LNK2001: unresolved external symbol "public: virtual long __stdcall IffDecoder::compat_findAutoSubflnm2(void)" (?compat_findAutoSubflnm2@IffDecoder@@UAGJXZ)
bin\ffdshow.ax : fatal error LNK1120: 2 unresolved externals
Error executing xilink6.exe.

ffdshow.ax - 4 error(s), 0 warning(s)

Andy2222 im useing icl 8
edit: tried to compile with vc6 the same 4 errors :(
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dx81_c/directx_cpp/htm/cvideotransformfiltercvideotransformfilter.asp
strange i compiled it and added it to dxsdk/lib and still those 4 errors :(

Andy2222

27th January 2004, 13:38

realy no clue... i hate those linking errors. If u can manage to get it work pls tell me how the performance on your system is with lanczos rezise at 1152x768 or up. On my ICL 8 compiles its so damm crappy... To bad cvs system is down atm cant check a other revision for my tests.

What compile switches u use? /G6 /O3 -Qxi ? Some vector optimize stuff too?

CruNcher

27th January 2004, 15:11

Andy2222 could you attach your .dsp file i don't know what im doing wrong i reinstalled dx9b and still the same 4 linking errors :(

those are my linking settings

msvcrt.lib strmbase.lib libircmt.lib libirc.lib kernel32.lib user32.lib advapi32.lib winmm.lib ole32.lib uuid.lib oleaut32.lib comctl32.lib gdi32.lib shell32.lib comdlg32.lib dinput.lib dxguid.lib oldnames.lib /nologo /entry:"DllEntryPoint@12" /dll /pdb:none /machine:I386 /def:".\src\ffdshow.def" /out:"bin\ffdshow.ax" /implib:"Release_ICL/ffdshow.lib"

Edit:

Ok i solved that also i was useing the Release_Unicode strmbase.lib wich was wrong now only 1 link error is left :)

Linking...
xilink6: executing 'C:\PROGRA~1\PROGRA~1\VC98\Bin\link.exe'
Creating library Release_ICL/ffdshow.lib and object Release_ICL/ffdshow.exp
TffDecoder.obj : error LNK2001: unresolved external symbol "public: virtual long __stdcall IffDecoder::compat_findAutoSubflnm2(void)" (?compat_findAutoSubflnm2@IffDecoder@@UAGJXZ)
bin\ffdshow.ax : fatal error LNK1120: 1 unresolved externals
Error executing xilink6.exe.

ffdshow.ax - 2 error(s), 0 warning(s)

any idear ?

Andy2222

27th January 2004, 18:47

hehe i just downloaded all releases from the cvs :)

Lemme try compile the latest, seems the V1/V2 and other releases are outdated, will check that later.

@Athos i dont want check all the ffdshow code, but what functions classes are mainly called from mplayerlib.dll wich are used in rezise and swscaler wich might cause that color bug?

Kurosu

27th January 2004, 21:03

I've seen most of the linking errors reported here, but I hardly remember what I've installed to get it to work. As for the speed difference, it's obviously the compilation by nasm of the .asm files, enabling MMX/iSSE code; Athos had already noted that problem.

I don't know what's possibly causing the other bugs, nor what my build fixes or breaks.

Andy2222

27th January 2004, 21:25

@CruNcher u have the dx9b sdk installed and the windows nt platform sdk and included all libs/includes to the vc++ dirs?

Im getting now this for the ICL compile

ec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TpresetSettings.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TDScalerSettings.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TpresetEnc.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
TffdshowEnc.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
Ttranslate.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(void)" (__imp_??1_Lockit@std@@QAE@XZ)
CresizeAspect.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec(dllimport) public: __thiscall std::_Lockit::~_Lockit(

i had this error already on ym first trys... forgot what i was changing hehe :)

Andy2222

28th January 2004, 01:59

and some luck CruNcher?

I was lucky and finaly found the bug with the green, its the "#define ARCH_X86" in the swscale.c seems something is messed up with the includes and the #defines seems also that cpudetect.c has some trouble on Athlon systems. I will check this out. I will try use the latest mplayer/ffmpeg and libavcodec for teh new compile. also using nasm and gcc with cpu flags. Will play a bit with the defines and see what speed i can get and maybe compile a AMD and intel SSE version.
I will try what i can to to see what that aspect ratio and overlay problem is releated too. Also the postprocessor could need some work :)

Coroner

28th January 2004, 05:29

Wow!

It's great to see this sort of activity in this thread. I was starting to worry that ffdshow might be dead, which it still could be. It would be nice if the niggling bugs were fixed and it's brought in line with Xvid latest.

Keep up the good work people.

Gaia

28th January 2004, 10:06

Originally posted by Coroner
Wow!

It's great to see this sort of activity in this thread. I was starting to worry that ffdshow might be dead. It will be so nice when the niggling bugs are fixed and it's brought in line with Xvid latest.

Keep up the good work people.

Cheers

Coroner

Development might be still dead... This discussion is about compiling.

Coroner

28th January 2004, 11:58

I do realize that, although it is nice to see some bugs being discussed and some possibly squashed.

I have rephrased the post above as I was using wills instead of woulds. I shall try to prevent my enthusiasm from over taking my posts in future.

dapipa

28th January 2004, 12:36

hi!did any1 find out(yet),what causes the DOESN'T_KEEP_CORRECT_ASPECT_RATIO_WHEN_RESIZING bug,which a couple of people(including me)were complaining about in this thread?all builds after 20030523 are suffering from it:-(

Andy2222

28th January 2004, 19:13

aye i also hate this bug. Maybe im able to build a working version with AR and without that green rezise bug. Still working on my release its damm hard to compile and to update. Im still trying to fix that green bug its 100% in the swscale_template.c if u "#undef RUNTIME_CPUDETECT" in the config.h and also #undef all speed optimizations u get a green free rezise (buts unusable slow) thats what mainly happens if u compile teh lib with vc++ since speed defines dont work and just a plain x86 version is generated thats why its so slow, but also dont have this bug.

@DEV's any tip what in the swscale_template can cause that? If its in the assembler code im out of business....

dapipa

29th January 2004, 08:35

@Andy2222:i'd like to help u,but i stopped programming in ASM/C++ a long time ago,under MS-DOS,so i've got no idea how it works under new WIN(or linux)platforms:-(

Andy2222

29th January 2004, 10:20

It is not that hard to "try" translate that asm code, its more that the code use mmx/3dnow/mmx2 optimized instructions and finding that little value wich cause the trouble can be a pain. Im trying to checkout if the mplayer also have the bug using scaling, if not than its something in the ffdshow swscale call routines. If its also in mplayer i will try mail the mplayer devs since the swscaler is not coded by the ffdshow dev i guess (or i try find an old rev wich dont have the bug but might be a bit slower :) )

Im realy enjoying it, its slow progress but funny if u finaly get your compile working. Its also funny to see the org. ffdshow in the firstrelease stage, cool interface.

Andy2222

31st January 2004, 16:39

oki found the error for the green problem, the new mplayer revs use a new
#define VROUNDER_OFFSET "11*8+4*4*256*2+8"

uint64_t vRounder __attribute__((aligned(8)));" definition in
struct SwsContext{}

Just add the new defs and "c->vRounder= 4* _u64(0x0001000100010001);" at the call and the green problem is solved.

But seems its already integrated in the latest cvs.

Andy2222

2nd February 2004, 15:17

wrong info

Blight

2nd February 2004, 19:59

Andy:
While you're at it, can you fix that bug that prevents the filter's property dialog from opening if the filter is not connected to an active graph (pressing the config buttons in ZP for example)

bond

2nd February 2004, 20:09

and plz add support for the small character "mp4v" again to the source, its needed to make ffdshow work with .mp4 and native matroska files! :D

Andy2222

2nd February 2004, 20:31

Originally posted by bond
and plz add support for the small character "mp4v" again to the source, its needed to make ffdshow work with .mp4 and native matroska files! :D

oki that should be easy :)

bond

2nd February 2004, 20:34

great it was commented out because there were too many 4ccs used it seems:

In TffDecoder_reg.cpp:

// I had to comment few media types, because graphedt was crashing when listing directshow filters
// Most probably there were too many registered media types by ffdshow's input pin
const TffdshowDecVideo::TmediaType TffdshowDecVideo::inputMediaTypes[]=
{ (...)
{ &MEDIATYPE_Video, &CLSID_MP4V ,FOURCC_MP4V},
//{ &MEDIATYPE_Video, &CLSID_mp4v ,FOURCC_mp4v},
(...)
NULL,NULL,0
};
maybe its better if you comment MP4V out (i dont know a codec that uses it) or any other strange 4cc, mp4v is more important imho

Andy2222

2nd February 2004, 20:49

Originally posted by Blight
Andy:
While you're at it, can you fix that bug that prevents the filter's property dialog from opening if the filter is not connected to an active graph (pressing the config buttons in ZP for example)

i will see what i can do, atm i mainly try get the following things fixed

1. swscale chroma rounding problems (aka no more green if u rezise)
(that is a mplayer problem)
2. get the correct AR if u rezise (bug in the newer versions)
3. speed optimizations and fully working asm code of the integrated parts from other projects (xvid color conversiosn and co)
4. get the code build with cygwin since i can set more speed stuff with gcc compared to ICL or VC6

so far i have 2 options use the latest cvs version and try fix all stuff or use a older rev and try integrate xvid4 + denoise3d + all new bugfixes/support

So far i could code a simple hack for the aspect ratio problem in the latest cvs version, in the old version overlay + overlay AR + normal Ar works fine. Still have no clue why overlay/AR in teh new versions not working...

I also try get a fix for the green + rezise chroma bug by reporting it to the mplayer devs. Problem is the new vrounder introduced in the latest dev mplayer version fixed the green problem but also cause a new bug, wich is already in the 10/11 versions Athos compiled.
Since its ASM code i cant realy do much...

maybe found the rounder bug could be compiler option related

BTW: if some1 want code a denoise3d asm/mmx2/sse code that would be a realy huge speed buff for ffdshow :)

dimzon

3rd February 2004, 11:44

Originally posted by bond
great it was commented out because there were too many 4ccs used it seems:

In TffDecoder_reg.cpp:

// I had to comment few media types, because graphedt was crashing when listing directshow filters
// Most probably there were too many registered media types by ffdshow's input pin
const TffdshowDecVideo::TmediaType TffdshowDecVideo::inputMediaTypes[]=
{ (...)
{ &MEDIATYPE_Video, &CLSID_MP4V ,FOURCC_MP4V},
//{ &MEDIATYPE_Video, &CLSID_mp4v ,FOURCC_mp4v},
(...)
NULL,NULL,0
};
maybe its better if you comment MP4V out (i dont know a codec that uses it) or any other strange 4cc, mp4v is more important imho

Maybe best way is to split ffdshow into 2-3 separate filters (in one *.ax file of couse) with exatly same implementation(using inheritance from base class) but with different fourCC set (to avoid max fourCC per filter limitation)

Andy2222

3rd February 2004, 13:04

@ the other compiler dudes

Is some1 able to build the baseclasses with gcc? Im using the dx9b sdk and seems the .diff file dont patch fully..

Some1 has a working set and can provide me with a working .diff patch file for the dx9b sdk and maybe a working makefile?

Or has the old dx9a sdk basecalesses wich work with the .diff?

problem solved

Andy2222

4th February 2004, 15:31

will repost later

oddball

5th February 2004, 16:37

ffdshow seems to have a jerky problem with XviD RC1 encodes. I tried with May 23 2003 version too just to be sure. Using XviD RC1's own decoder they playback smoothly.

bond

5th February 2004, 16:42

ffdshow doesnt handle more than 2 packed bitstream b-frames, as produced with the default settings with the latest xvid builds

its a bug in ffdshow

Andy2222

5th February 2004, 18:06

damm its a pain to rewrite all that inline __asm code from intel to AT&T standard for gcc...
some1 maybe know a working converter? ATm im using intel2gas v1.3.3 but it has some trouble with some commands. Is there a other script or tool?

Or is it possible to set a gcc option so it accept also intel inline asm code without rewrite the code?

found a solution
now i need test how the gcc 3.3.3 or 3.4beta vs ICL8.0 compiles perform.

LigH

5th February 2004, 18:11

I did not see such a problem with the build from 2004-01-13; maybe it was fixed, maybe the movie I used did not use (m)any packets with 3 B frames.

My dynamic mirror: http://www.ligh.de/software/mirrors.phtml

Andy2222

5th February 2004, 18:57

Originally posted by oddball
ffdshow seems to have a jerky problem with XviD RC1 encodes. I tried with May 23 2003 version too just to be sure. Using XviD RC1's own decoder they playback smoothly.

Im not sure what that bug is but in teh actual cvs a special xvid4 code was implemented i guess that bug is fixed.

oddball

5th February 2004, 23:01

Yeah but the newer builds have an inherent jerkiness of their own compared to the 23/5 build when playing back vids encoded in any other codecs.

hellfred

8th February 2004, 10:33

@LigH
Looks like you are the only one serving and talking about ffdshow buil 20040113.
(At least that is my conclusion after googling and searching this forum)
Did you compile this version yourself?
I have problems using this build on my Win98 system (with an Intel PIII Katmai CPU). ffdshow complains about a dll missing whenever it try to run the configuration after running the installer. ffdshow is not an selectable dshow filter, registering the ffdshow.ax fail, too. Sadly the error messages does not include which dll is missing.
On anothere system that i can access (Intel PIV with WinXP) the ffdshow build works fine. Is this yet another problem with the missing unicode on Win98? If you are the compiler of this version and the problems are due to the unicode support, i would like to ask you: Is it possible that you make a version not using unicode? I really like to use ffdshow on my PIII-550, as it it the only codec/dsfilter that allows me to view high resolution (>640x480) mpeg4 videos without stuttering. And it would be a shame to have to do without it because somewhere in the dialogs the unicode chars cannot be displayed. (At least that is a guess of mine).
Or am i missing something else? ffdshow 20031128 is working on my Win98 system.

Yours
hellfred.

filewalker

8th February 2004, 13:42

During the installation, one .dll was also missing, but a dialog popped up and showed me that "msvcp70.dll" is missing...( I found it here (http://www.dll-files.com/) )

Cu filewalker

Koepi

8th February 2004, 13:58

You also need msvcr70.dll, find it in the same location above as msvcp70.dll.

Regards
Koepi

hellfred

8th February 2004, 14:41

Thanks for the tipps. After coppying those two dlls next to ffdshow.ax configuration worked again and directshow based player can use ffdshow now. But neither the installer nor starting configuration gave me the name of the missing dll. I have confirmed that. The installer does not output any warinings or errors at all.

hellfred

bond

8th February 2004, 15:17

Andy2222,
i hope you didnt lost interest in ffdshow, people are really starving for a new ffdshow version with fixes :)

maybe you can ask trbarry (or milan if he answers) for getting your things added to the official ffdshow sources

Andy2222

8th February 2004, 17:03

Originally posted by bond
Andy2222,
i hope you didnt lost interest in ffdshow, people are really starving for a new ffdshow version with fixes :)

maybe you can ask trbarry (or milan if he answers) for getting your things added to the official ffdshow sources

nope, atm im tyring some compiler related stuff. The ICL8.0 version is already working, the speed is at least the same or a "bit" better than the 09/2003 version.
Atm im messing around with some asm stuff in the code for the gcc compiler. Im hoping the new gcc 3.3.3 or 3.4 maybe can get a bit more speed out of the code. The biggest bottleneck is still the denoise3d filter. But i have to rewrite/alter some code and defines for gcc.

What is already fixed?

"configure" crash in zoomplayer
aspect ration and overlay not working/connecting correct
some speed optimized code wasnt used in some filters, if compiled with VC++. (need recheck if the code might bug/crash those filters)
chroma rounding bug aka movie gets green if u use rezise filters, was most noticeable with lanczos and sinc
changed to "mp4v" fourcc -> (info from bond)

What im still working on?

gcc compile with all intel asm code used correct
overlay reset button not working
delinking nic's and mplayer postprocessor filters, so u can use deblock and dering seperate from both filters (example: using only nics deblock and only mplayer dering)
some minor changes for the "keep org. aspect ratio" button

If the gcc compile is finaly fully working and i can compare the speed vs the intel version, i will than release a first bugfixed version. The stuff im working on will need some more time.
Im aiming for bugfixes and most possible speed atm. Since i dont want rewrite the routines atm i can just work at the compiler end. "Maybe" i update my asm knowledge with some SEE/MMX2 stuff and see if i can update some bottlenecks with optimized versions, but i dont think i have that much time atm.

bond

8th February 2004, 17:06

great! and plz dont forget to uncomment the "mp4v" fourcc, as described above :)

avih

8th February 2004, 17:27

Andy2222, thx for your work, sounds very good so far.
good luck

avih

mikeX

8th February 2004, 17:28

updating nic's postprocessor with xvid4 (new nic's) versions

is that the same as xvid's >=beta code?
if so, won't that raise cpu usage tremendously? (that's what xvid's postprocessing does to me)

Andy2222

8th February 2004, 18:02

Originally posted by mikeX
is that the same as xvid's >=beta code?
if so, won't that raise cpu usage tremendously? (that's what xvid's postprocessing does to me)

Will review that, old xvid's revs used nic's wich has optimized asm code. The new beta just use simple c++ code, wich seems just grabbed from mplayer. If i cant find a new asm version of nic's i will keep the old one and just update the mplayer version.

Was sure there was an updated asm version of nic's in a xvid version i downloaded...

Blight

8th February 2004, 21:12

Andy, there is also AR information saved into XVID streams now, if ffdshow could pass that info down the line using the VIDEOINFOHEADER2 structure, that would make ffdshow the only decoder other than the nero one that could handle anamorphic xvid content (I think).

Andy2222

8th February 2004, 22:40

Originally posted by Blight
Andy, there is also AR information saved into XVID streams now, if ffdshow could pass that info down the line using the VIDEOINFOHEADER2 structure, that would make ffdshow the only decoder other than the nero one that could handle anamorphic xvid content (I think).

I can try implement this, the code is already in the overlay part since for overlay+rezise mode VIDEOINFOHEADER2 is used for the AR correction. Have to check if there is already code to get the AR out of the stream.

PS: atm some strange things happend here, the latest Intel 8.0 compiler produced code wich runs 30% slower than plain O2 code compiled with VC 6.0? Seems the Intel Compiler have some problems with verctorizing and inlineing. But even if i disable ipo aka /Ob2 the code is much slower than the VC6.0 version... I was thinking Intel produces always faster code than the old MS compiler, at least that was what latest compiler benches showed. Something is messed here.

athos

8th February 2004, 22:49

Andy> It's very cool to see that you are involved in this project! I havent followed this thread for a while, because, well, i forgot ;) I do check the CVS regularly though, still nothing from milan. I was wondering, as you seem to have been getting to know the code some, have you figured out how to update the mplayer and libavcodec parts from those projects? milan gave me the impression that it shouldnt be hard to do, but i havent managed to get it working myself. especially the libavcodec would be good, because i think there are some stuff that has been improved since the latest version being used in the current CVS.

Keep up the good work, and let me know if I can help you with anything. I do know some c/c++, but i have only been compiling the project, and made no code contributions.

Andy2222

8th February 2004, 23:06

hehe so we sit in the same boat :) I also know c/c++ but never coded extensive dshow filter like ffdshow :)

The mplayer parts are kinda simple, for the swscaler and noise not much changed. I have to take a look into the libavcodec myself but im concentrating on other stuff first since its working fine atm.I think rather use ffdshow as raw filter than as decoder. Im still not happy with the compiler speed..

What compiler options and compiler did u used for the 09/2003 version wich seems to be the fastest from your compiles?

PS: u know a tool to convert dsw/dsp files to unix makefiles or at least convert the windows makefile for nmake to teh unix version? Im tired of rewriting and changing makefiles.

Soulhunter

8th February 2004, 23:35

Wow, ffdshow resurrection... :D

Bye

athos

8th February 2004, 23:52

Originally posted by Andy2222
What compiler options and compiler did u used for the 09/2003 version wich seems to be the fastest from your compiles?
I used gcc with -O3 (from cygwin) for the gcc stuff (libmplayer, libavcodec and libmpeg2 i think) and then ICL 7.1 for the rest (except TomsMoComp which i cant get to compile with ICL) using /O3 /QawK or something like that (ie, optional use of cpu-specific optimizations/instructions such as mmx).

I compared compiling libavcodec with gcc and icl (7.0 i think it was) and gcc was much faster, but i think this was due to icl not compiling the asm stuff, but instead using c versions. Is this what you are looking at? It would be nice to be able to compile everything using the same compiler. if possible the choice would be gcc, in the spirit of open source ;)
Originally posted by Andy2222
PS: u know a tool to convert dsw/dsp files to unix makefiles or at least convert the windows makefile for nmake to teh unix version? Im tired of rewriting and changing makefiles.
Unfortunately not, but i have this script that supposedly converts the other way, perhaps this would help for something?
http://athos.leffe.dnsalias.com/makevcgen.txt

Andy2222

9th February 2004, 00:20

Nah the gcc for mplayer libavcodec is realy needed thats clear. No im meaning if i simple compile the ffdshow project without even changing the gcc dll's (mplayer/libav) using ICL 8.0 vs VC6.0 the VC 6.0 compile runns up to 40% faster compared to my ICL output..? Thats realy strange. I just deleted all switches and use simple O2 or O3 for ICL and the icl version is 30% slower..?

Maybe its a 8.0 Problem i will try reinstall the 7.1 version.
Since there is that much diff. in the compiles i realy expect some speed boost by fully using gcc. Im just comparing against your 9-11/2003 versions and the VC compile is already 10% faster. I cant belive that my old VC 6.0 tops an ICL 7.1 compile....
Need to rewrite the asm stuff for gcc since without it will be crappy slow.

I already checked the whole code for special _MSV_VER preprocessor instructions but just some uint64 stuff showed up so icl 8 and vc6 use 100% the same input to compile.

i just uninstalled icl 8 and installed 7.1 and have nearly the same results..? What CPU u have im using a AMD XP. Maybe its those fast_memcopy (from the libirc.lib) stuff wich dont work well on AMD CPU'S. But i cant see why since the XP also have SSE...

athos

9th February 2004, 02:09

Im using a P4.

I read somewhere that ICL 7.1 and 8.0 produces identical results when going for IA32 platform. I think most of the news is in IA64 and possibly SSE3 support. I'm not sure about this though. Also, if I remember correctly, Avery Lee (Virtual Dub) said that he thought the output of ICL was much better than VC's "pessimizations" (his words). Again, I might remember wrong.

It is very surprising that VC6 compiles are faster. Did you try VC7.1? I have avoided it because of the need for extra dlls, but perhaps there is a speed difference?

Stux

9th February 2004, 05:16

Andy2222

9th February 2004, 06:06

Originally posted by athos
Im using a P4.

I read somewhere that ICL 7.1 and 8.0 produces identical results when going for IA32 platform. I think most of the news is in IA64 and possibly SSE3 support. I'm not sure about this though. Also, if I remember correctly, Avery Lee (Virtual Dub) said that he thought the output of ICL was much better than VC's "pessimizations" (his words). Again, I might remember wrong.

It is very surprising that VC6 compiles are faster. Did you try VC7.1? I have avoided it because of the need for extra dlls, but perhaps there is a speed difference?

I dont want use VC7.1 since i mainly use VC6 for overall compatibility reason's. Still cant belive that VC6 tops ICL 8/7.1 for other projects i try use Bloodsheds DEV-C++ with gcc.
There is also a thread in the intel forum wich is related to speed problems of the intel compiler, seems some other users have this problem too. Maybe the intel compiler try to over "optimize" the inline ASM code? Im guessing that code is already optimzed by hand. In gcc u can prevent this with __asm volatile (...);

first asm problems solved

dapipa

10th February 2004, 08:12

Originally posted by Andy2222
What is already fixed?
aspect ratio and overlay not working/connecting correct

hi!can you post your(compiled)fixed version of ffdshow for download?i know,it's not completely fixed up yet,but i'd just like to check it out,because my only problem with builds after 20030523 was the buggy KEEP ORIGINAL ASPECT RATIO thing...pretty please with sugarlumps on top:)

Andy2222

10th February 2004, 17:32

@dapipa just give me 1 or 2 more days i just finished to rewrite all the damm inline asembler stuff last night, so the gcc compiler can parse that code. Now i just have to fix all the local declared variables since AT&T syntax dont allow this. Im grabbing some food now and will fix that after im refreshed :)

If im lucky the linker will find all stuff and give ma a ffdshow.ax file :)

gigatron

10th February 2004, 18:28

So what's the latest version? Where can one get it? I have like a 2002 version lol been two years uuh hehe :)

Edit: nm just found it, I wonder what's new heh. The last one I got was from sourceforge..

Andy2222

10th February 2004, 18:49

Originally posted by gigatron
So what's the latest version? Where can one get it? I have like a 2002 version lol been two years uuh hehe :)

Edit: nm just found it, I wonder what's new heh. The last one I got was from sourceforge..

the 05/2003 version is the latest official wich Mitka released all later versions base on the as "none stable" declared cvs tree. I dont think those version's are not stable but have some bug's. Thats the reason im working on those code atm, since Mitka dont have much time anymore to check and fix the cvs code.

The most improved stuff compared to 2002 or 05/2003 version is the denoise3D filter wich gives realy nice results. Also the rezise filter was much updated. The other changes are related to the audio filter and vfw stuff. I like the new version's cause of many assembler and MMX/3dnow/SSE code included for better speed. Also in the latest version the ASM yv12 convert code from avisynth comes handy.

bond

10th February 2004, 19:03

Andy,
if you still have enough motivation you maybe also want to have a look on the automatic resizing with anamorphic encodes in avi and mp4 (matroska already works, dunno about ogm)

the 3ivx guys found a way on how to store the ar info in avi and mp4 to make their decoder (with overlay mixer2) automatically resize such encodes, this would be great if it would also work in ffdshow, if possible :)
i think shitowax or stux wrote a description about how they do it in the xvid forum

keep up the great work :)

Andy2222

10th February 2004, 19:28

Hmm im no video guru, i also dont know codec internals very well. Is those anamorphic AR stored in the movie header?
I know how ffdshow handels the rezise AR, it just use videoheader2 if overlay is working and hand the x,y from the rezise settings and AR settings from org. Video over to the overlay. The overlay than calcs other stuff. So if we assume there is a special AR already in the xvid header ffdshow just need use that AR for videoheader2 right? In rezise mode it also just need to pass the org. header AR (not the pixel AR) over. Is that how those ana thing work?

Light me up with a bit more detailed stuff.

Koepi

10th February 2004, 19:40

We tried that stuff in xvid dshow ;)

The moment you handle out the conection in the graph you can set the info in the header - but you don't have access to the bitstream yet. So the container demuxer (and thus the container) must hold the AR info.

DShow sucks. Setting the correct AR afterwards (after having info from the bitstream itself) does _not_ work.

Maybe i'm totally wrong, some DShow experts please jump in here - i would be glad if ffdshow (and xvid dshow ;) ) could set the AR for the overlay from the bitstream data itself (well, it's kinda possible - you have to use the resolution you set at the start and _downscale_(!) the video internally - that's how i.e. Nero does it...).

Regards
Koepi

Andy2222

10th February 2004, 19:48

hehe fast post's!

@Koepi the latest cvs xvid use a simple/slow .c version as postprocessor. Is there a plan to update this versions with a asm/mmx2 version? In the old versions or at least in nic's old xvid releases there was a mmx/asm version?
Main problem with nic's was the crappy dering, deblock worked fine, better than mplayer's. U maybe have a updated mmx versions from nic somewhere?

arno

10th February 2004, 19:53

Originally posted by Andy2222
hehe fast post's!

@Koepi the latest cvs xvid use a simple/slow .c version as postprocessor. Is there a plan to update this versions with a asm/mmx2 version? In the old versions or at least in nic's old xvid releases there was a mmx/asm version?
Main problem with nic's was the crappy dering, deblock worked fine, better than mplayer's. U maybe have a updated mmx versions from nic somewhere?

What I especially dislike about the XviD decoder filter is the fact that it doesn't have automatic postprocessing like ffdshow has.

One other important comment is: Why not join hands and make 1 solution. Now it's like 2 people are reinventing the wheel: the XviD decoder developer(s) (Koepi?) and the ffdshow developer(s).

LigH

11th February 2004, 06:01

Originally posted by gigatron
So what's the latest version? Where can one get it? I have like a 2002 version lol been two years uuh hehe :)

The last version I have in my mirror was from 2004-01-13; unfortunately, I absolutely don't remember where I 'stole' it from. ;) -- Can anyone remind me?

http://www.ligh.de/software/mirrors.phtml

Andy2222

11th February 2004, 06:07

Originally posted by LigH
The last version I have in my mirror was from 2004-01-13; unfortunately, I absolutely don't remember where I 'stole' it from. ;) -- Can anyone remind me?

http://www.ligh.de/software/mirrors.phtml

u got it from this thread :) some pages before but this version has some speed problems, since the dll's arnt compiled with gcc and dont use any mmx/3dnow asm code. I dont recommend to host this 2004 version.

LigH

11th February 2004, 06:52

Thanks! As soon as someone makes a new and optimized version available, I will exchange it. Currently, the speed seems for me to be around equal to the XviD 1.0-RC1 decoder: 640x288 pixels is just a little too much for a Duron-800 with Deblocking and Grain (Film effect) with both decoders.

Blight

11th February 2004, 08:17

I made some changes to ZP so that it can sorta intercept AR changes in files on the fly (as the decoder calls for a mediatype change). I wouldn't recommend it though, there are all sort of unreliable stuff in it, it'd be for the best if the AR was pre-known. Maybe just patch some sort of tagging system over AVI. Or use the comment field in the AVI header ... dirty though.

shitowax

11th February 2004, 09:40

3ivx puts the VOL header in the codec private space in both .avi and .mp4 (never tried it but I bet it would work in OGM and MKV as well) and retrieve it at connection time in DShow... 3ivx way is completly container independant as it should be ;)

Originally posted by Koepi
Maybe i'm totally wrong, some DShow experts please jump in here - i would be glad if ffdshow (and xvid dshow ;) ) could set the AR for the overlay from the bitstream data itself (well, it's kinda possible - you have to use the resolution you set at the start and _downscale_(!) the video internally - that's how i.e. Nero does it...).Koepi

Koepi

11th February 2004, 11:54

Blight:

hm, that souns interesting, we didn't try something like that yet :-)

Use a flag "stream available" and after graph building, wen the first VOL is available, get the AR info, modify videoinfoheader2 accordingly and send a "media_type changed" message down the input pin.

Should it be as simple as that? Can a dshow filter do that or does it need the graph-building application?

Thanks for the hint! :)

Regards
Koepi

Smiff

11th February 2004, 13:04

i find 2004-01-13 very much slower than 2003-11-28 if postprocessing (mplayer) enabled on a Duron 1.2Ghz - is this normal?

edit: yes i'm thinking from Andy2222's reply above it is. it's just weird that this build got posted on softpedia as their pick of the week etc.. no offense, heh Andy great to have someone working on ffdshow! keep it up m8 :)

this AR stuff.. how important is it? is anyone using non 1:1 pixel ratio encodes, and what for? (i'm curious).

dimzon

11th February 2004, 13:43

Originally posted by Smiff
this AR stuff.. how important is it? is anyone using non 1:1 pixel ratio encodes, and what for? (i'm curious).

IMHO AR has no one advantage but it add some incompatibility...
I am not using non 1:1 pixel ratio encodes

athos

11th February 2004, 16:55

Originally posted by Smiff
this AR stuff.. how important is it? is anyone using non 1:1 pixel ratio encodes, and what for? (i'm curious).
you are aware that most retail dvd's (if cinema movies anyway) nowadays have anamorphic picture, so a 1:1 pixel encode would result in an anamorphic mpeg-4 (for example) video stream?

Smiff

11th February 2004, 17:04

Originally posted by athos
you are aware that most retail dvd's (if cinema movies anyway) nowadays have anamorphic picture, so a 1:1 pixel encode would result in an anamorphic mpeg-4 (for example) video stream?

right.. people want to do full res. copies of dvds? fair enough. i always resize & drop some lines when encoding to mpeg4 (so i effectively un-anamorphify it) like most people do, i guess you don't have to, for high bitrate mpeg4 (high being relative of course). ok good answer thanks :) sorry to go OT i'll stop now and get back on it.

Andy2222

11th February 2004, 18:43

mhh question: I found a 3ivx rip from dvd on my hdd and the movie plays wrong if i use ffdshow without overlay. The movie seems encoded in sucha anamorphic thinggi. If i use my fixed version with working overlay zoomplayer gets the correct AR from ffdshow and plays just fine.

I checked it in graphedit here are the datas:
Thats what the 3ivx decoder outputs:
Major Type: Video - Sub Type: YV12 - Format: YV12 712x360, 12 bits,
Aspect Ratio: 28480x11880,
Interlace format: Frames
rcSrc=(0,0,712,360)
rcDst=(0,0,712,360)

and thats what my ffdshow hand's to the overlay:
YV12 712x360, 12 bits,
Aspect Ratio: 28480x11880,
Interlace format: Frames
rcSrc=(0,0,712,360)
rcDst=(0,0,712,360)

now i just wonder what we all talking about? Since this also work in the 05/2003 version already? Do i miss something here?

bond

11th February 2004, 18:52

Originally posted by Andy2222
I found a 3ivx rip from dvd on my hdd and the movie plays wrong if i use ffdshow without overlay.hm the overlay mixer option has to always be ticked to get aspect ratio correction working (it uses overlay mixer2 in the filter graph)

The movie seems encoded in sucha anamorphic thinggi. If i use my fixed version with working overlay zoomplayer gets the correct AR from ffdshow and plays just fine.i dunno what zp does, but i think such a feature shouldnt depend on the player used
did you try it in graphedit?

Andy2222

11th February 2004, 18:59

yes in graphedit it worked too. So what we talk about if that thing is already working with overlay and vmr7/9 ? I dont think some1 here plays with the plain old render without overlay? So i dotn understand the discussion here realy.

bond

11th February 2004, 19:02

so in 3ivx encoded anamorphic encodes get resized automatically in ffdshow already (also if in avi)?
that would be news to me

Andy2222

11th February 2004, 19:06

ups was not a avi was a .mp4 file. :) Btw are we talking about raw mode or we talk about using libavcodec to decode 3ivx stuff and than gets out the real AR?

bond

11th February 2004, 19:11

i am talking about using libav :)

yep using raw (which means the 3ivx decoder is added in the graph) already works with .mp4, would be great if it could also work in ffdshow directly

Andy2222

11th February 2004, 19:19

oki some bad news btw, just usng the .intel_syntax directive for gcc and inline asm code dont work. The main problem are all those local C variables, i cant just declare them global this will break the code... I started to manualy rewrite the code to AT&T syntax but have some little understanding problems. Maybe some1 can help me a bit.

an example, here the org. Intel syntax:
__asm {
mov esi, [srcp]
mov edi, [dst]

mov eax,[esi]
mov ebx,[esi+4]
mov ecx,[esi+8]
mov edx,0
jmp yloop_test
align 16
yloop:
mov edx,0 // x counter
jmp xloop_test
align 16
xloop:
mov edx, src_pitch_uv2
movq mm6, [add_ones]
.......
xloop_test:
cmp edx,[src_rowsize]
mov x,edx
jl xloop
mov edi, dst
mov eax,[esi]
mov ebx,[esi+4]
mov ecx,[esi+8]

mov edx,skipnext
cmp edx,1
je dont_skip
add edi,[dst_pitch]
add eax,[src_pitch]
add ebx,[src_pitch_uv]
add ecx,[src_pitch_uv]
mov [skipnext],1
jmp yloop // Never out of loop, if not skip
align 16
dont_skip:
add edi,[dst_pitch4]
add eax,[src_pitch4]
add ebx,[src_pitch_uv2]
add ecx,[src_pitch_uv2]
mov [skipnext],0
mov edx, [y]
mov [esi],eax
mov [esi+4],ebx
mov [esi+8],ecx
mov [dst],edi
add edx, 4

yloop_test:
cmp edx,[height]
mov [y],edx
jl yloop
sfence
emms }

So we have here around 10 local variables (x,y,height....) Now i need define those for extended at&t syntax

___asm___(

......

: //output
: //input
: //clobber
)
So do i just define all variables as "m" and output as "=m" and in the code i use the %0-%10 macros? Problem is i understand simple examples with values loaded in registers and i realy like the at&t now over intel. But how i handle all those local C variables? Is there a way to tell GAS to load the variables for me and i can keep the org. C names in the asm code? Problem is with 10 variables i get wussy to rewrite all to %0-%10....

any tips?

sprit

11th February 2004, 23:04

Originally posted by Andy2222
Is there a way to tell GAS to load the variables for me and i can keep the org. C names in the asm code? Problem is with 10 variables i get wussy to rewrite all to %0-%10.... Have you looked at named operands? From info gcc -> C extensions -> Extended asm:As of GCC version 3.1, it is also possible to specify input and output operands using symbolic names which can be referenced within the assembler code. These names are specified inside square brackets preceding the constraint string, and can be referenced inside the assembler code using `%[NAME]' instead of a percentage sign followed by the operand number. Using named operands the above example could look like:
asm ("fsinx %[angle],%[output]"
: [output] "=f" (result)
: [angle] "f" (angle));
By using '.intel_syntax noprefix', you shouldn't even have to add the %'s before variables and registers (I haven't tried it with named operands).

Andy2222

11th February 2004, 23:22

ah cool thx this might help

athos

12th February 2004, 00:00

Originally posted by Smiff
right.. people want to do full res. copies of dvds? fair enough. i always resize & drop some lines when encoding to mpeg4 (so i effectively un-anamorphify it) like most people do, i guess you don't have to, for high bitrate mpeg4 (high being relative of course). ok good answer thanks :) sorry to go OT i'll stop now and get back on it.

sorry, mate. my bad. of course you most often resize the video when doing dvd -> mpeg4 conversion, and when you do that you might as well "un-anamorphify" it like you say. i dont know what i was thinking. i was cranky because of too little sleep, but now ive got my 4 hour afternoon nap ;)

still it might be a nice feature to have in some cases.

Blight

12th February 2004, 04:11

If you have DirectShow set to maintain the AR automatically (either through VMR9 or through Overlay), the changes should work instantly if a filter changes the videoinfoheader2 structure (see graphedit).

However, when the player itself controls the AR, this is a bit more complex. With VMR9, you need to intercept a message and then recalculate the AR, with Overlay, I only have an MPEG2 file to test this with, but some decoders throw an undocumented command to change the resolution.

Someone wants to post a small AVI file for testing?

Andy2222

12th February 2004, 08:29

puhh good news, i finaly managed to get ffdshow with gcc compiled and linked. After spending 3 day's in assembler and gcc forums. I had to learn the hard way that gcc 3.3.x and also the linker in binutils 2.14 have some troubles and i need manualy select files for gcc 3.2 and 3.3 and use the 2.13 linker to pass by all those crazy errors in the wonderfull unix world...

To get to the point the new gcc compile seems to be 10-30% faster than the latest 09-11/2003 version. It's also 10-15% faster than my fastest intel or VC6 compile. So cheer UNIX power :)

(30% is in cpu intensive filters wich use simple c++ code, no big boost for the filters wich use asm optimized code already. For example the denoise3d filter is plain c++ code and i noticed a nice speed boost there 10-20%)

If i have some time today i just need fix an error in the yv12_conversion code, since atm it crash my compile to use yv12. Seems i have to review my rewritten ASM code for bugs...

This time i dont give an ETA, to many things can still be very time consuming if something is not working, since i converted all inline asm code to unix syntax. Maybe there are more errors i realy hope not.

BoNz1

12th February 2004, 08:57

Andy2222, I don't want to make more work but have you updated the ffmpeg? There are a number of important fixes there that would be nice in a new build for example the decoding fix for packed bitstream. If it isn't too much trouble it might be nice to have the latest up to date version of ffmpeg.

Andy2222

12th February 2004, 09:12

um ... u maybe know the files? If those fixes are inside of function's without changing the return types. I can simple do a comparsion beetwen old and new code. If i have to add function's/classes or bigger stuff i will pass for now.

athos

12th February 2004, 13:47

Andy and others: Perhaps we should open a new project, ffdshow-mod, on sourceforge? When and if milan "returns" we could merge the both projects? I am a member of the original project, but I dont have write permissions to the CVS, and anyway I think milan wants control of what goes in the CVS.

About the ffmpeg update, I will have a look at it and see if I can figure out how to update it, so Andy can concentrate on the asm stuff which is totally out of my league.

dimzon

12th February 2004, 14:16

bond

12th February 2004, 14:51

before starting a new project maybe you should contact milan if he has nothing against joining the exisiting project!
you can also ask trbarry, who is around on doom9, for cvs access

hellfred

12th February 2004, 16:53

Originally posted by Andy2222

PS: u know a tool to convert dsw/dsp files to unix makefiles or at least convert the windows makefile for nmake to teh unix version? Im tired of rewriting and changing makefiles.

Did you have a look at the MinGW Utilities?
(http://sourceforge.net/project/shownotes.php?release_id=158859)

dsw2mak: Microsoft Developer Studio workspace (DSW) to Makefile converter

Maybe that will help. I have never used it.

hellfred

Andy2222

12th February 2004, 20:10

Originally posted by hellfred
Did you have a look at the MinGW Utilities?
(http://sourceforge.net/project/shownotes.php?release_id=158859)

dsw2mak: Microsoft Developer Studio workspace (DSW) to Makefile converter

Maybe that will help. I have never used it.

hellfred

rofl im using mingw for linking the final objects (cygwin suck, it always mix the cygwin and mingw c libs) but i never RTFM :) damm im still a windows dude, if there is no icon to click i wont find anything. Thx for the hint, to bad i already made the needed changes manualy. But will be handy to know for upcoming stuff.

Andy2222

12th February 2004, 20:14

Originally posted by athos
Andy and others: Perhaps we should open a new project, ffdshow-mod, on sourceforge? When and if milan "returns" we could merge the both projects? I am a member of the original project, but I dont have write permissions to the CVS, and anyway I think milan wants control of what goes in the CVS.

About the ffmpeg update, I will have a look at it and see if I can figure out how to update it, so Andy can concentrate on the asm stuff which is totally out of my league.

I just compared some of the ffmpeg files with the latest cvs, it seems nothing big changed just some more support for audio and some video codec's.
If i understand it right ffdshow just use those dll->call in the Tlibavcodec.cpp, and that file dont look very complicated so mainly u have to figure out what new dll-> calls (or renamed) are in the actual ffmpeg and implement them in the Tlibavacodec.cpp.

PS: For the sourceforeg thing, would be cool we just have to open a new branch in the ffdshow cvs so nothing get mixed. But since i could not find a way to write some working preprocessor macros for keeping the old intel syntax asm and convert them to unix style on the fly i realy did some changes to the code wich milan "might" not like and now its also impossible to use VC6 or intel compiler to compile my version. Since there is still Dev-C++ wich use gcc and the new gcc version is faster i dont see a problem but i think milan would like to keep those changes seperated from his version.

Andy2222

13th February 2004, 02:38

mhh maybe some1 know how assembler output templates work in gcc?

Problem:

inline void dummy()
{
__asm__ __volatile__("
push %eax
jmp jump
jump:
pop %eax"
);
}

int main()
{
dummy();
dummy();
}

Compiling with -S shows the fact that gcc just copies the asm block twice
in the main and so, the "jump" label is defined twice, wich resluts in a compiler error.

So there are those output templates, i think the "%=" will do the job, can some help me here, is this correct?
inline void dummy()
{
__asm__ __volatile__("
push %eax
jmp jump%=
jump%=:
pop %eax"
);
}
As far as i read %= output a unique number wich is generated new in every instance of the asm code. (i realy start to hate at&t syntax, since the org. intel code dont had to worry about multiple calls...)

problem solved, just 2 hours of using the www, seems the %= is working.

bond

13th February 2004, 09:55

Originally posted by Andy2222
i realy did some changes to the code wich milan "might" not likeits pretty easy in cvs to use exactly the same folders, etc... as the last "official" code, but still keep them seperated

it works via tagging. have a look at the drop-down menu at the bottom here (http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/)
someone could tag the latest "official" sources as "milan_latest" or so and after that simply add andy's changes to the cvs
that way you can use the same structures as milan, dont mess the cvs and his latest stuff would be still available

Andy2222

13th February 2004, 22:55

common dudes some1 here must have been used inline asm yet?

i keep posting here, dont know special asm forums...:

thats the intel syntax line
"mov edx, src_pitch_uv2" //src_pitch_uv2 is a local c variable

it load's the pointer to src_pitch_uv2 in edx

thats my at&t line
"movl $%[src_pitch_uv2],%%edx"
:
:[src_pitch_uv2] "g" (src_pitch_uv2) //reference to src_pitch_uv2, and "g" means let the compiler choose a register to store.
:"%edx"

and i get a asm error: "Error: junk `(%esp)' after expression"
seems the $%[src_pitch_uv2] is not working
also
"movl (%[src_pitch_uv2]),%%edx"
is not working.
Maybe its cause i load the value of src_pitch_uv2 in [src_pitch_uv2] as reference and not the pointer or is something wrong in the line?

arno

14th February 2004, 00:57

Originally posted by Andy2222
common dudes some1 here must have been used inline asm yet?

i keep posting here, dont know special asm forums...:

thats the intel syntax line
"mov edx, src_pitch_uv2" //src_pitch_uv2 is a local c variable

it load's the pointer to src_pitch_uv2 in edx

thats my at&t line
"movl $%[src_pitch_uv2],%%edx"
:
:[src_pitch_uv2] "g" (src_pitch_uv2) //reference to src_pitch_uv2, and "g" means let the compiler choose a register to store.
:"%edx"

and i get a asm error: "Error: junk `(%esp)' after expression"
seems the $%[src_pitch_uv2] is not working
also
"movl (%[src_pitch_uv2]),%%edx"
is not working.
Maybe its cause i load the value of src_pitch_uv2 in [src_pitch_uv2] as reference and not the pointer or is something wrong in the line?

Maybe this works (long time since I used x86 assembly, so don't bleem me if I'm wrong ;-)):

"movl src_pitch_uv2,%%edx" or maybe even "movl (src_pitch_uv2),%%edx"

But as I don't really understand what you're doing (whether you're doing a dword ptr [] or just a value load) it could also be:

"movl $src_pitch_uv2,%%edx" or maybe even "movl ($src_pitch_uv2),%%edx"

Using % is, as far as I recall exclusively for registers.

I could be completely wrong here, if you're not able to fix it with this help I will have to get my old books out of the dust and have a closer at it for you (as I'm really eager to help you build a brand new ffdshow release ;-))....

Andy2222

14th February 2004, 01:23

solved

Andy2222

14th February 2004, 06:56

oki seems i found a fix/solution, something was messed up with my clobber and input output registers... Seems the code is working now. Heading over to the next file with asm code :)

PS: i never noticed that using libavcodec vs org. xvid decoder is sucha speed diff. libavcodec is 50% faster than using xvid and ffdshow in raw mode? I tryed latest beta (sse/mmx compile) and the old nic and koepi all perform pretty poor (PP was disabled) compared to libavcodec :)

Neo Neko

14th February 2004, 08:32

Well I'm not saying libavcodec and ffmpeg can't deliver good quality because they can. But they are not specifically coded for quality as they are for speed. They are intended to be a "real time" encoder decoder solution.

Andy2222

15th February 2004, 00:54

more on asm stuff :)

have now nearly a working compile, but the damm yuy2->yv12 asm conversion code from avisynth crash by wrong memory writes...

It's caused by the "sfence" and "emms" command...

So why and when do we need "sfence" btw?

Other strange thing is while "emms" still crash my athlonXP the "femms" dont...? Since on athlon K7+ femms is mapped to emms i dont see why one crash and other not..?

hellfred

15th February 2004, 19:54

@Andy2222:
You are compiling on win32 using MSYS / MinGW. Or are you just linking there? I would like to know how you actually compile some critical files with gcc 3.2 and the rest with gcc 3.3. Do you manually start the compiling prozess for those files and then use make / your makefile and let it compile those source-files that have no .o object file next to it?
Or is it possible to define two different gcc's
(GCC32=/paht/to/gcc
GCC33=/Path/to/the/other/gcc)
in the Makefile and then use the relevant gcc for each line of the Makefile?
($(GCC32) -MM $(CFLAGS) problematic_file.c
$(GCC33) -MM $(CFLAGS) $(SRCS) //the rest)
But how to get two gccs working in one MSYS system? the normal way to install an binary packet of gcc is to unpack it into the MSYS root directory and it will override any existing gcc packet. I would really prefere not to have to compile gcc myself using the --prefix option to get two gccs working in MSYS.
I am asking as i would like to compile ffdshow for my system (PIII-550MHz) to be able to run propper postprocessing and hdtv content smoothly. ffdshow build from 20040928 sometimes has problems, and i could use your 30% speedup.

Yours
hellfred

Andy2222

16th February 2004, 00:30

hehe my trick is bit simpler :)

I have cygwin and mingw installed, using gcc 3.3.3 maybe update to 3.4 on cygwin since im unable to compile the package on mingw. Mingw uses the org. 3.3.1 or 3.2.3 i just made and zipfile before i updated and can easy delete/unzip to what version i need (since mingw is very small it just takes 10 seconds to do this)

I just compile all with cygwin with the -mno-cygwin options and since cygwin suck in this mode (it still mixx cygwin and mingw header/libs) even if i update all mingw libs/header in cygwin to the latest mingw i still get linking errors in the libstdc++.a.
I than delete the critical files and just run a make under mingw so the critical files get compiled with a older version an linked under mingw wich garantee a 100% working windows version. Cygwin is nice but that u still cant build files without the need of the cygwin1.dll is a shame and the -mno-cygwin -target=mingw dont work realy since cygwin+gcc suck to choose the right libs/path/includes and mixx all up wich end in linking errors.... But on the other hand mingw lacks some needed libs/packages to compile gcc/binutils and some other stuff (even if installed the dev package) im unable to compile many stuff under mingw wich work without problems under cygwin... cygwin just have sucha easy web install and support nearly everything u need as developper.

For me the best way is use cygwin as experimental developper system with latest nasm/yasm/binutils/gcc .... and mingw as stable system in wich i just use whats precompiled from the mingw site.

PS: u will need my new ffdshow sourcecode to compile it with gcc, to many stuff depend on inline asm and if u compile a older non gcc tuned version many asm code is simple replaced by plain c++ functions wich results in much slower code.

But dont worry the upcoming version will be a p4 SSE2 compile and a athlon4/p3 mmx2/sse/3dnow compile, i think the p3 also have mmx2/3dnow right and i test every damm gcc option wich might add speed.

Andy2222

16th February 2004, 11:10

damm it damm it damm it!!!!!

fu.... 4 days,
countless hours spending into mmx/sse tutorials..
countless hours compiling the same file over and over..
countless hours trying to understand why emms/sfence crash the memory..
countless hours of shaking my head to the desk..
installed 7 different assembler, 4 diff. compilers, tryed to rewrite to nasm format..

But what was the stupid little error i did while converting to at&t syntax? It was a simple crappy lazy "[]" to put around my %[varname] variable labels... so it looks [%[varname]] and not just %[varname].

I was thinking [varname] already load the VALUE but it dont.. to get the value u need the [] even if it looks crazy to write [%[..]]... that was all....

Sorry had to write this to get away some frustration from the last 3 days/nights. At least im not a ASM noob anymore... :)

PS: that means i just need review all the asm code again for this little error and maybe that was all to get it working finaly..

arno

16th February 2004, 12:06

Originally posted by Andy2222
damm it damm it damm it!!!!!

fu.... 4 days,
countless hours spending into mmx/sse tutorials..
countless hours compiling the same file over and over..
countless hours trying to understand why emms/sfence crash the memory..
countless hours of shaking my head to the desk..
installed 7 different assembler, 4 diff. compilers, tryed to rewrite to nasm format..

But what was the stupid little error i did while converting to at&t syntax? It was a simple crappy lazy "[]" to put around my %[varname] variable labels... so it looks [%[varname]] and not just %[varname].

I was thinking [varname] already load the VALUE but it dont.. to get the value u need the [] even if it looks crazy to write [%[..]]... that was all....

Sorry had to write this to get away some frustration from the last 3 days/nights. At least im not a ASM noob anymore... :)

PS: that means i just need review all the asm code again for this little error and maybe that was all to get it working finaly..

Just wanted to let you know that your efforts are highly appreciated!!!!!!!!

Andy2222

16th February 2004, 12:25

thx :)

PS: can some1 confirm this pls (with amdxp or intel) u need SSE

use xvid to force output yuy2 format and set ffdshow to yv12 output only (u need 09+/2003 version) now disable all filters but postprocessing nic's.

aka: xvid decoder yuy2 -> ffdshow yv12 -> video render

Now the sse yuy2 to yv12 code should be used wich, seems working but now just tunr on and off the Nic's box aka enable disable it. I just notice that if i use rezise/spline and use nic's PP before, by just enabling and disabling the cpu usage LOWERS from 100% to 60%?
Lets say it again enabling nic's PP lowers the CPU usage if the yuy2 conversion code is used? Something is wrong here....

athos

16th February 2004, 12:46

I'm really excited to test this new version when you are done Andy. About this 10-30% speed increase, is this compared to my november build or the january build?

Andy2222

16th February 2004, 13:25

Originally posted by athos
I'm really excited to test this new version when you are done Andy. About this 10-30% speed increase, is this compared to my november build or the january build?

its against your 9/10/11 2003 versions the 01/2004 is total crap :)

some more asm stuff pls maybe this time a little hint?

We have:

pmm1 = (uint64_t *)(&(v[1])); /* this is a 32-bit aligned pointer, not 64-aligned */

(why a 64 bit uint is than used if its just 32 bit, would uint32_t not do the job as well?)

than
mov eax, pmm1 (here the adress is stored in eax)

now my gcc compile crash cause it try this?
movq mm1, qword ptr [eax] /* mm1 = *pmm

(so it try to move the value of the memory adress stored in eax assuming its a qword)

Thats what VC6++ replace the line with:

movq mm1, MMWORD PTR [eax]

This MMWORD thing is something used with the processor pack stuff and 64bit integer types.

Normal quad word is the same but MMWORD can be up to 80/96 bit i think.

So why the gcc compile crash?

Oki i can direct use movq mm1, [%[pmm]] but i think the adress is used by eax cause its faster than get the adress direct out of the memory, maybe its often needed in a loop?

So whats all this int64 stuff about and whats this MMWORD?
Maybe gcc cant see that a cast is needed with this pointer while VC6 can and replace the code with the MMWORD and internaly it checks before it do the actual operation?

[update]
seems the problem is that gcc dont allow to store a 64bit (uint64_t) pointer adress into a 32bit register, wich is oki since its not allowed. I just wonder why VC6 allow this with MMWORD...

Asmodeus

17th February 2004, 23:06

Sorry for make an inroad, but I have one question. Your goal is new version of ffdshow only, or you also try do develop ffvfw?

---------------------------
Poor english team member :D

oddball

18th February 2004, 03:56

Looking forward to try your version Andy2222 :)

Andy2222

18th February 2004, 04:38

Originally posted by Asmodeus
Sorry for make an inroad, but I have one question. Your goal is new version of ffdshow only, or you also try do develop ffvfw?

---------------------------
Poor english team member :D

my first and only goal atm is to get a ffdshow (only the video filter + libavcodec part) wich work without mayor bugs and work as fast as possible. So no im not looking into the ffvfw parts.

For the future i might add some cosmetic stuff for some filters and if i worked through all those asm/mmx/sse tutorials "might" be able to optimize some code :)

Asmodeus

18th February 2004, 10:31

Thx for reply Andy.
It would be nice to optimalize few options in ffvfw, but for now smash every bug in ffdshow ;) Keep going. You doing great job ;)

Didée

18th February 2004, 13:00

Andy,

may I ask if you could have a look on the following issue:

It's a known fact that ffdshow doesn't decode XviD content fully correct. There are small glitches like too strong "floating-wall" artefacts, and too strong "I-frame-pumping"/"I-frame-refresh-effect".

These seem to be IDCT issues. Changing ffdshow's IDCT to "XviD" doesn't change anything in this regard.

The big question is now:
- is ffdshow's (resp. libavcodec's) implementation of XviD-IDCT buggy?
or
- is XviD-IDCT not envoked at all, even when checked?

It would be very, very nice if this problem could get narrowed down - or if it could even be solved!
(Currently, if one produces full-featured X-high-quality streams at big framesizes, there are only twopointfive possibilities: -1.Realtime playback with artefacts (ffdshow) -2. Slow motion without artefacts (xvid.ax) -3. Go back to the future & by a PC)

Regardless of if you can say/do something about this, or not: a really big THANK YOU for all your efforts, Andy!

crowds are cheering AN-DY ... AN-DY ... AN-DY ... AN-DY ... ;)

- Didée

Andy2222

18th February 2004, 15:17

mhh is that problem ffdshow related or also in mplayer?

I need some help with that problem: The libmplayer.dll is desinged to be compiled with gcc (cause of the at&t inline asm stuff) so i need to compile it with gcc wich work great.

Since atm im advancing my asm knowledge i "play" around with the AMD profiling (CodeAnalyst) tool for windows wich realy works nice with the Vc6 code + the .pdb file.

Is there any way to build the libmplayer.dll under gcc so i can use the debug/.gdb infos with teh AMD tool, or with Intel VTune?

I tryed the -g and -ggdb switch but under xp it seems i cant use the generated infos.

U know a way? Since profiling under gcc wont help here since the libmplayer.dll has to work with fddshow.ax.
It would be nice to get it worked since gcc allow -g debug options with -O. options and i realy would like to see what gcc change at some parts of the code and how this improves performance. But i need to find a way to debug/profile the ffdshow/dll gcc compiles under windows using the AMD tool.

Andy2222

23rd February 2004, 01:52

a little update for u

With the help from <alex_here> and <vektor> from the matroska/tvtime irc channel's (i bugged them with asm questions) i could finaly understand the basic concept of mmx/sse optimizing and how the processor access data and how to align them correct.

In result i could rewrite the bottleneck of the denoise3d filter wich is the most consuming filter in ffdshow and now its 2.5 times faster :) I will do some more optimizations and hope to get it 4 times faster.

Since that worked out well i will profile the other filters too and try fix spoted bottlenecks. The reziser wich is already mmx/mmx2/3dnow optimized could maybe get also some updates.

For the release i just can say if im happy with the overall speed i will release it. Means it must be at least 30% faster than any older version with (rezise, postprocess, denoise3d, asharp, levelfix, noise) enabled.

Coroner

23rd February 2004, 02:02

Great stuff Andy2222!

Thanks for all your work.

:)

nanoflower

23rd February 2004, 02:06

It's great that you are putting in all of this work, Andy. It should help make everyone much happier with ffdshow. One question that keeps coming up is, is it possible to get a bug-fix release some time soon, and then follow up with the optimized version. It would help if there was a version of ffdshow that worked better with the current version of XVID (handling multiple B frames in a packed bitstream.) That seems to be the biggest complaint I see.

hellfred

23rd February 2004, 03:42

I just want to cheer you on a little bit, too. (Good english?)

Hellfred

Danzel

23rd February 2004, 04:03

Good Work Andy, hopefully with some of your changes ffdshow will become the great all purpose decoder it once was.

From the libavcodec Changelog on h263dec.h:
Revision 1.144 / (download) - annotate - [select for diffs] , Thu Jan 15 01:29:26 2004 UTC (5 weeks, 4 days ago) by michael
Branch: MAIN
Changes since 1.143: +12 -6 lines
Diff to previous 1.143
xvid "packed" stuff support

If the libavcodec in ffdshow was updated to cvs version then it should be able to decode xvid with packed bitstream. (From what that says)

Danzel.

Dark_Angel_PT

23rd February 2004, 04:10

Just want to congratulate Andy2222 for all this work in developing ffdshow.

I read in the inmatrix forum that you are not thinking of including the audio filter in your work. Is there a possibility to include it , even if without any changes/improvements?

And what about updating the libavcodec? Will it be possible to ffdshow to be the best all-in-one decoder as it once was?

P0l1m0rph1c

23rd February 2004, 04:34

Originally posted by Dark_Angel_PT

And what about updating the libavcodec? Will it be possible to ffdshow to be the best all-in-one decoder as it once was?

It still is ;)

Great work Andy! Looking forward to try a new version soon :)

Cheers

Andy2222

23rd February 2004, 10:38

Originally posted by Danzel
Good Work Andy, hopefully with some of your changes ffdshow will become the great all purpose decoder it once was.

From the libavcodec Changelog on h263dec.h:

If the libavcodec in ffdshow was updated to cvs version then it should be able to decode xvid with packed bitstream. (From what that says)

Danzel.

mhh can some1 post a link to a small video with sucha packed bitstreams so i can test if the actual version can handle it and if not i can try fix that.

sysKin

23rd February 2004, 11:19

Originally posted by Andy2222
mhh can some1 post a link to a small video with sucha packed bitstreams so i can test if the actual version can handle it and if not i can try fix that.
http://homepages.ihug.com.au/~syskin/pb.avi
I have maximized number of b-frames to make the effect as clear (and painful) as possible :)

Good luck,
Radek

Kurosu

24th February 2004, 03:44

Originally posted by sysKin
http://homepages.ihug.com.au/~syskin/pb.avi
I have maximized number of b-frames to make the effect as clear (and painful) as possible :)

Good luck,
Radek
I've just tested it against a ultra-hackish build of ffdshow/VC7+gcc: if Andy2222 ports newer libavcodec, it should work OK. But there are quite a few painfull changes:
- Coder's context no longer holds per-frametype min/max frame mean quants; ffvfw's rate control is mostly broken because of this
- pixel ration has again changed
- there is much stuff to clean out of the files in libavformat
- showMV is broken and maybe some other stuff I didn't dare testing

In any case, I wish good luck too to Andy2222 to rationalize all the changes.

Andy2222

24th February 2004, 12:08

Btw im still looking for a way to use MASM/VC6/ICL8 obj files with the gcc compile/linker.

So far i came up that mingw and masm output coff (pe-i386) format, i use VC6/ICL8 to just output a asm file of the .cpp file. Than i build the coff format with masm out of it, after that i use "objcopy -Ope-i386" to get a clean version. But that dont work dllwrap/gcc linker cant still find the function names.

I came up and changed the names in the ASM file from
"?functionname@@QAAXHZZ LABEL NEAR" to "_functionname LABEL NEAR" but this still dont work...seems there is some kind of declaration in the gcc asm output files for gas.

So anyone have an idea how i can convert masm coff to a format the gcc linker/dllwrap understand under mingw?
Or at least know what else i have to change in the ms compiler/ICL asm output file to match the gcc name/call conventions?

I did not try to change the asm file so gas can understand it fully maybe that will be a better way to try, but for that i have to know what is different in the VC6/ICL8 asm output file compared to the gcc asm output for gas....

Blight

24th February 2004, 21:53

Andy:
I would like to second the motion of a stable ffdshow release. A lot of people use ffdshow as a general-purpose decoder rather than a post-processor and just getting it to play without any quirks would be good.

Danzel

25th February 2004, 00:03

you could try using the linux intel compiler and then using its output with gcc.. maybe?
(I dont know if the windows icl license allows you to use the linux version)

Danzel.

dimzon

25th February 2004, 10:42

I think that "add noise" and "resize" features work's incorrect together.

"add noise" is first and "resize" is after - it's not good. I think it's more proper to make "resize" and after "add noise"

Andy2222

25th February 2004, 13:24

Originally posted by dimzon
I think that "add noise" and "resize" features work's incorrect together.

"add noise" is first and "resize" is after - it's not good. I think it's more proper to make "resize" and after "add noise"

hehe oki i will change the colors of the damm mini arrows to move the filter position :)

There are little "invisible" arrows (up/down) for every filter so u can change the position to what u like. Just mark a filter and whatch the white arrows just before the name. Its not your fault i did not notice them neither on my first ffdshow use.

Andy2222

25th February 2004, 13:30

Originally posted by Danzel
you could try using the linux intel compiler and then using its output with gcc.. maybe?
(I dont know if the windows icl license allows you to use the linux version)

Danzel.

That what i was trying last night, but since i realy dont want switch to linux every time i need a working linux under VMWare or VPC. I had big troubles get debian work under vmware... i now try redhat if that fail suse...

I need a noob safe linux since, i dont want read linux manuals also(all the asm stuff is enuff for my tiny brain). I need a easy install and easy to use dist, if its possible with all developper tools preinstalled. I dont want setup/install a whole working linux by hand... Since i just need it for compiles.

I tryed that CoLinux thing but in the boot image is nearly nothing preinstalled and i dont know how to boot it up with one if the debian cd iso's or redhat iso's.

dimzon

25th February 2004, 13:46

Originally posted by Andy2222
There are little "invisible" arrows (up/down) for every filter so u can change the position to what u like. Just mark a filter and whatch the white arrows just before the name. Its not your fault i did not notice them neither on my first ffdshow use.
WOW :eek:

wise rissan saw (approx. in english) : age to live - age to lean

hellfred

25th February 2004, 14:19

There are some linux live CDs (like Knoppix for example) that have quite easy to us "install to disk" skripts, too. I do not know if those will work together with VMWare etc. But you can give it a try. You will have to install linux ICL manually, but most of the other porgramming tools should be shipped together with the linux live CD. Knoppix and Kanotix (derivation of the later one) are based on debian, so installing software can usually be archieved via apt-get install command easily.

hellfred

Andy2222

25th February 2004, 15:15

good news Milan is working again :) today he updated the cvs with some small updates

---------------------------------------------------------------------
working again... :) just few fixes and new features for now:

fixes in subtitles reader,
fixed mono audio processing,
SPP deblocker from mplayer,
volume normalization from mplayer,
updated installer to NSIS 2.0 final,
updated xvid to latest RC,
output colorspace is preset option,
updated libavcodec (now plays packed xvid b frame streams, some corruptions of picture after seeking),
fixes of few uninitialized variables found by DevStudio
---------------------------------------------------------------------

i just tested the new version, the old bugs are still in but i can merge my fixes with the new version. So far the packed xvid b frame streams seems to work with the testfile i got.

oki Athos got the new version rdy so hurry and grab them.

thx Athos!

athos

25th February 2004, 16:00

No reason to wait, here's the new build: http://athos.leffe.dnsalias.com/ffdshow-20040225.exe

Changelog: http://athos.leffe.dnsalias.com/ffdshow-changelog.txt

Note: This is based on milan's cvs, you will have to wait for Andy2222 to release his build with the cool assembly stuff. Compiled with MinGW and VS6, no ICL.

Selur

25th February 2004, 17:52

got a littel 'request' for the upcoming ffdshow versions:

All versions after ffdshow-20030816 won't work for me as post-processor* without killing aspect ratio informations.
(also see: here (http://forum.doom9.org/showthread.php?s=&threadid=69683&perpage=20&pagenumber=2))

Would be nice if someone could investigate what was chanced after this build,...
(since I'd like to use als newer version of ffdshow)

Cu Selur

*in overlay mode with raw video support enabled

bond

25th February 2004, 19:21

selur,
is overlay mixer2 used in the dshow graph?

oddball

26th February 2004, 06:56

That corruption on ff/rw in the new build is nasty. Hope it's fixed soon.

Selur

26th February 2004, 07:50

is overlay mixer2 used in the dshow graph?
can't find a info about it if I render the file in graphedit, but if you mean if I tried in newer version if it works if I set the over lay to 'gray/black activation' mode,.. tried both but it none helped, it only seems to work with builds where one couldn't switch between the 'gray/black activation' mode for overlay.

bond

26th February 2004, 17:01

Originally posted by Selur
can't find a info about it if I render the file in graphedit so you mean that with both 'gray/black' ffdshow never uses overlay mixer2 automatically?
if this is true than there is surely something borked, as it should use it (and does it that way with the old builds)

iradic

26th February 2004, 17:31

Hwy, what about "Automatic preset loading" - does this work?
Here ffdshow always crashes (winME - ffdshow versions I tried - latest sourceforge, athos 23112003, athos 25022004) after trying to setup automatic preset loading...

Thanks...

Selur

26th February 2004, 19:13

so you mean that with both 'gray/black' ffdshow never uses overlay mixer2 automatically?
if this is true than there is surely something borked, as it should use it (and does it that way with the old builds)[/quote]
The Filtergraph in Graphedit looks the same, no matter what ffshow version I use (overlay enabled) and for most versions it doesn't change if I change from 'gray' to 'black' or from 'black' to 'gray' for all the versions which got the possibility to switch between 'gray' and 'black'.

Hwy, what about "Automatic preset loading" - does this work?
Never tried it, but I will. ;)
(though I can't see how this will help :) )
=> works but doesn't help

---------

with the newest version:
- if I enable 'gray' overlay control&co works, but aspect ratio flag is lost
- if I enable 'black' ffdshow is no longer in the filter chain

Cu Selur

communist

26th February 2004, 20:56

Cool - one clip that was always stuttering (716x576, XviD 2pass / 2B-frames / PB / QPEL...) at around 14 fps with ffdshow and XviD decoder now runs almost fluid :D
Keep up the nice work :)

Only thing I encoutered so far is that when you seek through the file it has that sliming / crawling effect that vanished after some time.

sysKin

27th February 2004, 05:31

@devels

Hi,
I was working on this XviD directshow problem (http://forum.doom9.org/showthread.php?s=&postid=450683#post450683) recently. In short: playback is not fluent with overlay mixer but is fluent with VMR9 mixer. When I was working on it, I discovered that ffdshow (latest build compiled by Athos) has exactly the same problem.

Since I figured out what the problem was, I'll share my findings, hoping that it will help you as well. Note that I haven't seen ffdshow's code so *maybe* this is not it. Maybe.

Anyway, the problematic code was as follows:

CXvidDecoder::Transform(blahblah)
{
blahblah;
decode_frame_blah(and blah);
more_blah;
if (xvid_frame_type & VOL) { // we had a VOL header, most likely a keyframe
some_more_blah();
pOut->SetDiscontinuity(TRUE); // removing this fixed the problem
}
}

I can't really answer why the code was there, it shouldn't really be there according to MSDN. It also only happened once per keyframe, while stuttering was visible everywhere. Anyway, it's most likely a DX9 bug which XviD had to work around.
Please check if you have similar code. If yes, removing it will fix stuttering without any known side effects (xvid's dshow never had it before RC1).

I hope it helps,
Radek

LeQuack

27th February 2004, 14:06

sysKin:

Yes I had, and still have the exact same problem. Playback stutters with overlay mixer, but not with VMR9. Both in xvid and ffdshow decoders. But I think this happened to me even before the 1.0 versions.

athos

27th February 2004, 14:35

A little soon perhaps, but i saw that milan has made some work on the xvid decoding so i put up a new build today: http://athos.leffe.dnsalias.com/ffdshow-20040227.exe

Changelog:2004-02-27 12:15 milan_cutka

fixed for vc6

2004-02-26 21:18 milan_cutka

no message

2004-02-26 19:47 milan_cutka

libavcodec's noise reduction (when encoding), storing of quantizer
matrix in memory presets

2004-02-26 17:31 milan_cutka

no message

2004-02-26 17:27 milan_cutka

merge FRAME and FRAME_TYPE types

2004-02-26 14:15 milan_cutka

updated vc6 projects for libavcodec and libmplayer

2004-02-26 12:21 milan_cutka

graph when encoding, few variables moved out from Tffvfw

2004-02-26 09:30 milan_cutka

minimal compilation is sometimes broken in VC6

2004-02-26 06:29 milan_cutka

just small fixes

2004-02-25 20:00 milan_cutka

fixed few DevPartner warnings

2004-02-25 18:50 milan_cutka

checkbox for SPP soft thresholding

2004-02-25 18:33 milan_cutka

decoding by xvid4 seems to work

2004-02-25 15:21 milan_cutka

working of xvid4 decoding

The Link

27th February 2004, 14:59

When seeking in a xvid file (encoded with rc1 or rc2) with this new build I get this (http://www.beingalink.de/files/snap.png).

edit: only when using libavcodec, xvid4 seems to be ok

bill_baroud

27th February 2004, 15:45

yeah i got that too, until the next key-frame or so.

Arcon

27th February 2004, 15:54

i tried some of your latest builds, athos, but all of them crash every player if i use xvid as decoder for xvid content and set the postprocessing to maximum with nic's pp enabled. if i set pp to 4/6 or disable nic's pp it works without problems.

the (very old) 24042003 build doesn't have this problem.

edit: happens also with libavcodec as decoder. also selecting spp under postprocessing crashes bsplayer and wmp.

Leak

27th February 2004, 17:29

Originally posted by Arcon
i tried some of your latest builds, athos, but all of them crash every player if i use xvid as decoder for xvid content and set the postprocessing to maximum with nic's pp enabled. if i set pp to 4/6 or disable nic's pp it works without problems.

the (very old) 24042003 build doesn't have this problem.

edit: happens also with libavcodec as decoder. also selecting spp under postprocessing crashes bsplayer and wmp.

Well, I just managed to get an almost freshly installed W2K to bluescreen when using XviD 4, SPP postprocessing and moving the slider to the far right after rendering a file in GraphEdit.

Am I the only one who wishes for a fully documented, polished version of ffdshow through not adding bells and whistles for a while? ;)

np: Repeat - Studio 6122 (Miss Kittin - Radio Caroline Volume 1 comp.)

Arcon

27th February 2004, 17:34

i can use nic's pp as long as i dont enable chroma deringing. the 5 other selectable fields under custom pp work with nics without problems.

Leak

27th February 2004, 20:28

Originally posted by athos
A little soon perhaps, but i saw that milan has made some work on the xvid decoding so i put up a new build today:

http://athos.leffe.dnsalias.com/ffdshow-20040227.exe

Just wanted to mention that I get strange artifacts all over the picture with this build.

I've grabbed a part of the same frame when played with just ffdshow, just xvid and xvid + ffdshow registered for "raw video":

Original frames (http://desdemona.ssw.uni-linz.ac.at/LastExile_Original.png)
Effect emphasized using Levels (http://desdemona.ssw.uni-linz.ac.at/LastExile_Emphasized.png)

It seems as if ffdshow produces chroma blocks everywhere in smooth colored areas, even if it's not used as the decoder. And, as you can see, just using XviD to decode the video produces no blocks.

(This at least happens when using my Geforce FX's YV12 overlay; haven't tested it in other color spaces.)

Is anyone else getting this?

And while I'm at it, the "Keep original aspect ration" radio button doesn't seem to work; if I set the aspect ratio manually it works.

np: Pan Sonic - Hapatus (Miss Kittin - Radio Caroline Volume 1 comp.)

Andy2222

28th February 2004, 01:39

Originally posted by Leak
Just wanted to mention that I get strange artifacts all over the picture with this build.

I've grabbed a part of the same frame when played with just ffdshow, just xvid and xvid + ffdshow registered for "raw video":

Original frames (http://desdemona.ssw.uni-linz.ac.at/LastExile_Original.png)
Effect emphasized using Levels (http://desdemona.ssw.uni-linz.ac.at/LastExile_Emphasized.png)

It seems as if ffdshow produces chroma blocks everywhere in smooth colored areas, even if it's not used as the decoder. And, as you can see, just using XviD to decode the video produces no blocks.

(This at least happens when using my Geforce FX's YV12 overlay; haven't tested it in other color spaces.)

Is anyone else getting this?

And while I'm at it, the "Keep original aspect ration" radio button doesn't seem to work; if I set the aspect ratio manually it works.

np: Pan Sonic - Hapatus (Miss Kittin - Radio Caroline Volume 1 comp.)

Are u using the reziser? if so wich method?

There is still a follow up bug from the "green" chroma rounding fix in the mplayerlib.dll

Try use Spline or Bicublin and not Lanczos

arno

28th February 2004, 12:03

Andy2222, I (and many others) really appreciate your efforts in making a new ffdshow. If you like I can, when you release your build, host the package from my university (100mbit) server, if you like. Just let me know...

Leak

28th February 2004, 13:53

Originally posted by Andy2222
Are u using the reziser? if so wich method?

There is still a follow up bug from the "green" chroma rounding fix in the mplayerlib.dll

Try use Spline or Bicublin and not Lanczos

No, I have not used any resizer for those test images; also, for the "xvid + ffdshow" shot ffdshow practically was set to pass through the image unchanged - it didn't decode the picture, the xvid DirectShow decoder was passing YV12 images to ffdshow and ffdshow was set to output YV12 with all processing functions deactivated, so it really didn't have to touch the input at all... and it still made those streaks.

Strange, isn't it?

np: nix

Tyrael911

28th February 2004, 15:16

If i change anything under "picture properties" in the new ffdshow (even if i just check the box) it crashes the player (at least bsplayer 1.805) as a only use it i can't test with others...

AFAIK i didn't change anything from default... and everything being decoded with libavcodec..:confused: :confused:

therealjoeblow

28th February 2004, 19:35

Originally posted by LeQuack
sysKin:

Yes I had, and still have the exact same problem. Playback stutters with overlay mixer, but not with VMR9. Both in xvid and ffdshow decoders. But I think this happened to me even before the 1.0 versions.

Either of the ffdshow-20040227.exe or ffdshow-20040225.exe builds play back choppy for me too in overlay mode, but perfectly smooth with VMR9. Problem is that I can't use ZoomPlayer's onscreen color controls with VMR9 because they appear to be unsupported on ATI Radeons in VMR9 ,ode (ya, I know I can use ffdshow's picture properties, but that's a real pain, since ZP's controls are mapped to one of the buttons on the ATI remotewonder, and the interface is *way* easier to use on a TV screen).

BlindWanderer

1st March 2004, 12:19

was playing a rv20 stream (coming off gabests rm splitter) and getting a crash when enabled Temoporal smooth (set to 3) with color off. No problems if enabling color. oh, and the video output turns green when it crashes.

mikeX

2nd March 2004, 01:15

When seeking in a xvid file (encoded with rc1 or rc2) with this new build I get this (http://www.beingalink.de/files/snap.png).

i remember getting this quite often with xvid files on mplayer-1.0 (pre2 i think, not sure)

hellfred

2nd March 2004, 14:58

Hi Andy2222, how is the your work proceeding?
You were thinking of using ICL compiled obj files and link them together with gcc compiler/linker, weren't you.
But not everything that shines is gold - as a German proverb says.
Read this
http://www.hydrogenaudio.org/index.php?showtopic=18230&
and this:
http://www.warp2search.net/modules.php?name=News&file=article&sid=16416
I found those links on the doom9 forum thread about XVID 1.0 RC3
http://forum.doom9.org/showthread.php?threadid=71803&perpage=20&pagenumber=4
Fist one states that ICL 8.0 optimizes for P4 and therefore performance on non-P4 fall behind. Looks like ICL 7.1 will do a better job there.
The other one is about how to make Intel-spezific optimation of ICL8.0 to work on other SSE2 capable prozessors.

Did you succeed in linking object files form different compilers?
Still looking forward to use your gcc-otimzed filter on my somewhat slow machine.

Hellfred

Andy2222

2nd March 2004, 16:34

Originally posted by hellfred
Hi Andy2222, how is the your work proceeding?
You were thinking of using ICL compiled obj files and link them together with gcc compiler/linker, weren't you.
But not everything that shines is gold - as a German proverb says.
Read this
http://www.hydrogenaudio.org/index.php?showtopic=18230&
and this:
http://www.warp2search.net/modules.php?name=News&file=article&sid=16416
I found those links on the doom9 forum thread about XVID 1.0 RC3
http://forum.doom9.org/showthread.php?threadid=71803&perpage=20&pagenumber=4
Fist one states that ICL 8.0 optimizes for P4 and therefore performance on non-P4 fall behind. Looks like ICL 7.1 will do a better job there.
The other one is about how to make Intel-spezific optimation of ICL8.0 to work on other SSE2 capable prozessors.

Did you succeed in linking object files form different compilers?
Still looking forward to use your gcc-otimzed filter on my somewhat slow machine.

Hellfred

I did not had much time the last week and since Milan seems to change files every 2 days in cvs it make no sence to release a new version yet. I will wait till milan is rdy with his work since we all want working xvid4 stuff. And yes im still working on the object stuff, i had some success using icc under vmware debian and convert the elf files.

And im aware of the ICL8 speed problems, those mainly happens cause of some crazy overoptimization code that is already optimized. Speaking of the auto align and vectorizing features, it seem's also that the compiler place the asm code optimized for p3/4 wich is realy crap for athlon cpu's. But the whole idea behind the obj mixing thing was to simple use heavy coded inline masm style files with gcc. Gcc cant understand those files. Since in the future i bet more masm asm syntax will be integrated its crap to convert/translate all to at&t (u have to understand all the asm code for the convert, no auto convert or sed script will work) so the best way is keep the masm files and find a way to compile them and integrate them and thats what im trying. I bet i prolly wasted to much time on this try rather than simple do some code optimization myself...

So lets see what great work milan does and Athos does a great job releasing the fresh cvs snapshats here. Im trying my best for my crappy release but i realy underestimated the time and work u need to make ffdshow fully gcc compatible and writing new asm code isnt also that easy ...

hellfred

3rd March 2004, 17:07

Hi Andy2222
Out of curiosity i have typed "AT&T asm" into google and found this page:
http://www.delorie.com/djgpp/v2faq/faq17_2.html
Did you know this one?
They claim that there do is a SED script that can handle part of the conversion. You can give it a try, maybe then fussing with the compilers becomes unnecessary.

EDIT: Alas, it can only convert Intel style asm to Unix/AT&T style asm.
Not MASM
EDIT2: Still, go visit the side:

Obtain a copy of Microsoft MASM 6.11. It has a -coff option to generate object code in COFF format which can be submitted to GCC, so you can compile your original source. You can also use the LIB32 librarian from Microsoft C8 to convert object files to COFF by putting them into a .lib library, then extracting them as COFF files. 28 Note that, unless you link the MASM-generated object files with DJGPP's ld (as opposed to Microsoft's LINK /CO command), you won't be able to debug the resulting program, because the debug info is not in correct format. I'm also told that masm doesn't produce sections named ".text" and ".data", so you might need to hex-edit the section names in the object file manually.

Wasn't that the main problem? Linking MASM stuff with gcc?

Andy2222

3rd March 2004, 19:31

yes i know that site, the problem is the diff. handling of local variables in intel and at&t syntax. Sure i can handle simple conversions myself now, but stuff like the asharp filter wont work and need many manual work.
I also own a copy of the latest masm, the problem is not the obj format the problem is how the compiler produce the asm files. VC and ICL created files have total diff. naming conventions and they also miss some sections gcc need. So even if u have a coff file the gcc project cant link those files since it cant find the functionnames and how to handle/identify them.

But im realy close to solve this problem since the icc asm output under linux "nearly" match those from gcc under mingw. There is still a little diff. and icc use some crappy pseudo OP codes in there asm output like ".4bytes" ".2bytes" wich gas under linux understand but gas under mingw dont.

steven_m64

3rd March 2004, 21:20

this build wont decode a video stream with a fourcc of mp4v but the fourcc of MP4V will work.

Andy2222

4th March 2004, 06:07

just some little news,

i just checked the anamorphic encode stuff again. I had a 3ivx (mp4v) file with an anamorphic AR (pixel was 1.94 but real is 2.397) i just used graphedit and set ffdshow to libavcodec and the latest cvs version (+ my AR fixes) had np to extract the correct AR in the VH2. So anamorphic seems to work with libavcodec. (yes i had the 3ivx decoder disabled and pure libav/ffdshow was used)

bond

4th March 2004, 12:20

Originally posted by steven_m64
this build wont decode a video stream with a fourcc of mp4v but the fourcc of MP4V will work. yes, i also reported that a hundred times maybe, but noone seems to want to add mp4v support in again :( (it works with the latest official ffdshow build btw)
edit: looking at the cvs it seems milan added support again for mp4v in the latest sources :)

milan commented mp4v out, because he had to much fourccs used in ffdshow and needed to delete some
well unfortunately he decided to drop mp4v, needed for mp4 and native matroska support for example, and left MP4V in, which is needed for nothing

Originally posted by Andy2222
i just checked the anamorphic encode stuff again. I had a 3ivx (mp4v) file with an anamorphic AR (pixel was 1.94 but real is 2.397) i just used graphedit and set ffdshow to libavcodec and the latest cvs version (+ my AR fixes) had np to extract the correct AR in the VH2. So anamorphic seems to work with libavcodec. (yes i had the 3ivx decoder disabled and pure libav/ffdshow was used)great

Andy2222

4th March 2004, 19:02

btw some1 know a software wich can emulate a p4 + sse2?

I have the little problem that i cant write sse2 stuff since i dont own a sse2 cpu and since im far away from beeing perfect in asm i spend most time debugging and using the register monitor wich comes in VC6. So i need a way to test sse2 code and see what gets in the register's. I think there could be some kind of code simulator or so? maybe some1 know what i mean?

S_O

4th March 2004, 21:39

My ffdshow (27022004) decodes mp4v just fine, with a little trick: Unregister ffdshow.ax, open ffdshow.ax in a hexeditor and replace "MP4V" with "mp4v" everywhere (it´s several times in there) in the file and then register ffdshow.ax. This is not the perfect way, but it works just fine and so it´s a nice temporal solution until it´s fixed in the source.

athos

4th March 2004, 23:15

New build: http://athos.leffe.dnsalias.com/ffdshow-20040304.exe
A little bigger because I included ff_mpeg2enc.dll.
Changes:2004-03-04 17:56 milan_cutka

support for quantizer array exported by xvid

2004-03-03 15:11 milan_cutka

removed xvid's "b frame decoding lag" message, custom quant tables
selection moved to quantization type combobox

2004-03-03 08:46 milan_cutka

write install path for ffdshowEnc

2004-03-03 07:53 milan_cutka

updated vs.net icl project

2004-03-03 07:39 milan_cutka

updated vc6 project

2004-03-02 21:43 milan_cutka

ACM part is working

2004-03-02 18:20 milan_cutka

no message

2004-03-02 18:09 milan_cutka

fixed (?) 422P->RGB conversion

2004-03-02 17:10 milan_cutka

updated vs.net project

2004-03-02 12:22 milan_cutka

by request: horizontal subtitles alignment (just first try)

2004-03-02 09:53 milan_cutka

disabled SSE2 code in libavcodec, disabled quantizer noise shaping
for codecs which don't support it and crash

2004-03-02 08:25 milan_cutka

merged ffdata to ffglobals

2004-03-02 06:13 milan_cutka

working on VFW encoding

2004-03-02 06:01 milan_cutka

b frames seeking fix

2004-03-01 21:25 milan_cutka

updated mingw makefiles (thanks to Laurent Pinchart)

2004-03-01 19:02 milan_cutka

first successful VFW encoding

2004-03-01 15:36 milan_cutka

no message

2004-03-01 15:28 milan_cutka

working on VFW interface to ffdshow

2004-03-01 14:31 milan_cutka

third column in Codecs page: supported FOURCCs

2004-03-01 13:30 milan_cutka

VFW related cleanups

2004-03-01 08:15 milan_cutka

translate only buttons and static controls

2004-03-01 07:57 milan_cutka

updated vc6 project

2004-03-01 06:48 milan_cutka

merging settingsClass and valName macro parameters, fix for
language selection in GUI

2004-03-01 06:04 milan_cutka

enabled mp4v FOURCC

2004-02-29 18:06 milan_cutka

can be compiled using icl 8.0

2004-02-29 13:33 milan_cutka

fixing non-black image borders, fixed two mpeg2enc encoding bugs,
by request: OSD presets (can be cycled by pressing
CTRL+SHIFT+ALT+O)

2004-02-27 16:19 milan_cutka

translation fixes

2004-02-27 15:11 milan_cutka

no message

2004-02-27 15:11 milan_cutka

fixes crash when libavcodec isn't available

2004-02-27 14:41 milan_cutka

updated installer script (docs files from ffvfw)

2004-02-27 14:34 milan_cutka

libavcodec quantizer noise shaping (when encoding)

bond

4th March 2004, 23:30

thanks athos :)

mp4v support is finally back (when divx4 is enabled?)

anyways when ticking overlay mixer2 the mp4v doesnt seem to be enabled anymore, meaning ffdshow isnt used in the graph (when i untick om2 it works again)

Blight

5th March 2004, 00:56

Bond:
why are you enabling overlay mixer, unless you're using WMP 6.4, there's absolutely no reason to enable it. It can only cause instability with players that set their own rendering filters.

ChristianHJW

5th March 2004, 08:20

Originally posted by Blight Bond:
why are you enabling overlay mixer, unless you're using WMP 6.4, there's absolutely no reason to enable it. It can only cause instability with players that set their own rendering filters. .... for matroska AR correction, Gabest refuses to implement track header reading from MPC, like zoomplayer and TCMP are doing, he's calling it 'madness' and asked us to push DivX Networks to support VIDEOINFOHEADER2 in their decoder. With only 2 major player reading AR directly, i am afraid to say that enabling overlay in ffdshow is still necessary it seems :( ....

bond

5th March 2004, 09:14

yes because of AR correction (also with .mp4)
bsplayer also doesnt seem to be able to use om2 on itself :(

MarkCoolio

5th March 2004, 10:55

Do I understand it right that FFVfw is now included in FFDShow?

I have seen no new build of ffvfw since October and since I installed the latest ffdshow version I saw that I can encode with ffdshow encoder now with apps like virtualdub etc.

So in future there will only be one installer for both parts, i.e. ffshow and ffvfw?

Thanks for the clearing answer!

athos

5th March 2004, 11:41

Originally posted by MarkCoolio
Do I understand it right that FFVfw is now included in FFDShow?

I have seen no new build of ffvfw since October and since I installed the latest ffdshow version I saw that I can encode with ffdshow encoder now with apps like virtualdub etc.

So in future there will only be one installer for both parts, i.e. ffshow and ffvfw?

Thanks for the clearing answer!

Yes, milan has been working on integrating, so to speak, ffvfw in ffdshow. has anyone tried encoding with the latest build?

Arcon

5th March 2004, 16:01

ffdshow-20040304 still crashes if i enable chroma deringing in the pp.

iradic

5th March 2004, 19:10

where can i find some info about ffvfw's gui...

in vdub there ffvfw doesn't show...

on my comp preset auto-load doesn't work (crashes every ffdshow i had), can i get some reply about is this working for others (e.g. you)...

thanks...

arno

6th March 2004, 12:13

Originally posted by Arcon
ffdshow-20040304 still crashes if i enable chroma deringing in the pp.

Same here (with Nic's postprocessing). And it's still so damn slow on my 1.2GHz Duron. Maybe the other guy (Kuros?) that compiled a version before that works perfectly for me, can compile a new one. Just to fill the gap between now and when Andy releases his build.

Blight

6th March 2004, 17:11

ChristianHJW:
Gabest is right, implemeting it in the header is wrong. But in either case, enabling overlay mixer in ffdshow can clash with Zoom Player which adds Overlay Mixer on it's own by default.

kilg0r3

7th March 2004, 11:58

Hi there,
Since Google didn't turn up any result for "spp deblocking" , I dare to ask the question here. What exactly is it?

Coud it be that it tries to cover blocks by adaptively adding noise. If so this were great idea, which, I think has already been implemented by On2. Which is one of the reasons, why their codec looks so very good.

jk888

7th March 2004, 15:31

ffdshow produces artifacts in videos encoded with Xivd SixOfNine-HVS custom matrices. When the video is viewed using Xvid decoder no artifacts appear, but once I used the latest ffdshow 03042004 then I see artifacts. Please refer to this post for details:

http://forum.doom9.org/showthread.php?s=&threadid=72199

Didée

7th March 2004, 15:51

jk888,

don't want to dimish your enthusiasm, but that problem is known for a pretty LONG time now ...

- it's not the fault of ffdshow. It's the fault of the underlying libavcodec routines, hence the ffmpeg-guys will have to look into it, not those who code ffdshow!

- it's not the fault of that specific matrix you mention. The problem occurs with every matrix that contains values <16 for the (inter) DC component in it.

- we all love the speed at which ffdshow decodes streams - currently no other decoder can reach ffdshow in that aspect. I assume that a good part of this speed advantage comes from some simplified assumptions within the decoding routines in ffdshow, so ... you have to pay a price, one way round, or another.

- Didée

RedDwarf69

7th March 2004, 20:21

Originally posted by kilg0r3
Hi there,
Since Google didn't turn up any result for "spp deblocking" , I dare to ask the question here. What exactly is it?

Coud it be that it tries to cover blocks by adaptively adding noise. If so this were great idea, which, I think has already been implemented by On2. Which is one of the reasons, why their codec looks so very good.

I found something in google when was released in ffdshow (one or two weeks ago?). Was a discursion about using it in mplayer, but...
Seems that is a better PP alghoritm, but that needs a matrix used in the encode, and if this matrix was not passed (I don't really understad how this matrix is passed) then the resulted image was very blurred....I tried with ffdshow and certainly the image was veeeeeeeery blurred, then not tried anymore.

If you search for "mplayer" or "libavcodec" SPP you probably will find something more in google.

ADLANCAS

8th March 2004, 03:37

Sorry if this bug is already written somewhere in this thread, but I haven´t found in my search.

I´m trying to use VirtualVCR with ffdshow to filter during capture.
The only version that "works" is ffdshow-20030523. I´ve tested all versions (in Athos site) from this date and crashes in ffdshow.ax.
I said that version from april "works" because after my tests with success I disabled ffdshow but in someway it continue to works. For example, I captured using 704x480 and resize in ffdshow to 352x480. After that I disabled ffdshow but resizes still working! The only way to make VirtualVCR works correctly again was to unninstall ffdshow.
Is there a way to fix?

Thanks for any help.

athos

12th March 2004, 20:28

New build: http://athos.leffe.dnsalias.com/ffdshow-20040312.exe

Changelog:2004-03-11 18:46 milan_cutka

updated vs.net project

2004-03-11 15:16 milan_cutka

changed colorspace info handling, few fixes, updated libmpeg2

2004-03-11 05:47 milan_cutka

simple resize fix

2004-03-10 15:38 milan_cutka

no message

2004-03-10 14:48 milan_cutka

hungarian translation by Camelot <amorpheus at freemail dot hu>

2004-03-10 14:35 milan_cutka

support for AVIS

2004-03-10 13:16 milan_cutka

VFW wmv9 decoding

2004-03-10 12:06 milan_cutka

fix in writeAVI in ff_wmv9

2004-03-10 06:31 milan_cutka

working on show/hide filters

2004-03-09 21:52 milan_cutka

"use overlay mixer",findAutoSubflnm2 fixes by Andy <AndiEQ at gmx
dot de>

2004-03-09 19:41 milan_cutka

no message

2004-03-09 19:41 milan_cutka

updated vs.net project, updated mingw makefile

2004-03-09 15:52 milan_cutka

working on show/hide filters

2004-03-09 11:28 milan_cutka

basic VFW decoding (still much to do)

2004-03-09 08:30 milan_cutka

updated vs.net icl project

2004-03-09 08:17 milan_cutka

updated mingw makefiles

2004-03-09 08:17 milan_cutka

compiles, updated vc6 project

2004-03-09 06:33 milan_cutka

working of VFW decoding (ffdshow can't be compiled now)

2004-03-08 18:31 milan_cutka

simplification of sup_xxx macros

2004-03-08 15:24 milan_cutka

remote control API disabled by default + GUI control to enable it

2004-03-08 12:28 milan_cutka

updated libvavcodec, very basic palette handling in ffdshow

2004-03-08 09:18 milan_cutka

lossless JPEG support (RGB32 encoding disabled)

2004-03-08 07:44 milan_cutka

updated jpeg quality settings

2004-03-07 13:42 milan_cutka

few resize fixes

MfA

12th March 2004, 21:46

Strange that Michael chose to add SPP into mplayer instead of ffmpeg. This (http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/libmpcodecs/vf_spp.c?rev=1.18&content-type=text/x-cvsweb-markup) is the implementation of the post processing filter.

The original papers suggest the quantization matrix used during encoding should be used during the post processing, at the moment the code uses a single threshold though ... which would be equivalent to H263 quantization. Custom quant matrices which mess with the first weight in the matrix will probably cause the most trouble.

Slave01

13th March 2004, 10:02

Hi guys, i whish to join into the developer comunity of ffdshow project. Where can i find source code?

Thanks

Slave01

bond

13th March 2004, 12:03

overlay mixer2 handling has been fixed now :)
but
ffvfw still doesnt show up in vdm and
mp4 automatic ar resizing also doesnt work :(

dragongodz

13th March 2004, 12:10

1 thing i noticed about previous version (...0304.exe) was if you installed to a path with a space in it (such as program files) vfw didnt show up. if however you install to a path without a space(c:\ffdshow\) it shows up fine.

Andy2222

13th March 2004, 12:14

Originally posted by bond
overlay mixer2 handling has been fixed now :)
but
ffvfw still doesnt show up in vdm and
mp4 automatic ar resizing also doesnt work :(

Im sure it will get fixed in the next version, my email to milan about the bugfix for the overlay/AR thing leaked some deeper help so some little code was missing. I hope my last mail was more helpfull and he will implement the fix in the next version istn realy a big thing just 2 lines of code.

PS: The "findAutoSubflnm2 fixes" was the fix for the crashes if u try call "configure" out of other programms like zoomplayer. U should be able to configure ffdshow normal now without crash.

bond

13th March 2004, 12:17

Originally posted by dragongodz
1 thing i noticed about previous version (...0304.exe) was if you installed to a path with a space in it (such as program files) vfw didnt show up. if however you install to a path without a space(c:\ffdshow\) it shows up fine. can be the case here too as i install in such a space directory

Originally posted by Andy2222
Im sure it will get fixed in the next version, my email to milan about the bugfix for the overlay/AR thing leaked some deeper help so some little code was missing. I hope my last mail was more helpfull and he will implement the fix in the next version istn realy a big thing just 2 lines of code. great :)

Andy2222

13th March 2004, 12:18

Originally posted by Slave01
Hi guys, i whish to join into the developer comunity of ffdshow project. Where can i find source code?

Thanks
Slave01

The main stuff is done my Milan and Athos release the compiles. If u want help contact Milan <cutka@szm.sk>

Im not sure if he needs some help atm, but if u are a skilled asm (SSE/MMX) coder there is some stuff to do :)

The project page is here http://sourceforge.net/projects/ffdshow/
use the cvs for the latest code.

PS: if u have some asm skills u can prolly help me with some stuff, just leave me a pm here.
We also need some1 to help fix that crazy chroma bug in the mplayer resizer. I realy tryed hard but i leak the deeper decompression/resizer knowledge.

Slave01

13th March 2004, 15:37

:) Oh thank you! Yes but i have to study the source before.

Slave01

athos

13th March 2004, 16:17

LigH

13th March 2004, 16:49

I can agree here somehow: In a german Windows, the programs folder is called "Programme" - here it works fine, an "ffdshow Video Codec" appears.

To remind myself: I'll have to check if the "Orange blue" bug (increasing color distortions in slow motion for movies encoded with DivX before 5.03) was already fixed...

gitoshi

13th March 2004, 19:59

as posted before by sysKin
-----
I was working on this XviD directshow problem recently.
In short: playback is not fluent with overlay mixer but is fluent with VMR9 mixer. When I was working on it, I discovered that ffdshow (latest build compiled by Athos) has exactly the same problem.

solution:
http://forum.doom9.org/showthread.phps=&postid=450683#post450683
------

I still have the same problem with all build since the 20040225 one. If your player use OverlayMixer as default render you can see it. (ex Core Media Player).
In BSplayer or MPC the default render is VMR9.
Here the threat in Core Media Player bug forum.
http://www.corecoded.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=169

You can check this if you play some video , and check the info tab in ffdshow. Decoder FPS jump from 8 to 100. With VRM9 active you see Decoder FPS at 25 with minor variations.

My specs Athlon Xp 2400
Geforce 4 TI 4200 128mb
Win2K DirectX 9.0b

G

Andy2222

13th March 2004, 20:51

Originally posted by gitoshi
as posted before by sysKin
-----
I was working on this XviD directshow problem recently.
In short: playback is not fluent with overlay mixer but is fluent with VMR9 mixer. When I was working on it, I discovered that ffdshow (latest build compiled by Athos) has exactly the same problem.

solution:
http://forum.doom9.org/showthread.phps=&postid=450683#post450683
------

I still have the same problem with all build since the 20040225 one. If your player use OverlayMixer as default render you can see it. (ex Core Media Player).
In BSplayer or MPC the default render is VMR9.
Here the threat in Core Media Player bug forum.
http://www.corecoded.com/modules.php?op=modload&name=PNphpBB2&file=viewtopic&t=169

You can check this if you play some video , and check the info tab in ffdshow. Decoder FPS jump from 8 to 100. With VRM9 active you see Decoder FPS at 25 with minor variations.

My specs Athlon Xp 2400
Geforce 4 TI 4200 128mb
Win2K DirectX 9.0b
G

What exact is the problem? Since all xvid's i watched with ffdshow using libav or org. xvid decoder play just fine with overlaymixer and normal render.

ADLANCAS

13th March 2004, 23:47

It seems that nobody saw my post on 7th march:(

Is here the correct place to post this kind of bug or where could I do that ?

LigH

13th March 2004, 23:54

Yes, bug reports are right here; but there might be questions where no one yet knows an answer; and some questions indeed might have been ignored/overlooked accidently...

gitoshi

14th March 2004, 04:58

@Andy2222:

I'm not talking about the overlay controls in FFDShow.
I talk about the render mode of the player. If the player use Overlay Mixer you get jerky playback.(look like the decoder is droping frames to keep a/v sync)
This problem was solved in Xvid RC3 but remain in FFDShow, I don't think that is a Libavcodec problem, if I select the XVid4 library as decoder in FFDshow codec page I still had jerky playback.
Just check playback with Core Media Player, or with MPC using Overlay Mixer (Options/PlayBack/Output/Video).

G

Blight

14th March 2004, 06:50

Probably not really high priority, but both versions of WarpSharp are completely broken. The standard one seems to be warping the wrong parts of the image while aWarpSharp makes the entire image green.

arno

14th March 2004, 09:42

Originally posted by gitoshi
@Andy2222:

I'm not talking about the overlay controls in FFDShow.
I talk about the render mode of the player. If the player use Overlay Mixer you get jerky playback.(look like the decoder is droping frames to keep a/v sync)
This problem was solved in Xvid RC3 but remain in FFDShow, I don't think that is a Libavcodec problem, if I select the XVid4 library as decoder in FFDshow codec page I still had jerky playback.
Just check playback with Core Media Player, or with MPC using Overlay Mixer (Options/PlayBack/Output/Video).

G

Isn't the jerky playback also not (partially) related to the bad performance of the Athos-builds? It seems that the Athos builds don't seem to work properly (smoothly) on both my P2-500 systeem as well as my AMD Duron 1.2GHz systeem. I'm guessing the VC7++ only compiles proper (speedy) code for Pentium-4 users. Maybe Athos can enlight me (us)...

P.s. : One piece of evidence is the fact that the Kuros build, which was built with VC6 DID work properly on both my systems...

Andy2222

14th March 2004, 17:45

Originally posted by gitoshi
@Andy2222:

I'm not talking about the overlay controls in FFDShow.
I talk about the render mode of the player. If the player use Overlay Mixer you get jerky playback.(look like the decoder is droping frames to keep a/v sync)
This problem was solved in Xvid RC3 but remain in FFDShow, I don't think that is a Libavcodec problem, if I select the XVid4 library as decoder in FFDshow codec page I still had jerky playback.
Just check playback with Core Media Player, or with MPC using Overlay Mixer (Options/PlayBack/Output/Video).

G

I know that u mean the so called overlay mixer render, wich isnt actually the real render. I play all my stuff using the overlaymixer in zoomplayer or Crystal player and i never had problem's with ffdshow and dropping frames or jumping frames u discribe. My framerate is always constant 23.9... or 25.. in zoomplayer and i watch lotsa diff. types of movies (xvid3/4, divx3-5)? So it seems its a hardware/driver dependent problem.

PS: can u post your system stats and ffdshow version + zoomplayer settings? We cant fix bugs if we cant reproduce them...
Did those bug also happend in pure graphedit mode?

Andy2222

14th March 2004, 17:50

Originally posted by arno
Isn't the jerky playback also not (partially) related to the bad performance of the Athos-builds? It seems that the Athos builds don't seem to work properly (smoothly) on both my P2-500 systeem as well as my AMD Duron 1.2GHz systeem. I'm guessing the VC7++ only compiles proper (speedy) code for Pentium-4 users. Maybe Athos can enlight me (us)...

P.s. : One piece of evidence is the fact that the Kuros build, which was built with VC6 DID work properly on both my systems...

As far as i know Athos also use VC6 and CPU Blend options, wich dont optimize that hard for a special cpu. The ICL compiler use several P4/Intel optimizations wich cause problem's on athlon cpu's but are code dependend, so far for my test's it was realy bad using icl for ffdshow + athlon.
For my last speed test's the Athos builds performed oki and i had no big problem's on my athlonxp.

athos

14th March 2004, 18:13

Originally posted by Andy2222
As far as i know Athos also use VC6 and CPU Blend options, wich dont optimize that hard for a special cpu. The ICL compiler use several P4/Intel optimizations wich cause problem's on athlon cpu's but are code dependend, so far for my test's it was realy bad using icl for ffdshow + athlon.
For my last speed test's the Athos builds performed oki and i had no big problem's on my athlonxp.
I use VC6 and Pentium CPU option actually. The flags for gcc (libavcodec, mplayer etc) uses -march=i586 -mcpu=i686 which means it requires at least i586-class cpu (pentium) but if available uses i686 (pentium pro) features. so i thought there would be no meaning in including i486. Should I set to Pentium Pro or back to Blend? I am also thinking of maybe releasing specific processoroptimized builds for Pentium4 and maybe AthlonXP, but maybe I should wait for the code to be a bit more stable, especially Xvid 1.0 compability. At the same time I imagine that the low cpu usage of ffdshow is appealing to those with older cpus, who maybe are using an old computer as a media player.

Andy2222

14th March 2004, 18:26

Originally posted by athos
I use VC6 and Pentium CPU option actually. The flags for gcc (libavcodec, mplayer etc) uses -march=i586 -mcpu=i686 which means it requires at least i586-class cpu (pentium) but if available uses i686 (pentium pro) features. so i thought there would be no meaning in including i486. Should I set to Pentium Pro or back to Blend? I am also thinking of maybe releasing specific processoroptimized builds for Pentium4 and maybe AthlonXP, but maybe I should wait for the code to be a bit more stable, especially Xvid 1.0 compability. At the same time I imagine that the low cpu usage of ffdshow is appealing to those with older cpus, who maybe are using an old computer as a media player.

That all looks oki for me i realy cant see what cause this (jerky) playback for u gitoshi? Since u also have this problem using the org. xvid.dll and not libav, only the mplayer lib and ffdshow is left. U also have this problem if resize is disabled? Can u try use the org. xvid decoder and set the output to yv12 or rgb32 and also using yv12 or rgb32 in ffdshow output?

arno

14th March 2004, 18:35

Originally posted by Andy2222
That all looks oki for me i realy cant see what cause this (jerky) playback for u gitoshi? Since u also have this problem using the org. xvid.dll and not libav, only the mplayer lib and ffdshow is left. U also have this problem if resize is disabled? Can u try use the org. xvid decoder and set the output to yv12 or rgb32 and also using yv12 or rgb32 in ffdshow output?

Some other info (I said it here before but I think it got overlooked):
- The Kuros build fixed the slow-performance problem on both my Duron & Pentium2-500 machine.
- But another problem with the Athos builds: crashing Nic's postprocessing (when enabled ffdshow crashes) was also resolved so I think there's still a problem with the cpu-dependent code generated by your (Athos) compiles. Athos, could you maybe figure out what the difference is between the options you use and the other guy (Kuros) used?

Thanks for listening, guys.

Andy2222

14th March 2004, 19:01

Originally posted by arno
Some other info (I said it here before but I think it got overlooked):
- The Kuros build fixed the slow-performance problem on both my Duron & Pentium2-500 machine.
- But another problem with the Athos builds: crashing Nic's postprocessing (when enabled ffdshow crashes) was also resolved so I think there's still a problem with the cpu-dependent code generated by your (Athos) compiles. Athos, could you maybe figure out what the difference is between the options you use and the other guy (Kuros) used?

Thanks for listening, guys.

mhh the so called "Kuros" releases perform realy bad since the libav/mplayer libs was compiled using VC not gcc, so all asm code is ignored. The normal ffdshow code was using blend/normal options as far as i remember. I also remember just that 1 version from Kuros?
So seems its in the asm code of the mplayer lib or libav lib, it could be the asm color conversion code in the mplayer lib?

Can u test this for me, install Kuros release and save/copy the libmplayer.dll and libavcodec.dll somewhere, than install the Athos 09/2003 build and test if it have jerky playback. Now copy the libmplayer.dll from the Kuros release in the ffdshow dir and test it again.

LigH

14th March 2004, 19:12

Currently, the "orange-blue bug" seems to be fixed in the latest ffdshow build provided by athos (2003-03-12). At least I got new material from the same source without showing that effect. But I still have to check the same old material I used to discover the bug - later...

arno

14th March 2004, 19:49

Originally posted by Andy2222
mhh the so called "Kuros" releases perform realy bad since the libav/mplayer libs was compiled using VC not gcc, so all asm code is ignored. The normal ffdshow code was using blend/normal options as far as i remember. I also remember just that 1 version from Kuros?
So seems its in the asm code of the mplayer lib or libav lib, it could be the asm color conversion code in the mplayer lib?

Can u test this for me, install Kuros release and save/copy the libmplayer.dll and libavcodec.dll somewhere, than install the Athos 09/2003 build and test if it have jerky playback. Now copy the libmplayer.dll from the Kuros release in the ffdshow dir and test it again.

If I do this the jerkiness is 100% certainly fixed. But note that the "Nic's postprocessing" crash still occurs (immidiately), when enabled.

p.s. : Just tried with only replacing either "libmplayer.dll" or "libavcodec.dll", and it seems that the jerkiness is fixed when I only replace "libmplayer.dll". I hope it helps you on what to look for, Andy....

p.s2: I can fix the Nic's postprocessing crash (obviously, I guess) by replacing the ffdshow.ax file with the Kuros one.

Andy2222

14th March 2004, 20:18

Originally posted by arno
If I do this the jerkiness is 100% certainly fixed. But note that the "Nic's postprocessing" crash still occurs (immidiately), when enabled.

p.s. : Just tried with only replacing either "libmplayer.dll" or "libavcodec.dll", and it seems that the jerkiness is fixed when I only replace "libmplayer.dll". I hope it helps you on what to look for, Andy....

p.s2: I can fix the Nic's postprocessing crash (obviously, I guess) by replacing the ffdshow.ax file with the Kuros one.

oki can u now do some more for me :)

What CPU flags are displayed (wich cpu options ffdshow thinks u have) in the ffdshow "Info" page for both of your CPU's (MMX, MMXEXT, SSE...)
I think i have a clue what crashes nic's and produce that jerky playback for your cpu's.

arno

14th March 2004, 20:31

Originally posted by Andy2222
oki can u now do some more for me :)

What CPU flags are displayed (wich cpu options ffdshow thinks u have) in the ffdshow "Info" page for both of your CPU's (MMX, MMXEXT, SSE...)
I think i have a clue what crashes nic's and produce that jerky playback for your cpu's.

Glad to do so ;-).... CPU options enabled:

All (MMX, MMXEXT, SSE, 3DNOW, 3DNOWEXT) except "SSE2". This is on my Duron machine, the other machine the P3-500 is at work so I can't test this right now...

Andy2222

14th March 2004, 21:46

Originally posted by arno
Glad to do so ;-).... CPU options enabled:

All (MMX, MMXEXT, SSE, 3DNOW, 3DNOWEXT) except "SSE2". This is on my Duron machine, the other machine the P3-500 is at work so I can't test this right now...

There are 2 revs. model 7 and 3.

Can u check what Model u have 3 or 7 and what wcpuid tool shows for support?
wcpuid http://cgi2.tky.3web.ne.jp/~nrklv/cgi-bin/softdl.cgi?wcpu31a.exe

Arska

15th March 2004, 02:20

Originally posted by dimzon
Bug found at resize feature!

Seems like FFDShow does'nt keep original aspect ratio!
When I use 20030523 bild it work's fine!
I have 720*304 video
I set resize to 800*600 (my VideoCard does'nt work properly when width not mod 32)
Under 20030523 i got nice LETTERBOXED (black zones ot top and bottom) image with width scaled to 800 and video height is scaled proportionaly original aspect ratio (no aspect ratio changed)

Under last athos bild i got scaled to 800*600 image with aspect ratio changed to 4:3 (no letterboxing)

I just tried ffdshow-20040312.exe, and this resize bug still exists (i.e. 'keep original aspect ratio' doesn't work, instead it seems to do exactly the same as 'no aspect ratio correction').

gitoshi

15th March 2004, 04:52

ok here my specs
main system
Athlon Xp 2400 (T-Bred core)
Geforce 4 TI 4200 128mb
Win2K DirectX 9.0b
MMX, MMXEXT, SSE, 3DNOW, 3DNOWEXT
CPU 20-30% during play back no PP.

secondary system
Celeron 1Ghz (Tualatin core)
Intel 815
Win2K DirectX 9.0b
MMX, MMXEXT, SSE
CPU 60-70% during play back no PP.

FFdshow 20040312
ZoomPlayer 3.31 fresh install everything default
same problem. If I use VRM9 in ZP the jerky disappear.

Both system are non-SSE2.

G

pd: Where I get Kuros ffdshow build??

arno

15th March 2004, 08:08

Originally posted by Andy2222
There are 2 revs. model 7 and 3.

Can u check what Model u have 3 or 7 and what wcpuid tool shows for support?
wcpuid http://cgi2.tky.3web.ne.jp/~nrklv/cgi-bin/softdl.cgi?wcpu31a.exe

I can't check it for my home computer right now (the Duron one) as I'm at work. But for the P3-500 Machine (machine@work) this is the info:
CPU options enabled (ffdshow): MMX, MMXEXT & SSE
WCPUID info: Intel Pentium III, Family=6, Model=7, Stepping ID=3, MMX & SSE supported.

MarkCoolio

15th March 2004, 10:23

Has some had this problem too?:

Since 2 or 3 versions of ffdshow if I install it and NOT choose to let it decode mpeg video and audio at all, I get no sound anymore when trying to play such files...

I have installed the Cyberlink DVD decoder filters and all works well when not having installed ffdshow. But if it is installed, I get no sound.

Any ideas?

bond

15th March 2004, 11:15

does ffdshow read out the "decoderConfigDescriptor"?

kilg0r3

15th March 2004, 11:20

Is there any possibility to include ffdshow as preprocessor in the vfw encoding chain, e.g. with xvid?

Neo Neko

15th March 2004, 11:26

only in combination with Avisynth.

MarkCoolio

15th March 2004, 11:34

Originally posted by MarkCoolio
Has some had this problem too?:

Since 2 or 3 versions of ffdshow if I install it and NOT choose to let it decode mpeg video and audio at all, I get no sound anymore when trying to play such files...

I have installed the Cyberlink DVD decoder filters and all works well when not having installed ffdshow. But if it is installed, I get no sound.

Any ideas?

Edit: this only seems to appear with Windows Media Player 9 (maybe lower versions too...). In Zoom Player, MPC, etc. it works.

kilg0r3

15th March 2004, 12:10

Originally posted by Neo Neko
only in combination with Avisynth.
What I tried so far is to use Directshowsource. I expected ffdshow to then load automaticaly, which it didn't. I does not have anything to do with the avisynth setting in ffdshow, does it?

bill_baroud

15th March 2004, 20:11

you have to enable "raw video" in ffdshow i think. Then it's loaded everytime a video is rendered throught Directshow.

Honza

16th March 2004, 19:37

I have problem with new versions of ffdshow. The last version which work good was ffdshow-20040113. Newer versions crashes, when i activate dering with Nic´s method of postprocessing.

I use media player classic 6.4.7.6

arno

16th March 2004, 19:55

Originally posted by Honza
I have problem with new versions of ffdshow. The last version which work good was ffdshow-20040113. Newer versions crashes, when i activate dering with Nic´s method of postprocessing.

I use media player classic 6.4.7.6

This is a known problem -> I suffer from the same problem. Furthermore you probably also experience stuttering (bad performance). Currently (as far as I know) Andy is looking into this issue and I hope he can fix it.

arno

16th March 2004, 20:16

Originally posted by arno
I can't check it for my home computer right now (the Duron one) as I'm at work. But for the P3-500 Machine (machine@work) this is the info:
CPU options enabled (ffdshow): MMX, MMXEXT & SSE
WCPUID info: Intel Pentium III, Family=6, Model=7, Stepping ID=3, MMX & SSE supported.

Ok Andy, just got the info from my home machine (Duron 1.2 GHz) aswell:
CPU options enabled (ffdshow): MMX, MMXEXT, SSE, 3DNow, 3DNowExt
WCPUID info:
AMD Duron (model 7).
Standard: Family=6, Model=7, Stepping ID=1.
Extended: Family=7, Model=7, Stepping ID=1.
MMX & SSE supported.

I hope it helphs (Andy).

Andy2222

17th March 2004, 11:33

Originally posted by arno
Ok Andy, just got the info from my home machine (Duron 1.2 GHz) aswell:
CPU options enabled (ffdshow): MMX, MMXEXT, SSE, 3DNow, 3DNowExt
WCPUID info:
AMD Duron (model 7).
Standard: Family=6, Model=7, Stepping ID=1.
Extended: Family=7, Model=7, Stepping ID=1.
MMX & SSE supported.

I hope it helphs (Andy).

just to be sure does WCPUID show that both of your machines are "MMX+" supported? Since u just wrote "MMX & SSE".

arno

17th March 2004, 11:43

Originally posted by Andy2222
just to be sure does WCPUID show that both of your machines are "MMX+" supported? Since u just wrote "MMX & SSE".

Pentium 3 machine:
Supported: MMX & SSE (meaning eg. MMX+ is NOT supported).

For my AMD Duron machine I have to get back to you tonight (when I'm home).

Andy2222

17th March 2004, 12:06

Originally posted by arno
Pentium 3 machine:
Supported: MMX & SSE (meaning eg. MMX+ is NOT supported).

For my AMD Duron machine I have to get back to you tonight (when I'm home).

Oki thats the problem than, seems ffdshow thinks u have MMX+ but u dont have and that crash Nic's dering since it needs MMX+. If that is also the case for your Duron than its a bug in the Runtime CPU detection code of the mplayer lib or ffdshow function return.

hellfred

17th March 2004, 14:02

Originally posted by arno
Pentium 3 machine:
Supported: MMX & SSE (meaning eg. MMX+ is NOT supported).

That is strange. I, too, have a Pentium 3@550mHz. It is a Katmai type, so the first incarnation of the PIII, as far as i know.
And i think it does support MMXext, though wcpuid does tell me it does not, too. I will examine the intel homepage.

Hellfred

hellfred

17th March 2004, 14:40

Now i am completely confused.
On the intel homepage it looks like there is no distinction
between MMX and MMXext / MMX2.
Google did not really help, too.

Under linux mplayer detects this feature set for my CPU:
MPlayer dev-CVS-040129-17:38-3.2.3 (C) 2000-2004 MPlayer Team

CPU: Intel Pentium III Katmai/Pentium III Xeon Tanner 549.0 MHz (Family: 6, Step
ping: 3)
Detected cache-line size is 32 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE

Under windows, the win32 port of mplayer however does not find the MMX2.

/proc/cpuinfo says
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 3
cpu MHz : 548.545
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 1094.45

Hellfred

Andy2222

17th March 2004, 15:00

A realy strange problem, since i was also thinking that a P3 has MMX2/Ext, but if nic's dering realy crash ffdshow than it dont have mmx2... its prolly cause of the "pshufw" command wich is indeed a mmx2 command.

I also tryed get some info from the Intel side but all it say's is p3 has SSE and MMX (but not if its mmx + the 15 new mmx2 commands...)

All kinda strange but i think normal the WCPUID tool is 100% correct since that programm is out for a while.

PS: As far as i know the new mmx ext commands (or mmx2) was first introduced with the SSE1 commands or im wrong? Im confused now too...

found this site: http://www.tommesani.com/MMXLatency.html#Latency

here the pshufw command is listed for a P3 so the duron and p3 "should" have mmx2 and they should not crash using nic's dering...

hellfred

17th March 2004, 16:57

Originally posted by Andy2222
A realy strange problem, since i was also thinking that a P3 has MMX2/Ext, but if nic's dering realy crash ffdshow than it dont have mmx2... its prolly cause of the "pshufw" command wich is indeed a mmx2 command.

I also tryed get some info from the Intel side but all it say's is p3 has SSE and MMX (but not if its mmx + the 15 new mmx2 commands...)

All kinda strange but i think normal the WCPUID tool is 100% correct since that programm is out for a while.

PS: As far as i know the new mmx ext commands (or mmx2) was first introduced with the SSE1 commands or im wrong? Im confused now too...

found this site: http://www.tommesani.com/MMXLatency.html#Latency

here the pshufw command is listed for a P3 so the duron and p3 "should" have mmx2 and they should not crash using nic's dering...

Here is another one:
http://www.gamasutra.com/features/wyatts_world/19990528/pentium3_01.htm

What is all the fuss about with the Pentium III?

This new processor contains 70 new multimedia instructions, or "Streaming SIMD Instructions" as Intel would like them to be called. Some of these new SIMD (Single Instruction Multiple Data) instructions provide an extension to MMX, and like the existing MMX instructions, they are integer-based
Can you provide me with a small program just checking the relevant pshufw command? Then i will run it on my PIII. Just something like pushing some data in one Registry and afterwards checking the content of it. Maybe you can write something like this in an instant?

Hellfred

arno

17th March 2004, 19:15

Originally posted by Andy2222
A realy strange problem, since i was also thinking that a P3 has MMX2/Ext, but if nic's dering realy crash ffdshow than it dont have mmx2... its prolly cause of the "pshufw" command wich is indeed a mmx2 command.

I also tryed get some info from the Intel side but all it say's is p3 has SSE and MMX (but not if its mmx + the 15 new mmx2 commands...)

All kinda strange but i think normal the WCPUID tool is 100% correct since that programm is out for a while.

PS: As far as i know the new mmx ext commands (or mmx2) was first introduced with the SSE1 commands or im wrong? Im confused now too...

found this site: http://www.tommesani.com/MMXLatency.html#Latency

here the pshufw command is listed for a P3 so the duron and p3 "should" have mmx2 and they should not crash using nic's dering...

Just checked my home computer (the AMD Duron one) and this is the additional information you requested about it (WCPUID):
Supported: MMX, SSE, MMX+, 3DNOW & 3DNOW+

Seems that only SSE2 is NOT supported in that machine. It's also odd because that would mean that the problem is not MMX+ related..

IMPORTANT NOTE (Andy): Note that the Nic's postprocessing bug (like the slow-performance problem) were introduced at the exact point where Athos started making the unofficial ffdshow-builds. It still think it's a compile(r) issue....

NOTE2: It seems that the current Athos build does run partially on my P3-500 (although it still crashes sometimes. On my Duron it always crashes...

jk888

18th March 2004, 03:40

Ok maybe I'll shout it out to get some response, "FFDSHOW DOES NOT SUPPORT PLAYBACK OF XVID CUSTOM MATRICES SIXOFNINE-HVS". We did multiple rounds of testing in the Xvid forum with screenshots and video clips, check here:
http://forum.doom9.org/showthread.php?s=&threadid=72199

The Xvid decoder plays movies encoded with the SixOfNine-HVS matrices without problems, but when we used the ffdshow decoder it plays with artifacts in the video. Both the older stable version of ffdshow and the latest build does not support it.

PLEASE FIX!!!

Andy2222

18th March 2004, 09:24

Originally posted by jk888
Ok maybe I'll shout it out to get some response, "FFDSHOW DOES NOT SUPPORT PLAYBACK OF XVID CUSTOM MATRICES SIXOFNINE-HVS". We did multiple rounds of testing in the Xvid forum with screenshots and video clips, check here:
http://forum.doom9.org/showthread.php?s=&threadid=72199

The Xvid decoder plays movies encoded with the SixOfNine-HVS matrices without problems, but when we used the ffdshow decoder it plays with artifacts in the video. Both the older stable version of ffdshow and the latest build does not support it.

PLEASE FIX!!!

There is no real "ffdshow decoder" ffdshow use the libavcodec or can use the xvid3/4 decoder's if installed.
So those playback bugs appeer with playback set to libavcodec or xvid in ffdshow? If they appeer with libavcodec can u check if the mplayer also produce those errors?

thx

"NOTE2: It seems that the current Athos build does run partially on my P3-500 (although it still crashes sometimes. On my Duron it always crashes..."

i dont think its Athos fault, ffdshow still has many little bug's. I will compile soem test files for you to get an idea why those nic's and jerky playback appeer for u 2 since it never happend for me. Just check your pm's later.

nadlabak

18th March 2004, 12:05

jk888:
What exactly have you not understood in Didée's response to your first post?
http://forum.doom9.org/showthread.php?postid=455119

Kurosu

18th March 2004, 14:11

Originally posted by Didée
- it's not the fault of ffdshow. It's the fault of the underlying libavcodec routines, hence the ffmpeg-guys will have to look into it, not those who code ffdshow!

- it's not the fault of that specific matrix you mention. The problem occurs with every matrix that contains values <16 for the (inter) DC component in it.
Noticing this recurrent problem, I'm taking some time to discuss it. Looking at a document which I can't identify clearly (MPEG-4 Video Verification VM17.0), I see that Annex J, "encoder complexity reduction based on intelligent pre-quantization", we have this formula for MPEG-4 quantization of non-intra blocks:
coeff(u,v) = sign(F(u,v) * ( (16*|F(u,v)|)//w[u][v] ) / (2*QP)
with: - F(u,v) non-quantized and coeff(u,v) quantized DCT coeff
- w non-intra quantizer matrix
- QP quantizer step
This document states that "to guarantee that all coeff(u,v)=0, we have |F(u,v)|<2*QP"
To me, this means 16/W[u][v]=<1, hence W[u][v]>=16. I couldn't find a clear proof of that, but it would mean that ffmpeg isn't buggy. It would only follow (was: only follows) the standard, and the said matrix would be (was: is) "beyond specs".

The implication on the validity of 6of9 matrix (for instance) isn't immediate, but still, it was worth mentionning that point.

jk888

18th March 2004, 14:18

Nope I don't understand what Didée said before, but now I kinda do. So it has nothing to do with ffdshow? How do I let the libavcodec team and the ffmpeg team know about this?

I tested it and found that artifacts only appear when I select libavcodec. I don't use Mplayer, it's for linux isn't it? I only have a windows platform right now.

Sharktooth

18th March 2004, 14:24

Originally posted by Kurosu
Noticing this recurrent problem, I'm taking some time to discuss it. Looking at a document which I can't identify clearly (MPEG-4 Video Verification VM17.0), I see that Annex J, "encoder complexity reduction based on intelligent pre-quantization", we have this formula for MPEG-4 quantization of non-intra blocks:
coeff(u,v) = sign(F(u,v) * ( (16*|F(u,v)|)//w[u][v] ) / (2*QP)
with: - F(u,v) non-quantized and coeff(u,v) quantized DCT coeff
- w non-intra quantizer matrix
- QP quantizer step
This document states that "to guarantee that all coeff(u,v)=0, we have |F(u,v)|<2*QP"
To me, this means 16/W[u][v]=<1, hence W[u][v]>=16. I couldn't find a clear proof of that, but it would mean that ffmpeg isn't buggy. It only follows the standard, and the said matrix is "beyond specs".

The implication on the validity of 6of9 matrix (for instance) isn't immediate, but still, it was worth mentionning that point.
Really interesting. You may be right. I'll search for more on the web/newsgroups.

MfA

18th March 2004, 22:17

Kurosu, that section is NOT a normative part of the standard. Nothing in the normative part of the standard prohibits values lower than 16.

Kurosu

18th March 2004, 23:46

Originally posted by MfA
Kurosu, that section is NOT a normative part of the standard. Nothing in the normative part of the standard prohibits values lower than 16.
This is an annex, yes indeed.

But that wasn't my point: please note the use of the conditionnal. I was just pointing out a strange coincidence.

MfA

19th March 2004, 00:23

Okay let me then just point out that you were conditionally wrong :) Nothing in the normative part of the standard prohibits weights smaller than 16.

Kurosu

19th March 2004, 00:34

Shall I put conditionnal tense everywhere to get my point straight?
Edit2: This sentence was written with MfA's post in mind, prior to his editing. So it shouldn't have been so flaming. My apologies.

I still agree nothing (was: clearly) forbids the use of values below 16.

Now, that discussion won't solve any bugs, so I'll leave it to that point: the 'bug' occurs when an hypothesis of the optimization in that annex isn't true anymore. Such coincidence was worth mentionning IMHO.

MfA

19th March 2004, 01:08

Clear doesnt come into it, the standard doesnt forbid values below 16 period.

Coroner

19th March 2004, 01:43

Please could you stop this argument, it isn't helping anyone. It's annoying to get an email notification only to find out it's people still bickering.

Play nice.

:D

Didée

19th March 2004, 09:17

Trying to look at the problem from a different angle:

Everytime I stumble over a clip that ffdshow doesn't play correctly, due to "suspicious" quant matrices, I try to decode the clip

- by XviD itself
- by DivX's DS filter
- by 3ivx's DS filter

And it seems that all of these three are able to decode those streams correctly, and only ffdshow fails. This leads me to a certain assumption ...

BTW, what else decoders one could try? (Capable of B-frames, qpel & GMC)

- Didée

athos

19th March 2004, 12:55

Originally posted by MfA
Clear doesnt come into it, the standard doesnt forbid values below 16 period.
Ok, you have said that many times now, we get it. Nobody disputes it. You are the winner.

But, Kurosu was trying to point out something that he was hoping might explain this bug. If this explains the bug, we might be able to fix it.

How does your repeating of the same, undisputed claim, help with this?

Sirber

19th March 2004, 13:28

Originally posted by Didée
BTW, what else decoders one could try? (Capable of B-frames, qpel & GMC)

- Didée mplayer or VLC :) www.videolan.org

MfA

19th March 2004, 13:37

It means you need file a bug report with only one Michael instead of both ... if ffmpeg indeed "only followed the standard" and the matrices xvid allowed were "beyond specs" then xvid would have wanted to correct it. As much as ffmpeg does not mind fixing bugs in other encoders, xvid likes being standard compliant.

Has anyone verified the same problem occurs with mplayer/vlc yet? If so can anyone put up a small sample for the bug report?

Andy2222

19th March 2004, 13:38

Originally posted by Sirber
mplayer or VLC :) www.videolan.org

I dont think this will work since both player's (mplayer and VLC) also using the libavcodec libary from the ffmpeg project like ffdshow for MPEG4, H263, WMV/A ... playback.
But feel free to test it.

jk888

19th March 2004, 18:05

I tried VLC (using the default settings), and yes it produces the artifacts in the exact same manner as ffdshow.

P0l1m0rph1c

19th March 2004, 22:22

Hmm...even with this new build, ffvfw still desn't show on VirtualDubMod. Installing regular ffvfw works. Anyone having the same behavior?

iradic

19th March 2004, 23:39

read somewhere in forum that ffdshow install path without spaces gives solution to your not showing problem... try and see :)

athos

19th March 2004, 23:51

oh i put up a new build, forgot to post.
i tried to solve the path-problem by adding quotes around the path in the installerscript, but that didnt seem to solve it so i let it go. im guessing milans "Program Files"-equivalent does not contain spaces ;)

Edit: I realized I was using GCC 3.2.3 so I upgraded to 3.3.1. I'm not sure what implications this will have.

P0l1m0rph1c

20th March 2004, 01:43

Yeah, with no spaces it works :)

Another thing....

2004-03-14 18:47 milan_cutka

added support for skal's mpeg4 encoding library

Should skal's codec appear in ffvfw? Or is it just merged?

celtic_druid

20th March 2004, 03:06

Drop skl_drv_mpg.dll in the ffdshow directory and it will show up under the VFW config. No idea if it works, but it does show up.

Ok in my limited one test it worked fine.

LigH

20th March 2004, 09:18

Would have been nice if someone included a link to this DLL - I did not know about it yet. I found the sources on skal's MPEG4 page (http://skal.planet-d.net/coding/mpeg4codec.html), but who has a precompiled Win32 version?

celtic_druid

20th March 2004, 11:32

I have one, but that is only because I compiled it myself. Could give you a link if you really want it?

echo

20th March 2004, 12:20

Encoding with masking enabled does not work at all for me in the latest merged ffdshow/vfw version. It does not matter if the options are checked or not, masking is not used anyway. Also the simulation button in the 2-pass page crashes everything (virtualdub exits with no warnings). Anyone else seeing these?

regards
echo

APF_Gandalf

20th March 2004, 13:37

Originally posted by athos
oh i put up a new build, forgot to post.
i tried to solve the path-problem by adding quotes around the path in the installerscript, but that didnt seem to solve it so i let it go. im guessing milans "Program Files"-equivalent does not contain spaces ;)

looks like an old DOS "8.3" limitation, if you can somehow convert "c:\program files\" to "c:\Progra~1\" (and any "c:\xxxxxxxxxxxxxxxx\" to "c:\xxxxxx~1\") when it's added to the registery, it should work... I guess...

athos

20th March 2004, 13:41

Originally posted by APF_Gandalf
looks like an old DOS "8.3" limitation, if you can somehow convert "c:\program files\" to "c:\Progra~1\" (and any "c:\xxxxxxxxxxxxxxxx\" to "c:\xxxxxx~1\") when it's added to the registery, it should work... I guess...

I'll try this for next builds. I think it is allready done on Win9x platforms, so I'll just have to exchange a few variables.

LigH

20th March 2004, 14:01

@ celtic_druid:

Would be nice - if you can't provide a download address, write a PM to find a way for me to get it; afterwards, I could even host a copy if desired.
__

@ athos:

Using short path names (PROGRA~1) is one option, quoted paths ("Program Files") could be another. But I'm not sure which part of the installation process (script; registry storage) requires which kind of quotation. For path names, I found double quites quite often, but for registry key names, I also spotted single quotes sometimes.

Andy2222

20th March 2004, 20:20

little info:

the "keep org. aspect ratio" bug aka wrong AR in resize mode is finaly FIXED by Milan!

That bug was live since the first 06/2003 release and its finaly fixed :)

Means u now can use that setting again and use resize without getting your AR messed.

Thx so much milan. So the next Athos release will have it fixed too.

Didée

20th March 2004, 20:39

Hooray!

Someone tell ChristianHJW - he insists (http://forum.doom9.org/showthread.php?s=&postid=459765#post459765) on this bug being not there ... (also on the page before)

- Didée

celtic_druid

21st March 2004, 00:34

http://celticdruid.no-ip.com/skl_drv_mpg.7z

gitoshi

21st March 2004, 05:46

I don't know about resize bug (never use before), but the jerky playback remain here when your player use OverlayMixer, everything work fine if the player use VMR9.

G

jk888

21st March 2004, 09:56

small update to the Xvid SixOfNine-HVS matricies issue:

http://forum.doom9.org/showthread.php?s=&postid=461994#post461994

I changed the resolution and target filesize, then areas which are affected by artifacts have changed. Which I think means that the issue isn't related to certain frames.

Andy2222

21st March 2004, 10:15

Originally posted by gitoshi
I don't know about resize bug (never use before), but the jerky playback remain here when your player use OverlayMixer, everything work fine if the player use VMR9.

G

Arno could fix that by just disabling overlay mixer in the player (bsplay) and enabling it in ffdshow, or disable it at all.
For what files ffdshow has this jerky playback for u? Is it also Nic's PP related or always?

gitoshi

21st March 2004, 19:20

Arno could fix that by just disabling overlay mixer in the player (bsplay) and enabling it in ffdshow
Sure, if the player don't use overlay mixer the problem is gone.
For what files ffdshow has this jerky playback for u?
Most of the files show jerky playback. Including old DIVX5.
Is it also Nic's PP related or always?
It is always. Nic PP make no diference.

Also I try usign XVID4 as decoder for FFDSHOW and the problem remain, so I don't think that it is a problem of libavcodec. Look like a problem with the overlaymixer.

@Andy2222.
Did you check my previous posts, I post a link to the same problem in XVID RC1 - RC2 (solved in RC3) (and posible solution , just a line of code). I also post a link to the bug page of CoreMediaPlayer.

G

TripleA

22nd March 2004, 11:52

Originally posted by APF_Gandalf
looks like an old DOS "8.3" limitation, if you can somehow convert "c:\program files\" to "c:\Progra~1\" (and any "c:\xxxxxxxxxxxxxxxx\" to "c:\xxxxxx~1\") when it's added to the registery, it should work... I guess...

For any concerned I can confirm that telling the ffdshow-20040312.exe installer to install to "C:\PROGRA~1\ffdshow" resulted in "ffdshow Video Codec" showing up fine in VDub.

I have no idea if it works or not, though.

bond

22nd March 2004, 22:40

i get choppy playback with any content when i enable the overlay mixer option (meaning overlay mixer2 gets used)

this is surely not related to the source, which is decoded, as i get the same behaviour with the 3ivx decoder (with om2) and gabests realmedia decoder (with om2)

shitowax, meant that this can be fixed on the decoder side and "non-compressed ouput media samples should be always considered as keyframe"

hope this helps :(

timeismoney

23rd March 2004, 03:32

I think just move ffdshow.ax to system dir will be nice, and needn't change progra~1

Andy2222

23rd March 2004, 11:07

Originally posted by bond
i get choppy playback with any content when i enable the overlay mixer option (meaning overlay mixer2 gets used)

this is surely not related to the source, which is decoded, as i get the same behaviour with the 3ivx decoder (with om2) and gabests realmedia decoder (with om2)

shitowax, meant that this can be fixed on the decoder side and "non-compressed ouput media samples should be always considered as keyframe"

hope this helps :(

mhh the question is why just a few have that choppy playback? I tested many ffdshow version's (im using my own atm but also testing Athos version always) and i never ever had choppy playback. I play any kind of divx3-5/3ivx and xvid 3-4 also dvd's and im using zoomplayer and crystal player with and without overlaymixer. But for ffdshow i used overlay mixer1 and 2. Btw whats the difference? I also already used ffdshow as raw filter after the decoder and now using libav for all....

PS: maybe its processor, video card/driver related?

Didée

23rd March 2004, 12:49

Me too suffers from choppy ffdshow playback, and I have no clue what exactly could be the cause, sorry.

But let me report the following wired observations I made:

- it plays smooth when disabling OM in both ffdshow and ZoomPlayer, but that's not the real option.

- with OM on in ffdshow, I usually get choppy playback - but *not always*. Let's say, in 90%-95% after opening a file. Sometimes it just plays smooth ...

- even better: when I activate "resizing" in ffdshow, then playback is mostly smooth (!) - but not always. Let's say, in 90%-95% ...

The last point is the one I don't understand at all: plainly playing a 704*528 XviD through OM plays choppy; if it's additionally resized by ffdshow to e.g. 1280*720, then it plays fluid !?!

I can confirm this ATM for an Athlon XP1800 + ATI 8500DV.

- Didée

Ronin73

23rd March 2004, 13:39

Is the ffdshow from http://athos.leffe.dnsalias.com/ffdshow-20040319.exe
Optimized with asm or is using the slow c routines?

Andy2222

23rd March 2004, 13:52

Originally posted by Ronin73
Is the ffdshow from http://athos.leffe.dnsalias.com/ffdshow-20040319.exe
Optimized with asm or is using the slow c routines?

Athos version's use all optimized inline asm stuff since its a VC6 compile for the ffdshow.ax and he use mingw gcc for the libav/mplayer dll's.

Only a gcc compiled version of ffdshow.ax would not use the asm optimized version's.

I realy have no clue why those choppy playback happens for u... Question: Can some1 confirm that choppy (overlay mixer) playback for nvidia cards or does it just happens with ATI card's?

Can some1 make a link to a short file wich play's choppy and tell me the exact filter config, ffdshow version, player and stuff wich cause that bug? If we cant reproduce that error it's prolly hard to fix.

Slave01

23rd March 2004, 14:23

I have that problem too (xp 1700 + ati 7500). But it is so important using Overlay mixer?
Which are the pros?

Slave01

Didée

23rd March 2004, 16:49

Slave01:

There are several reasons. Many people encode to anamorphic resolutions these days, and you kinda need OverlayMixer to get the correct AR on playback. Then, using OM is most times required to pipe the data as YV12 to the video card, for fastest-possible performance (HDTV resolutions may need every single possible CPU/GPU cycle). Without OM, with normal renderer or VMR9, the performance is not as good, in most cases.

Andy2222:
Have also another machine, with an Intel-Celeron + an ATI card. I'll check if I can reproduce the choppy playback on that configuration. (It's the MM system for my wife, therefore *no problems allowed* ;) , therefore still ffdshow 23-05-2003 ...). Will test that tomorrow.

- Didée

Andy2222

23rd March 2004, 17:58

If u have an Athlon-XP or Pentium3 and those "choppy" playback can u try this testversion for me pls? get it here: http://mitglied.lycos.de/ieggei2/ffdshow/

It has no installer just copy the 3 files into your ffdshow directory.

There are ONLY version's for athlon-xp+ and pentium3+. Pls dont publish this link or lycos will kick me again. (Its just a Testversion to get an idea what cause the choppy playback)

PS: so tell me if it fixed the choppy playback and maybe also gimme feedback on the speed compared to your old version.

Try to use the fixed "keep org. AR settings" button in resize mode and set your player to keep source AR.

bond

23rd March 2004, 21:27

with the overlay mixer problem its important to mention that this bug happens with "overlay mixer2", which is different to "overlay mixer"

Originally posted by Andy2222
Can some1 confirm that choppy (overlay mixer) playback for nvidia cards or does it just happens with ATI card's?i have a nvidia tnt2

Can some1 make a link to a short file wich play's choppy and tell me the exact filter config, ffdshow version, player and stuff wich cause that bug? If we cant reproduce that error it's prolly hard to fix.i am pretty sure that it doesnt depend on the source

as i said i had the problem with xvid (with b-frames with packed bitstream or without) and realvideo content

and

i always had the problem when the decoders used overlay mixer2 (namely ffdshow, 3ivx and gabests realmediasplitter)

maybe shitowax can comment on this problem, as he seemed to have found a way to solve this bug in the 3ivx decoder ;)

Andy2222

23rd March 2004, 21:48

Is there a special reason why u want use overlay mixer2? If i set zoomplayer to costum mode and manualy select the overlay mixer2 as render, i still need select overlay mixer2 in ffdshow and this results in a black screen for me in zoomplayer.

Could it be that bsplay is the only player wich can use overlay mixer2? Since zoomplayer/crystal player and i think mpc all just use OM1?

bond

23rd March 2004, 22:01

well overlay mixer2 is needed for anamorphic encodes and when decoding realvideo with it, it needs far less processor power

Andy2222

23rd March 2004, 22:24

Originally posted by bond
well overlay mixer2 is needed for anamorphic encodes and when decoding realvideo with it, it needs far less processor power

mhhh

MSDN says: "The Overlay Mixer 2 filter is identical to the Overlay Mixer filter, except:

It supports only VIDEOINFOHEADER2 formats."

Since OM1 also support VIH2 u can decode anamorphic as well, dunno why u need OM2 for encodes? Sorry im a total encode noob :)

oki i installed the latest bsplayer and mpc and i could not force to use OM2 over OM1 (i checked the merits and OM2 has indeed a higher merit) but all player installed (bsplayer/zoomplayer/mpc/crystal) all use OM1 in auto mode. I surely set bsplayer to use OM2 but OM1 was still used... How u force your player to use OM2?

"it needs far less processor power"

The only way i could check OM2 was by using graphedit and forced ffdshow to use OM2. I still got no choppy playback (but just tested 2 files) but i tested the CPU usage, but for my Athlon-XP system there is no diff. using OM1 or OM2.

So u realy tested OM2 over OM1 for speed? Im confused now. Since for me OM2 just look like a more compatible mixer for VH2 or player's wich cant correct init OM1+VH2?

bond

23rd March 2004, 22:33

the point is as good as everyone uses "overlay mixer2" when doing anamorphic encodes (even the commercial stuff like 3ivx)
and its buggy

arno

23rd March 2004, 22:38

I get the choppy playback on my Duron 1.2 GHz + ATI Radeon 8500 + BS Player. Note that as far as I know this issue was introduced when the "overlay mixer" option was introduced in ffdshow (although I'm not sure)....

loni_blues

23rd March 2004, 23:42

Hi,

Is there any way to recover ffdshow defaults? Without touching the registry manually, of course.

Thanks for any help,
loni_blues

LigH

23rd March 2004, 23:53

Except "uninstall - reinstall"? Not that I knew...

gitoshi

24th March 2004, 01:05

get the same choppy playback with the test version.
I can reproduce the problem in Celeron 1GHZ (tualatin core)+ Intel 815.

But it is so important using Overlay mixer?
Yes, CoreMediaPlayer only use overlay mixer 2 mode.
Also DVobsub work best with OM2.

G

loni_blues

24th March 2004, 04:31

@ LigH,

I´m sorry and a little ashamed. I´ve just realized that uninstalling - reinstalling did the thing.

Thanks a lot,
loni_blues

dapipa

24th March 2004, 12:51

Originally posted by LigH
Except "uninstall - reinstall"? Not that I knew...

what about saving defaults to file after installing and restoring them when needed?not that it'd help,when you messed up the config already...
:)

Blight

24th March 2004, 17:23

Any reason why Zoom Player should try to use Overlay Mixer 2 if possible? I can probably check the filter to see if it uses VIDEOINFOHEADER2 and then use OM2 and if not use OM1.

Is this a course I should take?

athos

25th March 2004, 11:32

New build today. ffdshow vfw shows up in VirtualDub, I changed it to use the abbreviated win9x path (C:\Progra~1).

Same bat-location, same bat-changelog.

dapipa

25th March 2004, 11:47

Originally posted by Andy2222
If u have an Athlon-XP or Pentium3 and those "choppy" playback can u try this testversion for me pls? get it here: http://mitglied.lycos.de/ieggei2/ffdshow/

hi!i've got an athlon XP and i can confirm,that your build works flawlessly(i think it's the first build after 20030523 which keeps correct AR and hasn't choppy playback,which the latest releases had)...
:)

arno

25th March 2004, 11:51

Originally posted by dapipa
hi!i've got an athlon XP and i can confirm,that your build works flawlessly(i think it's the first build after 20030523 which keeps correct AR and hasn't choppy playback,which the latest releases had)...
:)

I just tried it with BSplayer + overlay mode 2 (mixer) but it still gives me choppy playback on my AMD Duron 1.2GHz (+Radeon8500). Note that I'm not sure where you intended to fix this issue too with this build.

Andy2222

25th March 2004, 14:15

Originally posted by arno
I just tried it with BSplayer + overlay mode 2 (mixer) but it still gives me choppy playback on my AMD Duron 1.2GHz (+Radeon8500). Note that I'm not sure where you intended to fix this issue too with this build.

I played around with some overlay and VH2 settings, but i leak the fully understanding of some parts in ffdshow and some dshow programming skills.

Some1 realy need to mail this bug/issue to milan with some very detailed info's and maybe he can contact shitowax too to fix that.
I realy think this problem is also system/graphic card/directx related?

Problem is i tryed all my xvid/divx files in graphedit and used OM2 and i could not reproduce the choppy playback for my system wich make's me realy useless for fixing that bug.. sorry

shitowax

25th March 2004, 14:50

My understanding of the problem is that:
- it's very related to video card drivers using overlay mixers 2 i.e using VIH2.
- It seems that systems not using overlay mixers like XP or DX9 ones using the new DX9 renderer, don't present this problem.

To fix that, you may have to :
- be sure that all output samples are syncpoints
- be sure of your output timestamps (some splitters don't output either stop or even any timestamp)

If it's not enough, try forcing a discontinuity on all the output samples.

hope that helps.

Originally posted by Andy2222
I played around with some overlay and VH2 settings, but i leak the fully understanding of some parts in ffdshow and some dshow programming skills.

Some1 realy need to mail this bug/issue to milan with some very detailed info's and maybe he can contact shitowax too to fix that.
I realy think this problem is also system/graphic card/directx related?

Problem is i tryed all my xvid/divx files in graphedit and used OM2 and i could not reproduce the choppy playback for my system wich make's me realy useless for fixing that bug.. sorry

CavalloPazzo

25th March 2004, 16:00

In latest build they seems only to work with 2 pass mode (maybe in 1 pass CBR) but not in 1 pass quantizer nor quality mode... In some old build (don't remeber which) instead it worked in these 2 modalities also...mencoder and ffmpeg also ignores that parameter in quality based encoding...I'd really like to encode at constant quantizer with bframe moltiplier actived

Mystiqq

25th March 2004, 16:15

Hi

Ive tryed to get the aWarpSharp to work properly but failed at it.
The screen is green when i turn the aWarpSharp on and changing the chroma mode will just give me different error on screen.
Is there any fix for this?
Anyone here ever got that aWarpSharp to work right?

Thanks in advance.

Cheers...

gitoshi

25th March 2004, 20:01

@shitowax:
To fix that, you may have to :
- be sure that all output samples are syncpoints
- be sure of your output timestamps (some splitters don't output either stop or even any timestamp)

@sysKin
CXvidDecoder::Transform(blahblah)
{
blahblah;
decode_frame_blah(and blah);
more_blah;
if (xvid_frame_type & VOL) { // we had a VOL header, most likely a keyframe
some_more_blah();
pOut->SetDiscontinuity(TRUE); // removing this fixed the problem
}
}

Yeah, the solution has been in page 33 of this threat for years, check sysKin post.

Andy2222

25th March 2004, 20:32

oki i made 2 new test version's to try solve that choppy OM2 playback (just the ffdshow.ax) can some1 test them again with OM2?

get them here:
http://mitglied.lycos.de/ieggei2/ffdshow/

If one or both version's solve the problem pls post wich.

btw can u test the choppy playback with disabled/no audio decoder filters?

thx

PS: i just installed the latest coreMediaPlayer and the player also uses "overlay mixer" and not "overlay mixer2" and all play's fine?
Btw i always use Gabest Avi Splitter and not the MS for playback.

gitoshi

25th March 2004, 21:31

work great no more choppy playback. Celeron 1ghz + Intel 815
install your fix over the last athos version (20040325).

going to test later at home.

G

Andy2222

25th March 2004, 21:33

Originally posted by CavalloPazzo
In latest build they seems only to work with 2 pass mode (maybe in 1 pass CBR) but not in 1 pass quantizer nor quality mode... In some old build (don't remeber which) instead it worked in these 2 modalities also...mencoder and ffmpeg also ignores that parameter in quality based encoding...I'd really like to encode at constant quantizer with bframe moltiplier actived

can u try install the test version's over Athos latest release, milan just added some new 2pass fix 30min's ago wich did not made it to athos version :(

bond

25th March 2004, 21:56

Originally posted by Andy2222
oki i made 2 new test version's to try solve that choppy OM2 playback (just the ffdshow.ax) can some1 test them again with OM2?tried both and both crash in libavcodec.dll :(

Andy2222

25th March 2004, 22:27

Originally posted by bond
tried both and both crash in libavcodec.dll :(

http://mitglied.lycos.de/ieggei2/ffdshow/

try again (compiled them with blend option this time)

and install athos latest release first pls
if libavcodec.dll still crash try the versions from my site (intel or amd)

thx

bond

25th March 2004, 22:39

ok, it doesnt crash anymore but its still jerky

Andy2222

25th March 2004, 22:43

Originally posted by bond
ok, it doesnt crash anymore but its still jerky

... :( oki i give up on this

bond

25th March 2004, 22:47

gitoshi

26th March 2004, 00:32

with TCMP the jerky is gone, some time when you fforward you get jerky for a few seconds. and yes TMCP use OverlayMixer 1 not 2 .

@Bond:
Can you post your spec, (including player) maybe i can reproduce the problem (did you have the lastet Forceware drivers)

G

Andy2222

26th March 2004, 01:27

Originally posted by gitoshi
with TCMP the jerky is gone, some time when you fforward you get jerky for a few seconds. and yes TMCP use OverlayMixer 1 not 2 .

@Bond:
Can you post your spec, (including player) maybe i can reproduce the problem (did you have the lastet Forceware drivers)

G

so my latest testversion's fixed the jerky playback for u?
Did athos latest release still had the jerky playback?

If so can u tell me wich version work better 1 or 2? Since i tryed to fix it by 2 diff. way's and i cant test it myself...

PS: can some1 else with those jerky playback maybe confirm the "semi" fix?

gitoshi

26th March 2004, 02:07

ffdshow_test2 work the best. With test1 I had sometimes jerky playback at the begin or after seek.
Athos last build (20040325) still have jerky playback.

G

bond

26th March 2004, 09:38

Originally posted by gitoshi
with TCMP the jerky is gone, some time when you fforward you get jerky for a few seconds. and yes TMCP use OverlayMixer 1 not 2 .let me repeat again:
the problem doesnt exist with "overlay mixer" but only with "overlay mixer2"
so i very much doubt that the problem was fixed, when you report that it works with om1, as there wasnt any problem with om1 anyways (at least here its that way)

Can you post your spec, (including player) maybe i can reproduce the problem (did you have the lastet Forceware drivers)i never use a media player when i am doing tests, i only use graphedit to be sure that no problem caused by the player kicks in!
also i am using dx9 and have a nvidia tnt2 graphic card

arno

26th March 2004, 10:13

Originally posted by Andy2222
... :( oki i give up on this

Please don't!. It seems that both test1 & test2 fix the jerkyness problem for me!!!

Btw: I also use DirectX9

gabest

26th March 2004, 12:31

After the last post of the previous page this may sound crazy, but I've got this in my mpeg decoder's code ever since it solved a very similar prob for me:
if(GetCLSID(m_pOutput->GetConnected()) == CLSID_OverlayMixer)
pOut->SetDiscontinuity(TRUE);

sbp

26th March 2004, 12:51

Hi I also have this jerky problem with XVID (latest) and ffdshow latest - so Im very interested in a solution.
But I didn't understand the latest post by Gabest - what was he saying? Did he have a solution or??
Steen

gabest

26th March 2004, 13:27

That meant setting every frame to be discontinuity helped me fixing a similar problem with the overlay mixer. I say similar because only the first few seconds were choppy for me.

Andy2222

26th March 2004, 14:05

Originally posted by gabest
After the last post of the previous page this may sound crazy, but I've got this in my mpeg decoder's code ever since it solved a very similar prob for me:
if(GetCLSID(m_pOutput->GetConnected()) == CLSID_OverlayMixer)
pOut->SetDiscontinuity(TRUE);

thats what i tryed in my testversion2 i set:
"pOut->SetDiscontinuity(TRUE);"
"pOut->SetSyncPoint(TRUE);"

in testversion1 i outlined "pOut->SetDiscontinuity(TRUE);"
like in the xvid CXvidDecoder::Transform

@sbp did u tryed my 2 testversion's too? http://mitglied.lycos.de/ieggei2/ffdshow/

Install athos latest first and than just copy the ffdshow.ax in your ffdshow dir and test it, i realy need more input.
I realy dont understand why it solved for one person and not for a other...

PS: strange thing is xvid just removed "pOut->SetDiscontinuity(TRUE)" wich caused the trouble while 3ivx and gabest set them always TRUE for all frames...
Testversion1 try the xvid way while Testversion2 try the 3ivx/gabest way...

kalxas

26th March 2004, 16:14

Greetings everyone!

I used to have choppy playback with the latest TCMP. I had ffdshow-20040325 version installed and I got the same effect. This wasn't a big problem for me as I use only MPC for my videos, which I think is best (and does not give me any choppy playback).
When I saw Andy's post I decided to test his latest builds with TCMP to see if I get any better result. After, overwriting ffdshow.ax file, I got to the same results as Gitoshi (perfect test2 playback and choppy playback with test1 ONLY at the first seconds of the video).

Thanks Andy for making a great job. Don't give it up.

gabest

26th March 2004, 16:51

Originally posted by kalxas
choppy playback with test1 ONLY at the first seconds of the video That's it, setting discontinuity on all frames fixed this for me. I think the overlay mixer has a bug :)

bond

26th March 2004, 17:11

Originally posted by gabest
That's it, setting discontinuity on all frames fixed this for me. I think the overlay mixer has a bug :) i reported a very similar problems some months ago for your realmediasplitter but...

gabest

26th March 2004, 18:42

Really? :o

therealjoeblow

26th March 2004, 22:25

Originally posted by Andy2222
thats what i tryed in my testversion2 i set:
"pOut->SetDiscontinuity(TRUE);"
"pOut->SetSyncPoint(TRUE);"

in testversion1 i outlined "pOut->SetDiscontinuity(TRUE);"
like in the xvid CXvidDecoder::Transform

@sbp did u tryed my 2 testversion's too? http://mitglied.lycos.de/ieggei2/ffdshow/

Install athos latest first and than just copy the ffdshow.ax in your ffdshow dir and test it, i realy need more input.
I realy dont understand why it solved for one person and not for a other...

In installed athos 20040325 build, then your test versions as above with following results:

ffdshow_test1F.zip - plays back choppy from startup, but if I stop and then restart the video (or seek), it plays smooth after that.

ffdshow_test2T.zip - plays smooth right from startup and throughout - WooHoo!! Problem solved (at least for me)

Playback specs - Zoomplayer v-3.20, Standard Media Playback settings, Overlay Mixer enabled.

Exact same results if I use MPC v-6.4.8.1, either with the system avi splitter, or if I enable the built in splitter.

So, it doesn't appear to be either the avi splitter or the player causing the problem (yes, I recognize that's pretty limited testing)

Andy2222

26th March 2004, 22:53

Originally posted by therealjoeblow
In installed athos 20040325 build, then your test versions as above with following results:

ffdshow_test1F.zip - plays back choppy from startup, but if I stop and then restart the video (or seek), it plays smooth after that.

ffdshow_test2T.zip - plays smooth right from startup and throughout - WooHoo!! Problem solved (at least for me)

Playback specs - Zoomplayer v-3.20, Standard Media Playback settings, Overlay Mixer enabled.

Exact same results if I use MPC v-6.4.8.1, either with the system avi splitter, or if I enable the built in splitter.

So, it doesn't appear to be either the avi splitter or the player causing the problem (yes, I recognize that's pretty limited testing)

mhh and u had choppy playback with athos 20040325 build in zoomplayer using overlay mixer1 ? not OM2?
There should be normaly no problem with OM1 in zoomplayer and athos version. If my little fix solved it for u it seems i did not totaly wasted my time on that bug than.

keygen

26th March 2004, 23:03

Anyone know where to get the latest ffdshow's? http://athos.leffe.dnsalias.com/ has been dead for several hours now so latest one I've got is ffdshow-20040319.exe

Andy2222

26th March 2004, 23:08

http://dvd.box.sk/

keygen

26th March 2004, 23:16

thanks :)

athos

27th March 2004, 00:39

Originally posted by keygen
Anyone know where to get the latest ffdshow's? http://athos.leffe.dnsalias.com/ has been dead for several hours now so latest one I've got is ffdshow-20040319.exe
They are also mirrored, among some xvid builds, at http://www.ligh.de/software/mirrors.phtml
doesnt seem to have the latest though.

therealjoeblow

27th March 2004, 00:58

Originally posted by Andy2222
mhh and u had choppy playback with athos 20040325 build in zoomplayer using overlay mixer1 ? not OM2?
There should be normaly no problem with OM1 in zoomplayer and athos version. If my little fix solved it for u it seems i did not totaly wasted my time on that bug than.

In ZP 3.20 I only see the following options under Video Renderer for Standard Media Playback: System Default; Standard Renderer; Overlay Mixer (I've selected this one); Video Mixing Renderer 9 - I see no Overlay 1 or Overlay 2 options. In any case, yes, the Athos 20040325 plays back choppy all the time, even when I pause and seek.

Some system specs might help - I tested om both my machines, and found the same results as reported originally (ffdshow_test2T.zip works smoothly)

Machine 1:
Athlon XP 2600+
Asus A7N8X-X mb (nforce2 chipset)
ATI AIW Radeon 9000 pro
Catalyst 4.10 drivers
Win2kSP4
Directx 9.0b

Machine 2:
Intel Celeron 633
Soyo mb (Intel BX chipset)
ATI Radeon 9200 (retail box)
Catalyst 3.90 drivers
Win2kSP4
Directx 9.0b

Since these 2 machines are so different, and I see the same results on both, I've got to assume that there's something wrong in the original athos code that you fixed in build test2T (unless there's an inherent bug in the ATI drivers that never gets changed).

Thanks - hope the modified code gets added to the main builds so that the chopy playback doesn't reappear in the next update.

Andy2222

27th March 2004, 01:50

[i]unless there's an inherent bug in the ATI drivers that never gets changed).
[/B]

Problem is i never ever had choppy playback and many other can use OM1 without any problem's. I realy think its a driver problem, and both of your pc's has ATI cards.

gitoshi

27th March 2004, 02:01

@Andy:
I don't think that is ATI driver problem. check my specs I had the same problem with Celeron+Intel815 and AthlonXP+GF4 TI4200.
The only thing this machines had in common is DirectX 9.0b, onboard sound, non-SSE2.

G

Andy2222

27th March 2004, 02:13

mhh whatever i will send the stuff we talked about the last 3 pages here to milan and he can add whatever he thinks works best. That will at least fix all the OM1 problems. For the OM2 .... maybe it will work with the next directX version.

PS: btw feel free to report other/new bug's from the latest version's so we hopefully have a stable version like the 05/2003 soon

Swede

27th March 2004, 06:55

Originally posted by keygen
Anyone know where to get the latest ffdshow's? http://athos.leffe.dnsalias.com/ has been dead for several hours now so latest one I've got is ffdshow-20040319.exe Dead? As far as I can see there are no problems here at my end and the server hasn't been down for ~6 months or so... Is there anyone else that don't get through?

LigH

27th March 2004, 18:56

Originally posted by athos
They are also mirrored, among some xvid builds, at http://www.ligh.de/software/mirrors.phtml
doesnt seem to have the latest though.

If you'd write me regularly when you're about to put up a new build, I'd know about it sooner. So you people have to wait until I accidently look if there's any new build... ;)

I updated my mirror a few hours ago.
__

@ Swede:

As I sometimes complained: For T-Online (ISP of the German Telecom) low bandwidth users, *.dnsalias.com is so horribly slow; in contrast, users of other german ISPs don't seem to have such a big problem to download from this domain. Somehow I'm afraid that "Robert T-Online" wants to upset us...

It takes more than half an hour for me to get ~ 1 MB, and only if I use a download manager with segmented downloads (multiple connections), and regularly manually refreshing the connections.

I doubt that you can do anything about that - but that was a main reason for me to provide my mirror!

communist

27th March 2004, 23:12

Originally posted by LigH
For T-Online (ISP of the German Telecom) low bandwidth users, *.dnsalias.com is so horribly slow; in contrast, users of other german ISPs don't seem to have such a big problem to download from this domain. Somehow I'm afraid that "Robert T-Online" wants to upset us(...) but that was a main reason for me to provide my mirror!
Very true and thanks for the mirror :)

keygen

28th March 2004, 00:28

Originally posted by Swede
Dead? As far as I can see there are no problems here at my end and the server hasn't been down for ~6 months or so... Is there anyone else that don't get through?

Well, this have worked fine for me for a long time, but since early friday I haven't managed to get through, still have problems.

Now it's working :)

Blight

28th March 2004, 14:59

ZP uses CLSID_OverlayMixer... I don't think there's a reason to ever use OverlayMixer2, the only reason it exists is that so DVD Graphs could be created automatically.

So I guess this "bug" effects both overlay mixers. I'm not really sure if you specify Overlay1/Overlay2 in BSPlayer it actually means OverlayMixer1/2 I think BSPlayer has it's own internal Video Renderer filter and his setting somehow relates to that.

bond

28th March 2004, 18:55

i now had time to test .mp4 files output by sorenson squeeze 3.5.300.6 with ffdshow

i tested various settings with the following results

- when decoding streams containing gmc, the picture is totally screwed up, meaning it looks "washed" (same behaviour with the 3ivx decoder, divx5 also the same, xvid crashes in xvidcore.dll)
- files with 2 b-frames are played little choppy (same with 3ivx, divx5 the same and shows a green stripe on the side, xvid crashes in xvidcore.dll)
- qpel works (as expected)
- mpeg quant works (xvid shows wierd colors with much green in it)

funny if i play it with ffdshow and overlay mixer2 the picture gets wrongly resized, seems to be width:height = 1:1 (graphedit also reports under "out": "aspect ratio 1x1")

the file is 320x240

SeeMoreDigital

28th March 2004, 19:04

Originally posted by bond
i now had time to test .mp4 files output by sorenson squeeze 3.5.300.6 with ffdshow What source did you use to generate your Sorenson .MP4 encodes?

Cheers

bond

28th March 2004, 19:07

Originally posted by SeeMoreDigital
What source did you use to generate your Sorenson .MP4 encodes?hm an old divx5 clip i had lying around on my disc

SeeMoreDigital

28th March 2004, 19:47

Originally posted by bond
hm an old divx5 clip i had lying around on my disc I only ask because Sorenson Squeeze 3.5 does'nt like some sources, especially Mpeg2 streams. Even Mpeg2 streams that has been generated by Sorenson Squeeze! :confused:

And when playing back MP4 contained encodes that have been generated from Mpeg2 sources, they behave a bit like "the b-frame stuttering with x-card playback" problem... without b-frames being encoded...

Cheers

skynetman

29th March 2004, 13:04

Luminance offset and luminance gain still make ffdshow crash with mpc.

Unhandled exception at 0x0145660a in mplayerc.exe: 0xC0000005: Access violation reading location 0xe9e9e9ec.

0145660A mov dl,byte ptr [eax+3]

Andy2222

29th March 2004, 13:24

What ffdshow version and what MPC version u use? For me it works perfect without problem's in the latest MPC.

(Pls: add your CPU type + graphiccard)

PS: try move the "picture properties" pannel to the top position in your filter chain (the little arrows in front of the filter name)

skynetman

29th March 2004, 14:29

MPC 6.4.8.2 (latest)
VMR9 (renderless) output

Athlon XP 2000+ on Abit KT7A
Windows 2003 with DirectX 9
ATI 9000 pro.

NO use switching picture properties on top.
In the same moment i try moving gain or offset from OFF value the image freezes (audio goes on) and i have a crash (as i have ms debugger it pops up).

Andy2222

29th March 2004, 14:46

mhh i remember the same thing happend to me in zoomplayer with the old nvidia driver's + VMR9. The same effect appeered if i tryed to adjust color's over the VMR9.
Can u try overlay mixer as render and are u using the latest 20040325 version?

MoonWalker

29th March 2004, 19:24

Just to share...

Using ffdshow-20040325 and MPC 6.4.8.0...

Overlay Mixer (enabled both on ffdshow and MPC) : Choopy playback..

WMR9 : Playback OK and no crash with Luminance offset and luminance gain..(on Geforce Ti 4200 with 56.64 ForceWare)

MoonWalker

athos

29th March 2004, 23:03

New build today, with the following modifications to milan's code:
* Andy2222's fix for OM choppy playback. Feedback appreciated!
* Win9x-style install dir i registry (C:\Progra~1), so ffdshow shows up in VFW apps even under Winnt (nt/2k/xp/2k3) OS
* Targetted at i686 in VS6 and GCC. If there is anyone still using a sub-pentiumpro-class cpu, please let me know.

I did this build so soon after the last mostly to check these modifications.

skynetman

29th March 2004, 23:34

I tried with all the possible settings with mpc 6.4.8.2 + new 20040329:

MPC with overlay mixer = no video
MPC with VMR 7 or 9 = crash if i change gain or offset.

any other test?

Andy2222

30th March 2004, 00:00

Originally posted by skynetman
I tried with all the possible settings with mpc 6.4.8.2 + new 20040329:

MPC with overlay mixer = no video
MPC with VMR 7 or 9 = crash if i change gain or offset.

any other test?

mhh im not 100% sure if it's a ffdshow+mpc problem or a ATI driver+dx9 problem, like the choppy playback bug if we cant reproduce the error its realy hard to fix those stuff.

U can try reproduce that crash on a other pc or with a other player or better in the graphedit tool.

TheShadowRunner

30th March 2004, 00:19

Hey all, it seems that SVQ3 is broken after ffdshow version 20040312 (latest version to work). Every version after this one crash the player (MS6.4) and give me an error in "libavcodec.dll".
I can specify the full error reported by Windows if anyone wishes.
Later,

TSR

MoonWalker

30th March 2004, 07:41

Just tested the ffdshow-20040329 build..

With overlay mixer enabled both on ffdshow and MPC (6.4.8.2), no choppy playbach (though the image is a little darker i think)...

BTW why overlay mixer at ffdshow has 3 options?? One tick, one dash, and unchecked...

Regards,
MoonWalker

bond

30th March 2004, 09:10

Originally posted by MoonWalker
BTW why overlay mixer at ffdshow has 3 options?? One tick, one dash, and unchecked...because there are three options:
- use overlay mixer2
- use overlay mixer
- use non of both

Owen

30th March 2004, 12:42

Why does anyone want to enable Overlay mixer in FFDShow?
This caused problems with most builds of FFDShow.
I don’t understand why that option even exists.
The player sets the output renderer.

Owen

skynetman

30th March 2004, 12:57

Originally posted by Andy2222
if we cant reproduce the error its realy hard to fix those stuff.

Same crash error on another PC with an AthlonXP 2400+ and Nvidia Geforce TI4400 with latest drivers.

It definitely has something wrong.

Can u build a debug version? So i can check what line do i have the error in code.

Wilbert

30th March 2004, 13:29

Why does anyone want to enable Overlay mixer in FFDShow?
For playing mkv's with an ar different as 1:1.

Btw: Athlon XP 3000+ (also Abit KT7A I think), Nvidia Geforce TI4200 (WDM 30.72 drivers) and overlay mixer enabled works fine for me. DirectX 8.1 I think :) WMP6.4.

I will try to change the gain and offset when I'm at home.

Andy2222

30th March 2004, 14:15

Originally posted by skynetman
Same crash error on another PC with an AthlonXP 2400+ and Nvidia Geforce TI4400 with latest drivers.

It definitely has something wrong.

Can u build a debug version? So i can check what line do i have the error in code.

oki will do :) we should prolly take the chance that some1 has vc installed.

Andy2222

30th March 2004, 14:33

Originally posted by Owen
Why does anyone want to enable Overlay mixer in FFDShow?
This caused problems with most builds of FFDShow.
I don’t understand why that option even exists.
The player sets the output renderer.

Owen

Since i like the fast and easy way to set the overlay color settings and the latest build's should not make problem's in those modes. I can have it enabled without any problems in every player (zoom/mpc/bsplay/core/crystal)

The not "connecting" bug was smashed a while ago and the AR bug too.

TheShadowRunner

30th March 2004, 18:16

ffdshow-20040329 also crashes with SVQ3 (quicktime sorenson)contents, also caused by a problem with"libavcodec".
Later,

TSR

Owen

30th March 2004, 21:38

Wilbert,

What has Overlay mixer got to do with AR control? :confused:

Owen

Kurosu

30th March 2004, 21:52

Owen, please read about the Overlay Mixer 2 (http://msdn.microsoft.com/library/en-us/directx9_c/directX/htm/overlaymixer2filter.asp?frame=true#overlaymixer2filter) and the VIDEOINFOHEADER2 (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/htm/videoinfoheader2structure.asp) that were both mentionned in the few last pages

skynetman

30th March 2004, 22:13

@Andy2222: I think we found the problem thanks to that debug version.
Simply debug version DOES NOT CRASH while standard CRASHES.
As i suppose they are the same ffdshow version it is obviously a compiler optimization that makes athlons crash and that is not active when compiling in debug mode.
U could check project configuration and try disabling only one each time then send me link to as many version as u want to find the wrong param :)

Anyway debug version works ;) I'm using it for a high definition avi and is smooth on my 2000+ on static scenes (choppy on fast ones)

Waiting for someting to test....

Wilbert

30th March 2004, 23:14

I will try to change the gain and offset when I'm at home.
Plays fine for me.

edit: used W2K SP4

Andy2222

31st March 2004, 00:12

Originally posted by skynetman
@Andy2222: I think we found the problem thanks to that debug version.
Simply debug version DOES NOT CRASH while standard CRASHES.
As i suppose they are the same ffdshow version it is obviously a compiler optimization that makes athlons crash and that is not active when compiling in debug mode.
U could check project configuration and try disabling only one each time then send me link to as many version as u want to find the wrong param :)

Anyway debug version works ;) I'm using it for a high definition avi and is smooth on my 2000+ on static scenes (choppy on fast ones)

Waiting for someting to test....

mhh im confused again.. why a normal version crash for u but not for me or other's, i have an athlon-xp too (but i use windows-xp)
The second pc u tested it and it crashed what OS had it also win2000?
I have realy no clue why a simple VC version can crash on one athlon system but not on a other... damm this suck's big time.

I will compile some more version's tomorrow u can test, need a break atm.

PS: i dont think its a optimisation problem of the compiler cause the VC compiler is out for a long time and i never heared of athlon problem's, however i think it's one of the debug lib's ffdshow get's linked against, wich fix that problem. I tip on the strmbasd.lib, i will test this.
Did my ffdshow compile also crash like athos, if so we both have the same lib's than :)?

BTW: what crashes in graphedit? Cause u just wrote mplayerc.exe crashed. Can u try it in graphedit and tell me if graphedit or ffdshow.ax or libav or mplayer.dll crash?

adx200

31st March 2004, 00:50

Just for Athos' information, the 3-29 build also fixes the choppy playback issue on my machine. I'm using Zoom Player, with FFDShow's post processing options turned on, on an Intel chipset with a Pentium 4. The 3-25 build was just choppy enough to make me go running back to the 5-23-2003 alpha build, but this one's working fine for me. Thanks!

Didée

31st March 2004, 10:08

Confirmation: ffdshow 03-29-2004 plays smooth for me, too. Finally - hooray! AR control w/w/out resizing also seems to work as expected.
'Gain' in 'picture properties' is crashing, but I could not mind less (I never use it).
Going to check if something has changed in handling of high bitrate quant matrices.

- Didée

edit: forgot the 'hooray'

oddball

31st March 2004, 10:11

I used to have choppy playback too. But in the latest builds it is not as bad. I still get odd dropframes but not nearly as bad as a few builds back. Dunno.

Arska

31st March 2004, 11:29

Yep, the resize issue that I mentioned earlier is now gone.

skynetman

31st March 2004, 13:44

@Andy
The crash problem is on 2 pc with windows server 2003 on both.
The strange thing is that on one of those 2 pc when i installed ffdshow (over the previous one) explorer shell crashed (and under win 2003 NEVER happens) and i had to reboot.

Can u send me a graphedit project? I have an exam. at univ. tomorrow( entropic coding, DCT,FFT, VLC subband etc....), and now i don't have any space left in brain for graphedit manual :p

Owen

1st April 2004, 11:02

Please excuse my ignorance, but I am still trying to figure out what enabling Overlay mixer in FFDShow has to do with aspect ratio parsing.
Are people suggesting that if overlay mixer is NOT enabled in FFDShow that aspect ratio parsing is still broken?
Why should enabling overlay mixer in FFDShow be preferable to enabling it in the player?
Where does all this leave the people who are now using the better quality VMR9 renderer and who cannot enable overlay mixer in FFDShow?

Regards,

Owen

Andy2222

1st April 2004, 16:10

Originally posted by Owen
Please excuse my ignorance, but I am still trying to figure out what enabling Overlay mixer in FFDShow has to do with aspect ratio parsing.
Are people suggesting that if overlay mixer is NOT enabled in FFDShow that aspect ratio parsing is still broken?
Why should enabling overlay mixer in FFDShow be preferable to enabling it in the player?
Where does all this leave the people who are now using the better quality VMR9 renderer and who cannot enable overlay mixer in FFDShow?

Regards,

Owen

oki simple example: u want play a media file with anamorphic ar, or a ar wich isnt the pixel ar of the movie. If overlay mode is disabled ffdshow use VH1 and just send this to the render wich get x,y as normal pixel info's and nothing more, so the movie play's at wrong AR. If overlay is enabled ffdshow use VH2 and "try" to read the correct AR out of the movie and than send x,y and Ar info's to the overlay mixer. With this infos the player/OM can correct the movie and play's at correct AR.

"better quality VMR9 renderer" u cant say that, VMR9 is bugged and on my system looks very bad compared to overlay mixer. There is no "better" atm, what looks better for u might look bad for a other people.

U can still enable overlay usage + VMR9 to get the AR info's handed down.
Btw i say it again since every1 try to push so hard to get VMR9 working, its not the holy grail.

VMR9 does 2 thing's atm wich might be usefull:
1. Multiple display's can be opened/used at once, while OM just allow 1.
2. It "might" have a better scaling mode compared to the overlay mixer, but this depend's on the videocard. If u use ffdshow for resize than u dont have to care.

The other stuff u might notice like so called "smooth" aka better or "washed" aka bad effect's hardly depends on the implemetation of the videodriver and which color control setting's are used. I just say its kinda subjective since a couple of ppl like overlay over vmr9 and other couple like vmr9 over overlay.

Im not a dshow programmer but i already wondered why ffdshow cant use VH2 all the time? For 3ivx decoder i noticed that the output is always in VH2 format even if the movie has special AR in it or not. It just copie the x,y values to the AR values if no infos are found.

maybe this help's?

Coroner

1st April 2004, 22:48

VMR9 does another thing that is very usefull (the only reason I use it). It's the only way to display subtitles (SRT, SSA) on an MPEG2 stream in MPC.

tato_uy

1st April 2004, 23:21

Hi, i want to ask about the ffdshow audio filter.
Does anybody has problems with mp3 decoder (both of them libmad and mp3lib??.
Those twho doesn't work for me. I tested on 3 different machines and have no luck.
Did you know if this is gonna be solved? or the possible causes?.
thanks.

shitowax

2nd April 2004, 00:01

3ivx output is VIH2 only if:
- it's required because the input contains non-square AR
- the force-overlay option is used.

Originally posted by Andy2222
Im not a dshow programmer but i already wondered why ffdshow cant use VH2 all the time? For 3ivx decoder i noticed that the output is always in VH2 format even if the movie has special AR in it or not. It just copie the x,y values to the AR values if no infos are found.

maybe this help's?

gabest

2nd April 2004, 00:32

shitowax: If only AR info is needed, you could set the biXPelsPerMeter/biYPelsPerMeter members of BITMAPINFOHEADER, they are picked up by the older renderers too.

Andy2222

2nd April 2004, 00:38

Originally posted by shitowax
3ivx output is VIH2 only if:
- it's required because the input contains non-square AR
- the force-overlay option is used.

oki my fault
mhh so we just have to add this too for ffdshow "- it's required because the input contains non-square AR"

this than should work with vmr7/9 render's and anamorphic encodes using VH2 without enabling "use overlay" in ffdshow

skynetman

3rd April 2004, 11:08

Any news about non crashing ffdshow version, i'm still with debug :( ?

P0l1m0rph1c

3rd April 2004, 15:39

Hi,

I don't know if anybody noticed this, or if its just me, but...

When decoding XviD content with ffdshow, using 'XviD 4' to decode it, the player just crashes when trying to decode the file. I tried changing iDct, enabling/disabling OM, but nothing of that worked. Using libavcodec to decode the file works just fine.

I don't have any post-processing or special filters activated in ffdshow, so that isn't the reason. This both happened in WMP6.4 and MPC 6.4.8.2. The stream i tested was an AVI with just video, so others streams aren't the problem either.

Btw, i'm using a P4 2.0 Ghz, 768 RAM, Win2k SP4, with latest Athos' build (29-03-2004). Using the one from 25th March does the same also.

gitoshi

3rd April 2004, 16:42

I can confirm the GAIN crash bug in a Celeron 1GHZ , however the strange thing is that sometimes if I render the file in GraphEdit or play another AVI then in the next playback GAIN work fine.

@Athos:
What about a FFDSHOW lite build, without the encoder and Audio Filters parts??

G

Andy2222

3rd April 2004, 17:39

Originally posted by gitoshi
@Athos:
What about a FFDSHOW lite build, without the encoder and Audio Filters parts??

I tryed this myself a while ago but one problem is to take all the encode/audio parts out and also resolving all the missing undefined object's and call's at linking time. If athos can manage this it would be nice but it wont fix any bug's or crashes and there will be also no speed gain.

@skynetman will build some test version's today maybe we can find out what's the problem.

Andy2222

3rd April 2004, 19:02

@skynetman and co

oki 7 diff. compiled version's up at: http://mitglied.lycos.de/ieggei2/ffdshow/

If the libavcodec or mplayer dll crash try to use my version also.

good luck and post wich version's crash and wich dont

PS: since i build them from the latest cvs update i forgot to add some bugfixes (the overlay choppy playback) so just test them for the gain crash and stuff thx.

skynetman

3rd April 2004, 20:28

Test Results:

Original libries:

ffdshow.ax.1 ---> CRASH
ffdshow.ax.2 ---> CRASH
ffdshow.ax.3 ---> CRASH
ffdshow.ax.4 ---> CRASH
ffdshow.ax.5 ---> CRASH
ffdshow.ax.6 ---> CRASH
ffdshow.ax.7 ---> CRASH

New libraries:

ffdshow.ax.1 ---> CRASH
ffdshow.ax.2 ---> CRASH
ffdshow.ax.3 ---> CRASH
ffdshow.ax.4 ---> CRASH
ffdshow.ax.5 ---> CRASH
ffdshow.ax.6 ---> CRASH
ffdshow.ax.7 ---> CRASH

Old libraries + old debug version ---> WORKING
New Libraries + old debug version ---> WORKING

U missed it this time, try again :(

Andy2222

4th April 2004, 01:26

@skynetman

dammit,

oki next round 5 new try's :)

skynetman

4th April 2004, 12:00

FOUND THE ONLY WORKING VERSION

Tested all 5 new build with both yesterday and today libs

ONLY ffdshow_5 works perfectly both with OLD(official) libraries and NEW libraries.
So libraries does not make any difference.

Did u compile ffdshow5 with same settings as the old "debug" version u gave me?
What was the problem? A compiler switch?

A new official version coming soon? :D

Andy2222

4th April 2004, 16:32

Originally posted by skynetman
FOUND THE ONLY WORKING VERSION

Tested all 5 new build with both yesterday and today libs

ONLY ffdshow_5 works perfectly both with OLD(official) libraries and NEW libraries.
So libraries does not make any difference.

Did u compile ffdshow5 with same settings as the old "debug" version u gave me?
What was the problem? A compiler switch?

A new official version coming soon? :D

oki its not a lib problem, its also not a problem with special debug defines or option's. I tryed every language switch wich is normaly on in debug mode.
The ffdshow_5 was compiled using /Os (all default optimization's off), while all other version's used /O2 or /O1.
Problem is i never ever had problem's in VS with /O2 and ffdshow will be crappy slow in /Os or /O1 mode.
I will compile some more version's where i turn off the default O2 switches one by one to find the problem. If we found the problematic switch i can than add a pragma optimize setting for just those 2 function's and disable the switch, so it should not impact the other functions.

CruNcher

4th April 2004, 16:52

Andy are you optimizing only for Athlon ?
in my latest test with Athos build vs XviD Decoder i can only see 1 fps gain for ffdshow but libavcodec should be alot faster then that hmmm at least that's what i hear is the situation natively under GNU/Linux

arno

4th April 2004, 16:56

Originally posted by Andy2222
oki its not a lib problem, its also not a problem with special debug defines or option's. I tryed every language switch wich is normaly on in debug mode.
The ffdshow_5 was compiled using /Os (all default optimization's off), while all other version's used /O2 or /O1.
Problem is i never ever had problem's in VS with /O2 and ffdshow will be crappy slow in /Os or /O1 mode.
I will compile some more version's where i turn off the default O2 switches one by one to find the problem. If we found the problematic switch i can than add a pragma optimize setting for just those 2 function's and disable the switch, so it should not impact the other functions.

I also have the crashing problem with luminance gain/offset for ages. Because I don't use the controls (anymore), since I use the settings in my videocard driver it's not a real issue for me. I know that in the past it used to work, if you like I can test with older versions of ffdshow were it exactly broke...

Andy2222

4th April 2004, 16:56

Originally posted by CruNcher
Andy are you optimizing only for Athlon ?
in my latest test with Athos build vs XviD Decoder i can only see 1 fps gain for ffdshow but libavcodec should be alot faster then that hmmm

What cpu u have? Since i did a similar test 2 night's ago and compiled myself a max. athlon-xp speed xvid.dll. I compared both version's with my normal ffdshow filter's and libav was around 30% faster, compare to the xvid version.

So i assume its a problem with the libavcodec for u? Or it could be a colorspace problem, did u used the xvid dshow decoder or did u set ffdshow to use the xvid.dll under codec's? Did u use yv12 enabled in ffdshow?

"Andy are you optimizing only for Athlon ?" There is no new special athlon code from me present in athos build's. My code still crash on p4 and some old pentium pc, on p4 there are also some speed problem's with my code. Im trying to fix this but i simple leak 10 yeahrs of assembler code knowledge :( and i dont want to add code wich add's more crashes/problem's to ffdshow. I realy try to get the denoise3d mmx2 code working since its one of the most used filter's, but its realy harder to code perfect asm code than i ever expected...

Andy2222

4th April 2004, 16:57

Originally posted by arno
I also have the crashing problem with luminance gain/offset for ages. Because I don't use the controls (anymore), since I use the settings in my videocard driver it's not a real issue for me. I know that in the past it used to work, if you like I can test with older versions of ffdshow were it exactly broke...

would be helpfull i can than look at the cvs system thx

CruNcher

4th April 2004, 17:05

i tested with 80 Mbit 1980x1080p ASP HDTV content and optimized the XviD version with icl 8 and definatly only 1 fps difference in playback speed where can i find your version of libavcodec.dll ?

P4 1.8 Ghz Williamette

actually it was the same result as with the old athos build i tested a while back

Andy2222

4th April 2004, 17:10

Originally posted by CruNcher
i tested with 80 Mbit 1980x1080p ASP HDTV content and optimized the XviD version with icl 8 and definatly only 1 fps difference in playback speed where can i find your version of libavcodec.dll ?

P4 1.8 Ghz Williamette

Just to understand your problem:

U compiled yourself a ICL8 version of xvid and compared this against the libav version in ffdshow right?

mhh the p4 is realy a strange cpu i have massive problem's with my code since some of the common used instruction's have hellish long vectorized cpu cycles.. so it could be that a special p4 version might help.

I will compile u a special p4 libav version for testing, might be intressting to see if this help's. Get it here in 5min's_: http://mitglied.lycos.de/ieggei2/ffdshow/

CruNcher

4th April 2004, 17:12

thx Andy i test with your version aswell heres the old test

http://forum.doom9.org/showthread.php?s=&threadid=71994

Andy2222

4th April 2004, 17:36

Originally posted by CruNcher
thx Andy i test with your version aswell heres the old test

http://forum.doom9.org/showthread.php?s=&threadid=71994

oki 3 version's up for testing

arno

4th April 2004, 18:27

Originally posted by Andy2222
would be helpfull i can than look at the cvs system thx

Here are my findings. The luminance gain/offset broke starting with Athos release 20031028, the previous release(s) (<= 20030816) work fine.... I hope it helps, Andy...

CruNcher

4th April 2004, 19:43

Andy here are the Results not much changed :)

Athos = 9,70 fps
Athos + libavcodec_P4 = Crash
Athos + libavcodec_P4_2 = 9,80 fps
Athos + libavcodec_P4_3 = 9,70 fps

XVID Rc4 = 8,00 fps

Andy2222

4th April 2004, 20:02

Originally posted by CruNcher
Andy here are the Results not much changed :)

Athos = 9,70 fps
Athos + libavcodec_P4 = Crash
Athos + libavcodec_P4_2 = 9,80 fps
Athos + libavcodec_P4_3 = 9,70 fps

XVID Rc4 = 8,00 fps

mhh strange that the P4 version crashed, whatever seems that the ICL8 compiler work's fine for P4 compiles and that gcc has some problem's to catch up. But i think its some hardcoded asm routines wich can be fast executed on athlon and p3 but cause a lot more troubles on P4 (u realy need to take care of what asm instruction's u use on p4 and wich better to avoid)

So the libav codec would need a review for P4 code to get the most out of it. To profile the code i would need a P4 CPU but i dont have one :) So i have no clue why on P4 the speed gain is just that low. Would be intressting to do the EXACT same test with an AMD or P3 CPU.

Kurosu

5th April 2004, 09:02

Did you compile libavcodec with -DHAVE_SSE2 (and maybe -DHAVE_CMOV)? Together with a bunch of other defines (like HAVE_3DNOW or HAVE_3DNOWEXT for AMD processors), some supposedly slower code is chosen.

skynetman

5th April 2004, 10:44

OK Andy New Test Results on 4 new builds:

ffdshow.ax.1 --> CRASH
ffdshow.ax.2 --> WORKING
ffdshow.ax.3 --> WORKING
ffdshow.ax.4 --> CRASH

Probably some ASM expert should look directly at assembly code cause i think compiler optimizes the wrong way some code.

are ffdshow_2 and ffdsow_3 optimized? Without any opt i lose many fps :(

@ALL: am I the only one testing? Hurry up, the party is almost over :p u will regret not having crashed your explorer shell at least 30 times :D

Andy2222

5th April 2004, 12:05

Originally posted by skynetman
OK Andy New Test Results on 4 new builds:

ffdshow.ax.1 --> CRASH
ffdshow.ax.2 --> WORKING
ffdshow.ax.3 --> WORKING
ffdshow.ax.4 --> CRASH

Probably some ASM expert should look directly at assembly code cause i think compiler optimizes the wrong way some code.

are ffdshow_2 and ffdsow_3 optimized? Without any opt i lose many fps :(

@ALL: am I the only one testing? Hurry up, the party is almost over :p u will regret not having crashed your explorer shell at least 30 times :D

oki its the /Og compiler switch than, aka global optimisation. I now try to check what this switch does for the code or just add a VC pragma and disable it for those cpp files.

athos

5th April 2004, 19:55

* win9x style install path
* Andy2222's fix for choppy OM playback
* Skal's codec
* Requires i686 (Pentium Pro) or better

Sirber

5th April 2004, 20:18

Originally posted by athos
* Skal's codecWhat is that? :confused:
[edit]
http://skal.planet-d.net/coding/mpeg4codec.html

forget it :)

bond

5th April 2004, 20:22

Originally posted by athos
* win9x style install path
* Andy2222's fix for choppy OM playback
* Skal's codec
* Requires i686 (Pentium Pro) or better cant install!
failure in ffdshow.ax during install

Defiler

5th April 2004, 20:43

Originally posted by bond
cant install!
failure in ffdshow.ax during install Works for me.

athos

5th April 2004, 20:49

Originally posted by bond
cant install!
failure in ffdshow.ax during install
What OS? I tried uninstalling / reinstalling, no problem here on WinXPsp1

bond

5th April 2004, 21:01

worked now :)
edit: tough i dont have ffvfw listed in vdm now, but a "ffdshow video codec" with no options

Originally posted by athos
Andy2222's fix for choppy OM playbackfor om2? if yes, its still choppy :(

LigH

5th April 2004, 21:12

@ bond:

When I uninstalled ffvfw and the old ffdshow (up to Feb. 2004), and installed the previous ffdshow (2004-03-25) with VfW interface, I got this "ffdshow" codec entry, and it was fully configurable. It substituted ffvfw well. And it was configurable via Start menu as well as from VDub.

After uninstalling 2004-03-25 and installing 2004-04-05, it still works well.

Using Windows 2000 SP4 (german: "Programme").

Andy2222

5th April 2004, 21:23

Originally posted by bond
worked now :)
edit: tough i dont have ffvfw listed in vdm now, but a "ffdshow video codec" with no options

for om2? if yes, its still choppy :(

sorry to hear this, but seems it only fixed the OM1 choppy playback and "semi" for OM2. Some reported success for OM2 some did not...

skynetman

5th April 2004, 21:29

Ohhhhhh no!! :angry:

CRASH AGAIN with latest 20040405 build :(

01457BD7 movzx ebx,byte ptr [eax+3]

Besides it didn't want to overwrite my old ffdshow.ax, i had to rename it and launch setup again.

bond

5th April 2004, 21:32

Originally posted by Andy2222
sorry to hear this, but seems it only fixed the OM1 choppy playback and "semi" for OM2. Some reported success for OM2 some did not... i think this damn overlay mixer is simply b0rked itself (ffdshow is not guilty for this)

Originally posted by skynetman
Besides it didn't want to overwrite my old ffdshow.axhere too, thats why it didnt work first (i had to reboot to be able to delete the old .ax)

Andy2222

5th April 2004, 21:35

Originally posted by skynetman
Ohhhhhh no!! :angry:

CRASH AGAIN with latest 20040405 build :(

01457BD7 movzx ebx,byte ptr [eax+3]

Besides it didn't want to overwrite my old ffdshow.ax, i had to rename it and launch setup again.

The gain/offset crash? im still on it will send the fix to athos if its done.

Blight

6th April 2004, 06:51

Regarding the OM1 vs OM2 issue... why is anyone using OM2? As far as I can see, there's no reason to use it as OM1 does support Format_VIDEOINFO2... It's just not an auto-loading filter... OM2 was introduced solely for autoamtic DVD graph creation as far as I can tell, and as most of you know, creating a DVD Graph automatically has a very high chance of failing or creating an unwanted graph.

Neither ZP, MPC and BSPlayer (I think) load OM automatically...

tato_uy

6th April 2004, 06:59

why ffdshow audio doesn't work?.
it gives a lot of rare sounds, but doesn't decode mp3.
somebody know's if that is gonna be fixed?

thanks

Andy2222

6th April 2004, 08:18

Originally posted by tato_uy
why ffdshow audio doesn't work?.
it gives a lot of rare sounds, but doesn't decode mp3.
somebody know's if that is gonna be fixed?

thanks

mhh what u mean with "but doesn't decode mp3"? Just configure it for mp3 playback and select "libmad"

I just tested it and my avi's with mp3 sound play just fine using ffdshow audio filter, so whats your problem? (crash/no sound/ ...)

PS: but i like the elecard moonlight "odio dekoda" more since it play's mpg1/2/2.5/3 and i never had problem's with out of sync or whatever problem's

tato_uy

6th April 2004, 14:35

with
mp3lib: glitches and strange sounds. A little of the original sound can be heard.
libmad: no sound at all.

i tested on 3 different machines with win2000 and winXP.

Andy2222

6th April 2004, 17:10

Originally posted by tato_uy
with
mp3lib: glitches and strange sounds. A little of the original sound can be heard.
libmad: no sound at all.

i tested on 3 different machines with win2000 and winXP.

mhh for me libmad works fine... but it seems im the only one where ffdshow works like a charm (no choppy playback, never ever a crash, working sound..) sometimes i wish i would have those bug's since those dbugging with zillion's of testversion's suck..

Put this bug on the todo list, but its not a high priority atm... just use a windows or download a other filter. U can also get the libmad dshow filter as seperate "working" install.

get all here: http://www.rarewares.org/

tato_uy

6th April 2004, 17:27

thanks, is weird, because audio filter never worked for me. And i tested on a lot of computers.
Yes, currently i'm using
http://sourceforge.net/projects/maddxshow/
or the fraunhofer decoder.

if i can help you with some tests, let me know!

dimzon

6th April 2004, 17:35

Originally posted by tato_uy
thanks, is weird, because audio filter never worked for me. And i tested on a lot of computers.
Yes, currently i'm using
http://sourceforge.net/projects/maddxshow/
does'nt work (glitches)

bond

6th April 2004, 18:17

Originally posted by dimzon
does'nt work (glitches) it should work correctly with .avi and .mp3 streams (only ogm and mkv causes problems) :p

Andy2222

6th April 2004, 18:24

Originally posted by dimzon
does'nt work (glitches)

try this one: http://mitglied.lycos.de/ieggei2/dshowfilters
get the "odio.zip"

unpack, and in cmd "regsvr32 mlcom.ax" and select "odio decoda" later as filter for all mpeg audio.

"....(I'm not Crystal Player developer)" -> hehe rofl

LigH

6th April 2004, 19:09

Just a question about decoding audio: Windows 2000 and XP audio drivers shall be able to process even single precision float samples - Windows 9x drivers may in general not be able to do that. But I'd wonder if Windows 2K/XP will reliably always support other sample formats than 16 bit integer.

Might that be any reason for such "glitches"?

zettai

6th April 2004, 22:55

I had a custom installer that would register VIDC.YV12 to ffvfw.dll and I was looking to see if I could get similar functionality somehow with the new combined ffdshow and ffvfw?

I know I can manually set ffdshow to decode YV12 raw content but I'm not sure what registry setting I should enable for this. Any ideas?

DKDIB

7th April 2004, 00:00

Zettai wrote:
> I know I can manually set ffdshow to decode YV12 raw content but I'm
> not sure what registry setting I should enable for this. Any ideas?

[HKEY_CURRENT_USER\SOFTWARE\GNU\ffdshow]
"raw_rawv"="1"
[HKEY_CURRENT_USER\SOFTWARE\GNU\ffdshow\default]
"outYV12"="1"

In NSIS:
WriteRegDWORD HKCU "SOFTWARE\GNU\ffdshow" "raw_rawv" "1"
WriteRegDWORD HKCU "SOFTWARE\GNU\ffdshow\default" "outYV12" "1"

zettai

7th April 2004, 00:07

Originally posted by DKDIB
[HKEY_CURRENT_USER\SOFTWARE\GNU\ffdshow]
"raw_rawv"="1"
[HKEY_CURRENT_USER\SOFTWARE\GNU\ffdshow\default]
"outYV12"="1"

In NSIS:
WriteRegDWORD HKCU "SOFTWARE\GNU\ffdshow" "raw_rawv" "1"
WriteRegDWORD HKCU "SOFTWARE\GNU\ffdshow\default" "outYV12" "1" [/B]

Thank you, just what I was looking for :)

dimzon

7th April 2004, 10:39

Originally posted by bond
it should work correctly with .avi and .mp3 streams (only ogm and mkv causes problems) :p
seems like bug into build-in CrystalPlayer Avi Splitter
I posted bug report into CrystalPlayer's forum

tickey

7th April 2004, 21:38

With the last few builds it seems I only get 25 fps w/mpeg2 encoder, even though source is 23.97 or 29.97.
If I use the mpeg2enc mpeg2 I can set the frame rate OK, but I prefer the main mpeg2 encoder.
Anyone else having these problems?
Happens in full procesing or fast recompress.
Happens if set frame rate in vdub, etc.
TIA

allynm

8th April 2004, 06:27

athos,
in the past every time i tried the newer ffdshow builds, i would get an instant crash upon playing a vid. i always ended up reverting back to the 20030523 build. just recently i got fed up and uninstalled all of the video related stuff, and installed media player classic again along with your newest ffdshow (0405). everything worked (yay), but then when i tried tweaking ffdshow settings i discovered what had been causing my crash all along:

under picture properties - adjusting either of the top 2 luminance sliders causes an instant crash with media player classic. mpc will then crash on every launch until ffdshow is set back to the normals for those 2 sliders.

my hardware:
geforce4 ti4200
dual xeon
1 gig ram

software:
newest nvidia reference drivers (crashed under the past few that i've tried)
newest mpc (also - crashed under the past few that i've tried)
xp sp1 / dx9
(note: also tried this under a clean install and got same result)

other notes: gamma adjustment works fine, as well as adjusting the 'levels' section (i'm currently using that adjustment to 'get by').

lemme know if you need any more info to replicate, or if you have any clue as to the cause of the crash.

p.s. is your source gonna show up on sourceforge in the future? we could help you out with the coding ya know... :)

p.s.2. why isnt your name in the about section? it appears you are doing just as much work as the original devs did...

thanks in advance for keeping this kickass filter alive and kicking

LigH

8th April 2004, 07:35

I just had a similar problem on one PC with several Windows 2000 installations per multi-boot menu. Practically all the same installations (same OS version and update level, same driver versions, just different purpose, different applications running).

On one system, ffdshow worked fine, I could slide the gamma level and everything else (only XSharpen crashed ffdshow and the player).

On another system, ffdshow crashed on sliding any option in the picture properties immediately. This was solved after uinstalling ffdshow, manually looking for registry entries containing "ffdshow" and deleting them, and reinstalling.

This solved it in my case; I woudn't guarantee that in any case, though.

yaz

8th April 2004, 08:56

i don't know where to post this, so i try here. feel free to transport my quests to the proper thread if i was wrong.

- i used makeavis coming with ffdshow for awhile so as to serve my avs scripts to some encoders (like mencoder) not accepting script files directly. afais in the new releases, the pack is rearranged to a certain extent. after installing ffvfw i don't find ffvfw.dll anymore. the vidc.avis entry is also missing from the registry.
the problem here is that mencoder whines for ffvfw.dll on feeding the fake avi. (or simply crashes, as there's no decoder found) i know, this dll is set in mencoder's config file, so i would change it easily to the proper value ... if i knew what's that. so, how should i do such kinda script-serving with the newest releases ?
- i tred ffvfw for encoding some test stuff. with the gui implemented it's quite easy & straightforward. my only problem was (so far) with setting the max.bitrate. it seems as if ffvfw wouldn't accept it. it's set to 10000 by def but if i change it to any other value it flips to 1000 & no way to change it. is it just a fake option or am i doing sg wrong ?

thx (& sorry if i'm at wrong place)
y

celtic_druid

8th April 2004, 10:21

Use ffdshow.ax instead of ffvfw.dll.

videocodec makeavis
info "FFdshow makeavis"
status untested
fourcc AVIS
driver vfw
dll ffdshow.ax
out YV12

yaz

8th April 2004, 10:47

@celtic_druid
thx alot !!! afais, it's the mencoder codec.conf file, isn't it.
hmmm ... should i set 'out' to yv12 (should i set it at all) ? if yes, should i always convert only(!) to yv12. (i got some scripts working in yuy2)
thx again
y
[EDIT] & how can i 'register' the 'avis decoder' ? gspot says, no proper decoder installed. i don't find the vidc.avis entry. should i set/change it also to ffdshow.ax?

dimzon

8th April 2004, 11:00

Hi
look at this post:
http://forum.doom9.org/showthread.php?s=&postid=471101#post471101

seem like there are some performance slowdown when using XviD 1.0 to decode (in comparision with native XviD Directshow Decoder)

athos

8th April 2004, 11:23

Originally posted by allynm
p.s. is your source gonna show up on sourceforge in the future? we could help you out with the coding ya know... :)

p.s.2. why isnt your name in the about section? it appears you are doing just as much work as the original devs did...

thanks in advance for keeping this kickass filter alive and kicking

I dont actually code this filter, so I'll just hope that some other user will supply you with a workaround, or maybe milan or Andy2222 can find a solution.

My contribution to this project is mainly just compiling the sources and making them available online. I do fiddle around some with the compiler flags, and small temporary modification like the OM bug, or the installer problem with long filenames.

My additions to the actual source are very few. I did add a small workaround for a bug some time ago, and this bug was soon fixed properly by milan. I also suggested a framerate doubling feature, along with a very simple algorithm for implementing it. Milan implemented this with some cool mmx assembler, and later added a much better, and more functional version of this which uses motion estimation. These can be found under the deinterlace section in the configuration.

So, I dont feel that I am really warranted to be in the About box, because I just compile the stuff that milan (mostly) writes. Anyone, who has set up their build environment with MingW, DirectX SDK etc could do this.

Andy2222

8th April 2004, 12:51

Originally posted by allynm
under picture properties - adjusting either of the top 2 luminance sliders causes an instant crash with media player classic. mpc will then crash on every launch until ffdshow is set back to the normals for those 2 sliders.

i think thats the same bug (compiler problem) wich cause the "gain" crash in that tab. Im on that one and might have a solution soon.

celtic_druid

8th April 2004, 12:58

That was just have the original ffvfw config was setup. It is going to end up YV12 anyway. That is assuming you are going for DVD, MPEG4, etc.

Doubt it matters if you have anything registered or not for mencoder.

Hmmm, dusted off GSpot and it says that same for me, but the AVI's playback fine both via VFW and dshow.

tickey

8th April 2004, 13:28

Originally posted by tickey
With the last few builds it seems I only get 25 fps w/mpeg2 encoder, even though source is 23.97 or 29.97.
If I use the mpeg2enc mpeg2 I can set the frame rate OK, but I prefer the main mpeg2 encoder.
Anyone else having these problems?
Happens in full procesing or fast recompress.
Happens if set frame rate in vdub, etc.
TIA
Let me be more precise. The problem is with actual framerate of the output.m2v file, not encoding speed.

I have found in the registry in the gnu/ffdshow_enc
a key: fpsOverride1000=dword:000061a8(25000)
and: fpsOverride1000=dword:000061a8(25000)

I remove these, and they combeback, so I select "don't save settings to registry" but still output.m2v is 25fps
I have tried older builds and it is still happening.
Again, it only happens on the "mpeg2" encoder. Using the "mpeg2enc mpeg2" i can set the frame rate output and it works but I can't set can't set a custom matrix, much slower, some quality settings not there.

Anyone?

yaz

8th April 2004, 13:32

Originally posted by celtic_druid
...That is assuming you are going for DVD, MPEG4, etc ... yep ... actually, i'm going for etc. :-))) i'd like to set up a good profile for svcd. sg freeware beating cce. i only use mencoder cus it seems to be the one accepting max_bitrate option. neither ffmeg nor ffvfw does it. wonder why ...
Originally posted by celtic_druid
Doubt it matters if you have anything registered or not for mencoder.sure. i just found (or haven't found :-) it when i scanned the system for the missing decoder.
Originally posted by celtic_druid
Hmmm, dusted off GSpot and it says that same for me, but the AVI's playback fine both via VFW and dshow. no problem with playback, afais. at least, mpc hasn't missed anything so far.

thx
y

oddball

8th April 2004, 14:59

I ccannot believe this filter is taking so long to get a proper release. So many bugs to fix I guess and not enough time from the programmers. Sigh...

allynm

8th April 2004, 21:53

Originally posted by oddball
I ccannot believe this filter is taking so long to get a proper release. So many bugs to fix I guess and not enough time from the programmers. Sigh...

you're kidding right? you MUST realize these guys are working on this filter in their spare time.

as a side note, there could be more programmers available if the new source re-appeared on sourceforge. i kinda figured that was the whole idea of gpl-ing the source to begin with, so others can pick it up and run with it, just as these fine coders have done.

c'mon guys, put that source out there. you may even be able to get the original ffdshow author (or some of the higher ups of the original group) to give you rights to the original ffdshow area. it only makes sense that it goes there. not to mention a MUCH better bug tracking system than what is currently being used (this one thread, ugh).

RadicalEd

8th April 2004, 22:08

Originally posted by allynm
as a side note, there could be more programmers available if the new source re-appeared on sourceforge. i kinda figured that was the whole idea of gpl-ing the source to begin with, so others can pick it up and run with it, just as these fine coders have done.

?:| The source is in CVS right here (http://sourceforge.net/cvs/?group_id=53761).

MfA

8th April 2004, 22:17

Radical, well the development process of ffdshow is a bit curious to say the least so you can forgive him for thinking Athos is just working from some old version and updating it.

allynm, what happened for some reason is that somewhere along the line Milan stopped having any interest in maintaining the website or building releases ... he is still steadily coding though, you just have to build from cvs. Which athos is doing.

allynm

8th April 2004, 22:18

Originally posted by RadicalEd
?:| The source is in CVS right here (http://sourceforge.net/cvs/?group_id=53761).

Sweetness! sorry, i was blindly going off of the old project page (the one thats a year old). i wrongly assumed that since the project page was outdated, the cvs would be as well...

athos

8th April 2004, 22:22

1. The source is on sourceforge. That's where I download it from for every build. See RadicalEd's post above.
2. The "group" is really Milan Cutka. There have been others helping out, but I would not really call it a group.

I just realised that both these points have allready been made. I have the impression that Milan is mostly interested in adding new features to ffdshow. I think he is doing a great job, but I do agree that there are a lot of bugs that need to be fixed. So I suggest that we try to find solutions and workarounds for the bugs, like the OM bug, the installer path bug etc, and then present them to Milan.

zettai

9th April 2004, 13:30

To return to a previous inquiry if no-one minds... upon further testing it appears that

[HKEY_CURRENT_USER\SOFTWARE\GNU\ffdshow]
"raw_rawv"="1"
[HKEY_CURRENT_USER\SOFTWARE\GNU\ffdshow\default]
"outYV12"="1"

Isn't enough to enable YV12 decoding if registered directly after the regular installation. There must be some other reg entries that are required to make it work but in comparing the reg entries when selecting the option so many get added that I've no idea which does what.

I've tried adding similar rawv settings in the HKLM registries as well, to no avail. Any more ideas?

allynm

10th April 2004, 00:53

Originally posted by allynm
athos,
in the past every time i tried the newer ffdshow builds, i would get an instant crash upon playing a vid. i always ended up reverting back to the 20030523 build. just recently i got fed up and uninstalled all of the video related stuff, and installed media player classic again along with your newest ffdshow (0405). everything worked (yay), but then when i tried tweaking ffdshow settings i discovered what had been causing my crash all along:

under picture properties - adjusting either of the top 2 luminance sliders causes an instant crash with media player classic. mpc will then crash on every launch until ffdshow is set back to the normals for those 2 sliders.

my hardware:
geforce4 ti4200
dual xeon
1 gig ram

software:
newest nvidia reference drivers (crashed under the past few that i've tried)
newest mpc (also - crashed under the past few that i've tried)
xp sp1 / dx9
(note: also tried this under a clean install and got same result)

other notes: gamma adjustment works fine, as well as adjusting the 'levels' section (i'm currently using that adjustment to 'get by').

lemme know if you need any more info to replicate, or if you have any clue as to the cause of the crash.

p.s. is your source gonna show up on sourceforge in the future? we could help you out with the coding ya know... :)

p.s.2. why isnt your name in the about section? it appears you are doing just as much work as the original devs did...

thanks in advance for keeping this kickass filter alive and kicking

ok, something to add here, and its weird.
i have found that on the picture properties tab, changing both 'luminance offset' and 'gamma correction' at the same time cause the crash (if one is moved from default but the other isnt, there is no crash).
now for the weird part: i can modify only 'luminance offset' in 'picture properties', and then i can go and modify 'gamma correction', but i do it under 'levels' instead, and it works!
this seems very odd, as the 'gamma correction' feature should work exactly the same under both tabs. it just doesnt like doing both simultaneously on the 'picture properties' tab...
...see? really weird

also, i've eliminated other causes by doing this under my clean install (which has never seen any older versions of ffdshow, and had no ffdshow entries prior to installing the 0405 build.

tickey

10th April 2004, 03:44

Originally posted by tickey
Let me be more precise. The problem is with actual framerate of the output.m2v file, not encoding speed.

I have found in the registry in the gnu/ffdshow_enc
a key: fpsOverride1000=dword:000061a8(25000)
and: fpsOverride1000=dword:000061a8(25000)

I remove these, and they combeback, so I select "don't save settings to registry" but still output.m2v is 25fps
I have tried older builds and it is still happening.
Again, it only happens on the "mpeg2" encoder. Using the "mpeg2enc mpeg2" i can set the frame rate output and it works but I can't set can't set a custom matrix, much slower, some quality settings not there.

Anyone?
Ok, thanks to Marcellus @
http://kvcd.net/forum/viewtopic.php?t=10149
I can just use restream. Works great/audio in sync.
I did notice this on output page.
http://www.planetsideimages.com/uploads/fpsoveride.jpg
Can this box be enabled/adjusted some how?
Thanks for the builds.

dvdmonger

10th April 2004, 06:54

Well I seem to experiencing one of those "ati issues". I installed ffdshow-20040405, and whenever I try to play any kind of divx3/4/5/xvid file, the cpu usage goes to 100%. I was using media player classic to playback the avi's. I also tried mplayer2, same result. I even tried using virtualdub, and using the vfw interface of ffdshow to decode. That seemed to be the best, with about 60% cpu usage. But that was still waaay more than what it should be. Also in virtualdub, the playback was still jerky, which is the same way it was when it was using directshow at 100%. Very odd. I'd debug it myself, but my skills are rather limited unfortunately.

I'm running xp pro sp1
athlon 750mhz
384mb pc100
MSI K7PRO
ati all-in-wonder 128 16MB agp

P.S. I am not using any postprocessing. I am using the fastest settings possible, simple idct, etc...

LigH

10th April 2004, 08:57

750 MHz is indeed not much, maximum resolution for full Post-Processing for my Duron 800 is ~ 512x288, bigger videos shall not use full PP on my PC (automatic level, maybe).

Also I wonder if there are any hints available which PP option consumes how much processing power - especially a comparison between MPlayer, Nics, and SPP: the last one appears very heavy to me.

hellfred

11th April 2004, 15:28

@athos
Just in case you did not notice up to now: 9 hours ago Milan Cutka has updated the CVS again:
e.g. VSSH FOURCC support - plays realtime and normal quality VSofts H.264 encoded files

Hellfred

bond

11th April 2004, 15:32

Originally posted by hellfred
Just in case you did not notice up to now: 9 hours ago Milan Cutka has updated the CVS again:
e.g. VSSH FOURCC support - plays realtime and normal quality VSofts H.264 encoded filesnice!

milan, if you are reading this can you plz also have a look at the mpg splitters from mainconcept and moonlight (their encoders output .mpg files), their splitters are available for free, would be great if ffdshow could also connect to them!

edit: these two splitter also allow parsing of plain h.264 bitstreams (.264) as outputted by the reference encoder for example
would be great if we could use ffdshow to decode these too

Selur

11th April 2004, 16:06

plays realtime and normal quality VSofts H.264 encoded files
nice :)

CruNcher

12th April 2004, 05:53

http://cruncher.mufflastig.com/ffdshow/

their it is was optimized for p4 in mind but should work on amd also gives me a small speedup in my hdtv mpeg4 content test :)

TheShadowRunner

14th April 2004, 00:12

About Quicktime SVQ3, it's still broken in Athos' latest build :
ffdshow-20040405.exe
The problem is ffdshow crashes the player (whatever it is, ZP, WMP6.4, etc..) with an error in "libavcodec.dll"
The last ffdshow version to work ok with SVQ3 is ffdshow-20040312.exe

For exemple this spiderman trailer in SVQ3 works perfect with 0312, but not with 0405. (video only since audio is qdesign)
http://int1.fp.sandpiper.net/sonypde/spider-man_2-tlr_us_320.zip
Later,

TSR

Sirber

15th April 2004, 14:33

In registry, what does "hwOverlay" do at "2" ?

m0rbidini

16th April 2004, 09:56

Hi everyone,

I have a tiny problem with ffdshow subtitles support (latest athos builds up until 2004-04-05). I have some (a lot actually) subtitles that fail to display a lot of lines If I set the vertical position > 96%. With the build dated 2003-11-28 it works correctly even if I set the vertical position to 100%. Don't know if this is a bug or not, though.

Here's a link of a (portuguese) subtitle that fails in ffdshow: example (http://pwp.netcabo.pt/m0rbidini/example.srt)
These lines, among many others, fail to render:

195
00:17:17,360 --> 00:17:18,270
Não!

196
00:17:18,920 --> 00:17:20,399
Não, não, não!

197
00:17:20,960 --> 00:17:23,633
Trinta e seis vezes, não!

198
00:17:23,880 --> 00:17:26,155
Enviaram-me um guinéu? Não!

Thanks everyone.

athos

18th April 2004, 15:55

New build today. Same location.
Compiled partly with ICL 7.1

Andy2222

18th April 2004, 16:05

Originally posted by athos
New build today. Same location.
Compiled partly with ICL 7.1

little notice for those build: the new "half mode" integration bugged the nic's pp filter and also the asharp filter, if u enable those filters u get a green screen or a strange sharped picture. All other "normal" filters seems to work.

LotharZ

18th April 2004, 22:58

Originally posted by athos
New build today. Same location.
Compiled partly with ICL 7.1
With this new build Im getting a green screen with messed subs when Ive some of the "Processing Method" is enable and "Subtitles" at same time.

ffdshow-20040418 + WMPC 6.4.8.2 + Win2k3

BoNz1

18th April 2004, 23:36

Yay, ffdshow can now play video encoded with CABAC p-frames so vss good quality now works.
EDIT: and at a very respectable 50% cpu load on a P4 1.6 at 704x288.

oddball

18th April 2004, 23:49

I've given up on ffdshow for the time being. Playing with XviD b4 decoder and enjoying jerk free playback.

TheShadowRunner

19th April 2004, 00:01

woohoo! something must have been done regarding SVQ3 since the latest Athos build (ffdshow-20040418) now works again without crashing libacodec.dll.
However the framerate doesn't resolve, and it's MUCH slower than with ffdshow 20040312; but at least it doesn't crash ;)
Later,

TSR

Tommy Carrot

19th April 2004, 12:06

Originally posted by BoNz1
Yay, ffdshow can now play video encoded with CABAC p-frames so vss good quality now works.
EDIT: and at a very respectable 50% cpu load on a P4 1.6 at 704x288.

The CABAC support is not perfect yet, the moving objects leave trails and blocks behind, which are not there with the VSS decoder. No problems with CAVLC decoding though. :)

gotaserena

19th April 2004, 20:17

Forgive me if this is a known issue (I wouldn't call it a problem)

I've been comparing the output of XviD decoding with both ffdshow and XviD decoders. I found that ffdshow colours are consistently shifted to magenta and/or blue when compared to XviD decoder.

Is it something that can be simply fixed (I've tried shifting to XviD4, but there was no difference), or is it something having to do with MPC?

LigH

19th April 2004, 20:31

ffdshow provides several iDCT functions - did you compare them all?

BoNz1

19th April 2004, 20:43

Originally posted by Tommy Carrot
The CABAC support is not perfect yet, the moving objects leave trails and blocks behind, which are not there with the VSS decoder. No problems with CAVLC decoding though. :)

Ah, yes you are right. I just checked my test clip and there are a few small trails but so you are right it isn't perfect yet however, the trails are almost unnoticable in my test clip.

dslava

22nd April 2004, 12:46

With thå new build I get green screen with messed up subs everytime sub showing up

ffdshow-20040418
WMPC 6.4.8.2
Win XP

Lekanda

22nd April 2004, 18:22

I can confirm that. Also OSD-on turns everything green.

CruNcher

22nd April 2004, 20:21

http://cruncher.mufflastig.com/ffdshow/

x264 support

*link corrected*

LigH

22nd April 2004, 20:35

DOKUMENT NICHT GEFUNDEN

Die von Ihnen angeforderte Seite

wurde nicht gefunden.

....hosted by KONTENT

rds_correia

22nd April 2004, 22:14

Originally posted by athos
New build is up on SF. This time I skipped ICL7 and used the regular MSVC++6 compiler, as the builds since 2002-12-13 has caused Explorer to crash when building thumbnails for video files in thumbnail view. This one doesnt seem to do that, at least not yet. Please post your findings regarding stability and possible performance loss (or gain?).
Hi Athos,
Last version I used was ffvfw-20030927.exe.
I know this is FFdshow but from what I've been told both products are now bundled in FFdshow, right?
If so, then my feedback is positive.
I've always had Windows Explorer's crashes due to just hovering the mouse cursor on top of a makeAVIS fake avi.
With the latest release I have ffdshow-20040418.exe this doesn't happen.
BTW I have a problem with the new fake avis provided by makeAVIS.
When used with mencoder, for instance, the encoded stream gets upside down :(
Any ideas why?
Cheers buddy.

Tommy Carrot

22nd April 2004, 22:48

Originally posted by CruNcher
http://cruncher.mufflastig.com/ffdshow/

x264 support

Wow, looks great! It's faster and easier to configure than VSS codec. My opinion about the quality is coming soon. ;)

First issue: it doesn't insert keyframes into the scene-changes.

Tommy Carrot

22nd April 2004, 23:26

Hmm, after a brief test, the VSS codec seems to be the winner. The image is more solid, and it preserves the details better. But it's only a brief test, i'm not sure we can extrapolate the result to every bitrates and scenarios.

Anyway, great to see a working open-source implementation.

BoNz1

22nd April 2004, 23:48

Originally posted by Tommy Carrot
Wow, looks great! It's faster and easier to configure than VSS codec. My opinion about the quality is coming soon. ;)

First issue: it doesn't insert keyframes into the scene-changes.

Well there is no frame decision just a fixed pattern and constant quant. It does work rather well and is relatively fast. I used the standalone exe a couple of weeks ago. When I used it there was a lot of inline assembler which as you might know is not too windows friendly. Some of the assembler has been ported for nasm since then but definitely not all I don't think, so a lot of the code you are running is just c code I think.

gitoshi

23rd April 2004, 02:05

is the Luminance Gain crash gone in the 20040418 version????
Asharp filter is broken.

G

arno

23rd April 2004, 08:55

Originally posted by gitoshi
is the Luminance Gain crash gone in the 20040418 version????
Asharp filter is broken.

G

Crash seems to be fixed over here... :-)

Arcon

23rd April 2004, 14:06

Originally posted by CruNcher
http://cruncher.mufflastig.com/ffdshow/

x264 support

*link corrected*
if i install it i can play xvid files with it but as soon as i try to open the settings window i get an access violation at 029f687f, write of address 00000007.

i'm back at build 040405 :(

Tommy Carrot

23rd April 2004, 15:55

Originally posted by Arcon
if i install it i can play xvid files with it but as soon as i try to open the settings window i get an access violation at 029f687f, write of address 00000007.

i'm back at build 040405 :(

Yupp, same here. Athos' 20040418 build is safe to use though, but it doesn't have x264 codec support.

athos

24th April 2004, 15:47

New build today.

libavcodec is updated
Managed to compile _all_ VC stuff with ICL 7.1, except TomsMoComp.
Targetted at i686 (in VC and GCC)
Win9x install path ($SHORTINSTDIR)
included makeAVIS.exe
included skl_drv_mpg.dll
included ff_x264.dll
Andy2222's OM fix
had to comment out declaration of getCodecFOURCCs, I hope this doesnt break anything.

Soulhunter

24th April 2004, 18:29

Originally posted by athos
New build today.
Nice... :)

But as suggestion:

Its always a pain to (re)search the link to your ffdshow builds in my favourite's... :(

Could you maybe add the link into your sign or the posts to make access easier ???

Tia n' Bye

athos

24th April 2004, 18:44

Originally posted by Soulhunter

Could you maybe add the link into your sign or the posts to make access easier ???

Good idea, added it to my sign.

Soulhunter

24th April 2004, 18:52

Originally posted by athos
Good idea, added it to my sign. Lovely... :D

THX n' Bye

iradic

25th April 2004, 17:53

i have problems with decoding xvid rc3 with ac3 or mp3 audio with libavcodec...

always happens at same frame (it seems it skips few frames) and a/v synch is lost afterwards...
without audio it looks to me like it doesnt skip frames...

decoding with xvid decoder is just fine (with/without audio)...

tried latest build and 29-03-2004 and ac3-filter 0.7, mp3 from besweet profile for avi, muxed with vdubmod or nandub...

skynetman

25th April 2004, 22:25

20040424 solved all my problems with gain and offset crash on AMD + win2003.
Well done ;)

Affar

26th April 2004, 00:17

Hi

I have a problem with versions after 23-3-2004.

In first case, my AMD K6-2 400Mhz is crash in every players, but in before versions works fine.

In second case, i have problems to decoder some videos (XviD 1.0 RC4), and to fix this i need to desactivate "autodetect" in Miscellaneous option. Here are sample with this bug http://www.portaldivx.com/error_ffdshow.avi [548k]

Thanks and sorry for my poor english

Kurosu

26th April 2004, 08:12

@Affar
You processor hardly support anything else than MMX: I believe there is no 3DNow code that isn't iSSE in fact. So someone will have to make a specific build, as the ones around here are for Athlons and P4s.

@All (and especially Didée and some others)
Date: Sun, 25 Apr 2004 21:03:37 +0200 (CEST)
From: Michael Niedermayer CVS <michael@mplayerhq.hu>
Reply-To: ffmpeg-devel@lists.sourceforge.net
To: ffmpeg-devel@lists.sourceforge.net
Subject: [Ffmpeg-devel] CVS: ffmpeg/libavcodec h263.c,1.248,1.249

Update of /cvsroot/ffmpeg/ffmpeg/libavcodec
In directory mail:/var2/tmp/cvs-serv14794

Modified Files:
h263.c
Log Message:
fix decoding with quant matrixes which contain elements <16
I think that is something you all waited for. I don't have videos to test if the change really improved decoding.

Didée

26th April 2004, 08:16

fix decoding with quant matrixes which contain elements <16
/* me starts dancing around, on, and under the table*/ ;)

Kurosu

26th April 2004, 08:20

Actually, I'm not that sure anymore. I don't know if h263's DCT/quant functions are actually used in all MPEG-like (de)coders.

Andy2222

26th April 2004, 13:36

Originally posted by Kurosu
@Affar
You processor hardly support anything else than MMX: I believe there is no 3DNow code that isn't iSSE in fact. So someone will have to make a specific build, as the ones around here are for Athlons and P4s.

All ffdshow builds are not "special" builds for Athlon's/P4, Athos used "blend" for the older and "/G6" wich means pentium pro class cpu compiles for the new compiles. Even a /G7 compile wich means "pentium 4" class will run on older cpu's. Only a gcc -"--march=pentium4" build will not run on other CPU's than P4, but Athos surly used "mtune" or "mcpu" for the gcc stuff.

The AMD K6-2 is surly a pentium pro class cpu, so it should work. Maybe ask athos to build a "blend" compile as fix.

Affar can u open the ffdshow setting's page and can u try run a movie with all filters disabled?

Kurosu

26th April 2004, 15:16

Originally posted by Andy2222
[B]All ffdshow builds are not "special" builds for Athlon's/P4, Athos used "blend" for the older
I was refering to gcc-compiled parts, but you are nonetheless true. However, if you check Makefiles/source lists, you can notice that mpeg2enc and ffmpeg build SSE code. I don't know if it's actually used. But I don't think that an error such as mixing iSSE ops with MMX/3DNow ops is the source of the error, otherwise it would have been signaled and fixed a long time ago in ffmpeg.

One solution would be to disassemble dlls/ax with nasm, and grep the output for non-MMX/K6 ops. Checking if that code is actually used comes next.

Andy2222

26th April 2004, 15:52

Originally posted by Kurosu
I was refering to gcc-compiled parts, but you are nonetheless true. However, if you check Makefiles/source lists, you can notice that mpeg2enc and ffmpeg build SSE code. I don't know if it's actually used. But I don't think that an error such as mixing iSSE ops with MMX/3DNow ops is the source of the error, otherwise it would have been signaled and fixed a long time ago in ffmpeg.

One solution would be to disassemble dlls/ax with nasm, and grep the output for non-MMX/K6 ops. Checking if that code is actually used comes next.

The question is what part of ffdshow crash for Affar, libav or ffdshow.ax or mplayer.dll or some of the other dll's. All the mmx2/sse1+2 code is only used if the cpu support it, otherwise the normal mmx function is used. The only problem i know are some mmx2 (pshufw) instruction's wich are used in the so called mmx version's but are mmx2 instructuion's (i think it was in the nic pp). But i think the k6-2 also have mmx2?

The problem is prolly the same like the "offset" crash wich is "fixed" now but i dont see any special code change wich direct fixed that crash, so its more like a random fix. Aka new version work old dont and no1 know realy why :)

Kurosu

26th April 2004, 16:02

Originally posted by Andy2222
But i think the k6-2 also have mmx2?Basically, it's 3DNow! 1 (not Extended/2) that introduced (most of) the new integer ops. I think that is also called MMX Extended. By changing caching stuff, you should have iSSE. One exception might be pavgusb (3DNow!)<->pavgb(iSSE) which maybe has a different code.

The problem is prolly the same like the "offset" crash wich is "fixed"I don't know if the fix was committed to CVS, but I never had this problem. Probably because of what you described.

athos

26th April 2004, 16:06

Just a note: the latest builds i have targetted for Pentium Pro (i686) cpu classes. So in VC i use /G6, and in GCC i use -march=i686. The default settings from CVS are (mostly) Blend in VC, and -march=i586 -mcpu=i686 in GCC. I decided to go I686 all the way since I didnt think anyone uses below-i686-class cpus for decoding.

Andy2222

26th April 2004, 16:13

Originally posted by athos
Just a note: the latest builds i have targetted for Pentium Pro (i686) cpu classes. So in VC i use /G6, and in GCC i use -march=i686. The default settings from CVS are (mostly) Blend in VC, and -march=i586 -mcpu=i686 in GCC. I decided to go I686 all the way since I didnt think anyone uses below-i686-class cpus for decoding.

yeah -march=i586 should prolly work on all cpu's these day's. Btw u dont have to use -mcpu=i686 since march=i586 overwrite that option. march produce code special for that cpu, while -mcpu build code for that special cpu too, but will also run on any other.

Example: -march=pentium4 will produce code special for p4 wich prolly crash on any other cpu. While -mcpu=pentium4 will also produce code for P4 but dont crash. In general for max. compatibility only use -mcpu or -mtune for gcc 3.4.

I tested some march against mtune or mcpu for my athlon-xp and i dont see any speed improvments or looss. Its prolly cause all the cpu intensive functions are asm coded and arnt effected by special compiler switches.
--------------------------------------------------------------------

-mcpu=cpu-type
Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions. The choices for cpu-type are i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium4, k6, k6-2, k6-3, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp, winchip-c6, winchip2 and c3.
While picking a specific cpu-type will schedule things appropriately for that particular chip, the compiler will not generate any code that does not run on the i386 without the -march=cpu-type option being used. i586 is equivalent to pentium and i686 is equivalent to pentiumpro. k6 and athlon are the AMD chips as opposed to the Intel ones.

-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mcpu. Moreover, specifying -march=cpu-type implies -mcpu=cpu-type.

Affar

26th April 2004, 20:55

@Andy
The error happens when i try to watch the video because the config is ok.

@athos
Ever now that everyone have modern pcs, there's still people that have a pc that is non compatible with those instructions. 23-5-2003 version works perfectly and it's, without a doubt, the version that consumes less resources, but this versions doesn't warked with xvid 1.0 with packed bistreams, apart from the new functions in the ffdshow.

I hope you can solve this problems. Seeya

athos

26th April 2004, 21:19

Originally posted by Affar

@athos
Ever now that everyone have modern pcs, there's still people that have a pc that is non compatible with those instructions.
I'm not sure if i686 introduced any new instructions? We are talking pre-mmx here, processors with speed below 200mhz.
Maybe the problems are not due to the compiler flags i use, as this change was only in the latest 3 or so builds.

Andy2222

26th April 2004, 22:17

Originally posted by Affar
@Andy
The error happens when i try to watch the video because the config is ok.

"..because the config is ok." ???

so u get a crash message? Can u post this message since i still dont have a clue which part of ffdshow crash....

@Athos dont worry its prolly not a 586 or 686 code problem, the AMD k6-2 is a pentium pro class cpu and the change to 686 will just crash pentium 1 cpu's... aka 200-250Mhz cpu's. And if some1 cant get a new cpu for 40$ and still want use ffdshow with his 250Mhz cpu than something is wrong :)

avih

26th April 2004, 22:30

eventhough the latest (2004-04-24) works amazingly well with my computer (Athlon Xp 2500+) especially ffvfw, i think that many ppl will benefit from a a build with fewer optimizations (would mmx be the minimal? i tend to think so).

i.e. my brother still uses a celeron 300, many others still use lower specs pc since not everyone has the money to upgrade (i only recently upgraded from duron 800), and some just use a secondary old pc as a living-room playback machine.

of course, it all depends on the good will of the builders (i.e. athos and others). if, though, u think it's a viable option (as myself) i suggest posting a poll about what computers will be used with such ffdshow/ffvfw builds. again, my guess is that mmx only is the sweet spot in this regard.

cheers.

Affar

27th April 2004, 03:40

@Andy2222

Here is the message error:

http://www.portaldivx.com/pc_viejo1.gif
In every player appears same message (or similar).

Seeya

Blkbird

27th April 2004, 06:08

Why isn't any Open Type fonts using OTF container showing up in the font list for subtitle? I only see fonts using TTF container.

Owen

27th April 2004, 22:05

Since we are on the subject of CPU optimisations, I would like to request a fully P4 optimised build for use HTPC users who push FFDShow to the limit. Even a 3.5Gig P4 is struggling when you get really serious with FFDShow filters and an optimised version to take full advantage of the P4’s capabilities would be great.

I’m sure the Athlon XP users would appreciate an optimised version as well.

Is it possible to do a build that can do both P4 and Athlon XP without compromising performance of either?

It would be a great pity if the performance of FFDShow was to be compromised just to allow compatibility with outdated CPU’s.

Even P3 and early P4 or Athlon CPU’s are to slow for effective use of FFDShow filters. Older CPU’s have no chance.

Thanks

Owen

ADLANCAS

28th April 2004, 03:28

I’m sure the Athlon XP users would appreciate an optimised version as well.
I´m in this team.;)

esby

28th April 2004, 05:51

For me ffdshow is a general purpose decoder,
Not a beast running at the max speed it can the maximum ammount of filters when playbacking...
I explain,
if it can decodes and do some filtering, that's ok.
But if you want to use it like avisynth, while keeping the fps to the top,
you'll need something better than the two upcoming generations of processors no matter the brand,
unless you plan to buy a z-serie machine from ibm...

And don't forget that heavy filtering don't enhance this much the video quality,
since it tends more to denaturate it than anything else.

esby

PS: but I agree that if someone can do cpu optimization
without running into futher problems it will be ok for me...

Andy2222

28th April 2004, 13:05

Originally posted by Owen
Since we are on the subject of CPU optimisations, I would like to request a fully P4 optimised build for use HTPC users who push FFDShow to the limit. Even a 3.5Gig P4 is struggling when you get really serious with FFDShow filters and an optimised version to take full advantage of the P4’s capabilities would be great.

Is it possible to do a build that can do both P4 and Athlon XP without compromising performance of either?

Thanks

Owen

"Is it possible to do a build that can do both P4 and Athlon XP without compromising performance of either?" nope

since u have to tell the compiler for what CPU u want to schedule the instruction's, there is no compiler wich can include more than 2 way's (normal i386 and the specific CPU) pathed code.

The problem is that the P4 is in some causes a very "strange" cpu compared to the P3 or AMD Athlon, wich means that the compiler change some stuff for the P4 for optimal performance, while those changes might slow down if executed on the Athlon.

A full optimized P4 or Athlon build wont boost the performance btw. since the compiler cant magically integrate mmx or sse code. The compiler arrange/schedule instructions for the special cpu (if u tell him) and thats all. U have to look at the most consuming functions to understand why ffdshow takes so much cpu time. 20%-30 goes to libavcodec.dll for decoding the frames, around 20-40% goes to the mplayer.dll (resize/sharpen function wich depends on the type and how big u resize) and 20-60% goes to ffdshhow depending on wich filters/color conversion u have enabled.

To build a AMD or P4 version some1 has to review all the hand coded asm code for those newer CPU's and optimize them. That means not only a general mmx/mmx2 or sse1/2 version. It means to arrange/use asm instructions special for athlon or p4.
The main problem is that the code is already in ASM syntax, so its a damm pain to understand what its going on in that parts .... u will prolly need the org. plain C++ version's and rewrite the asm parts complete new. But where to get the org. C++ version's, they arnt in the code anymore...