Log in

View Full Version : dffshow filter


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14

Smiff
15th January 2003, 13:42
wow, this thread still hasn't been renamed!

dffshow -> ffdshow.

:p :D

NiTroGen
15th January 2003, 15:08
Originally posted by Smiff
wow, this thread still hasn't been renamed!

dffshow -> ffdshow.

:p :D
Maybe we should rename the filter. ffdshow --> dffshow!!! :D ;)

masken
15th January 2003, 15:38
Originally posted by Koepi
post processng removes artefacts on low bitrate encodings (think of them as artificial details which get wiped out).

Now imagine you have a high bitrate encode, and the details aren't artificial "errors" but wanted. There's no way to detect that the details belong there, so they get wiped out as well, looking worse in the end than without post processing.hmm.. just a small idea... can't one detect the bitrate of the .avi and control post-processing degreees based upon that? SBC postprocessing? :D Perhaps I should go and stand in a corner now hehe... since I'm no programmer? ;)

kilg0r3
15th January 2003, 15:56
@ masken

it would be even cooler to link the degree of pp to the visual quality (i.e. blocking and ringing), which would make pp kick in in blocky highmo scenes. if one cannot determine the degree of blocking, i - if i were a programmer- would use a coefficient of motion, bitrate, resolution ...

joining you in the corner now ... :)

Wormz
15th January 2003, 19:17
What's wrong with the way it currently is, where it automatically lowers postprocessing if it has to due to CPU usage? I think that is a perfect implementation of postprocessing.

kilg0r3
15th January 2003, 19:43
@Worm

you care about cpu usage. this is perfectly alright. i only care about image quality. so, my criterion is entirely independent from cpu usage. pp _degrades_ image quality when you have a good encode but it helps when the video is full of blocks and ringing (read also koepi on previous page).

an adaptive approach is alright. yet, if there is enough cpu power it is far smarter to take the quality of the source data as criterion for the degree of pp.

just my 2 iraqi dinar

athos
15th January 2003, 21:20
I suppose you could make some sort of "guesstimate" regarding the quality of a clip by computing the lenght of the movie * the dimensions (ie bits per pixel, more or less), and then setting threshold values for the amount of postprocessing. Of course this would not be very accurate, as some movies (high motion, bad source, etc) require higher bitrate.

Wormz
15th January 2003, 22:25
Originally posted by kilg0r3
@Worm

you care about cpu usage. this is perfectly alright. i only care about image quality. so, my criterion is entirely independent from cpu usage. pp _degrades_ image quality when you have a good encode but it helps when the video is full of blocks and ringing (read also koepi on previous page).

an adaptive approach is alright. yet, if there is enough cpu power it is far smarter to take the quality of the source data as criterion for the degree of pp.

just my 2 iraqi dinar

Ok, hmm, I understand. Yes, I would say it's nearly impossible for it to autodetect whether it would be a good idea, and calculating based on bitrate, resolution, etc. seems unrealistic as well. I've never noticed postprocessing degrading quality, so I'm gonna do a few tests of my own. Are we talking 2CD rips only or maybe even some 1CD rips on highly compressible movies?

NoLogo
15th January 2003, 22:36
Yes ! that's exactly the request I did on sourceforge ! no PP for good encodes, especially on low bitrate scenes. That features would be some great Xmas present :)
I have seen that PP tends to smooth a little the faces, the pavements, etc...
Isn't it possible to use motion vectors to evaluate when it's low mo and when it's not ?

Regards
NoLogo

NuclearFusi0n
30th January 2003, 00:27
REQUEST
-------

PAR support: say i encode an NTSC video at 720 x 480, the 1:1 resolution
I want to just enter the Pixel Aspect Ratio (in anamorphic encodes, it's 72/79 * 4/3 = 1.21519) and have it correctly display the video with a resolution UPSIZE (retaining full resolution), not downsize (losing vertical resolution usually).

Chibi Jasmin
30th January 2003, 11:58
Originally posted by NuclearFusi0n
REQUEST
-------

PAR support: say i encode an NTSC video at 720 x 480, the 1:1 resolution
I want to just enter the Pixel Aspect Ratio (in anamorphic encodes, it's 72/79 * 4/3 = 1.21519) and have it correctly display the video with a resolution UPSIZE (retaining full resolution), not downsize (losing vertical resolution usually).

I second that! If you implement it, please let us have a few user-defined presets for it as well :-)

And while you're at it...the long promised black borders rework...adding black borders by percentage and stuff...would also be great... :D

Smiff
30th January 2003, 12:09
heheh i gave up on the borders and adjusted my TV

:D

No really, Sony Service menus are confusing as all hell but now i got no overscan with DVD or Sky either :) (can ffdshow do that? ;)

oddball
31st January 2003, 04:19
My TV is adjusted down to 1% or less overscan. It's adjusted as low as it can be before blooming causes odd black edges and corners to appear. The problem is with the way my Matrox G400 outputs the image. It appears to create additional overscan of it's own. Also with the position on my TV. If I adjust the TV signal so it's central and then go to SVID3 for my TV out card the SVID3 image is off center with a border on one side (This is when I set ffdshow to black borders and bring the border size up).

Ideally I would like ffdshow to come up with a more adjustable and less CPU intensive means of creating black borders (The ability to adjust left/right/top/bottom borders independently for instance).

Their is a 3rd party divx playback util called DiVXG400 that allows overscan compensation. His method uses just about 0% CPU and creates the black border effect nicely. However. There is a bug on it that causes 4:3 images sent to a widescreen TV using the Matrox G400 in 16:9 mode that causes the top and bottom to not get overscan compensation. It squeezes the image from the sides just fine. Also if you set the G400 TV out to 4:3 mode it squeezes the bottom fine. I reported this as a bug to the developer of DiVXG400 but he denies it is and has no intention of sorting it out. So I have to switch back and forth between the two modes to get DiVXG400 to overscan compensate correctly for all video playback ratios.

ffdshow is so CPU intensive when it adds black borders that my lowly P3 700 cannot keep up.

It's still #1 on my list of top wishes for ffdshow to sort out.

Smiff
31st January 2003, 10:35
You are right of course, controls are needed. My TV seems to save settings for each input, in particular RGB centering is invaluable. A major problem I have is that i can calibrate for PAL (my region), but then NTSC DivXs are wrong, and vice-versa. It's a bummer. And like you say, you can't eliminate the overscan completely because the TV isn't stable enough.. at least any i can afford.

Bummer eh :( ;)

I don't think you should find a ffdshow too slow on a P3-700... i have found even an Xvid with GMC and Qpel is not too much for my Duron 750 that i use for that... seriouly, i am very fussy about jerky playback, i think you might have to watch your settings better? Sometimes clean reinstalling ffdshow seems to help.

Chibi Jasmin
31st January 2003, 12:01
Originally posted by oddball
My TV is adjusted down to 1% or less overscan. It's adjusted as low as it can be before blooming causes odd black edges and corners to appear. The problem is with the way my Matrox G400 outputs the image. It appears to create additional overscan of it's own. Also with the position on my TV. If I adjust the TV signal so it's central and then go to SVID3 for my TV out card the SVID3 image is off center with a border on one side (This is when I set ffdshow to black borders and bring the border size up).

Ideally I would like ffdshow to come up with a more adjustable and less CPU intensive means of creating black borders (The ability to adjust left/right/top/bottom borders independently for instance).

Their is a 3rd party divx playback util called DiVXG400 that allows overscan compensation. His method uses just about 0% CPU and creates the black border effect nicely. However. There is a bug on it that causes 4:3 images sent to a widescreen TV using the Matrox G400 in 16:9 mode that causes the top and bottom to not get overscan compensation. It squeezes the image from the sides just fine. Also if you set the G400 TV out to 4:3 mode it squeezes the bottom fine. I reported this as a bug to the developer of DiVXG400 but he denies it is and has no intention of sorting it out. So I have to switch back and forth between the two modes to get DiVXG400 to overscan compensate correctly for all video playback ratios.

ffdshow is so CPU intensive when it adds black borders that my lowly P3 700 cannot keep up.

It's still #1 on my list of top wishes for ffdshow to sort out.

Well, DivXG400 is what I am using now, but I thought of getting rid of it and having its functionality of adding black borders integrated into ffdshow...the way it is now in ffdshow I always have to enter the final dimensions myself and set resize to none to get black borders, instead of just entering a percentage to add black borders...

DivXG400 doesn't seem to be updated anymore, it can't display latest VobSub subs etc...

Defiler
31st January 2003, 15:41
I'm seeing some green artifacts watching DivX 5.03 files with ffdshow-alpha 01-03-2003.
Is this old news, or am I the only one?

Monarc
31st January 2003, 18:08
Originally posted by Defiler
I'm seeing some green artifacts watching DivX 5.03 files with ffdshow-alpha 01-03-2003.
Is this old news, or am I the only one?

I don't know. Could you provide a example? (jpeg / avi)

Bye,
Monarc

drebel
31st January 2003, 18:10
DivXG400 doesn't seem to be updated anymore, it can't display latest VobSub subs etc
...plus it has no yv12 support.Best way to remove letterbox is to enable special resolutions on tv by modifying drivers(nv4_disp.inf for example) like 768x576 and tvtool for nvidia or something similar

oddball
31st January 2003, 21:02
There is no such utility for Matrox cards. Sizing of output in players like Zoomplayer have no effect whatsoever on TV overlay output. A lot of TV out cards rely on just displaying the desktop to the TV so that when you zoom to fullscreen on your monitor you get fullscreen on your TV and can resize in Zoomplayer on the screen to your hearts content. But this does not give an accurate display of the image and incorrect colours.

The Matrox cards and some others display a correct TV output using overlay. This means you can have a windowed Zoomplayer for instance but it's still fullscreen on the TV and correctly displays the image/res/colours etc.

So the problem I have is that ffdshow does not add borders without a huge hit on CPU usage or use a bugged DiVXG400. Ideally I'd love to continue using ffdshow for this. I cannot afford to upgrade my PC at present and believe if DiVXG400 can do a similar thing with little or no CPU hit why cannot ffdshow?

Smiff
31st January 2003, 21:14
Originally posted by oddball
There is no such utility for Matrox cards. Sizing of output in players like Zoomplayer have no effect whatsoever on TV overlay output.

They do if you change an option in Matrox's config.

Defiler
1st February 2003, 00:07
Originally posted by Monarc
I don't know. Could you provide a example? (jpeg / avi)

Bye,
Monarc
DivX 5.03, 1.24MB:
http://hellninjacommando.com/temp/divx503.avi

If you play it with ffdshow, you'll see odd green smearing. With DivX 5.03 as the decoder, it looks fine.

jcsston
1st February 2003, 09:30
Originally posted by Defiler
DivX 5.03, 1.24MB:
http://hellninjacommando.com/temp/divx503.avi

If you play it with ffdshow, you'll see odd green smearing. With DivX 5.03 as the decoder, it looks fine.
I see the odd green smears to with the ffdshow too? :confused:
My B-frame encodes with DivX 5.0.3 don't have this, but I'm guessing it's the new QPel?

Chibi Jasmin
1st February 2003, 11:25
Originally posted by drebel
...plus it has no yv12 support.Best way to remove letterbox is to enable special resolutions on tv by modifying drivers(nv4_disp.inf for example) like 768x576 and tvtool for nvidia or something similar

Since YV12 overlay is buggy, when using RGB-output, on Matrox, I can live with that, but you're right, of course.

Chibi Jasmin
1st February 2003, 11:26
Originally posted by Smiff
They do if you change an option in Matrox's config.

So what is it, please?

sam_b
1st February 2003, 12:41
Unchecking "autodetect" in "misc" fixes that clip you posted, at least for me. Got some nasty chroma smearing.

sillKotscha
1st February 2003, 13:15
'autodetect' enables 'divx and xvid qpel bug' as a workaround but obiviously fails in this case - I guess Divx qpel are corrupt (big encoder bug) and ffdshow tries to get rid of this bug but can't handle it propperly... = green effect. So, you can enable all other encoder bug workarounds except 'divx and xvid qpel bug' and of course 'autodetect'. Now qpel are shown as they are and not tried to be corrected.

I guess a new release of ffdshow may be able to detect this bug properly but it won't be nothing else than to get rid of a crappy divx bug...

or even better DivX.com is able to release a propper codec :D

regards Sill

oddball
1st February 2003, 19:49
I'd just like to add that I watch a lot of anime fansubs and most of those are in 4:3 and have subs very low that can sometimes be cutoff the bottom of the TV out. Thus you see my dillema ;)

Defiler
2nd February 2003, 07:05
Can someone tell me what the Accurate Deblocking OSD option is reporting?
Adjusting/Disabling postprocessing doesn't seem to change it.. but files with higher resolution have higher numbers. I've seen values between 32 and 40, and they don't seem to change during any given file.
I can't get the CVS checkout to work, so I can't consult the source to learn more.

Monarc
3rd February 2003, 08:45
Originally posted by Defiler
DivX 5.03, 1.24MB:
http://hellninjacommando.com/temp/divx503.avi

If you play it with ffdshow, you'll see odd green smearing. With DivX 5.03 as the decoder, it looks fine.

Michael Niedermayer fixed the bug in libavcodec (ffmpeg).
You have to wait for a new ffdshow version.

Bye,
Monarc

((( atom )))
3rd February 2003, 23:07
i recently understood from some posts, that the qpel-smearing was fixed meanwhile, so i got the latest build from koepi and found it still smear all over my favorite smearing test-scene when using ffdshow with and without the qpel-bug fixing option.

did i get something wrong? i'd really like to use that feature..

MaTTeR
3rd February 2003, 23:43
I'd say the Qpel smear problem is not totally fixed but it's certainly minimal compared to what we were getting. I don't notice the smear in all scenes now, only a few during the movie playback. Perhaps on the high quantizer frames?

Monarc
4th February 2003, 01:48
Originally posted by ((( atom )))
i recently understood from some posts, that the qpel-smearing was fixed meanwhile, so i got the latest build from koepi and found it still smear all over my favorite smearing test-scene when using ffdshow with and without the qpel-bug fixing option.

Again.

Could you provide an Avi? :)

Or

Test it yourself with mplayer (linux / newest cvs version)
and report the bug to the mplayer-users list.

Bye,
Monarc

((( atom )))
4th February 2003, 02:54
here you go:

used binaries and settings:

koepis XviD-02022003-1 (same result with older ones, though)
ffdshow-20030103

fourcc: xvid
q-pel
chroma motion
dx50 b-vop compatibility

if i use xvid to decode, everything looks fine.

i'll upload 1mb of an avi here and hope it's ok with the mods. if not, please just delete it, so i'll have to find another place..

((( atom )))
4th February 2003, 02:59
..hmmm, while uploading the avi, i figured, that .avi wasn't a valid file-extension to upload, so i pressed the stop-button of my browser and the message still got posted, just without the avi.

so here comes the zip.. even would fit on a floppy (1.44mb). ;)

((( atom )))
4th February 2003, 03:07
..hmmm, while uploading the avi, i figured, that .avi wasn't a valid file-extension to upload, so i pressed the stop-button of my browser and the message still got posted, just without the avi.

argh! -when i just tried it again with a zip-file, i was told that i exceeded the mamimux file-size!

tha actual file is 1.44mb, so i could even attach it with an email, if somebody was willing to either host it or would just be interrested in seing it..

since it came out to right 1.44mb i could also write it to a floppy and mail it if anybody was interrested :D

raistlin2k
4th February 2003, 17:48
funny thing: FFDshow gives me green pictures only when NOT using DVobSub. During DVobSub, everything OK!

Any Idea?

Raist

athos
4th February 2003, 21:10
Originally posted by raistlin2k
funny thing: FFDshow gives me green pictures only when NOT using DVobSub. During DVobSub, everything OK!

Any Idea?

Raist
dvobsub can convert colorspaces, perhaps ffdshow (without dvobsub) outputs to a colorspace that you graphic drivers do not support?

yaz
7th February 2003, 10:22
hi all !

i got some problems with the lates built.

- i've just faced lottsa (s)vcd these days & i gave a try to ffdshow. it has the option of mpeg1/2 support but when clicked, i got only an even black screen. size, sound, eveything seems to be ok, but no picture. what i missed or did wrong? should i install or destall anything else? i use(d) elecard for mpeg1/2 but i'm not fully satisfied with the way it works. (videos are ok, all 'playable' with hard/software players)

- asharp is implemented as postproc sharpener. it does a miracle but sometimes makes some stange effects. i found anything about it in the scroll-down help & the readme of marcfd attached to its avs filter version isn't informative enough to figure out how to tune it for different quality sources. can anyone drop me a short explanation?

- if i destall all of my codecs (just a theoretical case) can ffdshow do all decoding i want in mpeg1/2/(3)/4 or it'd be better to keep something at hand? in an other way round, besides ffdshow what else should i attached to an encoded movie, for providing 'playability' the most? or is it a stupid question?

thanx in advance
yaz

wotef
8th February 2003, 05:38
for mpeg1 and mpeg2 decoding, just use the windvd or powerdvd decoder - as the tooltip says, mpeg1/2 support is not working currently, so uncheck it from ffdshow

asharp :confused: - the readme explains enough, imho, just tweak the different parameters on a test video in avisynth if you want to see the what each parameter does (should do) in ffdshow

yaz
10th February 2003, 10:31
thanx for the answers

Originally posted by wotef
for mpeg1 and mpeg2 decoding, just use the windvd or powerdvd decoder - as the tooltip says, mpeg1/2 support is not working currently, so uncheck it from ffdshow

khmm ... dunno how to ask :-) your answers prompts as if i could use the decoder (only the codecs?) from the players listed. if so, how can i do that?

asharp :confused: - the readme explains enough, imho, just tweak the different parameters on a test video in avisynth if you want to see the what each parameter does (should do) in ffdshow [/B]

yes, that's a way to go. however, ffdshow (sometimes!) imlements modified (restricted?) versions of the corresponding vd/avs filters. say, unsharpmask has 8 parameters in vd & 2-5 in avs (depending on the version) that's the only reason i asked it. ok then, i take this cute little stuff under heavy attack.

thx once more
yaz

Leak
10th February 2003, 23:25
Originally posted by ((( atom )))
i recently understood from some posts, that the qpel-smearing was fixed meanwhile, so i got the latest build from koepi and found it still smear all over my favorite smearing test-scene when using ffdshow with and without the qpel-bug fixing option.

did i get something wrong? i'd really like to use that feature..

Well - I guess you got the wrong idea of what was fixed... in your case, it's not the XviD codec being buggy (since decoding with the "use XviD" option doesn't exhibit the smearing bug), but the libavcodec code that the MP4-decoding part of ffdshow is based on.

So in order to fix your problem, you've got to wait for a new release of ffdshow, not XviD.

(Ideally, I'd have posted this 5 days ago, but who'd thunk that new accounts can only post 5 days after being created... :rolleyes: )

athos
13th February 2003, 17:01
I just wanted to say that I have experienced some problems myself with the latest (official) alpha, namely crashing of Windows Explorer when creating thumbnails for divx3 clips. If this troubles you, I would recommend the build ffdshow-20021213, as this one seems to run fine on my system.

NuclearFusi0n
13th February 2003, 19:04
so when's the new build coming out? anybody? bueller? bueller?

raistlin2k
13th February 2003, 19:29
anyone compared FFDshow to 3ivx-Decoder?

Thy offer both an automatic for CPU-load on post-processing, but which one is better in quality, performance??

For me FFDshow needs less CPU-power, moreover I think 3ivx has sometimes problems with Divx5.03-encoded samples, sometimes video slows down a lot, almost stops, but I guess it's not a CPU-problem, but DivX changed something in their encoder, old DivXDec 5.02 is unable to play my 5.03-encodes, stops always at same position.

Any results to share?

Raist

athos
13th February 2003, 19:51
Originally posted by NuclearFusi0n
so when's the new build coming out? anybody? bueller? bueller?
As soon as I am able to compile a build that actually works. The latest CVS entries indicates that milan is trying to get the colorspace stuff to work now, so lets keep our fingers crossed.

NuclearFusi0n
13th February 2003, 20:24
Originally posted by athos
As soon as I am able to compile a build that actually works. The latest CVS entries indicates that milan is trying to get the colorspace stuff to work now, so lets keep our fingers crossed.
<3

KillaByte
1st April 2003, 01:34
Hi folks.

I got a nasty overlay problem here.
When I switch to fullscreen playback the video gets very blocky (meaning that you can count the pixels - no blurring).

This can only be fixed by switching to 32 bpp.

Seems to be an ffdshow problem because with DivX 5.0.2 as decoder everything looks fine in 16 bpp.


Is this issue on the "to be fixed" list already?

karl_lillevold
3rd April 2003, 06:28
ffdshow works really well, except on one of my systems. I was curious if anyone else has noticed this problem.

With ffdshow installed, opening any AVI file takes several (>5) seconds on my dual 2.2 GHz work system. This is true even for uncompressed files with no audio. With ffdshow uninstalled, it is almost instantaneous. On another system, with pretty much the same setup, but much newer so less DirectShow "clutter" I guess, there is no problem.

The problem is player independent and occurs with MPC, mplayer2, graphedit.

i have tried ffdshow-20021213, and ffdshow-20030103, and both have the problem, on this particular system.

Are there any known problems interacting with other filters, or suggestions where to look? Maybe I will just get the source, see if I can build it, and then run it in the debugger.

Does anyone know a way to clean up DirectShow filters or detect problems?

Latexxx
3rd April 2003, 06:46
With some version of Graphedit came a program wich showed all direct show filters and their filenames. After checking the file name just press start/run.. and write regsvr32 /u blahblahblaa.dll

Defiler
3rd April 2003, 06:54
I have the exact same problem, karl. Check out this registry access log. ffdshow stalls reading this key on my dual Xeon. The second column is a timestamp. i.e. it takes almost 5 seconds to deal with the first ffdshow registry key.


7501 15.90788454 explorer.exe:1536 QueryValue HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Fonts NOTFOUND
7502 15.90790450 explorer.exe:1536 CloseKey HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders SUCCESS Key: 0xE3FAC430
7503 19.65462379 zplayer.exe:71616 CloseKey HKLM\Software\GNU\ffdshow SUCCESS Key: 0xE1FD4818
7504 19.65467872 zplayer.exe:71616 OpenKey HKLM\Software\GNU\ffdshow SUCCESS Key: 0xE1FD4818
7505 19.65470450 zplayer.exe:71616 QueryValue HKLM\Software\GNU\ffdshow\xvid SUCCESS 0x1

In comparison, using the DivX 5.03 Pro decoder, the equivalent section of the log takes less than a second to finish. No startup lag.