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.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 21st March 2010, 10:19   #11141  |  Link
albain
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
albain is offline   Reply With Quote
Old 21st March 2010, 18:14   #11142  |  Link
STaRGaZeR
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.
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 21st March 2010, 19:07   #11143  |  Link
djesteban
Registered User
 
djesteban's Avatar
 
Join Date: Aug 2008
Posts: 112
Quote:
Originally Posted by clsid View Post
@Atak_Snajpera
Fixed in 3322

@djesteban
Fixed in 3320
Thanks! I tested this thoroughly with build 3326 and it now work as expected... no weird image corruption! Happy you could find the culprit!
djesteban is offline   Reply With Quote
Old 22nd March 2010, 04:43   #11144  |  Link
Eliminateur
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
Eliminateur is offline   Reply With Quote
Old 22nd March 2010, 08:10   #11145  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Eliminateur View Post
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)
The purpose of dithering in the YCbCr -> RGB conversion is to not introduce any additional banding, respectively to not make source banding more evident/ugly. Basically using dithering produces a more correct image compared to not using dithering. However, dithering (as implemented in the YCbCr -> RGB conversion) does not in any way reduce banding which is hard coded into the source material. In your images you can see that dithering does not reduce the source's banding. However, in the right top of the images the banding steps are more equally spread when using dithering compared to when not using dithering. So it seems to me that dithering does work as intended.

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."
madshi is offline   Reply With Quote
Old 22nd March 2010, 08:21   #11146  |  Link
fastplayer
Registered User
 
Join Date: Nov 2006
Posts: 799
Quote:
Originally Posted by madshi View Post
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."
Done.
fastplayer is offline   Reply With Quote
Old 22nd March 2010, 12:17   #11147  |  Link
albain
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
albain is offline   Reply With Quote
Old 22nd March 2010, 13:29   #11148  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
I don't think that's normal, you should be able to apply postprocessing to all sources if you want to.
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 22nd March 2010, 14:04   #11149  |  Link
fastplayer
Registered User
 
Join Date: Nov 2006
Posts: 799
Quote:
Originally Posted by albain View Post
For example it is disabled for H264 formats
Yep, doesn't make much sense for it to be enabled for H.264 content.
fastplayer is offline   Reply With Quote
Old 22nd March 2010, 17:54   #11150  |  Link
Snowknight26
Registered User
 
Join Date: Aug 2007
Posts: 1,430
You mean disabled?
Snowknight26 is offline   Reply With Quote
Old 22nd March 2010, 18:32   #11151  |  Link
fastplayer
Registered User
 
Join Date: Nov 2006
Posts: 799
No, I mean enabled. Post-processing an already post-processed (deblocked) video doesn't make much sense to me.
fastplayer is offline   Reply With Quote
Old 22nd March 2010, 18:49   #11152  |  Link
Eragon4ever
lost program in the net
 
Join Date: Jun 2006
Location: Germany
Posts: 106
The deblocking is part of any valid decoding. Therefore it is no post-processing IMHO. Filters should not be concerned by what the decoding of a certain codec does.
Eragon4ever is offline   Reply With Quote
Old 22nd March 2010, 18:52   #11153  |  Link
Px
>>^^__^^<<
 
Px's Avatar
 
Join Date: Jun 2005
Posts: 222
Quote:
Originally Posted by albain View Post
Is it normal that the postprocessing filter is applicable only to the following codecs :
In general case it is normal, strange is that DIVX missing in this list
Px is offline   Reply With Quote
Old 22nd March 2010, 20:48   #11154  |  Link
STaRGaZeR
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.
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 23rd March 2010, 09:11   #11155  |  Link
albain
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.
albain is offline   Reply With Quote
Old 23rd March 2010, 16:44   #11156  |  Link
_xxl
ffdshow user
 
_xxl's Avatar
 
Join Date: Oct 2005
Location: Romania
Posts: 818
Quote:
Originally Posted by Px View Post
In general case it is normal, strange is that DIVX missing in this list
Isn't missing:
Quote:
case CODEC_ID_MPEG4
case CODEC_ID_XVID4
_xxl is offline   Reply With Quote
Old 23rd March 2010, 16:48   #11157  |  Link
_xxl
ffdshow user
 
_xxl's Avatar
 
Join Date: Oct 2005
Location: Romania
Posts: 818
Quote:
Originally Posted by STaRGaZeR View Post
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.
Was removed in 2006 because H.264 has internal inloop deblocking and additional postprocessing wouldn't help.
_xxl is offline   Reply With Quote
Old 23rd March 2010, 18:18   #11158  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Quote:
Originally Posted by _xxl View Post
Was removed in 2006 because H.264 has internal inloop deblocking and additional postprocessing wouldn't help.
Internal inloop deblocking is not a sustitute of a deblocking filter. Plus an H.264 stream can be encoded without it for any obscure reason, and it will probably look like garbage without any postprocessing.

EDIT: albain, your patch is password protected.
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.

Last edited by STaRGaZeR; 23rd March 2010 at 18:39.
STaRGaZeR is offline   Reply With Quote
Old 23rd March 2010, 18:46   #11159  |  Link
albain
Media Control author
 
Join Date: Dec 2006
Location: Paris
Posts: 1,014
Quote:
Originally Posted by STaRGaZeR View Post
Internal inloop deblocking is not a sustitute of a deblocking filter. Plus an H.264 stream can be encoded without it for any obscure reason, and it will probably look like garbage without any postprocessing.

EDIT: albain, your patch is password protected.
Sorry : here is the right link
albain is offline   Reply With Quote
Old 23rd March 2010, 19:10   #11160  |  Link
_xxl
ffdshow user
 
_xxl's Avatar
 
Join Date: Oct 2005
Location: Romania
Posts: 818
Quote:
Originally Posted by STaRGaZeR View Post
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.
We should ask H.264 experts on this forum.
_xxl is offline   Reply With Quote
Reply

Tags
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:13.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.