View Full Version : dffshow filter
Pages :
1
2
3
4
5
6
[
7]
8
9
10
11
12
13
14
oddball
26th September 2002, 22:50
I know you have a ton of other 'features' and bug fixes going on at the moment. But I really am looking forward to having more control over those black bars. The Luma/Chroma trick doesn't quite do what I am attempting to do. I need to be able to have independent control over the black bars for each side. Top/Bottom/Left/Right rather than just top and bottom or left and right when not locked.
Sorry to keep bringing this one to the fore. Selfish git that I am ;)
Smiff
27th September 2002, 01:28
while we're on it, could we please have numerical values of some sort for those bar sizes. To be honest, i find it a bit confusing - why is both an aspect control and the borders, aren't they doing the same thing?
milan
27th September 2002, 06:59
@Nic
Thank you. Maybe today, but surely after weekend this postprocessing will be integrated to ffdshow.
About black bars:
Aspect ratio adds black bars either at left-right or at top-bottom margins. Numerical values for black bars aren't there just becasue I had no space where I could add them. But I agree, aspect ratio/black bars needs rework. For example I need to better handle overlay aspect ratio and MPEG2 aspect information.
midiguy
27th September 2002, 08:08
I was hoping this bug would be fixed in this latest version, but it still exists. It is the video flickering (or jumping) bug. when you enable Deblock (H) luminance and/or Deblock (v) luminance in the post-processing, there are some areas of the video that start to flicker or jump. you notice it especially on areas like plain floors or on foreheads. and it seems to have this problem with everything ffdshow plays back. I think the bug is associated with the post-processing in ffdshow, and has nothing to do with the playback of a particular codec/format. any comments?
Therion
27th September 2002, 08:17
Originally posted by midiguy
I was hoping this bug would be fixed in this latest version, but it still exists. It is the video flickering (or jumping) bug. when you enable Deblock (H) luminance and/or Deblock (v) luminance in the post-processing, there are some areas of the video that start to flicker or jump. you notice it especially on areas like plain floors or on foreheads. and it seems to have this problem with everything ffdshow plays back. I think the bug is associated with the post-processing in ffdshow, and has nothing to do with the playback of a particular codec/format. any comments?
I've noticed this too. The flickering is gone when I disable the post-processing feature, but then everything gets more blocky again. So I just put up with the flickering :(
milan
27th September 2002, 08:29
Current postprocessing routines were developed by Michael Niedermayer for mplayer project. I've just copied them without almost any modification. I will test some clips in mplayer and if these artifacts will be still visible I will ask Michael if he could fix it.
BTW I would like to know if your computers support MMX, SSE or 3DNOW instructions. Results may differ for each type.
Therion
27th September 2002, 08:41
I have an old fashion Athlon 1.4Ghz, so no support for SSE...
David caid
27th September 2002, 09:58
Hello,
I was using ffdshow-20020617.exe and it was absolutely perfect.
I updated ffdshow with the new version (2002-09-23) (after desintalling the previous version). but now I have a crash of WMP related to the libavodec.dll.
It is the same behaviour that I usually encounter with my machine with other product like Koepi Xvid binaries, oggDS filter...) Those problems were related to the OS (WIN98SE) or to my hardware because of some compilations options (CPU optimisation).
Milan, I don't know how you compile the libavcodec.dll (is that you or those you are responsaible of the libavcodec development), did you make those special compilation options that could lead to problems on old CPU ?
David
Blight
27th September 2002, 11:08
Shitframes on decoding...
Using the latest Alpha build, this XVID encode (using the latest XVID build) generates this frame.
Now, loading in virtualdub doesn't have this garbage data, and neither do switching the fourcc and playing through the divx decoder.
I even tried different types of XVID encoding at first, thinking it's the XVID encoder's fault, so I tried H263/MPEG, different bitrates, encoded to huffyuv and then re-encoded, nada. When using ffdshow to decode it, I get this garbage at the start.
Nic
27th September 2002, 13:36
@milan:
Hi Milan, good luck with the code, if you need any assistance just PM me, the new dev3 code completely mucks up my DShow filter, & I dont have the time to re-write it, so once you've put in the PostProcessing from mine, ill be discontinuing my DShow filter...
OT: for dev3-api...BFRAMES are on in core not in vfw? possible xvid.h problems(?)
-Nic
milan
27th September 2002, 14:24
I believe the inclusion is quite completed. I can't test thoroughly yet (the computer I'm using right now has incredibly slow graphic card), but it seems to work. I'm not sure if you should discontinue your XviD DShow filter, but this is your decision.
OT: ffdshow doesn't handle xvid.dll with dev3 api. In fact I haven't checked that branch yet. When it will be ready to use I will modify ffdshow to support new api. I haven't tested new b frames code in xvid (variable number of b frames), but again when that branch will be more stable I will do that.
Right now I'm writing a post to xvid-devel mailing list about quantizer array export support in API 3. Method used in your filter isn't very "clean", but I think 2.1 API won't change, so I can use it too for now.
BTW I don't think this is realy OT. This is XviD forum...
milan
27th September 2002, 14:43
@Blight
please could you provide some samples? If it is libavcodec bug, I will send them to Michael. If it's bug in ffdshow, I will try to fix it.
athos
27th September 2002, 17:05
I have uploaded a new (2002-09-27) alpha build to sourceforge. I have also updated the changelog for the last alpha (2002-09-23) to include all the changes since the last stable release (2002-06-17).
Nic's postprocessing seems to work just fine, but mpeg1/2 still doesnt work well for me, especially not when seeking.
I think the problems with K6 processors are because ffdshow is compiled with Pentium Pro and higher processers as target.
Psyche
27th September 2002, 18:20
@milan:
There's a bug in your last commit to CVS.
This piece of code disables post-processing (in both mplayer and Nic's routines).
if (dxY<16 || dyY<16) return;
When entering process, dxY and dyY are zero and so there's no processing. If no processing, then init is not called and dxY and dyY are not updated with the right values never. So they're always zero and no processing done.
Also, in TimgFilters.cpp there's a
switch (cfg->postproc.method)
but case 0 falls through case 1 giving the TWO PP routines.
Besides, in the sharpen process routine you forgot to uncoment the switch for sharpen.method.
Koepi
27th September 2002, 18:47
Athos,
when uploading new builds, can you disable debug?
It's a little bit annoying during my encoding sessions ;) (but just pure cosmetical).
Thanks,
keep up the good work,
regards,
Koepi
Nic
28th September 2002, 00:23
Well done milan!! :)
Cheers,
-Nic
DeezNutz
28th September 2002, 08:55
Using the two alpha versions 9-23 and 9-27, decoding MPEG1 with ffdshow no longer works, whether I check use libmpeg2 or not. I tried both BSPlayer and Windows Media Player 6.4. I don't see any picture at all.
I have a PIII 500 with an ATI Rage Pro.
Question: if I check to use ffdshow for MPEG2, does that mean I will not require a commercial DVD decoder? Can ffdshow handle DeCSS?
Thanks for your hard work on ffdshow.
Smiff
28th September 2002, 09:58
yeah postprocessing seems to be knackered. hehe.
Blight
28th September 2002, 12:50
Warpsharp doesn't seem to be working in latest build, and the setting can't seem to be remembered after the dialog is closed/reopened.
Also, shouldn't "resize" have a checkbox on the left pane?
wizzzard
28th September 2002, 14:04
Hello,
the famous unsharp mask is definitly broken in the 20020927 build.
I have big stutters and strange(zig-zag) edges. It's not usable anymore. When I install the 20020923 version again everything is fine.
Can someone confirm this, too?
I was so keen to try the newest de-noise with the unsharp mask ;)
CU
Frank
wizzzard
28th September 2002, 14:06
Hello,
an addition.
I tried the de-noise filter. At the first try is works really good with a relativly low performance hit - thanks milan and all others.
athos
29th September 2002, 15:57
Originally posted by Koepi
Athos,
when uploading new builds, can you disable debug?
It's a little bit annoying during my encoding sessions ;) (but just pure cosmetical).
I thought I did use release settings when I compile, but I'll have a look at it for next release. Thanks for pointing this out!
Edit: I have uploaded a new build (same CVS checkout as 0927) where I hope I have disabled debug: (removed, my mistake - see Edit2 below)
I will not upload this to sourceforge for the time being, but if i did it right, i will use this in the next alpha release.
@milan and koepi: What I did was I added
#ifdef NDEBUG to the top of ffdebug.h and of course a corresponding #endif to the bottom. Hope this does the trick :)
@milan, would it be possible to make an option in the installation script to let the user chose where to put the folder in the start menu? not at all important of course :)
Edit2: And this should have been "DEBUG" instead of "NDEBUG", which I realised too late. However it wasnt so easy, wont compile this way. Will dig deeper..
Dali Lama
29th September 2002, 23:31
Hello,
I was thinking...could it be possible to include an xvid decoder inside the .avi or .ogg so that it would register and playback automatically once the end-user clicked play? It doesn't even have to have post-processing or anything, just playback.
Am I making sense?
The benefit is that we don't have to worry about having a decoder installed on the system, it will be embedded with the video file. This would prevent compatability issues and such.
bye,
Dali
oddball
30th September 2002, 00:57
Probably asking in the wrong thread for that.
Smiff
30th September 2002, 01:28
can i make a small suggestions RE the Resize tab - could you make the "Expand to next multiply(sic?)" option seperate from the "specify size" and "specify aspect", so it's a checkbox not part of the radio group, and have it applied _after_ the other. Also allow the user to choose a value (e.g. 2,4,8,16,32...). I ask this because on my G400 i always want the output to have a res that's a particular multiple, even though i also want to resize e.g. to 640xwhatever, then hopefully can do away with DivXG400 filter (i realise this may cause the aspect to not be exactly as specified, that's the users lookout).
edit - ideally allow user to specify x & y rounding seperately, some may have a use for this... i know some hardware/players are only sensitive in one direction, or require different multiples.
Smiff
30th September 2002, 01:53
btw athos somehow PP seems to be OK in that latest build, cheers
edit: nope it seems to work for some films not others, weird (some divx movies i seem to get no postprocessing, others it works great).
Didée
30th September 2002, 02:33
Another suggestion I´d really like to see:
An option to make AR changes relative to the original AR.
This would be very useful for e.g. mixed playback of PAL/NTSC movies, and for VGA/PAL correction, etc.
@ Smiff
Erh, I get my G400 here to do everything. What´s the exact problem - faulty playback with non-MOD32 resolutions?
Since the day ffdshow has border control, I even cancelled the use of DivxG400.
milan
30th September 2002, 07:51
ffdshow was not ready for even alpha release. Nic's postprocessing routines were added, but as I wrote not very tested.
@Psyche:
Thank for pointing at those two bugs. They are fixed now.
I know MPEG1/2 aren't working yet, especially seeking. Propably it was a mistake to enable those two checkboxes. Be sure I'm working on it and when it will be working I will let you know. For now I'm trying warious approaches and once it may work, once not.
Yes, you won't need commercial MPEG 2 decoders when MPEG2 in ffdshow will be finished. I'm not sure if ffdshow by itself can handle DeCSS and this is a low priority to me for now. For AC3 decoding you can use GPLed decoder filter mentioned it this thread earlier.
I'm not sure why unsharp mask shouldn't work. I didn't change anything in it since previous release. Just want to ask other developers: is it safe to use EBX register in inline assembler? I'm using it there and I think I've read somewhere it's not safe. Is this true and could this cause that problem?
Debug output (OutputDebugString) doesn't depend on Release settings. It's for me especialy useful to have it enabled in release compiles when there are no other ways to see what's going. It must be manually undefined for builds intented for releasing to public.
I will try to modify NSIS script as you suggested.
Integrating codecs to AVI is not possible. What could be possible would be "integration" of movie in codec (or player). I think there were some "self-running" MODs, MP3s,... Could be interesting.
Resizing, aspect ratio, borders will be reworked. That idea of using borders for aspect ratio was good and will be used. I will try to implement other suggestions too. But this will take some time.
Warpsharp: this is of course not finished yet. I'm searching some way how to do this in realtime without sacrifying too much of quality. 5x5 blur is already mmx optimized, edges detection will be optimized too (I have an idea how to do this) and displacement will be faster (it will be limited to moving pixels by max. 2 pixels, but I think this should be enough)
So as I see a lot work to do, but during weeked I did something different. Maybe it was just wasting of time, but I've got an idea and immediatelly wanted to code it. The idea was: I wanted to write some sound processing DirectShow filter (equalizer, dynamic reduction - I've tried some other DShow filters, but didn't like any of them), but why should I write them when lots of good DSP filters are available for Winamp 2. So I wrote DirectShow audio in-place processing filter (based on one DirectShow SDK sample), which uses Winamp 2 DSP plugins to process sound samples in DirectShow. Especially I wanted to use DFX 6 filter, because it can do miracles with sound.
I've got it work. Not everything is stable, but it works. Biggest problems are with filters configuration dialogs.
Before I will try to enhance this filter (filter queue,...) I would like to know if there exists some software which does what I described. If yes, then I will abandon this project.
If you want to try it, it's sources are in dsp2dshow (I know it;s stupid name) module if ffdshow SourceForge CVS repository. If you will be interested in binaries, I will release them.
Rrrough
30th September 2002, 08:16
milan,
nice ideas you have. i haven't heard of a filter like that before. definetly a great idea. have you ever tried ozone winamp dsp plugin ??? it's simulating a tube amp and outputs a marvellous sound. would happily give it a try !
cheers
milan
30th September 2002, 08:39
I've downloaded the free version for Winamp and it seems to be working although it's slow. Can that dialog be hidden? I can close it when using winamp, but next time it opens again.
At iZotope page there is a plugin for DirectX. In fact, there are many of very HQ DirectX DSP plugins. Maybe it would be worth to try to use them too.
Rrrough
30th September 2002, 08:49
you can only minimize it to taskbar. it's cpu-hungry, yes it is. but it pays for the sound you get...
the directx version is different, it's meant for post-production. haven't tried much, but it's definetly different.
milan
30th September 2002, 09:16
I've just downloaded ffdshow-20020927 and looked at unsharp.
This version always uses at that time very experimental warpsharp filter. It was forced during testing when there was no cfg dialog option to select it. Now it's OK.
But I'm still curious if it's safe to use EBX in C++ inline assembly.
milan
30th September 2002, 13:48
I released dsp2dshow binaries in a new package on ffdshow SourceForge page. I also started new thread in Audio Encoding forum: http://forum.doom9.org/forumdisplay.php?s=&forumid=11. I think it would be better to discuss about dsp2dshow there.
athos
30th September 2002, 14:40
@milan - Sorry for releasing the binaries too early.
I think the audio filter sounds very interesting!
Smiff
30th September 2002, 17:36
Originally posted by Didée
Another suggestion I´d really like to see:
An option to make AR changes relative to the original AR.
This would be very useful for e.g. mixed playback of PAL/NTSC movies, and for VGA/PAL correction, etc.
@ Smiff
Erh, I get my G400 here to do everything. What´s the exact problem - faulty playback with non-MOD32 resolutions?
Since the day ffdshow has border control, I even cancelled the use of DivxG400.
If i don't have DivXG400 loaded, half the time my video comes out bright green (i assume this is the "mod32" bug - ?) How are you correcting this with ffdshow please, i'd love to do it like that :).
Could we have ffdshow just pad out the borders with black up the correct size (multiple of whatever), rather then resize (to save a resize - it's only a few pixels). Milan? maybe? :)
wizzzard
30th September 2002, 22:40
Originally posted by athos
@milan - Sorry for releasing the binaries too early.
I think the audio filter sounds very interesting!
Hello,
of couse I'm not milan ;) but I like the early compilings. I like it to have the latest features very early even when some of the stuff is not stable. I think this is normal at this develge, so please go ahead with fast compilings ;)
ookzDVD
1st October 2002, 05:02
@milan,
Could you tell us the status of Nic's PP is it integrated yet to the
ffdshow ?
Thank you.
milan
1st October 2002, 07:31
Could we have ffdshow just pad out the borders with black up the correct size (multiple of whatever), rather then resize (to save a resize - it's only a few pixels).
On Resize settings configuration page in method combo box select "None". ffdshow will just copy source image to destination rectangle (clipping or adding black borders). This is faster then resizing.
@wizzzard
When I want to follow development of some project, I'm regularly checking it's CVS and compiling it (mplayer, lame, ogg vorbis, xvid for now). Maybe you could try it too :)
But actually, it was in ffdshow-alpha package and everyone who was downloading it, should be aware of possible bugs. But for example those reports about broken unsharp mask were useless.
I think Nic's PP is correctly integrated now. By reading it's sources I've found how to get xvid.dll quantizers and motion vectors, so even when using xvid.dll for decoding deblocking and "Show motion vectors" will be correct. I want to do this today.
@Nic
I've found outcommented #define PREFETCH in your PP sources. I know it enables MMXEXT instructions, but is it faster enough to keep both versions in ffdshow and select them runtime?
Didée
1st October 2002, 08:25
Originally posted by Smiff
If i don't have DivXG400 loaded, half the time my video comes out bright green (i assume this is the "mod32" bug - ?) How are you correcting this with ffdshow please, i'd love to do it like that :).
The trick is - I don´t correct anything.
For me, playback is definetly fine with MOD16 and MOD8 resolutions.
Just before writing this, I tried to produce a short MOD4 sample to check - but XviD refused to encode this ;) It is advised to use at least MOD16 with XviD, and so I do usually.
Smiff, do you use recent drivers for your G400 ? !!
Currently I´m using v5.82.18, February 2002 or so - these worked 100% flawless for months now. Just a few days ago, Matrox released a new set, but I didn´t try them yet.
Ah, and I´m only referring to WinXP here.
Nic
1st October 2002, 09:53
@milan:
in my experience of using prefetch, it either makes no speed increase or can sometimes actually be slower. I left it disabled because of that. I think its probably best left that way, but if you think it will help things then im sure adding it wouldn't do any harm. :)
Im glad you got it integrated well :) lets hope it works ok with the new dev-api :)
Cheers,
-Nic
ps
with using ebx, I guess if your concerned about using it just push & pop it to be sure ;)
sherpya
1st October 2002, 18:24
Originally posted by milan
I released dsp2dshow binaries in a new package on ffdshow SourceForge page. I also started new thread in Audio Encoding forum: http://forum.doom9.org/forumdisplay.php?s=&forumid=11. I think it would be better to discuss about dsp2dshow there.
I've started an ac3 realtime encoder (dshow filter) using ffmpeg lib (usefull to send ogg 5.1 streams to external ac3 decoders), so milan if you are intrested we can share some infos on dshow shit :P, I've not released to public nothing yet because I've some problem with input buffer alignment and the encoder now works only in mono. But I'm (trying to) working on it with the help of dspguru...
milan
2nd October 2002, 07:08
I'm sorry but I'm not sure if I would be able to help you. I'm not very experienced in writing directshow audio filters (dsp2dshow is slightly modified gargle sample from DirectX SDK). But be sure I will do my best to help you with this. Feel free to send me an email with further details.
For now you can look at this: http://xvalex.hotbox.ru/programs/ac3filter/ac3filter_eng.html. It's GPLed AC3 decoder filter. This might help you. I wanted to modify it to support mp3 decoding with mp3lib and ogg decoding with tremor, but I realy had no time to do this :(
oddball
2nd October 2002, 21:58
Athos I have a problem with your latest build. Gamma correction seems to be fubar. It's either on (Bright) or off. If I move it in either direction along the slider it comes on really bright then goes off if you move to the next along.
Very strange.
athos
2nd October 2002, 22:28
Originally posted by oddball
Athos I have a problem with your latest build. Gamma correction seems to be fubar. It's either on (Bright) or off. If I move it in either direction along the slider it comes on really bright then goes off if you move to the next along.
Very strange.
Yes, I tried here and I get the same results. Never tried it before though. I wonder if this is related to my compile options or something in the sourcecode?
Smiff
2nd October 2002, 23:04
same here, it's been like that for a while, assumed you knew..
milan
3rd October 2002, 07:31
As I wrote before gamma correction in Picture properties tab now uses MMX optimized approximation. But for now the only value which works is 2.2 and it either off or on. I know about it and will fix or (or better to say make this feature realy working). For now use gamma correction on levels tab.
Poy
3rd October 2002, 11:47
Is there coming version where I can move subtiles to near black bar like in DivXG400? And support to all sub format?
athos
3rd October 2002, 19:01
New alpha release uploaded. I have disabled DEBUG, and compiled in "Blend" mode instead of "Penitum Pro and higher", so it should work with older cpu's (K6, Pentium I).
Smiff
3rd October 2002, 20:32
Originally posted by athos
New alpha release uploaded. I have disabled DEBUG, and compiled in "Blend" mode instead of "Penitum Pro and higher", so it should work with older cpu's (K6, Pentium I).
yay, i love you athos (for doing releases genererally :))
edit: yah, great, this is the first good release (for me) since ffdshow-20020923.exe, good work milan, everything (that i use) seems to be working... anyone know where i can find more information on Nic's postprocessing, how it works, how its better (or not) than the old one, etc.?
wizzzard
3rd October 2002, 21:54
Hello,
a dream came true. Now I can use a sharpness filter (unsharp mask - with adds a little noise) in combination with a de-noisefilter.
Thanks to athos, milan and the rest of the team.
Frank
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.