Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
21st March 2010, 10:19 | #11141 | Link |
Media Control author
Join Date: Dec 2006
Location: Paris
Posts: 1,014
|
@Stargazer : the patch is buggy indeed, I have to make a new one
I am suffering with this new libs, I have fixed the bicubic and gauss resize issues, but I still don't understand why postprocessing does not work @Ikarad : ok I'll take a look at it this week, thanks for your reports |
21st March 2010, 18:14 | #11142 | Link |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
clsid, after r3323 the icl10 project file has an error:
As you can see, ffdshow is configured to x64 when buiding for Win32, plus it's actually skipped because it's not selected. |
22nd March 2010, 04:43 | #11144 | Link |
Registered User
Join Date: Jan 2010
Posts: 75
|
in the RGB wiki help page: http://ffdshow-tryout.sourceforge.ne...rgb_conversion there's a link about dithering for img comparison: http://forum.doom9.org/showthread.ph...42#post1287242 which states it tries to make the same result as with deband.
Unfortunately, dithering does not work as expected and has little to no effect(nowhere near deband which produces a "smooth" transition of colors) and increases CPU load enough for my machine not to be able to smoothly play 1080p H264 (Xeon 3075 @3GHz). It would be interesting to see if the algorithm needs a revision as deband is quite cpu hungry, żis it multithreaded?, żis there any other filter with the same effect and better performance?. Here are the screenshots showing the difference very clearly(at least in my monitor which has HC range), aoutput is set to RGB32 HQ conversion: No deband or dither: Dither only: Deband 1.22 and Dither: i haven't included a deband-only image as the difference with deband+dither is negligible(the bands are clearly seen and the number of bands is the same, the difference is that some bands are lighter/darker) it would be good to update the wiki link or a better explanation to prevent banding |
22nd March 2010, 08:10 | #11145 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
The "deband" post processing aims at detecting and removing banding which is hard coded into the source material. So "deband" has a different purpose compared to the RGB conversion dithering. "deband" is a more complicated algorithm and is expected to consume more CPU power compared to dithering. I do think the wiki should be changed to make things less confusing. Currently it reads: "Dithering is an option to enhance visual quality. It reduces banding that RGB conversion tends to add." I'd replace that with: "Dithering is an option to maintain the source's full visual quality when doing YCbCr -> RGB conversion. Without dithering RGB conversion can result in added banding." |
|
22nd March 2010, 08:21 | #11146 | Link | |
Registered User
Join Date: Nov 2006
Posts: 799
|
Quote:
|
|
22nd March 2010, 12:17 | #11147 | Link |
Media Control author
Join Date: Dec 2006
Location: Paris
Posts: 1,014
|
Is it normal that the postprocessing filter is applicable only to the following codecs :
Raw codecs, then : case CODEC_ID_MPEG1VIDEO: case CODEC_ID_MPEG2VIDEO: case CODEC_ID_LIBMPEG2: case CODEC_ID_MPEG4: case CODEC_ID_MSMPEG4V1: case CODEC_ID_MSMPEG4V2: case CODEC_ID_MSMPEG4V3: case CODEC_ID_H263: case CODEC_ID_SVQ1: case CODEC_ID_FLV1: case CODEC_ID_INDEO2: case CODEC_ID_INDEO3: case CODEC_ID_XVID4: case CODEC_ID_MJPEG: case CODEC_ID_MJPEGB: case CODEC_ID_MSVIDEO1: case CODEC_ID_CINEPAK: case CODEC_ID_VP5: case CODEC_ID_VP6: case CODEC_ID_VP6F: For example it is disabled for H264 formats |
22nd March 2010, 20:48 | #11154 | Link |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
I think you guys have a confusion between two deblocking filters. Albain is not talking about H.264's inloop deblocking, but the deblocking filter inside ffdshow's postprocessing filter. Nothing to do with each other. ffdshow's postprocessing filter is like any other filter like resize or subtitles, you apply it if you want to. Any restrictions would be illogical.
|
23rd March 2010, 09:11 | #11155 | Link |
Media Control author
Join Date: Dec 2006
Location: Paris
Posts: 1,014
|
That's right, there are presets to apply those restrictions
Hello guys, I need some help : I spent a lot of time on this, I still don't understand why the postprocessing filter does not work correctly (I get a black picture when enabled) Here is the source patch, if one of you could have a look at it libswscale seems to be okay now libpostproc seems to be working on the deinterlacer part, but not on the deblocking (postprocessing) part. The parameterts that are sent to the filter seem to be fine, so this has to be something inside the postprocess methods Thank you for your help Last edited by albain; 23rd March 2010 at 18:46. |
23rd March 2010, 16:48 | #11157 | Link | |
ffdshow user
Join Date: Oct 2005
Location: Romania
Posts: 818
|
Quote:
|
|
23rd March 2010, 18:18 | #11158 | Link | |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
EDIT: albain, your patch is password protected. Last edited by STaRGaZeR; 23rd March 2010 at 18:39. |
|
23rd March 2010, 18:46 | #11159 | Link | |
Media Control author
Join Date: Dec 2006
Location: Paris
Posts: 1,014
|
Quote:
|
|
23rd March 2010, 19:10 | #11160 | Link | |
ffdshow user
Join Date: Oct 2005
Location: Romania
Posts: 818
|
Quote:
|
|
Tags |
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl |
Thread Tools | Search this Thread |
Display Modes | |
|
|