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. |
27th December 2010, 16:56 | #12841 | Link |
Software Developer
Join Date: Oct 2001
Location: Israel
Posts: 1,005
|
Hi Guys,
Some recent change(s) to the FFDShow API broke backward compatibility in the 'IffDecoder' interface (the 'putParamStrW' function now crashes due to incompatible headers). Is it possible to update the Delphi header files to the most recent version and possibly keep backward compatibility in future builds? |
27th December 2010, 17:51 | #12842 | Link |
*****
Join Date: Feb 2005
Posts: 5,647
|
Please figure out which change broke the API. Your program is a user of the API, so you can test it better. If you post a patch, I will apply it.
Edit: It is probably due to r3603/r3516: http://ffdshow-tryout.svn.sourceforg...&revision=3616 I am not sure what the proper solution would be. Perhaps adding a dummy function?
__________________
MPC-HC 2.2.1 Last edited by clsid; 27th December 2010 at 18:19. |
27th December 2010, 20:35 | #12843 | Link |
Registered User
Join Date: Aug 2008
Location: the Netherlands
Posts: 851
|
i m using mpc-hc lastest build and ffdshow latest (dl-ed from http://www.xvidvideo.ru/ffdshow-tryo...oject-x86-x64/).
problem is that my subtitles flicker a lot during a movie. what could cause this? |
27th December 2010, 20:45 | #12844 | Link |
Software Developer
Join Date: Oct 2001
Location: Israel
Posts: 1,005
|
clsid:
I'm not trying to get backward compatibility as I realize it's probably a lost cause. What I'm trying to do is modify my code to be compatible with the current builds, but the Delphi header translation on the SVN is 13 months old and no longer compatible. I was hoping one of the devs would update the delphi headers and from now on when changes are made, they would be made to a different class (i.e. iffdecoder2, iffdecoder3, etc...) thus maintaining compatibility from now on. I tried doing it myself, but I don't think I'm doing it right as I keep getting crashes. P.S. Backward compatibility has been broken at least once before this current issue, that's why I'm asking ... |
27th December 2010, 21:45 | #12845 | Link | |
Registered User
Join Date: Oct 2009
Location: France
Posts: 616
|
Quote:
This is FFDShowAPI that we use in mediaportal -> all is working good so i hope that it's working for you too FFDShowAPI Mediaportal Edit : This is the patch that works on FFDShow (small modification on using FFDShow (mediaportal) and FFDShowAPI (FFDShow) and also Copyright). FFDShowAPI Diff Cheers, Seb.
__________________
HTPC : i7 920 6Go Win10(x64) / Nvidia 1050Ti / P6T Deluxe / Harman-Kardon AVR-355. Last edited by Sebastiii; 27th December 2010 at 22:03. |
|
27th December 2010, 22:16 | #12846 | Link |
*****
Join Date: Feb 2005
Posts: 5,647
|
I shall commit that patch.
__________________
MPC-HC 2.2.1 |
27th December 2010, 22:51 | #12847 | Link | |
Registered User
Join Date: Oct 2009
Location: France
Posts: 616
|
Thank you
Quote:
Line 504 : function getPostproc(postprocPtrpointer):HRESULT;stdcall; I think with that all should be ok Seb.
__________________
HTPC : i7 920 6Go Win10(x64) / Nvidia 1050Ti / P6T Deluxe / Harman-Kardon AVR-355. Last edited by Sebastiii; 28th December 2010 at 02:38. |
|
28th December 2010, 00:39 | #12848 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,786
|
Quote:
Well -- I am relieved. |
|
28th December 2010, 04:52 | #12849 | Link |
Registered User
Join Date: Mar 2010
Posts: 98
|
I found out that ffmpeg supports neither standard pb-frame nor enhanced correctly. Not sure if it´s a regression or it never worked.
I just noticed you forget to add CODEC_ID_H263I in TimgFilterPostproc.cpp. Or was this intentional? |
28th December 2010, 04:58 | #12850 | Link |
Registered User
Join Date: Aug 2007
Posts: 1,430
|
ffdshow still seems to have issues doing colorspace conversions from BGR24, including a couple of crashes referring ffmpeg.dll (that don't seem to reproduce with the ffmpeg cli).
Sample: http://stfcc.org/misc/ffdshow.fraps.bug.rar Last edited by Snowknight26; 28th December 2010 at 23:18. |
28th December 2010, 16:19 | #12851 | Link |
*****
Join Date: Feb 2005
Posts: 5,647
|
Any help solving those colorspace problems is welcome.
Could you post (small) sample file(s) to reproduce the problems? That will be helpful for anyone that wants to try to fix these problems.
__________________
MPC-HC 2.2.1 |
28th December 2010, 18:23 | #12852 | Link |
Registered User
Join Date: Mar 2010
Posts: 98
|
I found an interesting bug:
Post-processing using mplayer method will result in a crash with Indeo3 and Indeo5 (Indeo2 not tested). Also when you watch a few seconds without ffdshow crashing chroma artefacts are introduced. Could the problem be the 4:1:0 colorspace? All other post-processing except fast SPP doesn´t seem to do anything at all. |
28th December 2010, 22:14 | #12853 | Link |
*****
Join Date: Feb 2005
Posts: 5,647
|
I shall disable PP for Indeo until someone figures out what is wrong and fixes it.
__________________
MPC-HC 2.2.1 |
29th December 2010, 03:26 | #12854 | Link | |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
And it seems you fit the above description quite well. You don't use it, but there's no substitute _______________________________ Another quick test. Random file, 1050p. 2 passes with MJPEG. Pass 1 results in a 341MB file. Pass 2 with a target size of 200000 KBytes ends up in the same 341MB file. Another file, same 1050p resolution. Pass 1 results in a 174MB file. Pass 2 with a target size of 100000 KBytes results in a 132MB file. If I choose large target sizes, VirtualDub crashes. My conclusion: 2 pass mode doesn't work properly. This time with the first sample only: 1 pass average bitrate: 7000 kbps results in a 228MB file. 9500 kbps results in the same 228MB file. My conclusion: this doesn't work either. Constant quantizer and quality work OK aparently. I say aparently because the only thing I've looked at is that lower quantizers and higher quality both result in better quality and bigger files as they should, so I don't know if the files are actually encoded with the configured CQ. _______________________________ Less talk and more tests are wecomed |
|
29th December 2010, 09:37 | #12855 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,786
|
Well, looks like I should have asked everyone who still uses it to walk up the barricade with waving flags, instead of just clicking a checkbox anonymously. May be that I hardly use it. But I am not so "selfish" that I only think of myself and my own needs; I try to consider the needs of others too. And I am scolded for it. What a community...
Enough of fruitless arguing. I can only assume that there are still users, with a probability like there are aliens in outer space, but I can't point on one of them and name them. __ 2-pass MJPEG?! I never even considered that... MJPEG with a fixed quantizer is useful for real-time urgent encodings like analog capturing. With a fixed quantizer or a "constant quality" it may even be partially suitable for intermediate heavily-filtered videos for a following 2-pass encode. But 2-pass encoding to a target bitrate ... hmm, considering the own bitrate requirements, that is an ... "interesting idea". |
29th December 2010, 14:36 | #12856 | Link |
*****
Join Date: Feb 2005
Posts: 5,647
|
@LigH
You must also understand things from out point of view. We are trying to remove all inferior and non-working stuff. For two main reasons: (1) because they are not maintained and thus we can't do any bugfixes, and (2) to direct users to better alternatives. I absolutely don't mind keeping MJPEG if there are good reasons to keep it. But such arguments should come from people who still use it now and not from people who used it a few times long ago. So far I have seen one good argument, it having good performance for capturing. It having good quality has already been debunked, as other format perform significantly better in that area. Of course the performance argument could use some validation as well. Anyone interested in testing fps compared to 1-pass Xvid and H.264 encoding with fast settings? @STaRGaZeR If you want and have time, you could remove 2-pass mode for MJPEG. I assume that those who use MJPEG use it as an intermediate format during capturing.
__________________
MPC-HC 2.2.1 |
29th December 2010, 20:56 | #12857 | Link | ||
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
Quote:
Did you even know the option was there? I know nobody uses 2 passes, but it's there and it's buggy as I said. I did some qualitative tests days ago, that's why I told you the encoder was buggy. I like to backup my claims, unlike others. Quote:
I prefer to do everything in one step, so when you decide to remove the hidden encoders I can remove the buggy features too. |
||
29th December 2010, 22:36 | #12858 | Link |
*****
Join Date: Feb 2005
Posts: 5,647
|
No need for any detailed numbers. Your description of the test results is enough.
__________________
MPC-HC 2.2.1 |
Tags |
ffdshow, ffdshow tryouts, ffdshow-mt, ffplay, icl |
|
|