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

[tetsuo55]

I make some test clips, 1920, ref_num=16 with bFrames=9 :

1920x1080 - freez after 3-5 second playback, but 1920x800 - play fine.

here sample 1920x800, that fime play with DXVA - http://aleksoid.tosei.ru/Samples/test_4.mkv

The conclusion - this is not the case, well, or not only that

The limits posted by marc99 are valid for 1920x1080 only, as soon as you lower the resolution the number of R or B frames can be increased

[marc99]

How check bFrames count in video ???

AVInaptic http://fsinapsi.altervista.org/
http://www.elecard.com/products/products-pc/professional/stream-analyzer/
http://www.elecard.com/products/products-pc/professional/streameye/

Hi marc99, everyone technical person i ask always says there is no limit for bframes?

How did you get these values?

From this list it appears like every 4 b frames count as 1 ref frame(while the specs say any value between 1 and 16 should only be 1 ref frame)

Testing, testing, testing....

Question is: How NVidia made it?

The limits posted by marc99 are valid for 1920x1080 only, as soon as you lower the resolution the number of R or B frames can be increased

Then why SD files doesn't work?

[tetsuo55]

AVInaptic http://fsinapsi.altervista.org/
http://www.elecard.com/products/products-pc/professional/stream-analyzer/
http://www.elecard.com/products/products-pc/professional/streameye/



Testing, testing, testing....

Question is: How NVidia made it?



Then why SD files doesn't work?

Interesting,

Well if you simply look at how it works:

Spec's limit R to 16 and B to 16
Spec's say if it fits in DPB we can decode it
Windows has added some limitations to further enforce(and sometimes lower) the spec's

B-Pyarmids changes the relation between R and B slighly, but some devices do not implement b-pyarmids correctly.

On paper a 1920x1080p R16,B16,B-pyramid encode should take 17 slots in DPB, as the 17th is not a ref frame the windows should not complain.

Clearly you're testing has shown, that at least for Nvidia, this is not the case, eventhough MPC-HC can force the decoder to use R16,B16,B-pyramid, the image will corrupt and/or crash the decoder.

The number of B frames might also be a problem on ATI/Intel/SIS hardware...

i wonder what would happen if we force fed an ATI card a 1920x1080 R=5 B=0 Pyramid=no

[ikarad]

I answer at your question

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

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

[Jong]

Correct me if I am wrong, but the signal will be converted to RGB in any case. If you output YCbCr444 from your gfx card, your TV will do the conversion. If you output in RGB from your gfx card, your gfx card will convert the nv12 to RGB.

My preference is still to output RGB from ffdshow, eliminating the need for the gfx card or tv to do any conversions. Experience has thought me not to trust either gfx card or tv for good conversions in all scenarios.I'm not sure it is that clear cut! As most if not all STBs output YCbCr and as YUV is typically a better colorspace to work in when manipulating video, I think some (maybe even many, possibly even most!) do all their video processing in YUV. So if you send RGB it may get converted by the TV to YUV and back! And TVs normally have nowhere near the horsepower to throw at these things as a modern PC.

I cannot say for sure, but I think my TV does a better job of processing a YCbCr input than an RGB one.

[vask]

All the builds newer than 1.2.1043 have major problems with evr custom renderer when using any filter that supports dxva. This is happening on the intel g45 chipset. The symptoms are stuttery video playback, video freezing while sound carries on. I suspect this started to appear after beliyaal features were added because the last publically available build to not excibit these problems is the 1.2.1043 svn.

[TinTime]

I'm not sure it is that clear cut! As most if not all STBs output YCbCr and as YUV is typically a better colorspace to work in when manipulating video, I think some (maybe even many, possibly even most!) do all their video processing in YUV. So if you send RGB it may get converted by the TV to YUV and back! And TVs normally have nowhere near the horsepower to throw at these things as a modern PC.

I cannot say for sure, but I think my TV does a better job of processing a YCbCr input than an RGB one.

Except...

If you output YCbCr from your pc I think it's just adding a final conversion before output. There will always be a conversion to RGB in a pc somewhere along the line regardless of the final output.

So if the TV does a conversion like you describe then you can choose between one of these conversion chains:

PC TV
YV12 -> RGB -> YCbCr ~~~~> RGB
YV12 -> RGB ~~~~> YCbCr -> RGB

But if it doesn't then you can choose between:

PC TV
YV12 -> RGB -> YCbCr ~~~~> RGB
YV12 -> RGB ~~~~> nothing

If the TV doesn't convert RGB then outputting RGB from the PC is a winner, from the point of view of minimising conversions.

[Steveo08]

so i am not sure what about to do.......how do i know what is better for my tv, rgb or YCbCr ?

any tests there?

[squid_80]

Which one looks better?

[leeperry]

so i am not sure what about to do.......how do i know what is better for my tv, rgb or YCbCr ?

any tests there?
plain RGB32 does, w/ whatever rgb3dlut() or mVR resampling the chroma in softcubic(1.0/0.0)...well from what I've seen anyway :)

I guess Leak's chroma upsampling PS script will output more or less the same stuff, if you output RGB32HQ from ffdshow

if your display accepts both RGB and YCbCr, it's a good that it will convert to RGB internally anyway...and your SD upscales might be borked and decoded in BT.709 :D

if it expects TV levels, don't enable any levels conversion in ffdshow of course.

[Pr3d]

http://img21.imageshack.us/img21/8508/captureive.png

Is possible to remove this message without install the SDK Redistributable?

[Steveo08]

@leeperry

i will try nv12 because i can't see a difference between rgb and nv12 and i don't now what my tv more like.



but i found a problem with the newer builds of mpc-hc, in the lower range of the picture there is a mirror line or a ghost line, i am not sure what is the correct word for that.

you can have a look what i mean:

http://img21.imageshack.us/img21/1475/snapshot20090425001007.png

it's not in all movies but a lot.

i don't changed my settings, i always use dxva with evr custom and some pixelshader and vista 32.

i tested the standard evr, too. but the problem is still there.
just vmr9 works fine.

[Keiyakusha]

Is possible to remove this message without install the SDK Redistributable?

As I understand, you need to Install DirectX9. Not SDK but End-User Runtime. Or maybe just put this DLL into MPC-HC folder.

Attention! To work correctly, the program needed to install a DIRECTX End-User Runtime to the version 9.26.1590 (http://www.microsoft.com/downloads/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&DisplayLang=en) (3/23/2009)

[marc99]

Aleksoid1978

Limit in Vista is 13 (not 16) in all resolution.

[Jong]

Except...

If you output YCbCr from your pc I think it's just adding a final conversion before output. There will always be a conversion to RGB in a pc somewhere along the line regardless of the final output.

So if the TV does a conversion like you describe then you can choose between one of these conversion chains:

PC TV
YV12 -> RGB -> YCbCr ~~~~> RGB
YV12 -> RGB ~~~~> YCbCr -> RGB

But if it doesn't then you can choose between:

PC TV
YV12 -> RGB -> YCbCr ~~~~> RGB
YV12 -> RGB ~~~~> nothing

If the TV doesn't convert RGB then outputting RGB from the PC is a winner, from the point of view of minimising conversions.Yeah I accept that. My point was though that with my TV I am pretty certain it processes YCbCr better than RGB and there is logic to it being optimised for that as all other non-PC sources are likely to be in YUV.

So I agree with the later post - you need to trust your own eyes - try both and pick which works.

[Aleksoid1978]

Aleksoid1978

Limit in Vista is 13 (not 16) in all resolution.

i test in Vista is 16 limit is fine DXVA work - 1280 and 1920.

[Mike5]

http://img21.imageshack.us/img21/8508/captureive.png

Is possible to remove this message without install the SDK Redistributable?

You must download the missing d3dx9 dll from the Internet and put it in C:\Windows\System32 (for the 32bit version).

[Mike5]

but i found a problem with the newer builds of mpc-hc, in the lower range of the picture there is a mirror line or a ghost line, i am not sure what is the correct word for that.

This problem is related to the decoder outputting 1088 vertical lines instead of 1080. I've never understood clearly when this occurs, but one solution is using the crop function of ffdshow to cut the 8 additional lines.

[leeperry]

@leeperry

i will try nv12 because i can't see a difference between rgb and nv12 and i don't now what my tv more like.
well some say nv12 can be greatly processed by some ATi cards....but going nv12 with a 720p movie that has an AR <1.78 will be decoded in BT601 on the ATi, as your graphic card drivers will convert to RGB32 anyway(it's mandatory, anything else will be converted afterwards...and even more lossy).

Also the chroma will most likely be blocky to hell, so at least use Leak's chroma PS script...which will blur it

[marc99]

i test in Vista is 16 limit is fine DXVA work - 1280 and 1920.

Not all files, limit is 13.

[Steveo08]

This problem is related to the decoder outputting 1088 vertical lines instead of 1080. I've never understood clearly when this occurs, but one solution is using the crop function of ffdshow to cut the 8 additional lines.



but what kind of solution should i do, if i don't use ffdshow, just dxva?
and i just look mostly 720p movies.

[leeperry]

but what kind of solution should i do, if i don't use ffdshow, just dxva?
enabling mixer mode in VMR9/EVR should fix it.

[Steveo08]

well some say nv12 can be greatly processed by some ATi cards....but going nv12 with a 720p movie that has an AR <1.78 will be decoded in BT601 on the ATi, as your graphic card drivers will convert to RGB32 anyway(it's mandatory, anything else will be converted afterwards...and even more lossy).

Also the chroma will most likely be blocky to hell, so at least use Leak's chroma PS script...which will blur it



well i don't have an ati card, i have a geforce 8600gt.

i tested it yesterday between rgb and nv12 but i don't see a difference and i would say the videos aren't blocky.

and what do you mean with leak's chroma PS?
in mpc the PS YV12 Chroma Upsampling?

[Steveo08]

enabling mixer mode in VMR9/EVR should fix it.


i am not sure if it is enabled or not, because ist grey and enabled, so i can't change it. so the problem still existed.

[vlada]

Hi,

I plan to get a Viliv S5 MID. It has an Intel Poulsbo chipset, which contains GMA 500 graphics card. The OS used is Windows XP. Is there any chance that DXVA support in this graphics card and OS will be implemented in MPC-HC?

[leeperry]

well i don't have an ati card, i have a geforce 8600gt.

i tested it yesterday between rgb and nv12 but i don't see a difference and i would say the videos aren't blocky.

and what do you mean with leak's chroma PS?
in mpc the PS YV12 Chroma Upsampling?
yep! but apparently the nvidia do a good job on YCbCr so you're safe....just make sure to output RGB over HDMI to avoid useless conversions. same for levels if your display is 16-235 only

[Mike5]

enabling mixer mode in VMR9/EVR should fix it.

It fixes the problem, but only for VMR9. In EVR the option is grayed, probably because it doesn't apply to this renderer.

I'd try to use the crop function of ffdshow, setting 8 in bottom. If this fixes we are sure that is a 1088 problem.

[deets]

a question about DXVA mode and de interlacing. So im playing back my 1080i TV football captures and using DXVA and EVR its nicely bobbing the output to 50fps. Is this being done via the nvidia graphics card or in software? maybe a stupid question i know :)

[Px]

Hi,

I plan to get a Viliv S5 MID. It has an Intel Poulsbo chipset, which contains GMA 500 graphics card. The OS used is Windows XP. Is there any chance that DXVA support in this graphics card and OS will be implemented in MPC-HC?
No, Intel hardware acceleration works only under Vista

[TinTime]

Yeah I accept that. My point was though that with my TV I am pretty certain it processes YCbCr better than RGB and there is logic to it being optimised for that as all other non-PC sources are likely to be in YUV.

So I agree with the later post - you need to trust your own eyes - try both and pick which works.

Games consoles will also output RGB, and traditionally, in analogue Europe, RGB is used instead of YUV.

You're dead right about just trying both and seeing which you prefer.

[rack04]

Is anyone having problems with EVR CP using the internal m2ts splitter?

Windows XP SP3
Nvidia 8800GT
MPC-HC svn 1065
EVR CP
Internal M2TS Splitter
ffdshow audio
ffdshow video

http://i11.photobucket.com/albums/a199/rack04/evrcpinternalm2ts.jpg

Windows XP SP3
Nvidia 8800GT
MPC-HC svn 1065
EVR CP
Haali
ffdshow audio
ffdshow video

http://i11.photobucket.com/albums/a199/rack04/evrcpexternalm2ts.jpg

Using the internal M2TS splitter with VMR9 works fine.

[tetsuo55]

I answer at your question

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

https://sourceforge.net/tracker/?func=detail&aid=2449648&group_id=170561&atid=854651Thanks for testing!

Is possible to remove this message without install the SDK Redistributable?
The required dll is included in the mpc-hc archive here: http://www.xvidvideo.ru/content/category/1/1/2/
It is always better to update directx.Aleksoid1978

Limit in Vista is 13 (not 16) in all resolution.
There is no such limit, but your testing has revealed that there is something wrong with either the nvidia decoder,x264, Coreavc or MPC-HC DXVA decoder.

The information you reported earlier reveals that at least nvidia is adding certain settings, like b-frames to the DPB.

[ikarad]

Thanks for testing!



have you an idea when these problems will be fixed?

[tetsuo55]

have you an idea when these problems will be fixed?

Sorry i don't.
I too suffer from this bug:
http://sourceforge.net/tracker/?func=detail&aid=2466321&group_id=170561&atid=854651

The problem(s) do not appear to be regressions, making it more difficult to fix them. I think the current focus is on DXVA and near-jitterfree AVsync.

[tetsuo55]

@Beliyaal and Casimir666

I have found the cause of my stuttering/desycning and macroblocking corruption!

It is caused by the subtitle renderer!

When i completely disable the internal subtitle renderer the image and AV-Sync are perfect!
No matter which settings i use the internal subtitle renderer will always cause macroblocking and/or stuttering

----------------

I have also discovered that the VC1 is corrupted only in full-screen mode. in windowed mode the image looks perfect but AV-Sync is bad.


EDIT:

I'm not sure how the subtitle renderer works but this is what it loosk like it's doing:
-The subtitle area is pre-allocated, most of the time corruoption will happen in this area.
-Because of the pre-allocation stuttering/desyncing/macroblocking can happen anywhere, even if there are no subtitles for many minutes
-Hardly any subtitles get buffered, it appears that a single buffered subtitle is simply displayed constantly at a different refreshrate(desktop,59hz) than the video(24)
-CTRL+J Subtitles free=0, allocated=0, buffered=0, when a subtitle appears on screen it changes to: free=0, allocated=1, buffered=1, regardless of the actual buffer settings

PS:
Cat 9.4 is completely broken for DXVA, 9.5 beta is almost perfect.

[Jong]

traditionally, in analogue Europe, RGB is used instead of YUV.

You're dead right about just trying both and seeing which you prefer.Broadcast PAL is YUV. You are right SD sets here used to have RGB inputs, but HD sets have component. Most still have legacy Scart sockets for SD that will support RGB, but not HD.

Anyway, as you say, let's agree to try both and trust your eyes. :)

[Casimir666]

@Beliyaal and Casimir666

I have found the cause of my stuttering/desycning and macroblocking corruption!

It is caused by the subtitle renderer!

When i completely disable the internal subtitle renderer the image and AV-Sync are perfect!
No matter which settings i use the internal subtitle renderer will always cause macroblocking and/or stuttering

----------------

I have also discovered that the VC1 is corrupted only in full-screen mode. in windowed mode the image looks perfect but AV-Sync is bad.

Interesting! Could you post a screenshot of the macroblock corruption? It's happen with SRT or PGS subtitles?

[tetsuo55]

Interesting! Could you post a screenshot of the macroblock corruption? It's happen with SRT or PGS subtitles?

I have not tried with PGS subtitles.

But it happens with SRT/ASS,SSA

It does not matter if they are animanted or not, animation is disabled, cpu usage never goes over 25%

[KoD]

Just like tetsuo55, I've noticed for a long time now, that the subtitle renderer, when using "Number of subpictures to buffer ahead = 0", is causing a desync when a new line gets displayed on the screen. This is more obvious when the line uses a more demanding ASS effect, and the CPU is on power saving mode (like the CPU on a laptop, which might run at 800 MHz when using DXVA decoding).

"Number of subpictures to buffer ahead = 0" is required by some ASS effects, otherwise they would not be displayed with buffering enabled. Here is such an example, where both a desync spike happens when the line is first shown on the screen, and the animation effect would not be shown if "Number of subpictures to buffer ahead" is any other value except 0:


{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11

- when the line is displayed, that desync spike happens. If the CPU is on low power saving mode (running at 800 MHz), the image is stuttering visibly when the line is displayed
- each pieceX is colored differently at a time determined by the \kNumber command (that's how animation of the color of each piece is achieved). This delayed presentation effect can be achieved only if "Number of subpictures to buffer ahead = 0". If you set the buffers to any other number except 0, you will not get the coloring animation effect running. There is no desync or stuttering when a piece gets its color changed at the \k command.

- every new line that starts with {\be1} gets that stutter before being displayed

Edit: ok, because it's easier to see the effect with an example, here's how to reproduce it.

1. pick one 720p or 1080p h264 video file from your collection (so DXVA will be used for decoding). Let's assume myVideoFile.mkv
2. copy the following to a file called myVideoFile.ass
[Script Info]
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 0
PlayResX: 640
PlayResY: 480
ScaledBorderAndShadow: yes
Video Aspect Ratio: 0
Video Zoom: 6
Video Position: 0

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,2,2,10,10,10,0

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:04.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:05.00,0:00:09.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:10.00,0:00:14.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:15.00,0:00:19.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:20.00,0:00:24.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:25.00,0:00:29.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:30.00,0:00:34.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:35.00,0:00:39.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:40.00,0:00:44.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:45.00,0:00:49.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:50.00,0:00:54.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:00:55.00,0:00:59.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11
Dialogue: 0,0:01:00.00,0:01:04.00,Default,,0000,0000,0000,,{\be1}{\k106}piece1{\k34}piece2{\k27}piece3{\k7} {\k35}piece4{\k26}piece5{\k11} {\k22}piece6{\k9} {\k20}piece7{\k32}piece8{\k23}piece9 {\k45}piece10{\k67}piece11

4. place this myVideoFile.ass subtitle file in the same folder as your myVideoFile.mkv
5. go to MPC -> View -> Options -> Subtitles -> set "Number of subpictures to buffer ahead" = 0 -> Apply -> Ok
6. go to MPC -> View -> Options ->Output -> set DirectShow video to VMR9 (renderless)
7. enable the stats in MPC -> View -> Display Stats
8. play myVideoFile.mkv in MPC
9. if you don't see any subtitles, then right click on the video surface -> Subtitles -> Enable
10. watch how every time a new line gets shown on the screen, there is a spike in the a/v line

Edit 2: changed the ass file above. And changed the renderer to VMR9 renderless, as it's the only renderer the internal subtitle filter seems to work with, when DXVA decoding is enabled (on my older version of MPCHC (v1.2.1043.0) + WindowsXP). When DXVA decoding is not enabled, the internal subtitle filter works with VMR7 renderless and EVR Custom Presenter as well.

[iron2000]

^ I also experienced lags with animated subtitles on video.
Once I turn off subtitles(or check the "disable animation" box) everything runs smooth.

Came across this problem many many times too, only to realise recently that its the animated subs.

[KoD]

Ok, I've just tried v1070 from xvideo.ru, because I thought my v1043 was too old.

But... what the ..... happened since v1043 ?

Issues:
- in v1070 I'm getting screen corruption at the beginning of playback of an avc file (green background, macroblocking, etc) and then it stabilizes. The same file has no issues in v1043 (I'm happy I've saved the old version). The macroblocks in the center of the screen are not compression artifacts (it's a png), those really are macroblocking artifacts at the beginning of decoding; and it's a green screen (it's not like this in v1043):
http://www.postimage.org/gx20eC9S.jpg (http://www.postimage.org/image.php?v=gx20eC9S)
- in v1043, VMR9 renderless + Direct3D Fullscreen, I was getting this:
http://www.postimage.org/PqfRit9.jpg (http://www.postimage.org/image.php?v=PqfRit9)
- in v1070, VMR9 renderless + Direct3D Fullscreen + any combination of Vsync, flush, or whatever else is new, I'm getting this:
http://www.postimage.org/PqfUPsS.jpg (http://www.postimage.org/image.php?v=PqfUPsS)

Is the constantly jittering line in v1070 supposed to be better than the completely smooth line in v1043 ? (the start spike in v1043 only happened when I paused the file to take the screenshot, it was not there during normal playback). Btw, I was having a jittering line in v1043 when not using Direct3D Fullscreen, and the smooth line above when using Direct3D Fullscreen. But in v1070 I'm having that jittering line when not using Direct3D Fullscreen as well as when using it.

[betaking]

MPC-HC mkv internal source filters and mkv standalone filters
can't select other stream audio language！ but haali can select!

[tetsuo55]

Interesting! Could you post a screenshot of the macroblock corruption? It's happen with SRT or PGS subtitles?

It is difficult to capture, but i got one:

http://img16.imageshack.us/img16/896/macro1.th.png (http://img16.imageshack.us/my.php?image=macro1.png)

[Jong]

Black screen playing an HD-DVD mkv rip since svn1056 (1050 definitely fine). Clip uploaded.

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

[Steveo08]

i have a question to the new renderer settings in mpc-hc.

for what is the setting "10 bit rgb"?

[Casshern]

Hi tetsuo,

this could fit to my findings that the older slower AGP cards are (sometimes) not fast enough to flush the gpu with the current beliyaal flushing logic (which i think might me suboptimal for all cards - but the bug only occurs on slower cards). I would think that:
1) Subtitle rendering takes additional time during vblank (this is the critical area, as beliyaal does his buffer switching stuff there)
2) wait for flush now takes longer well past the start of the next screen refresh - and the DXVA buffers are already being used by the dxva engine
3)the buffers get switched while still being worked on -> leading to corruption, jumping frames etc.
4) if windows is small enough, the card is fast enough and everything works fine.

I do not know if the subtitling rendering logic is synchronized to source frame rate or target screen refresh (the latter would be suboptimal) or if it can be moved out of the critical area....
Are you still using your 2400 AGP?

Interestingly the new merged builds work better than beliyaal standalones with h264 material on my 2600 AGP - the small judders during some critical scences (which were reproducable) are gone. Either the debug code was slowing the vblank code down, so now my card is just fast enough for the vblank period, or beliyaal changed something (to the better). Sadly VC1 does not work at all- just a black screen.

Tetsuo: whats different for you with the catalyst 9.5 beta ?

@Beliyaal and Casimir666

I have found the cause of my stuttering/desycning and macroblocking corruption!

It is caused by the subtitle renderer!

When i completely disable the internal subtitle renderer the image and AV-Sync are perfect!
No matter which settings i use the internal subtitle renderer will always cause macroblocking and/or stuttering

----------------

I have also discovered that the VC1 is corrupted only in full-screen mode. in windowed mode the image looks perfect but AV-Sync is bad.


EDIT:

I'm not sure how the subtitle renderer works but this is what it loosk like it's doing:
-The subtitle area is pre-allocated, most of the time corruoption will happen in this area.
-Because of the pre-allocation stuttering/desyncing/macroblocking can happen anywhere, even if there are no subtitles for many minutes
-Hardly any subtitles get buffered, it appears that a single buffered subtitle is simply displayed constantly at a different refreshrate(desktop,59hz) than the video(24)
-CTRL+J Subtitles free=0, allocated=0, buffered=0, when a subtitle appears on screen it changes to: free=0, allocated=1, buffered=1, regardless of the actual buffer settings

PS:
Cat 9.4 is completely broken for DXVA, 9.5 beta is almost perfect.

[Klaus_1250]

Short question to the devs: Are there any plans to tackle the jutter/occassional stutter when using the internal subtitling renderer? There was some talk about it in the Beliyaal thread and I think he had some idea to fix/mitigate it, but haven't heard anything about it since.

[tetsuo55]

Hi tetsuo,

this could fit to my findings that the older slower AGP cards are (sometimes) not fast enough to flush the gpu with the current beliyaal flushing logic (which i think might me suboptimal for all cards - but the bug only occurs on slower cards). I would think that:
1) Subtitle rendering takes additional time during vblank (this is the critical area, as beliyaal does his buffer switching stuff there)
2) wait for flush now takes longer well past the start of the next screen refresh - and the DXVA buffers are already being used by the dxva engine
3)the buffers get switched while still being worked on -> leading to corruption, jumping frames etc.
4) if windows is small enough, the card is fast enough and everything works fine.

I do not know if the subtitling rendering logic is synchronized to source frame rate or target screen refresh (the latter would be suboptimal) or if it can be moved out of the critical area....
Your theory sounds correct.
Pre-Beliyaal builds also play much better with subtitles disabled (but macroblocking and flashing frames still occur)

Are you still using your 2400 AGP? Yes, i cannot decide on which new card to get for the system i am building, i really like ati's price and speed but Nvidia seems ahead featurewise


Interestingly the new merged builds work better than beliyaal standalones with h264 material on my 2600 AGP - the small judders during some critical scences (which were reproducable) are gone. Either the debug code was slowing the vblank code down, so now my card is just fast enough for the vblank period, or beliyaal changed something (to the better). Sadly VC1 does not work at all- just a black screen.

h264 works like a dream with post-merge builds, but only if i disable subtitles and use my custom settings(EVR-CP,buf=8,DisDC,GluFlushAP,GPUFlushwt, VS, AltVS,0-255).

VC1 stutters in windowed mode and marcroblocks like crazy in full screen mode, i get a picture but it is unwatchable


Tetsuo: whats different for you with the catalyst 9.5 beta ?

This appears to be the best driver yet, all the problems from 9.4 are gone and everything seems stable.
I tested back to 9.1 and none of them changed the behaviour for either h264 or VC1, except for the 9.4 every x second stutter bug that everyone on the net is talking about. (do note that builds lower than 9.3 constantly crash earo on my system)

-----

Short question to the devs: Are there any plans to tackle the jutter/occassional stutter when using the internal subtitling renderer? There was some talk about it in the Beliyaal thread and I think he had some idea to fix/mitigate it, but haven't heard anything about it since.
If you read the last page you will see that your occassional stutter leads to dramatic playback problems on slower systems, i have not heard from Casimir or Beliyaal if they have a working solution. We need to better point out the cause first

--------------------

does anyone know, how i can select the right audio/subtitle track with m2ts files, which splitter should i use for best results?

[Aleksoid1978]

What videocard, driver, system(XP or Vista) ???

[Beliyaal]

Short question to the devs: Are there any plans to tackle the jutter/occassional stutter when using the internal subtitling renderer? There was some talk about it in the Beliyaal thread and I think he had some idea to fix/mitigate it, but haven't heard anything about it since.

As you mention I think I can fix this. I think I will be able to get to it next weekend.