ffdshow tryouts project: Discussion & Development

[mark0077]

w/ what player/renderer?
MPC HC and HR/EVR are not too DVD-friendly, mostly the m$ DVD Navigator is at fault I think :o
KMP lets you select other DVD navigators(nero/cyberlink/intervideo/nvidia), did you try that?
your last resort will be the keyboard arrows plus CTRL(or ALT, can't remember) to navigate the menus.

When using mpc-hc alone (using evr or evr-cp, I don't think the renderer is at fault), everything is perfect always. Using mpc-hc and any of the ffdshow mpeg2 decoders (including libmpeg2 which is what mpc-hc uses) its broken. This is why i assume its an ffdshow problem, not a navigator problem. I can still happily select any menu items so it doesn't stop me using most DVD's, just very ugly looking for the rest of the family ;) I have a small feeling that the uglyness in this case might be because this dvd menu (from "The World is Not Enough") like most of my DVD's are not marked as progressive (and everything on this DVD is completely progressive in origin) so I have deinterlacing completely disabled. Everywhere in my ffdshow options I have everything set to "Force Progressive" and I control deinterlacing myself by just enabling / disabling de-interlacing in ffdshow. So I have a feeling that whatever piece of code is drawing these little highlights, is assuming its drawing an interlaced highlight. I think this because you can see slight jumps in the highlights. So if this is the problem, maybe the fix could be to not let this piece of code just listen to the progressive flag, and take maybe an optional forced input, like "Force Progressive" which seems to be the solution to many of my problems surrounding bad dvd quality. This is really just a hunch though so I could be completely wrong. Below are two images comparing the different combinations of decoders. What you should gather from these is that ffdshow's decoders seem to be somehow the cause as mpc-hc looks perfect on its own.

http://img24.imageshack.us/img24/6749/comparisonty8.th.png (http://img24.imageshack.us/my.php?image=comparisonty8.png)
http://img511.imageshack.us/img511/4188/comparison2ux2.th.png (http://img511.imageshack.us/my.php?image=comparison2ux2.png)

My second issue with dvd menus and ffdshow, is only seen when using mpc-hc's internal decoder, and ffdshow as a filter doing whatever. In that situation, using a dvd menu that seems to be made up of one frame, not a video, then highlighting certain options completely freezes the image. This is a vast improvement over old ffdshow versions which just showed a black screen on these 1 frame menus (which was happily fixed due to my dvd quality post late last year), but something still causes these 1 frame menus to freeze up now when using mpc-hc mpeg2 decoder, along with ffdshow. Using ffdshows own mpeg2 decoders doesn't show the freeze so its an issue between the interface of mpc-hc and ffdshow I suspect. I don't think its a navigator problem again, something to do with the fact that this dvd menu is just one frame which was what caused the complete black frame in older versions.

I suppose my third and final issues with dvd menus, and again only when using ffdshow is if I have de-interlacing forced enabled (I use yadif, double frame rate, and de-interlace progressive frames enabled), as I do enable it sometimes when I know a certain DVD needs it. If the menus of that dvd were not designed to be de-interlaced, yes they look ugly sometimes with yadif but I still expect to get through the menu, hit play and the DVD begins and looks fine. The problem is, when forcing de-interlacing enabled (and forcing for frames marked as progressive also) 99% of the time the very first progressive image ffdshow meets will freeze. It will not progress onto the next image, or copyright warning or whatever should come next. The DVD that this happens on is again this "Queens Greatest Hits" dvd where there is a copyright warning, a DTS advertisement, both single frames. I very rarely get past the first warning as ffdshow will get stuck. My suspicion here is yadif or some internal ffdshow code is waiting on something, like a "field" or something that just isn't there when this single frame is actually progressive. Again this is just a hunch but this problem actually means many manual steps each time I want to play any of these disks. I end up enabling de-interlacing, starting the DVD, realizing, oh these progressive menus freeze when de-interlacing is forced in ffdshow, disable de-interlacing, apply settings, exit mpc, start dvd again, all works fine, then when I hit play within the dvd I can reenable de-interlacing.... Very weird but I suspect a fix would be easy ;) Again I see this problem mostly when dealing with single progressive frames. All stuff that probably wouldn't get caught during normal testing but something that will and does effect people actually being able to play DVDs or not.

[vio_man]

At xvidvideo.ru they wrote:

ffdshow-mt, beginning from revision 2677, was combined with the basic branch of ffdshow

So, this means that any ffdshow-tryouts build after 2677 will be using ffmpeg-mt?

[XhmikosR]

Yes, it is included, but by default libavcodec is used for h.264. You can set ffmpeg-mt as the default decoder for h.264 in codecs configuration.

[leeperry]

Again I see this problem mostly when dealing with single progressive frames. All stuff that probably wouldn't get caught during normal testing but something that will and does effect people actually being able to play DVDs or not.
oh, ok! well I've personally given up on DVD menus in HR a long time ago, so damn annoying to click...but nothing happening :mad:

if this could be fixed, that'd be pretty cool indeed :cool:

[Leak]

Maybe Leak knows how to fix that DVD menu issue.
Sorry, but I don't know any more about DVD subtitles (which the DVD menus are after all) than you do - but if I had to take a guess after looking at mark0077's image I'd say it's something to do with the fact that regular subtitles usually have black borders whereas menu highlights don't, and the ugly rendering seems to be caused by the highlight's chroma value overwriting the underlying image's chroma value instead of somehow being blended (at least at the edges).

I wonder if they'd look better if it was possible to add the subtitles after converting to RGB - at least when one converts to RGB in the end anyway...

np: The Qemists - SWAG Intro (Join The Q)

[mark0077]

Ooh interesting so I guess it can probably be boiled down to either ffdshow subtitles or the way the subtitles are merged with the video behind. Never knew the highlights were done with subtitles.

I guess in the case where I don't do mpeg2 decoding with ffdshow, the highlights / subtitles are handled with mpc's subtitle "engine" which seems to do the much better job?

[EpsilonX]

Yes, it is included, but by default libavcodec is used for h.264. You can set ffmpeg-mt as the default decoder for h.264 in codecs configuration.

What's the currrent "status" of ffmpeg-mt as H.264 decoder..?
Is it reliable enough to lets say replace libavcodec for daily use..?

[lych_necross]

each integer/float conversion is potentially very lossy...avoid them if you can.

Lossy isn't necessarily bad as long as its done properly. Also, if there is no perceivable difference between 16, 24, or 32 bit, simply choose the one that preforms the best/fastest.

[XhmikosR]

What's the currrent "status" of ffmpeg-mt as H.264 decoder..?
Is it reliable enough to lets say replace libavcodec for daily use..?
I'm not an expert on this, but ffmpeg-mt would probably have some bugs because it is experimental. So you better avoid using it for everyday use. Personally, I use ffmpeg-mt and haven't noticed anything wrong, but you know, use it at your own risk.
Besides, someone has to use it to report any bugs found and get them fixed.:p

[haruhiko_yamagata]

I suppose my third and final issues with dvd menus, and again only when using ffdshow is if I have de-interlacing forced enabled (I use yadif, double frame rate, and de-interlace progressive frames enabled), as I do enable it sometimes when I know a certain DVD needs it. If the menus of that dvd were not designed to be de-interlaced, yes they look ugly sometimes with yadif but I still expect to get through the menu, hit play and the DVD begins and looks fine. The problem is, when forcing de-interlacing enabled (and forcing for frames marked as progressive also) 99% of the time the very first progressive image ffdshow meets will freeze. It will not progress onto the next image, or copyright warning or whatever should come next. The DVD that this happens on is again this "Queens Greatest Hits" dvd where there is a copyright warning, a DTS advertisement, both single frames. I very rarely get past the first warning as ffdshow will get stuck. My suspicion here is yadif or some internal ffdshow code is waiting on something, like a "field" or something that just isn't there when this single frame is actually progressive. Again this is just a hunch but this problem actually means many manual steps each time I want to play any of these disks. I end up enabling de-interlacing, starting the DVD, realizing, oh these progressive menus freeze when de-interlacing is forced in ffdshow, disable de-interlacing, apply settings, exit mpc, start dvd again, all works fine, then when I hit play within the dvd I can reenable de-interlacing.... Very weird but I suspect a fix would be easy ;) Again I see this problem mostly when dealing with single progressive frames. All stuff that probably wouldn't get caught during normal testing but something that will and does effect people actually being able to play DVDs or not.
Does this happen if you decode MPEG-2 in ffdshow?
If you use other MPEG-2 decoder and decode raw video in ffdshow, it is expected.
yadif require previous, current and next frame to deinterlace. ffdshow passes through the first image of a segment, but if the second image of the segment has very long duration, ffdshow will wait for third frame without drawing the second frame.
If you decode MPEG-2 in ffdshow, ffdshow has more information about the stream, thus the long waiting is usually avoided.
I have no choice but to say "please decode MPEG-2 in ffdshow".

[leeperry]

Lossy isn't necessarily bad as long as its done properly. Also, if there is no perceivable difference between 16, 24, or 32 bit, simply choose the one that preforms the best/fastest.
well, if I decode mp3 in ffdshow I'm not sure whether it's decoded in 16 integer or 32 float....so I'm using Gabest's MP3 decoder in 32 float, then I process it in 32 float through the "Spectralive NXT" VST plugin in ffdshow, and output 32 float to my audio drivers.....at least there isn't any dodgy conversion happening.

ffdshow say "stereo PCM uncompressed" as input description, but I guess it "knows" that it's already 32 float :rolleyes:

my sound card is 24/96, so I've tried to output 24 integer + enable noise shaping to "heavy" in ffdshow, but I can't hear a difference.....so I prefer to let my audio drivers be the judge :D

[mark0077]

haruhiko_yamagata: I think your right. I can't reproduce the crash if I use ffdshows internal decoders. I still would definitely categorize this as a bug. It should be upto yadif / ffdshow to handle itself correctly and not crash... Some check should be put in place for the case where it doesn't have enough information from internal decoders.

[leeperry]

I can't reproduce the crash if I use ffdshows internal decoders.
so DVD menus work fine in HR/EVR if using ffdshow's MPEG2 decoder? I was using Gabest's, will give it a shot :cool:

[mark0077]

leeperry: no I have never been able to get menus working with HR. The three bugs I talk about in my post above are all related to ffdshow and can be fixed within it I am sure. The crash I see is, as haruhiko_yamagata says due to the way ffdshow with yadif works, and only seen in dvd menus where single frames are found. Because so many of my dvd's are badly marked as originating from progressive/interlaced sources I can say this yadif crash is something that will effect other users.

[haruhiko_yamagata]

It may be a bug, but workaround is impossible, as far as I can imagine.
By the way, does the highlight issue go away if you select libavcodec or libmpeg2 in ffdshow's MPEG-2 decoder configuration and check "DVD decoding" and just do not use it (decode YV12 instead)? If yes, it has been fixed at rev 2711.

[albain]

Hi all,

somewhere between revision 2686 (which is okay) and revision 2693 (which is not) I have many crashes with vista media center when loading videos. Last builds have this problem too (2715 included)

I have not made deep tests and I don't know if this is related to the video format or a general regression.
Videos are mkv 720p encoded in h264

I use Haali splitter and CoreAVC for decoding

I will try to narrow the analysis.

Crash occur on ICL or VS2008 builds, and in release mode only (not in debug, this is a memory violation error)

Regards

[clsid]

Perhaps your problem is related to this change:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2691

[albain]

Perhaps your problem is related to this change:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2691

Actually, no, the problem comes from this revision : 2688 & 2689
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2689
It concerns FFDShow converters cleanup

Haruhiko, could you have a look on this ?

Thanks

[mark0077]

It may be a bug, but workaround is impossible, as far as I can imagine.
By the way, does the highlight issue go away if you select libavcodec or libmpeg2 in ffdshow's MPEG-2 decoder configuration and check "DVD decoding" and just do not use it (decode YV12 instead)? If yes, it has been fixed at rev 2711.

I guess the real solution to the crash is to begin improving interlaced/progressive frame detection. ;)

For the highlighting issue (using version 2715), the problem ONLY happens when using ffdshows's mpeg2 decoders. Using the decoder in mpc-hc the highlights are 100% perfect. Its an ffdshow issue. I have "DVD decoding" enabled, and have tried outputting in yv12 but this doesn't change the resulting image with ffdshows decoders, still the highlights look completely wrong.

[lych_necross]

well, if I decode mp3 in ffdshow I'm not sure whether it's decoded in 16 integer or 32 float....so I'm using Gabest's MP3 decoder in 32 float, then I process it in 32 float through the "Spectralive NXT" VST plugin in ffdshow, and output 32 float to my audio drivers.....at least there isn't any dodgy conversion happening.

ffdshow say "stereo PCM uncompressed" as input description, but I guess it "knows" that it's already 32 float :rolleyes:

my sound card is 24/96, so I've tried to output 24 integer + enable noise shaping to "heavy" in ffdshow, but I can't hear a difference.....so I prefer to let my audio drivers be the judge :D
In my experience, noise shaping is usually only helpful when converting to 16bits from either 24 or 32. MP3s are usually ripped from 16 bit sources, so decoding it in 32 bits is usually results in padding. I believe this was already mentioned, but the kmixer in Windows resamples to 16bit 48khz (as do most soundcard drivers). The only way to avoid this is to use kernel streaming, ASIO, or WASAPI.

[Snowknight26]

You wouldn't want to resample it. It doesn't matter what bitdepth the source was for a lossy format. The lossy transcode needs all the bits it can 'reconstruct' the source as accurately as possible.

[Leak]

It may be a bug, but workaround is impossible, as far as I can imagine.
Ummm... that problem was the reason I put some custom code into libmpeg2 to signal a sequence end, which is what is set on single-frame menu images.

In that case, just feed yadif the last frame however many times you need to for it to produce output, or just skip yadif entirely and return the picture un-deinterlaced - I don't think there's many interlaced static menus, and even then I'd rather take an ugly image over a hang...

[haruhiko_yamagata]

Ummm... that problem was the reason I put some custom code into libmpeg2 to signal a sequence end, which is what is set on single-frame menu images.

In that case, just feed yadif the last frame however many times you need to for it to produce output, or just skip yadif entirely and return the picture un-deinterlaced - I don't think there's many interlaced static menus, and even then I'd rather take an ugly image over a hang...hmm...
IDvdInfo2::GetCurrentDomain may help.

[mark0077]

Ummm... that problem was the reason I put some custom code into libmpeg2 to signal a sequence end, which is what is set on single-frame menu images.

In that case, just feed yadif the last frame however many times you need to for it to produce output, or just skip yadif entirely and return the picture un-deinterlaced - I don't think there's many interlaced static menus, and even then I'd rather take an ugly image over a hang...

My thoughts exactly. I rather see garbled image than a crash at any stage. From your description of the problem I suppose when ffdshow knows a certain frame / selection of frames could cause yadif to blow up, then it could be skipped or just sent some duplicates to keep yadif happy and prevent any freezing.

[Leak]

hmm...
IDvdInfo2::GetCurrentDomain may help.
Maybe, but I think I tried that when I worked on the AviSynth plugin and it wasn't too helpful.

Also, it won't help with extras stuff like self-running image galleries (like the ones on my Fullmetal Alchemist DVDs) that have a lot of static images with several seconds long pauses in between - but those work fine using the sequence flags in the AviSynth filter; you just need to special-case frames that have the SEQUENCE_END flag set and somehow pass them through immediately.

[haruhiko_yamagata]

Maybe, but I think I tried that when I worked on the AviSynth plugin and it wasn't too helpful.

Also, it won't help with extras stuff like self-running image galleries (like the ones on my Fullmetal Alchemist DVDs) that have a lot of static images with several seconds long pauses in between - but those work fine using the sequence flags in the AviSynth filter; you just need to special-case frames that have the SEQUENCE_END flag set and somehow pass them through immediately.
yadif in ffdshow use the SEQUENCE_START/SEQUENCE_END flags and works if MPEG-2 is decoded in ffdshow.
I'm talking about the cases MPEG-2 is decoded in the upper stream and ffdshow is decoding raw video.

[mark0077]

Maybe two of my problems with crashing are related then. The second time I get crashes when using ffdshow, is again with single frame menu's but when using a non ffdshow mpeg2 decoder (yadif enabled or disabled doesn't effect this). Trying to highlight any menu options in these single frame menus freezes up. I can still click menu options but I see no visual highlighting or indication I am selecting different options. Its like no more frames are drawn. The freeze doesn't happen when ffdshow is not used, or when I use ffdshows internal decoders. So I am sure a fix for one might also fix the other :D:D:D

[leeperry]

I worked on the AviSynth plugin
do you have any idea why is it impossible to have the avisynth.dll anywhere else than in /windows/system32/ ?
I'd like to put it on my ramdisk to lower the media opening time, but then it won't work anymore :(
In my experience, noise shaping is usually only helpful when converting to 16bits from either 24 or 32. MP3s are usually ripped from 16 bit sources, so decoding it in 32 bits is usually results in padding. I believe this was already mentioned, but the kmixer in Windows resamples to 16bit 48khz (as do most soundcard drivers). The only way to avoid this is to use kernel streaming, ASIO, or WASAPI.
kado gave a link in the previous pages where it's pretty clear that mp3 being lossy, you wanna decode it in the highest resolution to avoid roundings....that's what I've been doing for a long while. plus I don't use KMixer ;)

[iron2000]

It works for me. Please make sure you have installed DScaler plugins on installation of ffdshow. Also make sure you have working installation of DScaler.

I don't mean using the DScaler deinterlacing filters in ffdshow.
I mean using ffdshow as a filter in DScaler, to postprocess the picture in DScaler.

Was able to do it in some version of ffdshow way back.

[Leak]

yadif in ffdshow use the SEQUENCE_START/SEQUENCE_END flags and works if MPEG-2 is decoded in ffdshow.
I'm talking about the cases MPEG-2 is decoded in the upper stream and ffdshow is decoding raw video.
Oh, okay... but why on earth would anyone do that? :confused:

I guess it would be possible to simply keep re-processing the last image if no new image has been coming in for a second or so, but I dare not say how hard that would be to implement...

[mark0077]

Oh, okay... but why on earth would anyone do that? :confused:

I guess it would be possible to simply keep re-processing the last image if no new image has been coming in for a second or so, but I dare not say how hard that would be to implement...

I need to decode mpeg2 in the upper stream, aka mpc-hc because of the problems ffdshow has with menu highlighting not looking correct. ;)

[Leak]

I need to decode mpeg2 in the upper stream, aka mpc-hc because of the problems ffdshow has with menu highlighting not looking correct. ;)
Maybe it's just me, and maybe I'm repeating myself, but I'd take slightly blocky menu highlights over stuck menus every day of the week...

Not to mention that I watch DVDs for the content and not for the menus... :p

[haruhiko_yamagata]

Actually, no, the problem comes from this revision : 2688 & 2689
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2689
It concerns FFDShow converters cleanup

Haruhiko, could you have a look on this ?

Thanks
It's not my fault. You have an e-mail from me.

[mark0077]

Maybe it's just me, and maybe I'm repeating myself, but I'd take slightly blocky menu highlights over stuck menus every day of the week...

Not to mention that I watch DVDs for the content and not for the menus... :p

I guess I can just hope someone figures out whats going wrong with the highlighting using ffdshow then :D That really makes using ffdshow decoders pretty much perfect when it comes to DVD decoding. Just smart progressive/interlace detection is all thats needed then, detection that can rival some of these expensive hardware DVD players ;)

I just thought the second type of freeze I get which is not related to yadif, just single menu freezes alone would be something that could be fixed. Earlier builds just showed a black screen, its improved quite alot but with decoding happening earlier in the graph... ffdshow still gets a bit confused and stuck :)

[haruhiko_yamagata]

Hi all,

Just started playing with ffdshow resize in build 2699.

I happened to be playing a 1920 x 1080 .ts file, but when I set resize to "Specify Horizontal Size" and begin typing into the "New Size" width, media player classic+ffdshow crash. Have to restart them both.

Reproducible time after time. Maybe someone could take a look? Means I can't reliably use the resize to test different settings without a crash.
I can't reproduce. What did you type?

[mark0077]

I was actually going to type 720.

I think the crash happened after the 7. I will try and reproduce again and see what settings may stop it happening if any.

[haruhiko_yamagata]

As for the positioning of DVD menu, if I uncheck "Set pixel aspect ratio in output media type" the problem is fixed. The AR is still correct. Tested with overlay mixer, VMR7, VMR9.

[mark0077]

Wow, great find :D Thanks for that I will try it when I get home. :D

[clsid]

Does that mean that the dvd menu positioning issue is caused by ffdshow sending bad interlacing info to the next filter in the graph? But since ffdshow gets the same bad info from the MPEG-2 decoder, it is not really ffdshow's fault?

When ffdshow is only doing the processing, it is not able to (use the sequence flags to) detect whether it currently is processing a 1 frame menu, right?

[albain]

It's not my fault. You have an e-mail from me.

Yes this is my fault (this was not an accusation by the way, I suspected this was an old bug because it would not crash under debug mode. Those bugs are the most difficult do trace)
Thanks I got your email. How did you reproduce without debug mode ?

Following your guidelines, I think this is fixed by now : revision 2716

[haruhiko_yamagata]

Yes this is my fault (this was not an accusation by the way, I suspected this was an old bug because it would not crash under debug mode. Those bugs are the most difficult do trace)
Thanks I got your email. How did you reproduce without debug mode ?

Following your guidelines, I think this is fixed by now : revision 2716
I could reproduce the crash with debug build, however, if CoreAVC is used in the filter graph, we can't use debugger.
I used Debugview for Windows (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx) and many DPRINTF. It's the classic.
Thank you for the fix.

[haruhiko_yamagata]

Does that mean that the dvd menu positioning issue is caused by ffdshow sending bad interlacing info to the next filter in the graph? But since ffdshow gets the same bad info from the MPEG-2 decoder, it is not really ffdshow's fault?The aspect ratio rather than interlacing flag. The position is calculated in the application (MPC-HC in this case), ffdshow has to send some info to video renderer or somewhere so the the application can calculate correctly.

When ffdshow is only doing the processing, it is not able to (use the sequence flags to) detect whether it currently is processing a 1 frame menu, right?It's impossible as the sequence flags are obtained by ffdshow custom code in libmpeg2 and libavcodec.

[madshi]

It's impossible as the sequence flags are obtained by ffdshow custom code in libmpeg2 and libavcodec.
I think you could go down (you would say "up" :)) the filter chain by browsing through the connected pins to find the MPEG2 output pin and then ask its connection media type and grab the codec private data from there, which usually contains the sequence headers. Isn't that what you need? A bit ugly, but it might work...

[mark0077]

As for the positioning of DVD menu, if I uncheck "Set pixel aspect ratio in output media type" the problem is fixed. The AR is still correct. Tested with overlay mixer, VMR7, VMR9.

Damn, unfortunately setting this option to any of its 3 available options has no change on my menu highlights. I have also tried playing with settings like the mpc-hc "Keep aspect ratio" setting, and the ffdshow resizer on and off, ... the highlights seem a few pixels off, or slightly garbled in some cases.

Tis a pity. In my opinion, if ffdshow relies on internal data like you say, flags set by the internal decoders, and gains an advantage by doing this, I think every effort should be made to try and get that information from raw video also. I will leave the implementation upto you guys but it just sounds like the right thing to do... ie not favour internal / external decoders if the information can be gained using other methods. (although in this case, decoding WITH ffdshow seems to be causing the ugly highlights on 1 frame and moving menus, decoding WITHOUT ffdshow causes the freeze/crash in 1 frame menus, and decoding WITHOUT ffdshow in one frame screens with de-interlacing incorrectly enabled causes freezes / crashes).

[tetsuo55]

Shouldn't the relevant information be passed on between each step in the filter graph?

Information like:
-AR(in all its flavours)
-Framerate
-Interlace flag

Maybe even more information is usefull, if any value is no longer true(in the case of deinterlacing) the part of the chain that caused the change in the value should update the information to the new status and pass that along.

[haruhiko_yamagata]

I think you could go down (you would say "up" :)) the filter chain by browsing through the connected pins to find the MPEG2 output pin and then ask its connection media type and grab the codec private data from there, which usually contains the sequence headers. Isn't that what you need? A bit ugly, but it might work...
SEQUENCE_START/SEQUENCE_END flags indicate that the frame is a start/end of a sequence. It is not possible to use media types, because media types are not attached to all frames.

[lych_necross]

kado gave a link in the previous pages where it's pretty clear that mp3 being lossy, you wanna decode it in the highest resolution to avoid roundings....that's what I've been doing for a long while. plus I don't use KMixer ;)
I re-read that link and I see what your saying. I normally don't use gabset for mp3 playback (I usually use foobar) :)

[haruhiko_yamagata]

Damn, unfortunately setting this option to any of its 3 available options has no change on my menu highlights. I have also tried playing with settings like the mpc-hc "Keep aspect ratio" setting, and the ffdshow resizer on and off, ... the highlights seem a few pixels off, or slightly garbled in some cases.
A few pixels? Then it's quite usable.
With some special DVD (wrong encoding IMO), the menu is off by 10% of the screen height. I found I can avoid this by using DVD navigator's aspect ratio instead of decoded aspect ratio.

[mark0077]

A few pixels? Then it's quite usable.
With some special DVD (wrong encoding IMO), the menu is off by 10% of the screen height. I found I can avoid this by using DVD navigator's aspect ratio instead of decoded aspect ratio.

Oh definitely usable but consistently wrong for every DVD I have... Its not just a few pixels off really you can see in the screen shots where the perfect rectangle that mpc-hc draws isn't drawn nearly as good when using ffdshow decoders. The corners get blurred and the lines are skewed and a few pixels off. MPC-HC seems to get it perfect each time with every DVD I have... Not a big issue, at least better than the crashing when not using the non ffdshow decoders so for the moment I will put up with ugly highlights until someone would like to take a look into the code ;)

Actually I do notice, on this Queen DVD menu where you can select the audio output, PCM Stereo, DTS, or DD I think it is. The three options go from top to bottom so

---------- top of screen -------------



Option 1 - Highlight 1 should be here
< Position of option 1 highlight (ie. skewed toward centre)


Option 2 < Position of option 2highlight (90% perfect)


< Position of option 3 highlight (ie. skewed toware centre)
Option 3 - Highlight 3 should be here


---------- bottom of screen -------------

When I look at where the rectangles around these options are, I notice they are all skewed / offset towards the centre of the image (horizontally). Those further from the center get offset more so the further from the horizontal centre, the worse any menus will look in this combination.

So i think you are right in saying the aspect ratio flag has something to do with this problem. Its like the highlights are being displayed on an overlayed image but in slightly different aspect ratio window to the underlying image, like as if the overlay window isn't being given the right AR. I don't know how subtitles / highlights work but this sounds like a reasonable explanation. :D Do you see any easy solution.... what part of the ffdshow AR code might be at fault? I assume an AR is also supposed to be output with these subtitles / highlights, or at least taken into account when rendering them. Seems as if it is not in fact being taken into account correctly. Not a big deal but still would be nice to see it fixed now that we have an idea what it could be.

EDIT: Unfortunately build 2718 doesn't fix the above for me. Thought it was going to looking at the change list :P I thought fiddling with ffdshow resize settings, and turning it on or off, or editing the ar output option might have an effect but not for me. All highlights are stretched towards the centre of the screen by a few pixels, as I said, the further the highlight should be from the centre, the more it seems to get offset.

[haruhiko_yamagata]

I don't mean using the DScaler deinterlacing filters in ffdshow.
I mean using ffdshow as a filter in DScaler, to postprocess the picture in DScaler.

Was able to do it in some version of ffdshow way back.
OK, I'll take a look later.