ffdshow tryouts project: Discussion & Development

[tetsuo55]

Hmm. Looking at your links, I only see one old benchmark (http://forum.doom9.org/showthread.php?p=998532#post998532) where MSVC is faster and two (this (http://forum.doom9.org/showthread.php?p=1363969#post1363969) and that (http://forum.doom9.org/showthread.php?p=1217662#post1217662)) where it's slower?
The two you linked to seem to use ICL for compiling it seems, so its not a true comparison to clean msvc.

Also to give msvc a fighting chance against gcc it will have to be compiled with: /O2 /GL /GS- /GA /arch:SSE2 /NXCOMPAT /DYNAMICBASE

(replace arch with whatver the lowest sse version is you want to support, equal to gcc)
I don't recommend /GS- for release builds, use /GS instead.

[nm]

The two you linked to seem to use ICL for compiling it seems, so its not a true comparison to clean msvc.
Ok, but could you point out those results where MSVC is faster?

[tetsuo55]

Ok, but could you point out those results where MSVC is faster?Only in the old benchmark you mentioned.

These older benchmarks that are missing a lot of information all seem to prove that no matter what compiler/settings you use the end result will be slower or faster within a margin of -2% to +2%.

We need good benchmarks, where all the variables are named.
*Exact compiler versions
*Switches used/disabled
*builds provided for verification on other systems
*tested on both amd/intel
*Each test run 5 times, with the average used as the final result
*etc...

Also nobody tested PGO which can result in anything from 0 to 40% more performance.

It should not matter at all for most of ffmpeg though as its mostly hand optimised with assembly.

[clsid]

For compiling libavcodec MSVC has no fighting chance whatsoever, no matter which settings you use. That is a pure and simple fact. I will repeat the reason again: all optimized code is excluded from the build. Compiler optimized C code simply can't win from the hand-written assembly code. It can't even come close.

And instead of spending lots of time to squeeze of % performance gain out of the other parts of the code, I think the effort should instead be spend on fixing bugs. More and more people are using DXVA. Also since computing power is doubling roughly every 18 months, performance is becoming a non-issue.

The only other CPU cycle hungry part in MPC is the subtitle renderer. That should be optimized by rewriting the code. For example to avoid animation overhead for static subtitles.

[tetsuo55]

For compiling libavcodec MSVC has no fighting chance whatsoever, no matter which settings you use. That is a pure and simple fact. I will repeat the reason again: all optimized code is excluded from the build. Compiler optimized C code simply can't win from the hand-written assembly code. It can't even come close.the same is true for gcc no?

[nm]

the same is true for gcc no?

No, the inline assembly in FFmpeg/libavcodec is written for GCC and compilers that support that particular syntax. MSVC doesn't.

[tetsuo55]

if thats true then i can understand the difference, however we include a assembly compiler ourselves, why do we do that then?

We have done some quick tests, hope to get a clear scientific test out tonight.
Results so far (libmpeg2)

MSVC 2008 SP1, dfps: 294.3
GCC 4.5.0, dfps: 209.5

Very strange results, we are investigating to make sure it isn't a mistake in our test environment. (both tests where run 8 times)
We are going to optimise the gcc switches further, but the current settings should already beat msvc... (and msvc uses sub-optimal switches which we intend to optimise too)

[_xxl]

Hmm. Looking at your links, I only see one old benchmark (http://forum.doom9.org/showthread.php?p=998532#post998532) where MSVC is faster and two (this (http://forum.doom9.org/showthread.php?p=1363969#post1363969) and that (http://forum.doom9.org/showthread.php?p=1217662#post1217662)) where it's slower?
That was back in 2007 when I compiled ffdshow.ax using GCC, now is not possible. Please stop this nonsense, ffdshow and all except ffmpeg(mt), mplayer, x264 should be compiled with msvc and the rest by GCC. What is so hard to understand? Forcing SSE will require SSE capable CPU's so older CPU's will fail. For speed's less then 10% is pointless to force SSE when compiling.
FFMPEG, MPLAYER and X264 will never compile with MSVC.
Ask FFMPEG, MPLAYER and X264 developers and you get your answer.
libmpeg2 has custom code that isn't in original version from mplayer to support MSVC and win64.
Original version should only be compiled by GCC, but ffdshow version only by MSVC.
ffdshow has a lot of custom code inside most libs.

[dann23]

Forcing SSE will require SSE capable CPU's so older CPU's will fail. For speed's less then 10% is pointless to force SSE when compiling.

less than 10% could make the difference for the cpu to stay in P3 state not P0 and even Pentium III has SSE. It just stupid to maintain support for such old processors.

[clsid]

The difference is <1% for libavcodec so we don't need to engage in discussion whether SSE is useful or not. All the performance critical parts are already hand-optimized to use MMXext/SSE/SSE2/SSSE3/etc whenever possible.

Libmpeg2 is compiled with MSVC by default in ffdshow because that is the fastest. In case of libmpeg2 the code contains inline assembly with a different syntax, one that MSVC does understand. In this case GCC has less optimized code to work with, hence the worse performance.

[XhmikosR]

I managed to build libmpeg2 with ICL 11 (O3, nothing else changed). And it is quite faster than MSVC (nothing changed in project settings) on my machine. The video I tested was a 1280x720 mpg @59.940fps @ 16Mbps, remuxed to avi with mplayer with the following cmd:

mencoder input.mpg -o output.avi -ovc copy -oac copy -of avi -ffourcc mpg2

MSVC 2008 SP1
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 291.7, dfps: 291.3
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 292.9, dfps: 292.3
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 291.8, dfps: 291.3
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 292.9, dfps: 292.3
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 290.1, dfps: 289.7
User: 29s, kernel: 0s, total: 29s, real: 29s, fps: 292.1, dfps: 291.6

ICL 11
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 315.4, dfps: 314.9
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 316.2, dfps: 315.4
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 315.8, dfps: 315.2
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 315.1, dfps: 314.7
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 315.8, dfps: 315.3
User: 27s, kernel: 0s, total: 27s, real: 27s, fps: 315.1, dfps: 314.2

Here (http://www.mediafire.com/?sharekey=3f33c77c2cf9ce25ab1eab3e9fa335ca33cdc61d280511ab) are the compiled dlls for anyone that may be interested.

[albain]

Beware of benchmarks results when you compare the benefits of SSE with each other :

1/ we have very few intrinsics methods defined for SSE3 and SSE4. We could add more
2/ even though we don't use them. Very few classes are templatized with more than MMX level. A few have both MMX and SSE2, and I have not seen anywhere SSE3 and 4

Simply because this is the double amount of work when you want to templatize a new series of instructions to do the same task

@Tal, I am surprised about what you said on DXVA vs software decoding results. I have a radeon 5750 and I find the picture blurrier in DXVA mode.
The only thing that could explain (apart maybe gpu drivers settings) is the fact that I use RGB32 mode against NV12 in DXVA mode

@All : I refounded the subtitles section which became a mess, please tell what you think me about it. Also I reverted the modification that affected Hebrew subtitles.

[clsid]

The subtitle format options are now suboptions of the Embedded option. What about non-embedded subtitle files? It may be useful to have an option for disabling that as well.
Maybe have seven checkboxes:
1) Embedded 2) External
3) Bluray (enabled if embedded is checked)
4) VobSub (enabled if embedded OR external is checked)
5) SSA (enabled if embedded OR external is checked)
6) Closed Captions (enabled if embedded is checked)
5) Text (enabled if embedded OR external is checked) (currently not yet present)

I would also suggest renaming "Text subtitles with SSA tags support". People now may think that it is another kind of subtitles format and check it. Something like "Process SSA tags in text subtitles" would be better, but maybe anyone else has can come up with a better description for it.

[ikarad]

@All : I refounded the subtitles section which became a mess, please tell what you think me about it. Also I reverted the modification that affected Hebrew subtitles.

@Albain
1) Have you see this problem with blu-ray subs and xp?
@Albain,
there is a bug with blu-ray sub support with xp sp3 (under vista it works very well).

The subs are divide in two parts and are not completed
http://nsa14.casimages.com/img/2010/04/20/mini_100420050119368677.jpg (http://www.casimages.com/img.php?i=100420050119368677.jpg)


I try with YUY2 or RGB 32 and there is the same problem.
I try with all versions of ffdshow (3350 to 3368) where it works under vista and there is the same problem udner xp sp3.

I notice some crashs but I think that crashs come from this problem .

same example that I give you before
example
part 1
http://www.zshare.net/info.html?7219...12ca4e70f4959e
part2
http://www.zshare.net/info.html?7222...cb0c45e37239c1
part3
http://www.zshare.net/info.html?7222...fa215e89fcfdf2

part 4
http://www.zshare.net/info.html?7287...1fac7d6620cda5

part 5
http://www.zshare.net/info.html?7289...835142beff854c
part 6
http://www.zshare.net/info.html?7290...3fe6974fb1237c

partie 7
http://www.zshare.net/info.html?7215...a94c0fc61987f5

2) Bug with 3371 :I try with 3371 and blu-ray subs are not displayed under xp and vista (rgb32 and yuy2)


3) I try the new versio nand maybe it would be interesting to explain each functions in subtitle section because there are many options and I don't know if I must use or not.

For example I don't know what means these options (in black circle)
http://nsa15.casimages.com/img/2010/04/23/mini_100423080302246904.jpg (http://www.casimages.com/img.php?i=100423080302246904.jpg)
http://nsa15.casimages.com/img/2010/04/23/mini_100423080409854437.jpg (http://www.casimages.com/img.php?i=100423080409854437.jpg)
http://nsa15.casimages.com/img/2010/04/23/mini_100423080725534897.jpg (http://www.casimages.com/img.php?i=100423080725534897.jpg)
http://nsa14.casimages.com/img/2010/04/23/mini_100423080748835235.jpg (http://www.casimages.com/img.php?i=100423080748835235.jpg)

[STaRGaZeR]

I like the new options, and I like clsid suggestions too. Also I'd rename BluRay to Blu-ray. Nitpick, yes, but that's the format's correct name :p

@albain, I'm trying to fix an "issue" with SSA/ASS subtitles, but I don't have enough knowledge to do it properly. Currently ffdshow searches for "PlayResX" and "PlayResY", and if one is missing it'll use the video resolution to calculate the subtitles' coordinates. However there are many old scripts that only have "PlayResY", and MPC/VSFilter work with that only. Obviously people create the scripts with MPC/VSFilter in mind, so ffdshow puts the subs in "incorrect" places. I've determined (by testing, so I could be totally wrong) that if Y is set but X is not, MPC/VSFilter will assume a 4/3 aspect ratio and use Y=Y and X=Y*4/3. If Y is missing but X is present it's the opposite. I've made a patch that corrects this partially, but this is what I can't fix: with the patch, if X is set and Y is not, ffdshow now puts the subs where they belong, but at the incorrect font size. Can you help me with this?

Patch: http://www.mediafire.com/?ymgznzjzeu3

[albain]

@Ikarad : sorry I can't help you, I don't have XP.
Otherwise :
- Subtitles section : checkboxes are here to enable or not the support of the different subtitle formats listed here
- Font section : only applicable to text subtitles (srt/ssa)
- Bluray/DVD subtitles positioning : if no coordinates are set then use the horizontal and vertical placement in the placement section

@clsid : for now it is not possible to disable distinct external subtitle formats, so if the subtitles filter is enabled, then all the external subtitle formats which are supported are enabled
As you said : one option per subtitles format, and 2 options : embedded and external is the right way to go.

Otherwise this is right that vobsub (DVD subs) are supported in both embedded and external, as well as srt/ssa.
But not bluray (not yet), only embedded for now.

[ikarad]

@Ikarad : sorry I can't help you, I don't have XP.


:( never fix for xp I think. I hope one day anybody will fix this problem.

But I notice this problem with 3371, blu-ray subs are not displayed under vista.

[adam777]

@All : I refounded the subtitles section which became a mess, please tell what you think me about it. Also I reverted the modification that affected Hebrew subtitles.

Doesn't seem to work.
Hebrew subtitles still displayed wrong, with "Text subtitles with SSA tags support" on and off.
Nothing is selected - No bluray, DVD etc., simply trying to play simple .srt subtitles.
Rev. 3367 still the last to work under x64.

[rica]

What is very interesting to me, expectations of everybody are too much for a coder.
Any open source coder must have three PCs?

1) XP 32 on one disk, XP 64 on another disk.
2) Vista 32 on one disk, Vista 64 on another disk.
3) 7 32 on one disk, 7 64 on another disk.

And how?
6 OS, 6 HDDs and 3 PCs? (I never stated the sub-brunches btw.)
Any donations?

[lych_necross]

I think its time to consider phasing out support for XP (focus should be placed on newer versions of Windows). Users of XP should really consider upgrading to 7.

[Shankster]

I think its time to consider phasing out support for XP (focus should be placed on newer versions of Windows). Users of XP should really consider upgrading to 7.

And before XP users go apeshit, ponder this:
You are now angry because there is no attention towards xp, cause all focus is on vista/7.

Now flip the table and imagine how it would feel if you couldnt get problems on XP fixed because of Win98 users.

At some point you are gonna have to let go of that 10 year old OS.

[ikarad]

I think its time to consider phasing out support for XP (focus should be placed on newer versions of Windows). Users of XP should really consider upgrading to 7.
Why don't support old os ?
And I don't speak about win 95 or 98 but xp which is still a very used os.

Xp isn't win 95 or 98 and xp is more use than vista or seven.

Xp has beeen replaced by vista only since two years and for most users xp stay the main os. I don't think that we can consider xp like an old os.

After I understand that albain can't fix this problem because He doens't have xp

[lych_necross]

Why don't support old os ?
And I don't speak about win 95 or 98 but xp which is still a very used os.
At some point, a developer needs to stop supporting old OSes. If a program functions correctly under Win7 but not XP, it could be said that the problem is with XP. It takes a lot of time to develop workarounds for old OSes. Instead of spending time writing workarounds, I would prefer that same time be spend on developing new features. Besides, even Microsoft has discontinued support (http://www.microsoft.com/windows/support/endofsupport.mspx) for all versions of Windows up to XP SP1 (XP SP2's support will be discontinued on July 13th, 2010 (http://windowsteamblog.com/blogs/windowsvista/archive/2010/02/24/end-of-support-for-windows-2000-windows-xp-sp2-and-windows-vista-rtm.aspx)).

[sacharja]

They only care about working playback, which is what the pack provides.
Actually, no. #3370 is unusable in its current state. As several people mentioned now, it's crashing all the time while seeking fast (with a player that is capable of fast seeking, like ZoomPlayer). I'm a little bit afraid that such an essential thing is still not fixed after over a month.

[dann23]

At some point, a developer needs to stop supporting old OSes. If a program functions correctly under Win7 but not XP, it could be said that the problem is with XP. It takes a lot of time to develop workarounds for old OSes. Instead of spending time writing workarounds, I would prefer that same time be spend on developing new features. Besides, even Microsoft has discontinued support (http://www.microsoft.com/windows/support/endofsupport.mspx) for all versions of Windows up to XP SP1 (XP SP2's support will be discontinued on July 13th, 2010 (http://windowsteamblog.com/blogs/windowsvista/archive/2010/02/24/end-of-support-for-windows-2000-windows-xp-sp2-and-windows-vista-rtm.aspx)).

If so then drop support for old processor. :D

[madshi]

At some point, a developer needs to stop supporting old OSes.
"At some point"? True. But that description fits anything between now and eternity.

Look, there are probably many people out there who have a stable and well working XP HTPC. Why forcing them to upgrade to win7, if XP works great for them? They would have to buy a win7 upgrade, reinstall the OS and all the DirectShow filters and everything, search for a reasonably well working GPU driver, etc etc. They might even have to upgrade hardware. And after going through all that trouble - what would they gain? Nothing at all, if XP does all that they need. They would even risk replacing their stable and well working setup with a new setup with new problems. So IMHO it's *MUCH* too early to drop XP support. And I don't see the need to drop XP support, anyway.

Win9x was a whole different world. It wasn't even remotely similar to XP if you looked behind the facade. XP and win7 are very very similar inside.

[tetsuo55]

I don't see why ffdshow needs to drop/add support for anything.
Since its just a transform filter and post processing filter there is little benefit in supporting a specific platform.

Over at MPC-HC the story is different, as Windows7 offers a LOT of features that benefit playback.

[ikarad]

At some point, a developer needs to stop supporting old OSes. If a program functions correctly under Win7 but not XP, it could be said that the problem is with XP. It takes a lot of time to develop workarounds for old OSes. Instead of spending time writing workarounds, I would prefer that same time be spend on developing new features. Besides, even Microsoft has discontinued support (http://www.microsoft.com/windows/support/endofsupport.mspx) for all versions of Windows up to XP SP1 (XP SP2's support will be discontinued on July 13th, 2010 (http://windowsteamblog.com/blogs/windowsvista/archive/2010/02/24/end-of-support-for-windows-2000-windows-xp-sp2-and-windows-vista-rtm.aspx)).

sp3 is still supported for one year or more.
Why don't support an old os when It's the main os for the majority of users?

I prefer a stable version of ffdshow for each OS used that add features never completly fucntionnal.


As I said above, XP isn't an useless OS like win 98. It's the main OS for many users.

[albain]

We don't intend to drop xp support as its architecture is not that far from newer OS and is still spread a lot

I just hope that someone on xp not necessarily with developer skills but able to build ffdshow in debug mode will be able to narrow down that problem, at least just enough to have a lead

About Hebrew subtitles, I will look after that : do you have an idea why the subtitles are garbled ?
I wish we could drop the srt engine and use the substation alpha one which brings a lot of features

@Stargazer : I'll look into your patch and let you know

[Px]

What is very interesting to me, expectations of everybody are too much for a coder.
Any open source coder must have three PCs?

1) XP 32 on one disk, XP 64 on another disk.
2) Vista 32 on one disk, Vista 64 on another disk.
3) 7 32 on one disk, 7 64 on another disk.

And how?
6 OS, 6 HDDs and 3 PCs? (I never stated the sub-brunches btw.)
Any donations?
There is no need for 6 HDD and 3 PCs, in time when I was actively testing/benchmarking different things, I have 5 OS-es installed on signle 200GB HDD:
C - 30 GB, main XP x64
D - 10 GB, XP x32 for game benchmarking
E - 10 GB, XP x32 for video editing
F - 10 GB, XP x32 for other experiments
G - 10 GB, W2K Prof for video capturing (drivers for XP for my tuner was less stable, then for W2K)
H - 130 GB, main storage for games, documents and other stuff
Later I bought 2nd HDD, 320 GB, and install there Vista.
So I don't see any problems to install as many OS-es as needed on single PC even with 1 HDD

[albain]

The problem is not technical but the time to spend on this kind of problem.

Personally I don't have the time to work on this and I am not motivated as well to play the DJ with OS swapping.
I guess that clsid and Tal are in the same position.

As I said, we are very few coders, and help from contributors in this forum would be highly appreciated, as it has been the case to put in place HD audio bitstream, DXVA,...

Otherwise I have brought the changes to subtitles section with the new checkboxes:
http://img17.imageshack.us/img17/3060/ffdshowsubs.png (http://img17.imageshack.us/i/ffdshowsubs.png/)

My next moves : bluray subtitles files support, fix the subtitle scalers that don't work in RGB32.
Stargazer last patch too

[Sebastiii]

Always :) thx you :)
Seb.

[clsid]

An easy way to test different OSes is to run them in a virtual machine. For example VirtualBox.

[Midzuki]

About Hebrew subtitles, I will look after that : do you have an idea why the subtitles are garbled ?
I wish we could drop the srt engine and use the substation alpha one which brings a lot of features

Hebrew and Arabic text lines are written and read "RTL". For some reason, ffdshow is "RTL"ing word-by-word, and not line-by-line. BTW, MaestroSBT has the same (unsolved) issue.

[STaRGaZeR]

@Stargazer : I'll look into your patch and let you know

This is what I have so far. VSFilter and ffdshow at the same time.

1. Without the patch, PlayResX=unset, PlayResY=768. ffdshow is at the bottom right corner.

http://thumbnails10.imagebam.com/7785/e8b65e77843528.gif (http://www.imagebam.com/image/e8b65e77843528)

2. With the patch, PlayResX=unset, PlayResY=768. Good.

http://thumbnails3.imagebam.com/7785/92168977843529.gif (http://www.imagebam.com/image/92168977843529)

3. With the patch, PlayResX=1024, PlayResY=unset. Position matches VSFilter, but the font size is wrong this time. This is what I can't figure out.

http://thumbnails24.imagebam.com/7785/cc0e5477843532.gif (http://www.imagebam.com/image/cc0e5477843532)

4. With the patch, PlayResX=1024, PlayResY=768. This one, being identical to 2., confirms that VSFilter, and ffdshow with the patch, assume the 4/3 ratio if one of them is missing.

http://thumbnails24.imagebam.com/7785/00b04f77843535.gif (http://www.imagebam.com/image/00b04f77843535)

[amango]

In FFDShow I can force bob deinterlacing to the output. This is also a good way to double the framerate. This is quite handy if you use Mediaportal because the speed of the gui is bound to the frame rate of the video.

There is however no option for this in the DXVA decoder, could someone add this? :)

[adam777]

Well, the bad news is Hebrew subtitles are still no go in rev. 3373, however, I think I realized something that might prove useful.
It seems that when there are 2 lines under the same subtitle index, that later (bottom) line is displayed to the right, while the earlier (top) line is displayed to the left.
It should be the other way around.

That is, if an index exist:
14
00:02:12,741 --> 00:02:14,657
3 2 1
6 5 4
it's displayed as (remember Hebrew is read right to left) - 3 2 1 6 5 4, while it should be displayed as 6 5 4 3 2 1

[tal.aloni]

In FFDShow I can force bob deinterlacing to the output. This is also a good way to double the framerate. This is quite handy if you use Mediaportal because the speed of the gui is bound to the frame rate of the video.

There is however no option for this in the DXVA decoder, could someone add this? :)

Not technically possible AFAIK.

[tal.aloni]

An easy way to test different OSes is to run them in a virtual machine. For example VirtualBox.

actually, if you want to test DXVA and such, than iSCSI is your best friend. I'm booting xp or win7 using gPXE.

[Keiyakusha]

In FFDShow I can force bob deinterlacing to the output. This is also a good way to double the framerate.
If you mean forcing bob on progressive footage, than I think you loosing half of the vertical resolution by doing that. Copying every frame once should be better and probably not slower. However no way to do that with DXVA...
And for interlaced content I think there should be some way to do bob with GPU, however don't know if it compatible with DXVA and I don't have interlaced content at all, so not sure.

[tal.aloni]

@Tal, I am surprised about what you said on DXVA vs software decoding results. I have a radeon 5750 and I find the picture blurrier in DXVA mode.
The only thing that could explain (apart maybe gpu drivers settings) is the fact that I use RGB32 mode against NV12 in DXVA mode

exactly,
by default, Radeon outputs YCrCb 4:4:4 over HDMI, which for 16-235 NV12 content (including DXVA), might result in wrong levels (depends on monitor settings).

when selecting RGB 4:4:4 as HDMI output colorspace, you can either let the radeon convert NV12 to RGB internally (with correct levels), or let ffdshow handle the colorspace conversion, which will result in higher cpu usage, and according to some, better quality.

in any case, the PQ benefits of not using DXVA are only the benefits of using ffdshow's (or other renderer) colorspace conversion, at least for the radeon.

Tal

[tal.aloni]

Well, the bad news is Hebrew subtitles are still no go in rev. 3373

Shalom Adam, I've just tested some hebrew srt subs with 3373,
EDIT: I see it now, when two lines are involved, the first line comes second.

Tal

[STaRGaZeR]

Found another "issue": all the ASS scripts I have are always blurred with ffdshow, while they're not with VSFilter. I've found these lines in TsubtitleText.cpp:

if (fontSettings.blur || (w->props.version >= TsubtitleParserSSA::ASS && lf.lfHeight > int(37 * gdi_font_scale))) // FIXME: messy. just trying to resemble vsfilter.
prefs.blur=true;

That if is always true here. I don't know what the author was trying to resemble in VSFilter, but I'd just enable blur if the setting is enabled in the Font section, like this:

if (fontSettings.blur)
prefs.blur=true;

BTW, what is "gdi_font_scale"? I don't understand this variable and it's used everywhere.

[madshi]

in any case, the PQ benefits of not using DXVA are only the benefits of using ffdshow's (or other renderer) colorspace conversion, at least for the radeon.
Don't forget chroma upsampling.

[XhmikosR]

@albain: I just tried r3374 and it crashes every time I try to use the subtitles. The video is a 1920x1080p WVC1 and the subtitles is a BD .sup file. If you cannot reproduce the crash let me know. I'll try to upload a sample.

Also, someone should update the ICL project files.

[fastplayer]

SRT subs don't load anymore. Even though there's a checkbox showing that the file is loaded, nothing is displayed. Checking that checkbox (in the subtitle context menu) actually enables subtitles.
SRT subtitles with 2 lines are displayed in one line. "Split long subtitle lines" has no effect.

[albain]

Found another "issue": all the ASS scripts I have are always blurred with ffdshow, while they're not with VSFilter. I've found these lines in TsubtitleText.cpp:

if (fontSettings.blur || (w->props.version >= TsubtitleParserSSA::ASS && lf.lfHeight > int(37 * gdi_font_scale))) // FIXME: messy. just trying to resemble vsfilter.
prefs.blur=true;

That if is always true here. I don't know what the author was trying to resemble in VSFilter, but I'd just enable blur if the setting is enabled in the Font section, like this:

if (fontSettings.blur)
prefs.blur=true;

BTW, what is "gdi_font_scale"? I don't understand this variable and it's used everywhere.

Indeed, this test should be removed. I guess this is Haruhiko's code.

Haruhiko tried a while ago to increase the resolution of the glyphs but that resulted into choppy playback. I think it would be good to digg into this to get better subtitles

I committed bluray subtitles files support by the way. I have not tested it a lot but it seems to work so far.
Unlike the other subtitles formats that load all the content of the file in memory (even vobsubs), I chose to have only 10 seconds ahead to reduce memory usage. As a result the subtitles file remains opened and read all the time but I don't think this is a problem

[XhmikosR]

OK, here (http://www.mediafire.com/?wikozzzxknz) is a sample and here (http://www.mediafire.com/?ojhvmnvtmqm) are the BD subtitles which cause the crash with r3374.

[Casshern]

DTS Spdif passthrough problems with m2ts files:

1) The DTS core does get picked up when playing the file from the beginning
2) I had MPC-HC set to remember last position, so it essentially seeked before playing -> this results in the core not being picked up
3) When seeking sound gets totally screwed, only multiple reseeking helps to get it back

Here is a small sample (which makes seeking hard, but try to play it NOT from the beginning to replicate)

http://www.mediafire.com/file/mztm2kmzu4u/testdtscore.m2ts

A workaround for this issue is to disable the "connect as pcm first" option under the output options. This may not work for all soundcards, but on my gear there seem to be no side effects as of yet. I hope this helps for others with this problem.

[fastplayer]

SRT subs don't load anymore. Even though there's a checkbox showing that the file is loaded, nothing is displayed. Checking that checkbox (in the subtitle context menu) actually enables subtitles.
SRT subtitles with 2 lines are displayed in one line. "Split long subtitle lines" has no effect.

Forgot to mention that hitting the "Reload" button in the subtitle filter options caused MPC to crash. This is fixed now in rev 3376. Subs still don't load automatically though.