ffdshow tryouts project: Discussion & Development

[Blight]

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?

[clsid]

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?

[THX-UltraII]

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?

[Blight]

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 ...

[Sebastiii]

Originally Posted by Blight

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 ...

Hi,

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.

[clsid]

I shall commit that patch.

[Sebastiii]

Originally Posted by clsid

I shall commit that patch.

Thank you

Originally Posted by Blight

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 ...

For the Delphi API, i think you should comment out this line in delphi\IffDecoder_com.pas :

Line 504 : function getPostproc(postprocPtrpointer):HRESULT;stdcall;

I think with that all should be ok
Seb.

[LigH]

Originally Posted by clsid

I count "nice to have" as "don't care" rather than "must have!". So the poll results are up to different interpretation. And polls like these are biased to begin with.

Yes, it is possibly biased ... but as I already mentioned, ffdshow's MJPEG encoder is exceptional in quality. There is no known substitute for me. In contrast to e.g. MPEG4-ASP and MPEG4-AVC codecs where we have Xvid and x264 as much more practical solutions for end users.

Well -- I am relieved.

[xv]

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?

[Snowknight26]

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

[clsid]

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.

[xv]

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.

[clsid]

I shall disable PP for Indeo until someone figures out what is wrong and fixes it.

[STaRGaZeR]

Originally Posted by LigH

Current poll result:

4× "must have!"
1× "need fixes" -- probably already solved
5× "nice to have"
1× "don't care"

Well, more or less a 10:1 for "keep MJPEG".

I hope it has any value.

As expected, not a single "yes, I use it now, for XXX in YYY because of ZZZ" yet. All of them are don't care/don't know/what's MJPEG/it's a pity to lose something nobody uses so keep it. So yes, it does have value, but against MJPEG not the other way around. And that's in a forum full of people in the know. What we know for sure is that people don't want to lose things, even when they don't use them

Originally Posted by LigH

There is no known substitute for me.

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

[LigH]

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".

[clsid]

@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.

[STaRGaZeR]

Originally Posted by LigH

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".

We told you we wanted people to give us reasons to keep the encoder, not to check an option in a poll. I hope you can see the difference...

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.

Originally Posted by clsid

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.

The MJPEG encoder is single threaded, and with 1 thread its speed is unmatched. This, combined with the close to lossless quality of low quantizers or high quality makes it a good choice for intermediates, so I'll change my vote to remove it to don't care, as I don't use it and thus I can't decide because of that. However, nobody uses xvid or x264 with 1 thread, and with only 3 threads perfomance was close to MJPEG, but compression was a lot higher of course. No numbers this time as I did the test days ago, will have to redo them unless someone does it for me.

I prefer to do everything in one step, so when you decide to remove the hidden encoders I can remove the buggy features too.

[clsid]

No need for any detailed numbers. Your description of the test results is enough.

[Blight]

This post is just to confirm that Sebastiii's patch fixes the Delphi compatibility issue.

[Sebastiii]

Great thank you