ffdshow development

[CruNcher]

thx athos finaly OSD bitrate display :D

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

[Calculon]

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]

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

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

[LigH]

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]

is there any special realmedia support available?

[visigotik]

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

[Gaia]

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]

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

[Stux]

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]

@Stux

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

[Stux]

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]

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]

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]

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]

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]

@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]

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]

@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]

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]

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]

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]

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]

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]

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

[wannabe]

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]

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]

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]

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

[wannabe]

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]

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]

@ 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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

Greetings

[Soulhunter]

So... What system ??? :D

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

Bye

[LigH]

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]

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]

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]

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

[wannabe]

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

[Alxemi]

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]

@ 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)