ffdshow tryouts project: Discussion & Development

[sansnom05]

ICL builds are necessary, they're a lot faster with filters enabled. VS should always be the main compiler. What we should do is upgrade to VS2010 and ICL12, and only keep those IMO. But giving people time to upgrade. What's the status on migrating to VS2010 BTW?


No problem building ffdshow using VS2010 with ICL 12. Here's the link if you or anyone want to try it: http://www.mediafire.com/?px9u12giiqyud5c, so far I see no problems. :)

[Ap3 n1nja]

@sansnom05: The ICL12 build seems to have the audio glitches XhmikosR's ICL12 build had before. Not sure if the cause is the same or not.

[fastplayer]

ICL builds are necessary, they're a lot faster with filters enabled.
That was an argument back in 2005. :p In 2010 you get hexa-core CPUs for less than 200 bucks, quad-core for less than 100.
By the way, didn't the gap between ICL and MSVC get smaller? I think we talked about this a few months ago...

[STaRGaZeR]

No problem building ffdshow using VS2010 with ICL 12. Here's the link if you or anyone want to try it: http://www.mediafire.com/?px9u12giiqyud5c, so far I see no problems. :)

I know, was talking about the adoption by the devs here. I've already switched to MSVC2010 thanks to your patches :)

That was an argument back in 2005. :p In 2010 you get hexa-core CPUs for less than 200 bucks, quad-core for less than 100.
By the way, didn't the gap between ICL and MSVC get smaller? I think we talked about this a few months ago...

Nope, it's the same today, because CPUs have improved, but video content has improved too :p. The gap hasn't changed. I can't use yadif+deband+resize+sharpen+subtitles+RGB32HQ(with dithering) with 1080i60 Blu-ray content using MSVC2008 or 2010 builds because they're slow, while it runs perfectly fine with ICL11/12 builds. When using these filters and content, playing and seeking is almost instant with ICL11/12, MSVC2010 can't even do realtime, if you seek you can wait an eternity for the player to resume. Not to mention the CPU heats up significantly more.

Blu-ray, 1080i60, MBAFF, ~35mbps average, with the filters listed above:

----------ICL12---------------------ICL11---------------------ICL10-------------------MSVC2010-----------------MSVC2008
http://thumbnails36.imagebam.com/10953/dba84e109528787.jpg (http://www.imagebam.com/image/dba84e109528787) http://thumbnails.imagebam.com/10953/603316109528790.jpg (http://www.imagebam.com/image/603316109528790) http://thumbnails.imagebam.com/10956/1c1ab8109555541.jpg (http://www.imagebam.com/image/1c1ab8109555541) http://thumbnails16.imagebam.com/10953/c090fd109528793.jpg (http://www.imagebam.com/image/c090fd109528793) http://thumbnails35.imagebam.com/10953/493632109528795.jpg (http://www.imagebam.com/image/493632109528795)

Compared to MSVC2008: MSVC2010 is ~4,1% faster, ICL10 is ~19,3% faster, ICL11 is ~18,5% faster, ICL12 is ~20,2% faster.

Keep in mind that 60fps is realtime here. Playing the file in MPC-HC, ICL11/12 run and seek fine, MSVC2010 runs but freezes after 5 secs to never recover, MSVC2008 freezes at start. All of this is when using the specs in my sig. I can't imagine how bad it is with those cheap CPUs, being painful already with an i5 at stock. Less demanding content just seeks faster, and the CPU is always quieter, sucks less power and produces less heat. I know that supporting 2 compilers is a pain in the ass, but the benefits are clear IMO.

[clsid]

Those who regularly build with ICL11/12 should together decide if ICL11 projects are removed or not in favor of ICL12, and whether it is based on vs2008 or vs2010.

I will continue to maintain the ICL10 project, since that has no known problems and I don't yet feel the need for updating. If I remember correctly, in the last benchmark ICL10 was also at least as fast as ICL11. Also, I use a patched ICL that allows SIMD use on AMD CPUs.

Makefiles for stuff that is compiled with Visual Studio by default can be removed if nobody objects.

It would be interesting to see some more benchmarks with a variety of files, settings, and CPUs. It would be cool if vs2008 is really a few % faster in some situations, because newer versions of visual studio are not always faster than their predecessors.

Are the ICL12 audio problems caused by ffdshow.ax or by libfaad? If it is the latter, then we could just use a plain vs2010 build for that.

off topic: have all vs2010 related issues for MPC-HC been solved already?

[dann23]

@STaRGaZeR. from where to download that program you used to test the decoding speed? I want to test it on my amd system.

I also tested the ICL12 build and I didn't see any noticeable problems and until now I didn't experince sound problems.

[fastplayer]

I know that supporting 2 compilers is a pain in the ass, but the benefits are clear IMO.
Thanks for the numbers! :) These are pretty impressive results coming from a pain in the butt compiler! :p
I wish I could see half the boost you're getting on my Athlon64 X2 setup (K8@2.4GHz): +6% over MSVC2008 was the best I could get from ICL10/11 (720p H.264, subtitles+RGB32HQ+dithering). Results with a more current Athlon/Phenom II would be really interesting. Just to see how much love Intel has left for AMD... :D

[STaRGaZeR]

Those who regularly build with ICL11/12 should together decide if ICL11 projects are removed or not in favor of ICL12, and whether it is based on vs2008 or vs2010.

ICL11 projects will be removed, but not yet. For ICL12 I'd choose VS2010.

I will continue to maintain the ICL10 project, since that has no known problems and I don't yet feel the need for updating. If I remember correctly, in the last benchmark ICL10 was also at least as fast as ICL11. Also, I use a patched ICL that allows SIMD use on AMD CPUs.

Do ICL11/12 builds work properly on AMD CPUs? Because if yes, the only reason to keep the ICL10 projects would be that H.264 crash (and your feel for updating :p), that is probably related to code that is there for fixing ICL10 bugs that are probably not present in newer versions like the one I fixed in r3588. I added ICL10 results to my previous post.

Makefiles for stuff that is compiled with Visual Studio by default can be removed if nobody objects.

I vote for removal.

It would be interesting to see some more benchmarks with a variety of files, settings, and CPUs. It would be cool if vs2008 is really a few % faster in some situations, because newer versions of visual studio are not always faster than their predecessors.

Indeed. Almost all of my content is Blu-ray, so I can't bench other stuff. But what we have to test are the filters, and only those that are not ffmpeg filters. They are content independent as they work with the decoded material. The only variables are resolution, fps, specs and builds.

Anyone with an AMD CPU to test? I can upload my sample if needed.

Are the ICL12 audio problems caused by ffdshow.ax or by libfaad? If it is the latter, then we could just use a plain vs2010 build for that.

The audio problems were caused by libfaad, and disabling an optimization fixed it.

@STaRGaZeR. from where to download that program you used to test the decoding speed? I want to test it on my amd system.

Graphstudio, go to View-->Decoder perfomance. If you can test different builds as I did, that would be great :)

[dann23]

Anyone with an AMD CPU to test? I can upload my sample if needed.

I have two AMD systems. One with athlon x2 and one with phenom II x4. I use ICL11 builds on both of them and didn't notice any problems. Just video decoding. no filters. It's worth mentioning that I'm using lavf splitter for mkv files and when it's possible ffdshow dxva. Tomorrow I'll try to post some results with different ffdshow builds.

[STaRGaZeR]

I have two AMD systems. One with athlon x2 and one with phenom II x4. I use ICL11 builds on both of them and didn't notice any problems. Just video decoding. no filters. It's worth mentioning that I'm using lavf splitter for mkv files and when it's possible ffdshow dxva. Tomorrow I'll try to post some results with different ffdshow builds.

If you're not using filters you won't see any differencies, as all the work will be done by ffmpeg, compiled with GCC in all builds. You can try high quality RGB conversion with dithering (you have to output RGB32 for this obviously), deband, sharpen-->unsharp mask, etc. In short, everything that doesn't use ffmpeg.

[STaRGaZeR]

The crash is related to libavcodec/ffmpeg-mt and it looks like it's the same one as the other one you fixed recently. But I cannot reproduce the crash if I run mpc-hc through MSVS.
EDIT: I tried a debug build of mpc-hc and I can reproduce the crash. It must be that ffdshow custom code in golomb.h, line 68. I cannot be sure but this is what I can tell from the disassembly code.

Try with this patch: http://www.mediafire.com/?hnw9w9m7ja1sv1d

Check if ICL11/12 and debug buils are fixed. Fingers crossed :)

[sansnom05]

Try with this patch: http://www.mediafire.com/?hnw9w9m7ja1sv1d

Check if ICL11/12 and debug buils are fixed. Fingers crossed :)

Here's updated icl12/vs2010 builds with STaRGaZeR's golomb patch and /Ob1 flags for libfaad2(aac) to fix audio glitchs. http://www.mediafire.com/?jc0xbxaczqad44r

And if anyone want the vs2010/icl12 project files, please PM me.

[XhmikosR]

My plan was to first get VS2008/ICL12 builds to work fine and then move to VS2010/ICL12 finally. I'll talk to sansnom05 on irc and we'll see what will go in the svn. I have only VS2008/ICL12 projects in my local tree.

@STaRGaZeR: OK then since you do plan to delete the ICL11 projects. I don't like having 20 files in a dir with 15 files being projects :p
I'll give a try to your patch and I'll let your know. (I only have ICL12 installed so I can't try the ICL11 builds anymore)

@clsid: I agree with removing the makefiles from stuff build with VS. I suggest that we remove any random solution files since there are already solution files for ffdshow which includes those projects, like KernelDeint.


EDIT:
@STaRGaZeR: I still get the crashes even with that patch. ICL12 build (http://xhmikosr.1f0.de/zzzother/ffdshow_rev3637_20101204_xhmikosr_icl12.exe).

[STaRGaZeR]

I vote for VS2010 and VS2010/ICL12. I'll delete all the ICL11 stuff as soon as I upgrade. What's left to do to delete VS2008 projects and start making "generic" builds with VS2010?

About the patch, then I'm out of ideas. I'd need a sample to reproduce the crash plus the name of a function or something to start from there. Did it at least fix the crash in debug builds? Does it happen if you use libavcodec instead of ffmpeg-mt?

BTW, I just tested x64 builds with the same sample and filters as before and there's no difference between VS2008/10.

[XhmikosR]

Just to make sure we talk about the same thing, when I said VS2008/ICL12 I mean the ICL12 projects with VS2008. Cause with ICL12 you can use VS2010 now but I had a few problems so I did what was easier at the time. If you mean the generic MSVC builds, I too vote for 2010 since it has no change in size and performance is better. I'll talk to sansnom05 on the irc about the ICL12 builds.
As for the crash I'll need to start digging into the problem with debug builds.

[STaRGaZeR]

Just to make sure we talk about the same thing, when I said VS2008/ICL12 I mean the ICL12 projects with VS2008. Cause with ICL12 you can use VS2010 now but I had a few problems so I did what was easier at the time. If you mean the generic MSVC builds, I too vote for 2010 since it has no change in size and performance is better. I'll talk to sansnom05 on the irc about the ICL12 builds.
As for the crash I'll need to start digging into the problem with debug builds.

Yup, I meant ICL12 projects with VS2010 instead of 2008. And make the generic builds (x86 and x64) with VS2010 from now on.

So who's against removing VS2008 projects and for what reason? There are no known problems with them AFAIK.

[XhmikosR]

OK, I have good news. I'm talking with sansnom05 on irc trying to get the new projects ready and VS2010/ICL12 builds don't crash with the same sample that the VS2008/ICL12 build crashed. Very weird...
I have no problem in removing VS2008 projects, I won't use them anymore.

[STaRGaZeR]

Didn't you say that it happened with ICL11 too? But whatever, if it's fixed with ICL12/VS2010... :p

[fmagreed2]

Could support for HDYC pixel format be added to the encoder? HDYC is the output of the popular black magic capture cards. The default codecs lack options, and aren't really suited for many popular uses of the cards (such as recording console gameplay).

According to fourcc.org HDYC is identical to UYVY in layout, but uses the BT709 colorspace instead of normal BT470.

Off that information, it sounds like it shouldn't be too hard to add, but I really have no idea about these things.

Thank you for your time.

[XhmikosR]

@devs:
How about commenting out the code regarding the donates? The link doesn't work anymore.
Also, do we need all the Japanese translated text files? And also the build scripts are kinda of useless and obviously we don't need 10 batch files for simply building ffdshow. And I'm pretty sure everyone is using their scripts since the ones in the svn do not work as expected in all cases and they do not cover all the compilers.

@STaRGaZeR: when you update to icl12 please remove the icl11 projects.

[clsid]

@devs:
How about commenting out the code regarding the donates? The link doesn't work anymore.It can be removed.

[XhmikosR]

Done. How about the other stuff I asked?

[STaRGaZeR]

And also the build scripts are kinda of useless and obviously we don't need 10 batch files for simply building ffdshow. And I'm pretty sure everyone is using their scripts since the ones in the svn do not work as expected in all cases and they do not cover all the compilers.

Agree.

And what do you think about renaming libavcodec.dll and associated stuff to ffmpeg.dll? Our libavcodec is not libavcodec anymore.

[XhmikosR]

I'm fine with it as long as the installer deletes the old dlls on install if it's an upgrade.
How about the translated readme files? They are not used as far as I can tell and the root directory is too populated in my opinion.

Oh, by the way, is anyone going to update x264, tremor or unrar? The current unrar source is butchered and it's hard for me to update it. sansnom05 updated unrar but he didn't commit it though it worked. I can't remember the reason.

EDIT: I want to apply astyle formatting in ffdshow's own code only since right now its code it's practically unreadable for the most people. What do you prefer, tabs or spaces? Right now I have used 4 spaces for indentation.

[STaRGaZeR]

I don't know how to do that with InnoSetup, but why do it? It wasn't done with libmplayer.dll and since nothing is going to use the dll it should be fine to leave it there.
I'm all for deletion, but if other devs don't want to do it one solution would be to not delete them, create a doc directory and put everything there.

I won't update x264. IMO it has no reason to be there but I know a lot of people use it and will complain, so meh. I asked about Tremor some time ago and there were no responses, libavcodec has been the default decoder for vorbis audio for quite some time with no complaints. So I'll delete it when I have time. I don't care about unrar either.

Spaces of course. If possible try to mimic ffmpeg's style. Just open any of its files and look at it, very easy to read, very well organized, looks really good...

BTW, there's something wrong with debug builds with VS2010. It compiles fine, but when you hit debug I get this warning:

C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5): warning MSB8012: TargetPath(E:\ffdshow\obj\Debug_Win32_VC2010\ffdshow.ax) does not match the
Linker's OutputFile property value (E:\ffdshow\bin\ffdshow.ax). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName)
and $(TargetExt) property values match the value specified in %(Link.OutputFile).
Creating library E:\ffdshow\obj\Debug_Win32_VC2010\/ffdshow.lib and object E:\ffdshow\obj\Debug_Win32_VC2010\/ffdshow.exp
ffdshow_2010.vcxproj -> E:\ffdshow\obj\Debug_Win32_VC2010\ffdshow.ax

Then an error popup "Unable to start program "E:\ffdshow\obj\Debug_Win32_VC2010\ffdshow.ax"". Can you take a look at it?

[XhmikosR]

It's easy to do it with Inno Setup in the [InstallDelete] section but I'll leave it to clsid to decide about it.

As for the VS2010 warnings, they are caused because the OutDir is different that the linker outdir etc. Cause the dlls and the ax files are output in the bin dir while all other files are output in different dirs. That's why I said in the past that I don't like this approach. I would prefer if everything used one outdir based on the config/compiler.

And also the template configs should be removed since they are useless.

As for astyle, check this and tell me what you think, or suggest any specific options http://pastebin.com/qJtD1XsM
I used 4 spaces for that and all other options are the default ones.

[clsid]

Renaming libavcodec.dll to ffmpeg.dllI don't mind this change if you guys would really like it. But I don't consider this very important. I do would like to keep the name libavcodec in the GUI though, as changing it would confuse people, and of course the decoders are part of libavcodec, so it is still correct.
Deleting files with InnoSetup is easy. Just one line in [InstallDelete] section.
Translated text filesUnused ones could be removed.
Build scriptsI would like to keep these. They are also useful for non-dev builders and serve as a good example for create custom scripts. The ICL one could be removed though.
Astyle formattingI prefer these settings:
--style=kr
--indent-switches
--indent-namespaces
--add-brackets
--convert-tabs

The formatting should be applied just a few files at a time (25 max?) and a build should be made before each commit. This to avoid errors and make it simpler to track down any possible regressions.

The formatting should only be applied to files belonging directly to ffdshow. Files from external sources should not be touched, for example the various codec libs, zlib, etc.

Removing tremorI am not aware of any bugs/limitations in the current libavcodec Vorbis decoder. So unless anyone can come up with a good reason to keep tremor, I agree that it may be removed.

Removing x264I don't mind if this would be removed. It is not really being maintained anymore, and alternatives such as x264vfw as available. Although I agree that some users may not be happy if it were to be removed, but we can't make everybody happy.

We could also consider removing other encoders from ffdshow. FFV1 and FFVHUFF are useful, but what about the others? Is there any good reason for anyone to use for example the libavodec MPEG4 encoder instead of Xvid?

[XhmikosR]

I always test before committing, and I was thinking about the same thing, apply astyle in one dir at a time and check things. I'll try your suggested settings and I'll let you know. And of course I'm not going to apply it in 3rd party code, I know how painful it's to update them after that :p

I do believe that the current scripts are bad. The last time I tried them just for the fun of it, it simply failed. I could share my script but it's not completely silent at the moment, since I use some choice commands to choose what to build. If you could at least remove most of them and simply update the base script to use a few arguments that would be better. Also the Inno Setup path is simply wrong. See the mpc-hc batch file for how to get its path correctly.

EDIT: I'm not sure about the --add-brackets option though I do see the purpose of it. I agree with the rest and also using 4 spaces.

[dann23]

We could also consider removing other encoders from ffdshow. FFV1 and FFVHUFF are useful, but what about the others? Is there any good reason for anyone to use for example the libavodec MPEG4 encoder instead of Xvid?

As I remember, drevil_xxl used to update x264 and if I'm remembering correctly it happend 3 or 4 months ago. Maybe I'm wrong about this. Also I'm using libavcodec mpeg4 encoder instead of xvid. :)

[clsid]

Yes, but WHY are you using the libavcodec MPEG4 decoder?

[dann23]

I have no special reason. It's just that I need to make something with dx50 as fourcc and some time ago xvid seemed to be dead. As decoder I don't know anyone to use xvid. that's why I didn't use the xvid encoder.

[STaRGaZeR]

@clsid

The name change only affects the dll. Changing the GUI would be wrong, because as you say the decoder itself is libavcodec.

I'll remove Tremor then.

So do we remove x264? I vote yes. Also a list fo encoders I'd remove: all libavcodec ones except HuffYUV, FFV1 and maybe DV. And about xvid, xvid also has a vfw codec that works perfectly well, so the same x264 argument could be applied here.

I have no special reason. It's just that I need to make something with dx50 as fourcc and some time ago xvid seemed to be dead. As decoder I don't know anyone to use xvid. that's why I didn't use the xvid encoder.

xvid can also encode with DX50 FOURCC.

[clsid]

ffdshow also has a DirectShow encoder in addition to its VFW one. But there also is an alternative (http://blog.monogram.sk/janos/2009/05/20/monogram-x264-encoder-1050/) for that in case of x264. I don't know if it is good though.

Here is a list of encoders in ffdshow, with my votes/comments:
MPEG4 => remove
Xvid => remove
H.264 => remove
DivX3 => remove
MS MPEG4 => remove
MPEG2 => Remove from VFW, keep in DS? Any free DS alternatives?
MPEG1 => Remove from VFW, keep in DS? Any free DS alternatives?
H.261/3/3+ => Any VFW alternatives?
Windows Media * => remove
FFV1 => keep
Huffyuv => keep
DV => keep
MJPG => keep?
Lossless JPG => keep? Any advantage over for example Huffyuv?

We could possibly only disable stuff now, await feedback, and then decide in a few months what to remove.

[dann23]

for me it's ok but how to use directshow encoder with virtualdub?
I can quit using vfw completly. I have no problem with this. But I need a similiar tool like virtualdub that is capable to use directshow encoder. Any suggestions?

[CruNcher]

Could somebody check Karls Matroska RV9 testcase for me it drops heavily frames with ffdshows RV40 libavcodec decoder in MPC-HC im not sure why it seems strange as CPU utilization is very low obviously, you can find it here http://www.mediafire.com/?tc6tb131m1i677z.
Tried it also in graphstudio same result it drops frames heavily on both Gabest and Haalis Splitter with the ffdshow decoder. No problems with mplayer,vlc only ffdshow and also the ffplay builds from http://ffmpeg.arrozcru.org/autobuilds/ show this performance issue.

Maybe some Optimization is missing @ compilation in ffdshow as well as those ffplay builds ?

[XhmikosR]

Astyle formatting should be completed. If I applied it in a couple of 3rd files feel free to revert the changes, I tried to review most of the files just in case they are 3rd party code. If I missed any source file, feel free to apply astyle to it.

EDIT: Why exactly do we have to call update_version.bat from the IS script? Isn't it enough to get the needed stuff from svn_version.h? You must have compiled ffdshow before building the installer which means you already have svn_version.h anyway.

[clsid]

There may be changes committed unrelated to building ffdshow.ax, so that is why is never hurts to update version from IS as well.

The RV40 issue is a known FFmpeg bug:
https://roundup.ffmpeg.org/issue814

[XhmikosR]

I'm sorry but this is impossible. The revision will be the last committed rev so calling update_version.bat is pointless. Or at least give me one example where this is needed. Cause it beats me :p

[clsid]

I already gave the example. Commit something does does not affect ffdshow directly. Don't (re)compile ffdshow.ax. Build installer. Yes, I know that the version in the .ax will then be somewhat 'outdated'. But it is masochistic to compile again it just to update a mostly meaningless number.

Please focus on things that actually make ffdshow better in terms of functionality/stability/performance.

[XhmikosR]

OK so you want to keep the case where the wrong revision will be used? That's simply wrong. I will focus where I can and have interest atm.

PS. STaRGaZeR, update your Inno Setup version :p

[clsid]

It is not wrong. The revision applies to the project as a whole, not individual files. If ffdshow.ax has not changed since rev X, then there is no requirement to update its version to rev X+1. That is just optional.

[STaRGaZeR]

ffdshow also has a DirectShow encoder in addition to its VFW one. But there also is an alternative (http://blog.monogram.sk/janos/2009/05/20/monogram-x264-encoder-1050/) for that in case of x264. I don't know if it is good though.

Here is a list of encoders in ffdshow, with my votes/comments:
MPEG4 => remove
Xvid => remove
H.264 => remove
DivX3 => remove
MS MPEG4 => remove
MPEG2 => Remove from VFW, keep in DS? Any free DS alternatives?
MPEG1 => Remove from VFW, keep in DS? Any free DS alternatives?
H.261/3/3+ => Any VFW alternatives?
Windows Media * => remove
FFV1 => keep
Huffyuv => keep
DV => keep
MJPG => keep?
Lossless JPG => keep? Any advantage over for example Huffyuv?

We could possibly only disable stuff now, await feedback, and then decide in a few months what to remove.

Where is that DS encoder? I didn't know about it and it doesn't show in Graphstudio.

The disable proposal sounds good to me, but in a few months is possible that nobody is active to remove them. I'd remove them now, we can always revert the commit if people complain too much. My opinion:

MPEG4 => remove
Xvid => remove (people should use xvid itself)
x264 => remove (nobody should use it, outdated, can't configure it properly, has proper vfw and cli alternatives)
DivX3 => remove
MS MPEG4 => remove
MPEG2 => remove (if anyone actually wants to encode something in MPEG-2 they should use a proper encoder, like HCenc)
MPEG1 => remove
H.261/3/3+ => remove
Windows Media * => remove
FFV1 => keep
Huffyuv => keep
DV => keep
MJPG => remove
Lossless JPG => remove

A lot of them are exotic formats that shouldn't really be supported in ffdshow. These formats are so rarely used that if people want to encode to them I'm sure they're advanced enough to use ffmpeg directly, something they should be doing in the first place. So basically I agree with you: only keep FFV1, HuffYUV and DV.

for me it's ok but how to use directshow encoder with virtualdub?
I can quit using vfw completly. I have no problem with this. But I need a similiar tool like virtualdub that is capable to use directshow encoder. Any suggestions?

What formats do you want to encode to? H.264, use x264vfw in Virtualdub. xvid, use xvid in virtualdub. Both have way better GUIs, they're updated, etc.

PS. STaRGaZeR, update your Inno Setup version :p

Done, but is 5.3.8 not enough or what? :eek:

[CruNcher]

There may be changes committed unrelated to building ffdshow.ax, so that is why is never hurts to update version from IS as well.

The RV40 issue is a known FFmpeg bug:
https://roundup.ffmpeg.org/issue814

Thx for the hint but im not sure if that is the real problem as VLC (nightlies) actually plays it fine sound drops from time to time but overall much better.

The end result is this absolutely unwatchable because of the jitter in mpc-hc + ffdshow

http://img31.imageshack.us/img31/6158/jitterheavy.png

[dann23]

Where is that DS encoder? I didn't know about it and it doesn't show in Graphstudio.

The disable proposal sounds good to me, but in a few months is possible that nobody is active to remove them. I'd remove them now, we can always revert the commit if people complain too much. My opinion:

MPEG4 => remove
Xvid => remove (people should use xvid itself)
x264 => remove (nobody should use it, outdated, can't configure it properly, has proper vfw and cli alternatives)
DivX3 => remove
MS MPEG4 => remove
MPEG2 => remove (if anyone actually wants to encode something in MPEG-2 they should use a proper encoder, like HCenc)
MPEG1 => remove
H.261/3/3+ => remove
Windows Media * => remove
FFV1 => keep
Huffyuv => keep
DV => keep
MJPG => remove
Lossless JPG => remove

A lot of them are exotic formats that shouldn't really be supported in ffdshow. These formats are so rarely used that if people want to encode to them I'm sure they're advanced enough to use ffmpeg directly, something they should be doing in the first place. So basically I agree with you: only keep FFV1, HuffYUV and DV.



What formats do you want to encode to? H.264, use x264vfw in Virtualdub. xvid, use xvid in virtualdub. Both have way better GUIs, they're updated, etc.



Done, but is 5.3.8 not enough or what? :eek:

Fine. Remove all the formats. vfw is old and in windows 7 is present just for compatibility with old software. But where is the DS encoder and how to use it??

[khagaroth]

@XhmikosR
revision 3668, ffdshow.rc:
19: // Neutral resources
20:
21: #if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_NEU)
22: #ifdef _WIN32
23: LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
24: #pragma code_page(1253)
25: #endif //_WIN32
shouldn't that be 1252 (latin 1) instead 1253 which is Greek

[LigH]

I'd like to vote to keep ffdshow's M-JPEG codec. It is by far the best quality M-JPEG codec I know. See my comparison thread in the german board (http://forum.gleitz.info/showthread.php?24071-MotionJPEG-Codec-Vergleich&highlight=picvideo). There is no substitution for me.

Reply #1 (start) = artifical still content with samples (click the smilies for sample pictures); reply #19 (http://forum.gleitz.info/showthread.php?24071-MotionJPEG-Codec-Vergleich&p=217751&viewfull=1#post217751) = VQEG comparison with PSNR and SSIM

[XhmikosR]

It is not wrong. The revision applies to the project as a whole, not individual files. If ffdshow.ax has not changed since rev X, then there is no requirement to update its version to rev X+1. That is just optional.
Well, in case you don't know, you do NOT have to rebuild the ffdshow project to change the revision. The only file which is affected by the revision is ffdshow.rc. So, the resource compiler will rebuild the resource file and that's all. This will take something like 3 seconds.
It's redundant and should be removed.

Done, but is 5.3.8 not enough or what? :eek:
v5.4.0 is the latest which has a much improved editor. I can tell from the fact that every time you edited the .iss file a new empty line was inserted at the end of the script which was fixed in the latest version.:p
And 5.3.8 is almost one year old, there have been so many improvements.

shouldn't that be 1252 (latin 1) instead 1253 which is Greek
Probably, but this is what VS does.

[_xxl]

Originally Posted by clsid
ffdshow also has a DirectShow encoder in addition to its VFW one. But there also is an alternative for that in case of x264. I don't know if it is good though.
We could possibly only disable stuff now, await feedback, and then decide in a few months what to remove.
I don't have time to update them, please start remove all unnecessary code and maybe fix all warnings. I vote to remove them.

[Px]

shouldn't that be 1252 (latin 1) instead 1253 which is GreekProbably, but this is what VS does.
Location: Hellas (Greece)
:rolleyes:

[XhmikosR]

:rolleyes:

Hmm, so?