ffdshow tryouts project: Discussion & Development

[clsid]

Old hardware shouldn't be the issue. ffdshow works fine for me on even older hardware than you have. Settings load instantly.

[Monamona]

Under YCbCr specification set to Auto, it seems that ITU-R BT.709 is used only for width > 1024.
However, it should be also used for hight >=720 as HDTV definition.

[leeperry]

Ofcourse all of this should be based on 3D-luts (so we need basic ones on top of the per-user custom ones)
problem is : each LUT is 48 mb so one for 601/one for 709...we're talking about ffdshow requiring at least 100 mb of HDD space(and better not get them fragmented, I personnaly copy them on a ramdisk :D )

they compress to 1 mb w/ WinRAR so the installer size is no problem, though.

[Taurus]

Old hardware shouldn't be the issue. ffdshow works fine for me on even older hardware than you have. Settings load instantly.
I think you got me wrong.
ffdshow is working fine here up to the newest releases.
It's only opening the properties windows which shows this weird behaviour.
And I tested all versions from late november08 to January09.
It exactly changes between 05.12.2008 and 08.12.2008.
I've read the changelog @sourceforge but could'nt see any significant changes at this time in the gui.
I'm not complaining, just wondering :p

[Leak]

they compress to 1 mb w/ WinRAR so the installer size is no problem, though.
ffdshow already includes the unrar sources so keeping them compressed shouldn't be hard.

Also, how long does calculating those tables take? If it's a couple of seconds tops it's something that could be done right after installation...

[leeperry]

how long does calculating those tables take? If it's a couple of seconds tops it's something that could be done right after installation...
takes less than 5 seconds on my o/c Q6600 :cool:

[haruhiko_yamagata]

As a long time user of ffdshow, since when Milan Cutka was still around..
For the first time I found this most annoying behaviour in ffdshow.
My childrens PC's are mostly equipped with older hardware, Athlon XP 2200 and up.
Everytime I call up the video or audio properties page it takes about half a minute
until the windows load and the video and audio gets stuttering in the background.
So I did a little investigation. Every version of ffdshow before the 08.12.2008 is doing fine,
almost immediately the properties window pops up.
So ffdshow_rev2421_20081205_clsid.exe is the last good working.
ffdshow_rev2447_20081208_clsid.exe is the first one which shows the lags.
WinXP SP3 on three machines
I can't reproduce now, but I experienced the slowdown several times. Maybe the settings in the registry is broken somehow.
Don't you have garbled AviSynth script?
Could you save the settings and uninstall/reinstall? If it fixes the problem, please send me the settings.

[Taurus]

I can't reproduce now, but I experienced the slowdown several times. Maybe the settings in the registry is broken somehow.
Don't you have garbled AviSynth script?
Could you save the settings and uninstall/reinstall? If it fixes the problem, please send me the settings.
Uninstall/Reinstall, cleaning registry, -nothing changes.
Avisynth in conjunction with ffdshow works fine as far as I can see.
I can open any directshowsource and avisource script without any errors or misleading colours.
And remember, I did it the hard way, testing every release from late november till january.
The turning point was at 5th to 8th December.
Thank you for your interest in this thing.

Taurus

[iSunrise]

...and the video and audio gets stuttering in the background.
I experienced something of that kind 2 weeks ago, strange thing is that this problem went away after some updates to my Vista x64 SP1. The video and audio started to stutter right after I clicked the right mouse button and the context-menu showed up and kept stuttering until I closed the context-menu again. Happened both with EVR and Haali as renderer and both with ffdshow and the standard MS WMVideo/Audio Decoder.

I read that you use XP SP3, but nevermind, I´m gonna post it anyway, because it may help with your problem.

Since I didn´t really use a stop watch, all that I can remember is that I´ve installed the latest DirectX-redist directly from Microsoft (http://www.microsoft.com/downloads/details.aspx?FamilyId=2DA43D38-DB71-4C1B-BC6A-9B6652CD92A3&displaylang=en), because 3DMark Vantage asked for d3dx10_36.dll amongst other things. There were also _a lot_ of other files updated, which I didn´t expect since I´ve installed a fresh new Vista x64 SP1 from a bought DSP DVD.

After these updates I´ve never had any problems anymore, everything runs rock stable and fast (currently using x86 ffdshow, since MT had problems with some of my MP4 files, I´m not using x64 since I´m not sure if it is wortwhile). Maybe there were some new files related to DirectShow in there, I´m not sure.

Try it if you didn´t already do this. Maybe it solves your problem.

[tobinaka]

Thanks for ffdshow tryouts developers! I installed rev2653 (2nd Feb 2009) and saw video_full_range_flag interpreted correctly, how nice it is! I'm looking forwards to seeing a new stable version goes released.

I think it would be better if there is such a notice in "RGB conversion" setting like "uncheck all YUV from 'Supported output colorspaces' in output setting". Some people who gave me comments in my blog, and I also, have a simple mistake not to uncheck them. I guess that YUVs have higher priority than RGB to be send for renderes, then if a YUV is checked at "Supported output colorspaces' not RGB which is converted at ffdshow but YUV goes directly to renderers. Don't say those mistakes are stupid. Even if so, the fact is there are some users who miss unchecking them and all the option at "RGB conversion" may get affected by 'Supported output colorspaces'.

By the way, in rightside menu of ffdshow Japanese version "RGB conversion" isn't intended below "output". That's partly why some Japanese made the mistakes as above. Someone told me he wanted to correct and asked me where to reporte it. Please update it if you can.



What about my algorithm :D

AviSynth's YV12->YUY2 converter does this vertically, but it has limitation of output bit depth (naturally 8bit).
My implementation output 10bit vertical 75:25 averaging, 12 bit horizontal 75:25 averaging, other calculations are more than 10bit.


After thinking about chroma locations, I think bilinear interpolation is the best way. Your 75:25 is good, but it's only for "chroma sample type 1" in Annex E of H.264/AVC recommendation. Indeed, that's the way of YUV converting in AviSynth as much as in huffyuv and Ut Video Codec Suite. But it's not the only way: H.264 recommendation says there are 6 way to locate chroma samples. For example, I found "chroma sample type 0" the most suitable for the result of YUV converting in AviUtl, a video editor which has been widely used in Japan and in Asia as I heard. The documentation of x264 says "type 0" is for MPEG-2 and "type 1" is for JPEG-1 and MPEG-1.

Annex E of H.264 recommendation determines 6 chroma sample types and indicated on a figure, but for reference I explain it with the figures I made.

http://www.tobinaka.com/files/4luma.jpg <- 2x2 luma locations. Two upper luma are of top fields and two lower luma are of bottom fields.
http://www.tobinaka.com/files/6chromaloc.jpg <- 6 chroma sample types on it.

IMO, the locations of each chroma sample type tell how 2x2 chroma samples was down-scaled into 1x1 sample. One of the most important information about chroma is its value. The value of 1x1 chroma is usually given at the avarage from 1 to 4 samples of chroma. Then if you avarage not only their values but also their locations? I think that's the locations of 6 chroma sample types.

http://www.tobinaka.com/files/chromaloc0.jpg　http://www.tobinaka.com/files/chromaloc1.jpg　http://www.tobinaka.com/files/chromaloc2.jpg　http://www.tobinaka.com/files/chromaloc3.jpg　http://www.tobinaka.com/files/chromaloc4.jpg　http://www.tobinaka.com/files/chromaloc5.jpg

If the value of 1x1 chroma is the average of all of 2x2 chroma samples, the location of 1x1 chroma is the same as type 1.
If you make the value of 1x1 chroma by avaraging two rightside samples, the location of 1x1 chroma is the same as type 0.

So, how you use those informations of chroma sample types? I think it should be used for interpolation in converting YUV 4:2:0 into 4:4:4 or RGB. I show below 16 locations of chroma samples type 0 or 1 around the chroma sample you want to determine in YUV 4:4:4.

http://www.tobinaka.com/files/16chromaloc1.jpg
chroma sample type 1, the same 75:25 avarage linear interpolation in vertical and horizontal.
http://www.tobinaka.com/files/16chromaloc0.jpg chroma sample type 0, for MPEG-2 and x264 default.

You will find the figures above similar to the calculation for bicubic or B-spline interpolation. Those figures is useful to think about bilinear interpolation: see only 4 chroma locations around the red point.

If you support H.264 chroma sample types, the speed will become slower than your simple 25:75 avarage converting. And many users don't set H.264's chroma sample type in the right way. The default at x264 is chroma sample type 0 but the way of AviSynth looks like type 1 for me.

But I prefer what's written at H.264 recommendation to the current situation. So, how about setting the current way as default and add the option of "auto" like video_full_range_flag?

[ikarad]

I have the same issue. I have to move the slider before the sound will kick in (or alternately I can click on the subtitle option in the splitter output). I am using an ATI HDMI sound card. I have used various revs of MPC-HC filters along with different revs of ffdshow. This only happens with TrueHD. thx

rev2653 corrects your problem or not?

[ikarad]

I have fixed the first bug already : no sound on some MLP/TrueHD samples.

Done in revision 2648

Concerning the other bug you mentioned, I wonder how to test it without an ATI 4xxx or a sound card that can handle HD bitstream ?

Maybe the previous fix will solve the problem...

thanks,
But I have problem with an other video.
sample here:
http://www.zshare.net/info.html?55201231-bd04da067f0414b262f3c37ee94b83ab

Sound disappears after 20 seconds (rev2653).
I notice that jitter is very bad (-8656 ms)
http://nsa05.casimages.com/img/2009/02/06/mini_090206054500879129.jpg (http://www.casimages.com/img.php?i=090206054500879129.jpg)


one question: what is the other bug?

If it's the bug that ffdshow doesn't recognize lpcm sountrack from blu-ray, this problem isn't resolved

And I don't understand why you must have ati HD4xxx because even with stereo lpcm soundtrack (2.1), ffdshow isn't capable to listen lpcm soundtrack from blu-ray

[haruhiko_yamagata]

Thanks for ffdshow tryouts developers! I installed rev2653 (2nd Feb 2009) and saw video_full_range_flag interpreted correctly, how nice it is! I'm looking forwards to seeing a new stable version goes released.

I think it would be better if there is such a notice in "RGB conversion" setting like "uncheck all YUV from 'Supported output colorspaces' in output setting". Some people who gave me comments in my blog, and I also, have a simple mistake not to uncheck them. I guess that YUVs have higher priority than RGB to be send for renderes, then if a YUV is checked at "Supported output colorspaces' not RGB which is converted at ffdshow but YUV goes directly to renderers. Don't say those mistakes are stupid. Even if so, the fact is there are some users who miss unchecking them and all the option at "RGB conversion" may get affected by 'Supported output colorspaces'.
I think it's the worst part of ffdshow's GUI. I agree it needs to be improved.
CoreAVC has a good GUI, but that may not suit for ffdshow. ffdshow has "Select closet matching colorspace" feature. For example, if the input is YUY2 ffdshow output YUY2 instead of YV12.
Maybe simple check box "Prefer RGB32" may help, but what about NV12?
Maybe a check box "Force output colorspace" + combo box [YV12, YUY2, NV12, RGB32]? Fallbacks will be allowed.

By the way, in rightside menu of ffdshow Japanese version "RGB conversion" isn't intended below "output". That's partly why some Japanese made the mistakes as above. Someone told me he wanted to correct and asked me where to reporte it. Please update it if you can.OK, I'll do so.

After thinking about chroma locations, I think bilinear interpolation is the best way. Your 75:25 is good, but it's only for "chroma sample type 1" in Annex E of H.264/AVC recommendation. Indeed, that's the way of YUV converting in AviSynth as much as in huffyuv and Ut Video Codec Suite. But it's not the only way: H.264 recommendation says there are 6 way to locate chroma samples. For example, I found "chroma sample type 0" the most suitable for the result of YUV converting in AviUtl, a video editor which has been widely used in Japan and in Asia as I heard. The documentation of x264 says "type 0" is for MPEG-2 and "type 1" is for JPEG-1 and MPEG-1.

Annex E of H.264 recommendation determines 6 chroma sample types and indicated on a figure, but for reference I explain it with the figures I made.
Thank you for the info. It shouldn't be too hard to support type 0. Other types may not worth while.
But recent experiments seem to indicate type 1 looks better for MPEG-2 samples. More experiments are welcome.

[haruhiko_yamagata]

Uninstall/Reinstall, cleaning registry, -nothing changes.
Avisynth in conjunction with ffdshow works fine as far as I can see.
I can open any directshowsource and avisource script without any errors or misleading colours.
And remember, I did it the hard way, testing every release from late november till january.
The turning point was at 5th to 8th December.
Thank you for your interest in this thing.

Taurus
Thank you for your tests. I can't find anything suspicious between revision 2421 and 2447.
Only one thing relevant is rev 2441, which correct initialization of CRT.
As iSunrise pointed, it may be related to some bugs of OS or other device drivers, as initialization of CRT may invoke initializer of GDI and DirectX.

[madshi]

In revision 2653 (haven't checked newer revisions) there's a checkbox "High quality YV12 to RGB conversion" in both the "Output" and "RGB conversion" tabs. Wouldn't it make more sense to have this option only in the "RGB conversion" tab and to remove it from the "Output" tab? I always found that logically it didn't really belong into the "Output" tab, anyway. Fits much better into the "RGB conversion" tab.

Thank you!!

[haruhiko_yamagata]

In revision 2653 (haven't checked newer revisions) there's a checkbox "High quality YV12 to RGB conversion" in both the "Output" and "RGB conversion" tabs. Wouldn't it make more sense to have this option only in the "RGB conversion" tab and to remove it from the "Output" tab? I always found that logically it didn't really belong into the "Output" tab, anyway. Fits much better into the "RGB conversion" tab.

Thank you!!OK, I'll remove it next time I change the dialog.

[albain]

thanks,
But I have problem with an other video.
sample here:
http://www.zshare.net/info.html?55201231-bd04da067f0414b262f3c37ee94b83ab

Sound disappears after 20 seconds (rev2653).
I notice that jitter is very bad (-8656 ms)
http://nsa05.casimages.com/img/2009/02/06/mini_090206054500879129.jpg (http://www.casimages.com/img.php?i=090206054500879129.jpg)


one question: what is the other bug?

If it's the bug that ffdshow doesn't recognize lpcm sountrack from blu-ray, this problem isn't resolved

And I don't understand why you must have ati HD4xxx because even with stereo lpcm soundtrack (2.1), ffdshow isn't capable to listen lpcm soundtrack from blu-ray

Ok I reproduce the problem : it is working but the jitter causes problem. I remember I disabled jitter correction for MLP because it was causing problems. I will digg this around.

Concerning LPCM, I have no problem playing LPCM 2.0 but you mentioned LPCM coming from blurays, maybe the bandwidth is higher or the sample rate is different. Anyway, if you are able to extract a sample it will help. Also it may be interesting if you can confirm that you also have no sound using SPDIF output of your motherboard and not HDMI of your graphic card.

[yesgrey]

OK, I'll remove it next time I change the dialog.
haruhiko,
next time you'll change the dialog you could also correct some little details... here is a pic with those little details marked with red:
9406
Two "chroma" words were not substituted by CbCr, some spaces that were not removed between the '(' and ')', and in the last there are two spaces and it would look better just one, to be like the other text labels.

Forgive my pickiness...;)

[ikarad]

Ok I reproduce the problem : it is working but the jitter causes problem. I remember I disabled jitter correction for MLP because it was causing problems. I will digg this around.

Concerning LPCM, I have no problem playing LPCM 2.0 but you mentioned LPCM coming from blurays, maybe the bandwidth is higher or the sample rate is different. Anyway, if you are able to extract a sample it will help. Also it may be interesting if you can confirm that you also have no sound using SPDIF output of your motherboard and not HDMI of your graphic card.

for the sample : This sample have three soundtracks: one mlp and two lpcm 2.1.
http://www.zshare.net/info.html?54307328-f4cf1e029ba268fd6fc1e3907e3ab1dc

a second example with lpcm 2.1 and lpcm 6.1 soudntrack
http://www.zshare.net/info.html?55241905-3d52058746470a1fa90c6eed8b81c6ea


For spidf, I'm sorry but I can't try because my speakers only offers analogic output and not digital output. I d'ont use HDMI from my grphic card.
I use vga connector from my graphic card (I have CRT monitor) and for sound I use analogic connector from my soundcard (xfi titanium)

[v0lt]

I found a bug in DirectShow Huffyuv-decoder in ffdshow-mt rev2644.
I coded my video by Huffyuv v2.1.1 (YUY2). I get blue color instead of red in MPC.
In ffdshow beta6 bug is not watching.

Effect like http://forum.doom9.org/showthread.php?p=1229050#post1229050

[ACrowley]

One Question :

Is ffdshow _MT already /merged integrated in "standard" ffdshow tryouts ? No it isnt correct ?

I mean MT Build was faster for example on 1080p Bluray H264 1,85:1 with internal Subtitle Decoder enabled. ffdshow non MT was stuttering a bit and goes out of sync when the Subtitle Decoder was enabeld too

[clsid]

No, it is still a separate branch.

[Jeremy Duncan]

If you don't resize/scale the convert yv12 to rgb32, standard contrast.

Does this mean if I resize the picture in ffdshow, the conversion is being applied to a non-resized resolution?

Should it not be if I make the picture 1080p through resizing, the rgb conversion be applied to 1080p rather than 720x480?

[haruhiko_yamagata]

I would like to use Boost C++ Libraries (http://www.boost.org/) to make the new color space converters multithreaded and still keeping it portable.

Patch (http://ffdshow-tryout.sourceforge.net/samples/multithreading_of_ffdshow_converters.patch)

Thanks to threadpool (http://threadpool.sourceforge.net/), multithreading is realized by very simple and clean code.
Because ffdshow color space converter is C++ template code, multithreading of it should be done in the way of C++. Boost and threadpool helps much.

By the way, should we add Boost to our svn? It's 41.8MB, almost as big as ffdshow (67.5MB). If we add it, it will over 100MB. If we do not, new developers will suffer a bit. Version compatibility may be a issue.
Boost installer is available from here (http://www.boostpro.com/products/free).

On Core2 Quad, it is 3.2x faster, it is faster with "High quality YV12->RGB conversion" checked than unchecked (probably on Core2 Duo too). Of course my purpose is to make that option checked by default on modern CPUs (SSSE3 + core > 1).

[ACrowley]

No, it is still a separate branch.

ok, is MT significant faster in multithreading ? As i say, non MT stutters/async a bit on some 16:0 Full Frame Bluray with Subtitles enabled. MT not.

[_xxl]

By the way, should we add Boost to our svn? It's 41.8MB, almost as big as ffdshow (67.5MB). If we add it, it will over 100MB. If we do not, new developers will suffer a bit. Version compatibility may be a issue.
Yes, please add it.

[Leak]

Yes, please add it.
Isn't that what SVN externals (http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html) are for, though?

(Unless there's a need to make ffdshow-related changes to the Boost source code, that is...)

np: Fennesz - Perfume For Winter (Black Sea)

[haruhiko_yamagata]

Isn't that what SVN externals (http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html) are for, though?

(Unless there's a need to make ffdshow-related changes to the Boost source code, that is...)

np: Fennesz - Perfume For Winter (Black Sea)
Boost FAQ (http://www.boost.org/users/faq.html)How can the Boost libraries be used successfully for important projects?
Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the boost repository.

[_xxl]

I would like to use Boost C++ Libraries to make the new color space converters multithreaded and still keeping it portable.
Thanks to threadpool, multithreading is realized by very simple and clean code.
Because ffdshow color space converter is C++ template code, multithreading of it should be done in the way of C++. Boost and threadpool helps much.

Bin:
http://www.dump.ro/fisiere/ffdshow-rev2664-20090208-xxl-zip/90216/Cp8OZN7cpRsuXSk5

[Leak]

Boost FAQ (http://www.boost.org/users/faq.html)
SVN externals docs (http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html)
You should seriously consider using explicit revision numbers in all of your externals definitions. Doing so means that you get to decide when to pull down a different snapshot of external information, and exactly which snapshot to pull. Besides avoiding the surprise of getting changes to third-party repositories that you might not have any control over, using explicit revision numbers also means that as you backdate your working copy to a previous revision, your externals definitions will also revert to the way they looked in that previous revision, which in turn means that the external working copies will be updated to match the way they looked back when your repository was at that previous revision. For software projects, this could be the difference between a successful and a failed build of an older snapshot of your complex codebase.
Just add the revision for any (stable?) release of Boost to the external and update that revision when you think it's ready...

np: Joy Division - The Only Mistake (Still)

[haruhiko_yamagata]

Bin:
http://www.dump.ro/fisiere/ffdshow-rev2664-20090208-xxl-zip/90216/Cp8OZN7cpRsuXSk5
Thank you.

Guys who have Core2 Duo or Pentium D, could you tell me if it is faster with "High quality ..." checked than unchecked?

[haruhiko_yamagata]

SVN externals docs (http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html)

Just add the revision for any (stable?) release of Boost to the external and update that revision when you think it's ready...

np: Joy Division - The Only Mistake (Still)
Oh, I should have read it carefully.
Then it should work.

[clsid]

Or alternatively, just put a zip/rar/7z archive on the sourceforge website with the correct Boost libs that ffdshow needs. Then anyone can just download it once, instead of several times (once for each active branch). Put a text file in SVN with instructions on where to download it.

Speaking of branches. Do we want to keep the old inactive branches? Imo we could delete them.

Haruhiko, are you planning to write converters for all colorspaces? Does that mean we can eventually get rid of imgconvert and part of libswscale?

[clsid]

ok, is MT significant faster in multithreading ? As i say, non MT stutters/async a bit on some 16:0 Full Frame Bluray with Subtitles enabled. MT not.
The whole idea of the experimental multi-threading (= MT) branch is to have better decoding performance due to MT. It is still a work in progress. There are bugs. So use at own risk.

[_xxl]

I hope that soon MT and trunk will merge. haruhiko_yamagata is working to add MT to ffdshow's converters, maybe some other filters.

[tetsuo55]

I would like to use Boost C++ Libraries (http://www.boost.org/) to make the new color space converters multithreaded and still keeping it portable.

Patch (http://ffdshow-tryout.sourceforge.net/samples/multithreading_of_ffdshow_converters.patch)

Thanks to threadpool (http://threadpool.sourceforge.net/), multithreading is realized by very simple and clean code.
Because ffdshow color space converter is C++ template code, multithreading of it should be done in the way of C++. Boost and threadpool helps much.

By the way, should we add Boost to our svn? It's 41.8MB, almost as big as ffdshow (67.5MB). If we add it, it will over 100MB. If we do not, new developers will suffer a bit. Version compatibility may be a issue.
Boost installer is available from here (http://www.boostpro.com/products/free).

On Core2 Quad, it is 3.2x faster, it is faster with "High quality YV12->RGB conversion" checked than unchecked (probably on Core2 Duo too). Of course my purpose is to make that option checked by default on modern CPUs (SSSE3 + core > 1).


Cool!!

Some functions could be even faster than that if you use Libco. A long time ago we ran all kind's of tests comparing boost-thread with libco and is some cases it is up to 300x faster

you can find it here:http://byuu.cinnamonpirate.com/programming/

Released under PD but the author would like to recieve the changes so he can updated the PD archive.

[haruhiko_yamagata]

Maybe it's time to consider having two libavcodec in the trunk. Maintaining two branches is hard.
I give up updated libswscale.

[haruhiko_yamagata]

Cool!!

Some functions could be even faster than that if you use Libco. A long time ago we ran all kind's of tests comparing boost-thread with libco and is some cases it is up to 300x faster

you can find it here:http://byuu.cinnamonpirate.com/programming/

Released under PD but the author would like to recieve the changes so he can updated the PD archive.
I choose Boost because its thread library is very likely to be the next standard of C++ language.
I think overhead of thread is negligible in this case because each task is big enough.

[haruhiko_yamagata]

Or alternatively, just put a zip/rar/7z archive on the sourceforge website with the correct Boost libs that ffdshow needs. Then anyone can just download it once, instead of several times (once for each active branch). Put a text file in SVN with instructions on where to download it.Checking out takes a bit of time, but the advantage of version management outweighs IMO.
Inconveniently, threadpool is on CVS.

Speaking of branches. Do we want to keep the old inactive branches? Imo we could delete them.
What's the point of deleting? I hardly check out all.

Haruhiko, are you planning to write converters for all colorspaces? Does that mean we can eventually get rid of imgconvert and part of libswscale?
No, I don't have plan to write RGB->YCbCr conversion.

[clsid]

Maybe it's time to consider having two libavcodec in the trunk. Maintaining two branches is hard.
I give up updated libswscale. That would be a good idea, provided that the only differences are in libavcodec. Is trunk ffdshow.ax currently capable of working together with ffdshow-mt libavcodec.dll?
What's the point of deleting? I hardly check out all.I don't check them out either, but others might (accidentally) do. Is there any point in keeping them? If nobody is using them, we might as well clean them up.

[_xxl]

Is trunk ffdshow.ax currently capable of working together with ffdshow-mt libavcodec.dll?
No, there are changes in ffdshow.ax.
I don't check them out either, but others might (accidentally) do. Is there any point in keeping them? If nobody is using them, we might as well clean them up.
Delete them, not used anymore.

[Leak]

I don't check them out either, but others might (accidentally) do. Is there any point in keeping them? If nobody is using them, we might as well clean them up.
You can't really delete them anyway unless you dump/filter/load the SVN repository, as an SVN delete just hides the files you deleted - they'll still always be there in the earlier revisions.

But if you mean to prevent people who check out the whole repository instead of the trunk or a branch from wasting bandwidth - why not?

np: Joy Division - Dead Souls (Unknown Pleasures Extras)

[yesgrey]

Guys who have Core2 Duo or Pentium D, could you tell me if it is faster with "High quality ..." checked than unchecked?
I have, but the link above doesn't work, so no ffdshow version that I could test...

Edit: I have downloaded it. Will test and post results.

[@Tron@]

Hello all!

Long wanted to learn how you can update ffdshow??? I have ffdshow version 2624 and want to upgrade to 2665 (the latter at the moment ffdshow-tryout)

How can I update it????

[iron2000]

Having problem with all videos having Vorbis sound.
The sound comes out stuttering and theres this crackling sound also.
Both Tremor and libavcodec have the problem.
The MPC-HC filter has it too.

All other sound formats play fine.

Noticed this on 2653 and 2661.

Ok, I found the cause.
Under MPC-HC's options for the "DirectShow Audio" dropdown, the entry of type "DirectSound: ..." need to be selected.

[rack04]

Hello all!

Long wanted to learn how you can update ffdshow??? I have ffdshow version 2624 and want to upgrade to 2665 (the latter at the moment ffdshow-tryout)

How can I update it????

Latest build that I've seen is 2661.

[iSunrise]

Thank you.

Guys who have Core2 Duo or Pentium D, could you tell me if it is faster with "High quality ..." checked than unchecked?
I´d love to, but what exactly do I have to install? xxl´s build and Boost (you mentioned it) 1.37?

Cause without Boost, all my current players (e.x. ZoomPlayer) crash instantly when using that build. Before installing I had clsid´s build rev2649 icl10 (and all builds from him before it) working without problems. After installing clsid´s latest build again, everything is back to normal. I´m on Vista x64 with a Core i7 (all cores/MT enabled).

[clsid]

No, there are changes in ffdshow.axMaybe Haruhiko can solve that issue. Shouldn't be too difficult I think.

Then we could create an ffmpeg-mt directory in trunk for the MT version of libavcodec. That would mean we only need to keep that second copy of libavcodec updated, no more need for a whole separate branch.

I could even add an option in the installer to choose which version of libavcodec to use.

[_xxl]

Then we could create an ffmpeg-mt directory in trunk for the MT version of libavcodec. That would mean we only need to keep that second copy of libavcodec updated, no more need for a whole separate branch.

I could even add an option in the installer to choose which version of libavcodec to use.

I should start merging all updates from mt to trunk.

[_xxl]

Is anybody experiencing ffdshow crashes if mplayer temporal noise reducer is enabled. 2653 trunk and 2644 mt are fine, but 2664 is not.