Media Player Classic Home Cinema (MPC-HC) - DXVA!

[tetsuo55]

I'm using MPC-HC's default settings (see my signature) including internal splitter and (which is what CLSID was refering not the splitter:))

Since it seems it's only me ...:mad: let's forget about it

I fixed my post, i wil run some tests with your sample later

EDIT:

Using ffdshow as the video/audio decoder
Internal mkv splitter enabled
Internal audio switcher enabled

No matter how often i switch i always only hear 1 track playing

Maybe you have a .ini file or registry setting that is doing something wierd.

Please delete any .ini files in the mplayerc directory and run the delete registry file, you can find it on the wiki troubleshooting page

[gngn]

I confirm the crashes, i cannot get a minidump(file is 0kb)

the same happens to any encode from the subbing-group StrikeSubs. minidumpfile is also empty. in their case i belive it's because of the value used for the ChapterUID's, they use 0 ,1 , 2 ...

sample of a encode (http://www.mediafire.com/download.php?um2nzdfyetl) from StrikeS
extracted chapters file (http://www.mediafire.com/download.php?hle2twjl1d1) , if you mux this with any mkv file, MPC-HC will crash

[tetsuo55]

It looks like MKV's with chapters are crashing the internal matroska splitter.

does anyone have a mkv with chapters that does not crash?

I also confirmed the reclock audio switcher bug is not a bug.

[tetsuo55]

@Everyone,

Thanks to a lot of testing by Mark and me i have been able to find the cause of a lot of strange splitter related problems.

It's all in the configuration settings.

With these settings almost all reported problems are unreproducable:

*Enable internal subtitle renderer by checking "auto load subtitles"
*Enable internal audio switcher by checking "auto load audio files" and checking "enable built in audio switcher"
*Select the desired video renderer in the output page
*Select the desired audio renderer in the output page
*Remove any renderers from the external renderer page
*Check the built in container splitter of the file you want to play on the internal filter page

With these settings i have been unable to reproduce any of the reported bugs(so far, still working through the list) except:

-Internal MKV splitter crashes when chapters are embedded(however haali works fine)
-MadVR does not show subtitles with internal subtitle renderer(however using vobsub through the external filter page works fine)
-Internal MT2S splitter autoselects "subtitle stream 1" when changing audio track(i have not tested haali because its terrible for m2ts)

--------

It is important to keep in mind, that selecting a renderer in the "external filters" page will often block other internal filters and/or renderers.(this is not a bug)

[allak]

It looks like MKV's with chapters are crashing the internal matroska splitter.

does anyone have a mkv with chapters that does not crash?

I am at work atm and unable to test the latest mpc-hc, but I did not have any problems lately with MKVs with chapters.

I'm used to skip to the next or previous one with PageUp and PageDown and mpc does not crash.

I use only mpc-hc, no haali splitter or ffdshow.

[allak]

-MadVR does not show subtitles with internal subtitle renderer(however using vobsub through the external filter page works fine)


I think that this is not a mpc-hc bug.

Madshi has stated the he does still have to implement the subpicture subpin for his renderer. It is on his todo list.

[Mercury_22]

@Everyone,

Thanks to a lot of testing by Mark and me i have been able to find the cause of a lot of strange splitter related problems.

It's all in the configuration settings.

With these settings almost all reported problems are unreproducable:

*Enable internal subtitle renderer by checking "auto load subtitles"
*Enable internal audio switcher by checking "auto load audio files" and checking "enable built in audio switcher"
*Select the desired video renderer in the output page
*Select the desired audio renderer in the output page
*Remove any renderers from the external renderer page
*Check the built in container splitter of the file you want to play on the internal filter page

With these settings i have been unable to reproduce any of the reported bugs(so far, still working through the list) except:

-Internal MKV splitter crashes when chapters are embedded(however haali works fine)
-MadVR does not show subtitles with internal subtitle renderer(however using vobsub through the external filter page works fine)
-Internal MT2S splitter autoselects "subtitle stream 1" when changing audio track(i have not tested haali because its terrible for m2ts)

--------

It is important to keep in mind, that selecting a renderer in the "external filters" page will often block other internal filters and/or renderers.(this is not a bug)

I've "follow" your settings (and also reset all settings aka= clean / blank my ini file) and I'm still unable to get video (just audio) on some mkv files using internal splitter although with Haali's I have both video & audio

Can anyone confirm this ? or it's just me, again ?

Sample http://www.megaupload.com/?d=X4FA5TX3

[alexins]

Media Player Classic HomeCinema (x86/x64), svn 1130 (http://www.xvidvideo.ru/content/view/775/1/)

Supported languages: BY, CN, CZ, DE, EN, ES, FR, HU, IT, KR, PL, RU, SK, TR, UA

Changes log (http://www.xvidvideo.ru/content/view/7/17/)

(1129-1130)
Fixed : broken FLAC-splitter (bug #2797333);
Updated to latest libFlac.

[allak]

Can anyone confirm this ? or it's just me, again ?

Sample http://www.megaupload.com/?d=X4FA5TX3

Confirmed for this sample.

I only get the audio, not the video. mpc-hc latest version, no haali, no ffdshow.

But if I extract the video track only with mkvextract I can play it fine ...

[Mercury_22]

Confirmed for this sample.

I only get the audio, not the video. mpc-hc latest version, no haali, no ffdshow.

But if I extract the video track only with mkvextract I can play it fine ...

:thanks: for testing I was going nuts...:)

[gngn]

I am at work atm and unable to test the latest mpc-hc, but I did not have any problems lately with MKVs with chapters.

I'm used to skip to the next or previous one with PageUp and PageDown and mpc does not crash.

I use only mpc-hc, no haali splitter or ffdshow.

yes, the problem is not with all embedded chapters, but only with some that have something different that will cause MPC-HC to crash.
almost all anime-encodes have embedded chapters, all the ones i have play fine with the internal mkv splitter, only the StrikeS encodes have got "some" problem, and it seems to be the same that makemkv generates, the valuues given to ChapterUID

later edit: its probably not related to the ChapterUID, but something else

[pdanpdan]

None of my mkv files crash with internal splitter. All h264 + mutiple AAC audio + multiple vobsub/srt subtitles + chapters (mkvmerge muxed).
The only problem I have with the internal mkv splitter is that it does not respect the prefered flag on audio/subtitle track.

[ikarad]

I want to thank all the developers for the many bug-fixes over the past few weeks.

These fixes have fixed bugs as old as 2007!
I have closed many bugs on the bug-tracker as fixed (and some as out of date)

@Everyone,
Thank you for having a look at the bug's from batches 1 and 2, the information posted has helped fix some of them and close many of them.
Please take a look at batch 3 and see if you can confirm any of the 6 bugs(please also update the bug if you where unable to reproduce)

https://sourceforge.net/tracker/?func=browse&group_id=170561&atid=854651&status=1&artgroup=898924

for those intersted, most of the subtitle and renderer(including DXVA) bugs should be fixed with build 1112 or higher, please confirm :)
Subtitles: https://sourceforge.net/tracker/?func=browse&group_id=170561&atid=854651&status=1&category=1165521
Renderer: https://sourceforge.net/tracker/?func=browse&group_id=170561&atid=854651&status=1&category=1165522
DXVA: https://sourceforge.net/tracker/?func=browse&group_id=170561&atid=854651&status=1&category=1165515

This problem isn't corrected with mpc-hc 1130
http://sourceforge.net/tracker/?func=detail&aid=2449648&group_id=170561&atid=854651

[tetsuo55]

I've "follow" your settings (and also reset all settings aka= clean / blank my ini file) and I'm still unable to get video (just audio) on some mkv files using internal splitter although with Haali's I have both video & audio

Can anyone confirm this ? or it's just me, again ?

Sample http://www.megaupload.com/?d=X4FA5TX3Confirmed by me too, on my slow PC MPC even crashes.yes, the problem is not with all embedded chapters, but only with some that have something different that will cause MPC-HC to crash.
almost all anime-encodes have embedded chapters, all the ones i have play fine with the internal mkv splitter, only the StrikeS encodes have got "some" problem, and it seems to be the same that makemkv generates, the valuues given to ChapterUIDSo it's not chapters per-se but the just chapters in a certain formatNone of my mkv files crash with internal splitter. All h264 + mutiple AAC audio + multiple vobsub/srt subtitles + chapters (mkvmerge muxed).
The only problem I have with the internal mkv splitter is that it does not respect the prefered flag on audio/subtitle track.I don't know if the internal splitters ever respect those, that would be a feature request i thinkThis problem isn't corrected with mpc-hc 1130
http://sourceforge.net/tracker/?func=detail&aid=2449648&group_id=170561&atid=854651I don't think this bug will get fixed. It is caused by the "DVD Navigator"
there are a lot of different versions of the "DVD Navigator" spread over the different windows versions

The problem is caused by the way the "DVD navigator" reports the where in the stream we are, this information is inaccurate at best and a random guess at worst.

Beliyaal did say that he would try to find a workaround for the problem but that it would be very difficult(probably impossiple with the current framework).
The advice for now is remux to MKV and the subtitle timing will be accurate.

[ikarad]

I don't think this bug will get fixed. It is caused by the "DVD Navigator"
there are a lot of different versions of the "DVD Navigator" spread over the different windows versions

The problem is caused by the way the "DVD navigator" reports the where in the stream we are, this information is inaccurate at best and a random guess at worst.

Beliyaal did say that he would try to find a workaround for the problem but that it would be very difficult(probably impossiple with the current framework).
The advice for now is remux to MKV and the subtitle timing will be accurate.

If it's not fixed (although, to fix the problem, a solution (without modify "dvd navigator") would be to add a delay (only under vista) just when opendvd and load subtitle are used in the same time (then just for dvd movies) because with all dvds that I have the delay is always the same (I calculate with directvobsub that delay is nearly 1600 ms and I think it's the same delay for all dvd movies in the world under vista)) , it wil be important to add an option like in ffdshow or directvobsub that allow to add a delay to display subtitle.

I don't know if this problem exists under Windows 7.

[tetsuo55]

If it's not fixed (although, to fix the problem, a solution (without modify "dvd navigator") would be to add a delay (only under vista) just when opendvd and load subtitle are used in the same time (then just for dvd movies) because with all dvds that I have the delay is always the same (I calculate with directvobsub that delay is nearly 1600 ms and I think it's the same delay for all dvd movies in the world under vista)) , it wil be important to add an option like in ffdshow or directvobsub that allow to add a delay to display subtitle.

I don't know if this problem exists under Windows 7.That would be a good solution if everyone using Vista actually has the same problem.

Windows 7 has no problems with this.

[allak]

:thanks: for testing I was going nuts...:)

Your sample does contain an mpeg2 video track.

Do you have other samples that aren't working but that uses some other video codec (xviv, h264, etc.) ?


BTW, i have some mpeg2 in mkv working (ripped from DVDs), but they do contain a CodecPrivate section.

Your sample does not have any CodecPrivate section.

[tetsuo55]

Your sample does contain an mpeg2 video track.

Do you have other samples that aren't working but that uses some other video codec (xviv, h264, etc.) ?


BTW, i have some mpeg2 in mkv working (ripped from DVDs), but they do contain a CodecPrivate section.

Your sample does not have any CodecPrivate section.If i understand the matroska specs correctly that would mean the file is technically incompatible and should not play.

Haali splitter should not work either, it probably has error resiliance or something

[Mercury_22]

Your sample does contain an mpeg2 video track.

Do you have other samples that aren't working but that uses some other video codec (xviv, h264, etc.) ?


BTW, i have some mpeg2 in mkv working (ripped from DVDs), but they do contain a CodecPrivate section.

Your sample does not have any CodecPrivate section.

Sorry but no cause I'm only using mkv to backup my DVDs so only mpeg2
I'm using mkvtoolnix (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#windows) so maybe this Removed the workaround to find tags written by Matroska Shell Extension, this caused excessive file scanning when opening files created by recent MKVToolnix from Haali's latest "official" Changelog it's relevant :confused:

[allak]

I agree with tetsuo55; from the doc about the supported codecs in Matroska at Haali site:

V_MPEG2
ISO/IEC 13818-2
MPEG-2 sequence header extracted from elementary stream, the stream itself does not contain any sequence/gopheaders anymore
Subtype MPEG2_VIDEO
Format MPEG2Video
CodecPrivate is copied to the format block starting at dwSequence header member of MPEG2VIDEOINFO

So I think the muxing of a mpeg2 video file in a mkv container should fill the CodecPrivate section.

Demuxing and remuxing it with mkvtoolnix does not help.

[tetsuo55]

Maybe it's best to start with a bug report/support request here:
http://forum.doom9.org/showthread.php?p=1291790

[allak]

I have remuxed Mercury_22 sample from mkv to mkv with the eac3to tool by Madshi, that uses the Haali muxer, and now it playes correctly on mpc-hc.


So:

- mkvtoolnix sometimes does not create the codecPrivate section, at least for mpeg2 tracks

- the mpc matroska splitter is not able to handle them

- the haali splitter has some kind of workaround and it is fine

[tetsuo55]

I have remuxed Mercury_22 sample from mkv to mkv with the eac3to tool by Madshi, that uses the Haali muxer, and now it playes correctly on mpc-hc.


So:

- mkvtoolnix sometimes does not create the codecPrivate section, at least for mpeg2 tracks

- the mpc matroska splitter is not able to handle them

- the haali splitter has some kind of workaround and it is fine

Does it have the CodecPrivate after eac3to remux?

[allak]

Does it have the CodecPrivate after eac3to remux?

yes it does

[Mosu]

The CodecPrivate for a MPEG-2 video stream is the first (!) sequence header found in the stream. This sequence header is also repeated in the bitstream itself. Therefore it is NOT mandatory.

Additionally: the sequence headers may change in the bitstream, but in such cases the CodecPrivate would NOT be updated. Again, there's no practical gain whatsoever in requiring CodecPrivate to be present for playback, no matter what the specs page say. I'll change mkvmerge to always write the first sequence header into the CodecPrivate for MPEG2 video tracks. However, there is no technical reason for you to require it to be present.

This is only valid for MPEG-1/2 video tracks. Other codecs have other requirements.

[tetsuo55]

The CodecPrivate for a MPEG-2 video stream is the first (!) sequence header found in the stream. This sequence header is also repeated in the bitstream itself. Therefore it is NOT mandatory.

Additionally: the sequence headers may change in the bitstream, but in such cases the CodecPrivate would NOT be updated. Again, there's no practical gain whatsoever in requiring CodecPrivate to be present for playback, no matter what the specs page say. I'll change mkvmerge to always write the first sequence header into the CodecPrivate for MPEG2 video tracks. However, there is no technical reason for you to require it to be present.

This is only valid for MPEG-1/2 video tracks. Other codecs have other requirements.Thanks for the info and the proposed update, i will add this information to the splitter bug

[allak]

The CodecPrivate for a MPEG-2 video stream is the first (!) sequence header found in the stream. This sequence header is also repeated in the bitstream itself. Therefore it is NOT mandatory.

Mosu, you are certainly right; it is the internal Matroska splitter that works in the laziest possible way to extract mpeg2 tracks. I am now reading the source of the MPC splitter to see if there is some simple way for handling the case for a missing CodecPrivate.

But as you said it back in 2004:

"So for the sake of convenience I vote for the same as Cyrius: leave the stream as it is and ALSO put the first sequence header into the CodecPrivate."

http://lists.matroska.org/pipermail/matroska-devel/2004-November/002148.html

:)



Anyway, let me use this message to thank you for MKVToolnix, I am using it more and more and has always worked perfectly.

[Mosu]

After looking at my own source code I can say that this is definitely a newer bug -- the code for putting the sequence header into the CodecPrivate element is there, but that function is never called. This is new because it used to work a couple of versions ago; I don't know why I've changed it. Either accidentally or for some reason that I certainly cannot remember anymore.

So fixing it will be easy.

[bur]

Can you find the exact regression point?I couldn't pin it down exactly because xvidvideo.ru doesn't host every build.

But 1101 is still working for me while 1104 doesn't anymore, so the problem was introduced somewhere between those builds. From the changelog it seems that one of the fixes in build 1103 might be the source of the problem, especially this one: Fixed: Reset device could lock up player in VMR9 renderer mode. (For example when moving between monitors)

I just checked and changing the renderer to anything else than VMR9 prevents the lock-up, so it seems the fix broke things on my computer...


Here's my original post:
I recently updated to build 1120 from an olde build, maybe around 1000 or earlier and since then mpc hc just shows an empty window after restarting from Hibernation. If I press the shortcut for play or click within the window, the audio can be heard, but no picture.

The same thing happens when I played a full screen game.

Software:
MPC HC build 1127
ffdshow 2968
XP sp3 (german)

Hardware:
nForce 430
8800 GT

[Steveo08]

i have a question for the latest update from 1133:

"DX allocator for madVR"


what does it mean?

[Casimir666]

i have a question for the latest update from 1133:

"DX allocator for madVR"

what does it mean?

This update was necessary for subtitle support between Mpc and madVR.

[Steveo08]

This update was necessary for subtitle support between Mpc and madVR.

ah, ok thank you casimir.

[tetsuo55]

Now with the new MKV-merge i am only able to reproduce 2,5 of all the remaining internal mkv splitter bugs.

-Internal MKV splitter should read mpeg2 streams without the need for an explicit decleration of the CodecPrivate value(which the latest svn build of mkvmerge now always writes).
-There is no video-track-switcher, multi video track files play all tracks simultaniously as a result.
-Internal MKV splitter crashes when files use a certain type of chapters.

Note everything works correctly with the haali splitter.

[bur]

tetsuo55, you asked for the build where the bug happened on my system, in case you didn't see it because it's on the previous page:

http://forum.doom9.org/showpost.php?p=1291867&postcount=8099

[tetsuo55]

tetsuo55, you asked for the build where the bug happened on my system, in case you didn't see it because it's on the previous page:

http://forum.doom9.org/showpost.php?p=1291867&postcount=8099Beliyaal will have to take a look at that, please add a bug to the tracker

[Leak]

This update was necessary for subtitle support between Mpc and madVR.
And, I take it, to at some point enable madVR to use MPC-HCs shaders?

[allak]

the same happens to any encode from the subbing-group StrikeSubs. minidumpfile is also empty. in their case i belive it's because of the value used for the ChapterUID's, they use 0 ,1 , 2 ...

extracted chapters file (http://www.mediafire.com/download.php?hle2twjl1d1) , if you mux this with any mkv file, MPC-HC will crash

The problem is related to having a ChapterUID with the value '0'.

If you take that chapter file, modify the line:

<ChapterUID>0</ChapterUID>

to

<ChapterUID>87673</ChapterUID>

or whatever other value, and then mux a mkv file with it, MPC-HC don't crash anymore.

[allak]

And using a value of 0 for ChapterUID should be illegal; from the specs:

http://matroska.org/technical/specs/chapters/index.html

the ChapterUID element must be a u-integer with range ">0".

[tetsuo55]

Nice find, so the value "0" is illegal.

Still it should not crash the internal splitter, might be very easy to work around.

[NanoBot]

Here is a report concerning the internal flac splitter when playing back raw flac files:

This splitter now connects and works fine together with the builtin flac decoder, but is still does not work correctly together with ffdshow as flac decoder. After loading a raw flac file, the playback immediatly goes into the "pause" state when I am trying to use ffdshow as flac decoder. I do not know if this fault is caused by ffdshow or if it is caused by the internal splitter.

I am using the latest ffdshow svn compile from clsid ( ffdshow_rev2975_20090528_clsid ) and version 1.2.1130 of MPC HC on WinXP Pro Sp3 32bit.

C.U. NanoBot

[allak]

Still it should not crash the internal splitter, might be very easy to work around.

Looking at the source, I'd say that the problem is with the function Segment::FindChapterAtom, in the file:

~/mpc-hc/src/filters/parser/matroskasplitter/MatroskaFile.cpp

It takes a ChapterUID as an argument, but the value '0' is treated as a special case, and the return value is a different kind of matroska node.

I'd say a quick and dirty solution would be to add a new input parameter to that function, to signal explicitly what kind of return value the caller wants.

The FindChapterAtom function is called only in two places, both of them in the MatroskaSplitter.cpp file, so this fix should not be too much intrusive.

Could you pass this information to one of the developers ?

[alexins]

Media Player Classic HomeCinema (x86/x64), svn 1137 (http://www.xvidvideo.ru/content/view/776/1/)

Supported languages: BY, CN, CZ, DE, EN, ES, FR, HU, IT, KR, PL, RU, SK, TR, UA

Changes log (http://www.xvidvideo.ru/content/view/7/17/)

(1133-1137)
Added : DX allocator for madVR; Fixed : Patch for temp file leak in CSubtitleSource (bug #2784378);
Fixed : German filter properties window problems (bug #2792096);
Fixed : changing audio stream select a subtitle in M2TS (bug #2792676);
Fixed: Mono HDMV LPCM;
Fixed: Imperceptibly faster Bicubic resizer.

[Beliyaal]

I have submitted a fix for the mono LPCM bug.

Also I have investigated Bicubic resizer performance. I have compared to the old Bicubic resizer, and it seems that it resulted in incorrect output. Because the old resizer uses 8 samples instead of the required 16 samples it is incorrect and almost twice as fast.

Old incorrect result (http://www.olofsson.info/mpchc/BicubicIncorrect.png)
New correct slow result (http://www.olofsson.info/mpchc/BicubicCorrect.png)

It looks like the old resizer was bicubic "only in the x direction". Right now I'm thinking that the old resizer was buggy and will not provide an option for enabling the old code, especially since a new option would require more translation.

Someone asked about PS 3.0 path for the resizers. The HLSL shaders are already complied against PS 3.0 if it's available on the graphics card. This doesn't result in better performance however.

During the coming week I will be working on refresh rate detection and I will also endeavor to explain all the VSync options to everyones satisfaction.

[ikarad]

I have submitted a fix for the mono LPCM bug.

Also I have investigated Bicubic resizer performance. I have compared to the old Bicubic resizer, and it seems that it resulted in incorrect output. Because the old resizer uses 8 samples instead of the required 16 samples it is incorrect and almost twice as fast.

Old incorrect result (http://www.olofsson.info/mpchc/BicubicIncorrect.png)
New correct slow result (http://www.olofsson.info/mpchc/BicubicCorrect.png)

It looks like the old resizer was bicubic "only in the x direction". Right now I'm thinking that the old resizer was buggy and will not provide an option for enabling the old code, especially since a new option would require more translation.

Someone asked about PS 3.0 path for the resizers. The HLSL shaders are already complied against PS 3.0 if it's available on the graphics card. This doesn't result in better performance however.

During the coming week I will be working on refresh rate detection and I will also endeavor to explain all the VSync options to everyones satisfaction.

Beliyaal,
Sorry to disturb you but have you the time to see the problem of subtitle display with separated subtitle described here appeared with 1117 ?
http://sourceforge.net/tracker/?func=detail&aid=2795839&group_id=170561&atid=854651

I notice another problem. Fraps is broken with mpc-Hc sine merge between mpc-Hc and beliyaal branch. Maybe DO you know how correct this bug?
http://sourceforge.net/tracker/?func=detail&aid=2795842&group_id=170561&atid=854651


And I don't know if you are the good person for this problem described here but if you are the time to watch this problem
http://sourceforge.net/tracker/?func=detail&aid=2449648&group_id=170561&atid=854651

About this problem I think about two solutions (I don't know if it's the best solution but maybe it's a good solution if it's a solution)
first:
a solution would be to add a delay (only under vista) just when opendvd and load subtitle are used in the same time (then just for dvd movies) because with all dvds that I have the delay is always the same (I calculate with directvobsub that delay is nearly 1600 ms and I think it's the same delay for all dvd movies in the world under vista))

second:
it wil be usefull to add an option like in ffdshow or directvobsub that allow to add a delay to display subtitle.

[bur]

Beliyaal will have to take a look at that, please add a bug to the trackerThanks, I did that.

https://sourceforge.net/tracker/?func=detail&aid=2799089&group_id=170561&atid=854651

[tetsuo55]

Looking at the source, I'd say that the problem is with the function Segment::FindChapterAtom, in the file:

~/mpc-hc/src/filters/parser/matroskasplitter/MatroskaFile.cpp

It takes a ChapterUID as an argument, but the value '0' is treated as a special case, and the return value is a different kind of matroska node.

I'd say a quick and dirty solution would be to add a new input parameter to that function, to signal explicitly what kind of return value the caller wants.

The FindChapterAtom function is called only in two places, both of them in the MatroskaSplitter.cpp file, so this fix should not be too much intrusive.

Could you pass this information to one of the developers ?Would you be able to supply a patch for that?

[tetsuo55]

I have submitted a fix for the mono LPCM bug.

Also I have investigated Bicubic resizer performance. I have compared to the old Bicubic resizer, and it seems that it resulted in incorrect output. Because the old resizer uses 8 samples instead of the required 16 samples it is incorrect and almost twice as fast.

Old incorrect result (http://www.olofsson.info/mpchc/BicubicIncorrect.png)
New correct slow result (http://www.olofsson.info/mpchc/BicubicCorrect.png)

It looks like the old resizer was bicubic "only in the x direction". Right now I'm thinking that the old resizer was buggy and will not provide an option for enabling the old code, especially since a new option would require more translation.

Someone asked about PS 3.0 path for the resizers. The HLSL shaders are already complied against PS 3.0 if it's available on the graphics card. This doesn't result in better performance however.

During the coming week I will be working on refresh rate detection and I will also endeavor to explain all the VSync options to everyones satisfaction.In that case i suggest leaving the bicubic resizer alone. People who now have problems with the bicubic resizer will have to use bilniear for now.

EDIT: removed my typo

[clsid]

Bilinear ;)

[Steveo08]

Bilinear ;)




and which one is the best for picture quality?

[allak]

Would you be able to supply a patch for that?

Well, yes, but there are some caveats ... :)

I've never programmed for Windows, and my knowledge of C++ is at best superficial. I've programmed a fair bit with C, but only under *nix, and that was many moons ago.

Moreover, I do not have Visual Studio, much less a complete setup to compile MPC-HC, so I've no way to test the correctness of my suggestion.


Anyway, if one of the developers want to try to apply it, here is a very quick and dirty workaround; it *should* just skip any chapters with a ChapterUID equal to 0:




[~/mpc-hc/src/filters/parser/matroskasplitter] > diff -u MatroskaSplitter.cpp.svn MatroskaSplitter.cpp.allak
--- MatroskaSplitter.cpp.svn 2009-05-31 23:54:06.945076900 +0200
+++ MatroskaSplitter.cpp.allak 2009-06-01 00:19:38.534678800 +0200
@@ -668,7 +668,10 @@
while(pos)
{
// ca == caroot->ChapterAtoms.GetNext(pos) ?
- if(ChapterAtom* ca = m_pFile->m_segment.FindChapterAtom(parent->ChapterAtoms.GetNext(pos)->ChapterUID))
+ UINT64 ChapUID = parent->ChapterAtoms.GetNext(pos)->ChapterUID;
+ if (ChapUID == 0) continue;
+
+ if(ChapterAtom* ca = m_pFile->m_segment.FindChapterAtom(ChapUID))
{
CStringW name, first;