ffdshow tryouts project: Discussion & Development

[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]

Current poll (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG) 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 ;)

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 :rolleyes:

_______________________________


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

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?! :eek: I never even considered that... :cool:

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]

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

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?! :eek: I never even considered that... :cool:

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? :D
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.

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 :)

[Gingko]

I am trying to decode digital TV with audio as "AAC in transport stream with a synchronization layer (LOAS) and a multiplex layer (LATM)" used in some countries, and to find codecs working with this.

I more or less succeeded with Monogram AAC Decoder (http://blog.monogram.sk/janos/2009/03/08/monogram-aac-decoder-0960/), but I had to modify and recompile it in order to get it working, because the proper Media Type was not exposed to DirectShow (although internally used). Now it works, but with some instabilities.

This Media Type, as far as I understand correctly, is defined (at least by Microsoft (http://msdn.microsoft.com/en-us/library/dd390676%28v=VS.85%29.aspx)) as MEDIASUBTYPE_MPEG_LOAS, and its value is {00001602-0000-0010-8000-00AA00389B71}.

Monogram AAC Decoder is a wrapper for libfaad2, which is used also by ffdshow-tryouts, so logically, ffdshow-tryouts should be able to decode it, but unfortunately, it does not expose this Media Type either.

I'm wondering if it wouldn't be possible to include it in future versions of ffdshow-tryouts in order to make possible, or more easy, to get ffdshow-tryouts decoding AAC+LOAD+LATM?

If you need some sample, you can use this file :
http://gingko.homeip.net/misc/TDT_Continente_2010-12-09_19-20-02.ts

This is a 30 seconds record of a full DVB-T Transport Stream multiplex (from Portuguese TV) with 4 TV channels (plus an empty one), all encoded as H264 (for video) and AAC+LATM+LOAS for audio.

Regards,

GingkoHello,

Is there any chance that I could get an answer to this ?

I am developer on a DVB-T application, and the lack of this mediasubtype makes problematic for me to find a codec able to decode soundtracks in this kind of video stream.

Even Media Player Classic HC, for example, seems to be unable to play it.

Gingko

[LigH]

@ clsid and STaRGaZeR:

A first verbose reply from Tom Keller (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG&p=415122&viewfull=1#post415122). Brief translation:

Due to a rather slow capturing system, he needs a both fast and easily cuttable (keyframe only) and high quality video format as VfW codec. So ffdshow's MJPEG is the optimum for his case because:

it is fast
it is free of charge
it provides acceptably high quality
and even though ffdshow is "just a VfW wrapper for ffmpeg", he needs exactly that
Xvid is no substitute because it is neither fast enough on his system nor freely cuttable (or who would try to set it up for 0 P-frames?)
FFV1 is no substitute because even though it compresses tightly for a lossless codec and can provide I-frames only, it is too slow on his system
Huffyuv is no substitute because although it is fast enough and even lossless, the result is way too big


Recommendations like "buy bigger harddisks" or "buy a faster PC" are easy. But not every user is able to do that. If they were, then ffdshow would need no encoder at all, and we could use "lossless x264vfw" for capturing.

So much about Tom's opinion. Now I have at least one specific person I can point at. ;)

[clsid]

Hello,

Is there any chance that I could get an answer to this ?

I am developer on a DVB-T application, and the lack of this mediasubtype makes problematic for me to find a codec able to decode soundtracks in this kind of video stream.

Even Media Player Classic HC, for example, seems to be unable to play it.

Gingko
LATM/LOAS are not supported by ffdshow. It would require adding a parser for such headers.

If you want to see this capability added to ffdshow you need to submit a patch for it. We have no manpower available to do it.

[Ger]

Even Media Player Classic HC, for example, seems to be unable to play it.


Your sample plays with audio in MPC-HC if you use the latest LAVFSplitter beta and Monogram AAC decoder.

LAVFSplitter gets the duration of your sample wrong though, like it does with most H.264/HD samples, due to limited TS support in libavformat, but hopefully the TS duration issue will be resolved in LAFVSplitter eventually, since it is supposed to replace the internal MPC-HC splitters for the supported formats when it's deemed ready.

You may want to check out the LAVFSplitter thread (http://forum.doom9.org/showthread.php?t=156191). We've discussed LATM there before.

If you are a developer with the necessary time and skill to create a patch for LATM/LOAS support in ffdshow it would be appreciated though, since we wouldn't need the Monogram AAC decoder for those particular streams anymore.

[roozhou]

Hi clsid,

Is it possible to use ffdshow DXVA in encoding apps? It seems ffdshow gets the decoded frame back to main memory via IAMVideoAccelerator::GetBuffer or IDirectXVideoDecoder::GetBuffer in overlay mode. If ffdshow provide a new interface, the encoding app could pass a callback function to ffdshow and ffdshow calls it when it gets the frame. This should be useful for ATI and Intel graphic card users.

[clsid]

Hi clsid,

Is it possible to use ffdshow DXVA in encoding apps? It seems ffdshow gets the decoded frame back to main memory via IAMVideoAccelerator::GetBuffer or IDirectXVideoDecoder::GetBuffer in overlay mode. If ffdshow provide a new interface, the encoding app could pass a callback function to ffdshow and ffdshow calls it when it gets the frame. This should be useful for ATI and Intel graphic card users.
Even if it would be possible, the performance will probably be disappointing. But more importantly, I doubt any of the current developers has any interest in implementing this. So if you want it you need to code it yourself.

[Gingko]

LATM/LOAS are not supported by ffdshow. It would require adding a parser for such headers.

If you want to see this capability added to ffdshow you need to submit a patch for it. We have no manpower available to do it.

If you are a developer with the necessary time and skill to create a patch for LATM/LOAS support in ffdshow it would be appreciated though, since we wouldn't need the Monogram AAC decoder for those particular streams anymore.I see.

Necessary time is probably the most needed resource for me if I want to do that (difficult to work on several projects in the same time), but maybe I will try it anyway one day or another. :)

Gingko

[STaRGaZeR]

@ clsid and STaRGaZeR:

A first verbose reply from Tom Keller (http://forum.gleitz.info/showthread.php?43081-ffdshow-VfW-wird-quot-ausgemistet-quot-bald-ohne-MJPEG&p=415122&viewfull=1#post415122). Brief translation:

Due to a rather slow capturing system, he needs a both fast and easily cuttable (keyframe only) and high quality video format as VfW codec. So ffdshow's MJPEG is the optimum for his case because:

it is fast
it is free of charge
it provides acceptably high quality
and even though ffdshow is "just a VfW wrapper for ffmpeg", he needs exactly that
Xvid is no substitute because it is neither fast enough on his system nor freely cuttable (or who would try to set it up for 0 P-frames?)
FFV1 is no substitute because even though it compresses tightly for a lossless codec and can provide I-frames only, it is too slow on his system
Huffyuv is no substitute because although it is fast enough and even lossless, the result is way too big


Recommendations like "buy bigger harddisks" or "buy a faster PC" are easy. But not every user is able to do that. If they were, then ffdshow would need no encoder at all, and we could use "lossless x264vfw" for capturing.

So much about Tom's opinion. Now I have at least one specific person I can point at. ;)

It was hard, huh? It would have been inmediate if you would have proposed the poll in a less biased and more informative tone. 6 "Yes, absolutely - must stay inside!" explanations left for you ;)

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

Since it was easy, I've done it in r3709. 2 pass and 1 pass bitrate are no longer available for MJPEG.

[fastplayer]

It was hard, huh?
Since Tom Keller has a small disk and slow system in general, he can stick with older builds of ffdshow. Nobody is taking that away from him.

By the way, I still see no "Keep MJPEG or die!" petition on PetitionOnline.com (http://www.petitiononline.com/)...

[dann23]

By the way, I still see no "Keep MJPEG or die!" petition on PetitionOnline.com (http://www.petitiononline.com/)...

+1

I also need mpeg4 encoder from ffdshow and I'm sure I can make a poll and gather a few votes for this. But what's the point? So I believe it's better to remove all of the old and buggy encoders or let them just the way they were.

[clsid]

Can anyone with a S/PDIF setup please test the AC3 encoding functionality? I got a report that it is not working properly after its recent update, and I need confirmation.

[VipZ]

Can anyone with a S/PDIF setup please test the AC3 encoding functionality? I got a report that it is not working properly after its recent update, and I need confirmation.

EDIT: Sorry my bad, tested with 3661, indeed 3708 doesn't work for me either. After testing it seems 3681 broke AC3 encoding.

[Perls]

Tested encoding via HDMI both 2.0 and 5.1 @ 48kHz, working fine for me. 44.1kHz doesn't work natively for me, re sampling to 48kHz solves it, this could be the issue being reported.

Maybe automatically re sampling to 48kHz on AC3 encoding could be a solution?

For me, updating from 3626 to 3707 broke AC3 encoding of 2.0 at 48 kHz. Haven't tested anything else.

[tetrahex]

Hi!

I'd like to express my (somewhat lengthy :rolleyes: ) opinion about moving the encoders out of ffdshow. I don't like it.

For me, the ffdshow was a very welcome alternative after years and years of using first all kinds of codec packs and suffering for that, after which I used specific codecs or encoding apps for anything I needed. But even with a few codecs/splitters and a couple of encoding apps (like VirtualDub/Mod, Megui, AviDemux) I felt that simpler solution would be better, especially after I bought my first laptop. I wanted to keep the number of individual apps/codecs/whatever as small as possible, so as not to clutter the system too much and keeping it light and simple. And it worked, very well for my needs: all I needed was ffdshow for any kind of encoding/decoding, VHScreenCapture codec for capturing flash videos from web browser window (from national broadcasting company; not possible to download) and VirtualDub to put it all together.

Mainly I used XviD (and sometimes x264 for testing hardware etc.) from ffdshow, though I tried some other codecs too just for the experience. Now that almost all the possibly useful encoders have been taken out, I tried separate XviD for capturing. It worked of course (despite a few crashes which didn't happen with ffdshow, probably due to updating VirtualDub), but for my eyes/hardware, the quality and the speed seem to be pretty much the same as with ffdshow. So now I don't really know what use I'd have for ffdshow, since I can get the decoders with the encoders. Which means more apps/codecs for no apparent benefit for me, only more clutter and hassle.

The one thing that ffdshow is (was?) known for (at least for me & people I know & the magazines I read) is it's ability to handle almost all kinds of encoding/decoding needs, with possibly 1-3 additional codecs/splitters, and you could do anything. But remove the encoders (I REALLY have no use for FFV1, MJPEG, DV, HuffYuv..) and all you've got is a playback addon, which needs the splitter anyway for anything else than avi basically. Of course there's the filters/postprocessing stuff etc., of which subtitles would be the only one I needed, but since it's so inferior to DirectVobSub, that's no good either.

So what would I do with ffdshow? I can playback movies with the codecs I now need to install anyway, if they haven't come with the OS already. I really liked the vfw interface, similar GUI for audio/video decoding and for different video encodings, nice to try some filters/more rare codecs just for fun if there was no actual need. But now the fun & the experience seems to be over, which is really a pitty. If the encoders are taken out, I simply have no (practical) use for ffdshow.

Anyway, it was fun while it lasted. And I do understand your reasons for minimizing outdated/buggy/inferior code from the app, I've coded too and I know how precious time is, and how frustrating it is to do things that seem to only consume time and not bring any benefits.
I just hope that the large masses of people that are using ffdshow for things I mentioned would notice the changes you've done in time and have the ability (ie. language skills, finding the forum, time to read your reasons & know-how to explain use cases which you asked for) to express their opinions before it's too late, before another great app is being taken down the road not everybody's happy about, by the decision of a small number of developers. Those kind of situations we've all come across, I'm sure, just see eg. Firefox's disappearing features, or OpenOffice/LibreOffice, even Mac not being able to play flash videos, or Oracle's acquiring Sun and the worries and disappointments that's brought out (way out of proportion to this situation, I know, but basically the same issue).

Thank you if you've read all this, and thank you for your efforts and for your accomplishments; any way you go, you still deserve to be applauded!! :thanks:

[clsid]

What is the total size of your Windows and program files folders combined? Several gigabytes I guess? But installing a single extra codec suddenly creates a clutter? Oh, the horror.

Your heartwarming story is just more and more confirmation that our decision was in fact excellent.

By using the official Xvid codec you will soon be able to enjoy several nice improvement that have been recently committed to its CVS. Like better MT encoding and MT deblocking during playback. But if you prefer what you had, then you can just keep using an old version of ffdshow.

[kieranrk]

What is the total size of your Windows and program files folders combined? Several gigabytes I guess? But installing a single extra codec suddenly creates a clutter? Oh, the horror.

Your heartwarming story is just more and more confirmation that our decision was in fact excellent.


K-lite methodology on ffdshow. It's no wonder ffdshow is a total mess as acknowledged by ffmpeg developers themselves...

[clsid]

It is a mess that we are trying to clean up. The Xvid encoding in ffdshow was merely an unmaintained wrapper for an old version of xvidcore.dll. Are you suggesting we should keep that? What is wrong with the official Xvid codec?

Also, if you are suggesting that I am somehow responsible for the messy code in ffdshow then you know very little about the history of ffdshow.

Idiot.

[kieranrk]

It is a mess that we are trying to clean up. The Xvid encoding in ffdshow was merely an unmaintained wrapper for an old version of xvidcore.dll. Are you suggesting we should keep that? What is wrong with the official Xvid codec?

Also, if you are suggesting that I am somehow responsible for the messy code in ffdshow then you know very little about the history of ffdshow.


I was commenting on your response about bloat. Never said that anything about you being responsible for ffdshow's mess...

[iron2000]

Seem like MPC-HC's DXVA is more compatible.
Still having the freezing problem with ffdshow DXVA in 3713.

[avih]

Guys, take it easy please. Keep the discussion on topic. Thanks.

[_xxl]

I'll update soon xvidcore to latest. Maybe only ffmpeg encoding with ffdshow shouldn't be removed.... That shouldn't be to hard to maintain...

[clsid]

I was commenting on your response about bloat. Never said that anything about you being responsible for ffdshow's mess...
What you call bloat is a gift from god for another. Your needs do not equal those of everybody else.

The reasoning is to prefer two good dedicated solutions over a single mediocre all-in-one. Also to avoid wasting time on replicating functionality that already exists. That time is better spend on improving parts of ffdshow for which there isn't a good alternative.

We could even turn around the bloat story. Why should we include xvid in every single ffdshow installation, when the majority of users only plays files and thus never uses it? Force bloat on many to avoid bloat on a few?

I'll update soon xvidcore to latest. Maybe only ffmpeg encoding with ffdshow shouldn't be removed.... That shouldn't be to hard to maintain... If you want, go ahead. But if you do, also update the GUI. From a quick glance at the changelog these things might require attention: threads, slices, VHQ metric combobox, max bitrate, profiles, frame_drop_ratio.
http://cvs.xvid.org/cvs/viewvc.cgi/xvidcore/ChangeLog?r1=1.16&r2=1.17

I still think it is a waste of time to replicate xvidvfw.

[Milardo]

Hi,
Not sure if this the right area but it is mostly i believe a ffdshow problem i think.
I'm using virtualdub 32 bit on my win 7 x64 os and I've got ffvdub.vdf and ffdshow encoder. Either one I have used when I am encoding video in virtualdub will not output any of the image processing filters like post processing or visualizations! Is that how it is supposed to work? Basically I would like whatever image processing filter i checked and configured to be encoded/processed into my output file.

[STaRGaZeR]

A new year present for you all, the new ffmpeg's gradfun (deband filter in ffdshow). Improvements? Faster and it works just fine with x64 :D

ICL12: http://www.mediafire.com/?jvs457q43cixbq0
MSVC 2010 x64: http://www.mediafire.com/?aem2r27pddm1ldd

Please test and report bugs or whatever, there's still some things to do before I commit it.

[Milardo]

After some thorough testing, it seems some filters work and some don't like post processing doesn't work but noise does? Why is that?

[ranpha]

A new year present for you all, the new ffmpeg's gradfun (deband filter in ffdshow). Improvements? Faster and it works just fine with x64 :D

ICL12: http://www.mediafire.com/?jvs457q43cixbq0
MSVC 2010 x64: http://www.mediafire.com/?aem2r27pddm1ldd

Please test and report bugs or whatever, there's still some things to do before I commit it.

It is faster, no doubt about that and works on 1080p sources too.

[cyberbeing]

ffdshow builds after rev3326 appear to have an Ordered Chapters regression which crashes libavcodec and ffmpeg-mt when decoding H264.

Sample:
http://www.mediafire.com/?xlz5xe8l3gpcoqc

The March 22, 2010 ffdshow rev3328 ffmpeg update seems likely to blame.

[fastplayer]

A new year present for you all, the new ffmpeg's gradfun (deband filter in ffdshow). Improvements? Faster and it works just fine with x64 :D
I like how this year starts! :thanks:

[clsid]

ffdshow builds after rev3326 appear to have an Ordered Chapters regression which crashes libavcodec and ffmpeg-mt when decoding H264.

Sample:
http://www.mediafire.com/?xlz5xe8l3gpcoqc

The March 22, 2010 ffdshow rev3328 ffmpeg update seems likely to blame.
I am investigating it now, but it seems those two files don't use the same x264 encoding settings. The first file doesn't show any x264 metadata in MediaInfo.

[cyberbeing]

That's only because I split it multiple times to cut down on the filesize for upload, they both use identical x264 settings.

[clsid]

I have narrowed it down to this change:
http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=c1e15f7a54852ce64e345ac7b7f61edcbbc58478

Edit: and the actual crash occurs in h264.c line 1801:
h->frame_num= get_bits(&s->gb, h->sps.log2_max_frame_num);

Edit2: implemented a workaround in r3714

[STaRGaZeR]

Please test and report bugs or whatever, there's still some things to do before I commit it.

New version with fixes and a new option: radius. Right now I'm using ffmpeg defaults, threshold = 1.2 and radius = 16. If someone feels these defaults are off just propose new ones :p

ICL12: http://www.mediafire.com/?9s21x7txnrvqm11

BTW, debugging really needs to be fixed in the MSVC2010 solution, having to use 2008 only for that is a pain in the ass.

[arestarh]

Updated Russian translation for ffdshow:
http://www.mediafire.com/?7wi3b01yypm8doi

[Milardo]

Hi,

Can someone build ffdshow with post processing enabled in ffvdub and/or ffdshow encoder? How hard would it be compile ffdshow myself that has the filter enabled when encoding video? I would really like to use the all the image processing filters when encoding video.

[cyberbeing]

Thanks for the quick fix in rev3714 clsid. It does indeed seem to resolve the ordered chapter decoder crash.

[god_md5]

is the ffdshow h264 in decode first have bug ?
i try the ver is 3713
sample is here
http://dl.dropbox.com/u/3668343/sample.ts
http://dl.dropbox.com/u/3668343/sample2.ts
and xhmikosr ,i all the decode software is you comilpe ver ,thank you
i install you compile DirectVobSub
DirectVobSub_2.40.2499_x86.exe ,is it not have vobsub.dll and vobsub.ax inside?

[cyberbeing]

STaRGaZeR, could you please add old gradfun2db back to ffdshow and give an option to use either that or the new ffmpeg gradfun?

While the new ffmpeg gradfun may be fast, I find the quality utterly horrible on anime content... It doesn't appear to deband all that well, it's temporally unstable, makes nasty rings on hard edges (worse than gradfun2db), and it produces blocking artifacts at higher thresholds...

It may have it uses as a fast deband option on 1080p and such, but I think gradfun2db should be kept as well for those who desire a higher quality deband option.

[Keiyakusha]

cyberbeing
emm maybe I miss something but since when gradfun2db and debanding filter in ffdshow is NOT the same code?

[cyberbeing]

Since around 13 hours ago with FFDshow rev3717.

[Keiyakusha]

Oops... For some reason I thought its the same filter just improved in speed. Need to test the new revision then...