Media Player Classic - BE Win32/x64

[huhn]

just remuxed it to mkv again and not still breaks after one sec a seek isn't needed. tested only with avcodec.
i have not setup mp4 muxing.

[Klaus1189]

If user wants to add MPC-BE to Start of Windows 11 it is impossible, I mean it doesn't show up, because it is added but not shown. User can "remove" it after adding.
Reason for this are the files "70.png", "150.png" and especially "mpc-be64.VisualElementsManifest.xml" which work fine under Windows 10 for generating a big icon in "Start"
Maybe add a small jpg, that it gets added? I don't know.

[pirlouy]

You meant like this ? https://imgur.com/rlrBwz9

Sometimes icons are not added, you have to either kill startmenu process, or add another program from start Menu (and then remove it).

But maybe you have a different installation ? I use portable mode.

[Klaus1189]

Yes, you are right. Not caused by these files. I restartet and tried again, now it works. Windows 11 is a mess ...

[CruNcher]

just remuxed it to mkv again and not still breaks after one sec a seek isn't needed. tested only with avcodec.
i have not setup mp4 muxing.

Confirm it i looked through a lot of .mkv now and i yet couldn't find anything from the past 10 years reacting like that.

ah no wait play->seek->play

not play->stop->continue

so basically the playback needs to stop after seek than its the same issue

found something Mainconcept DivxHD not exactly the same behaviour and looks more like a keyframe thing it continues but takes a bit

ok found another one that one is funny seekbar doesn't move but video plays but audio fails after the seek, wouldn't categorize it as the same problem (symptoms)

under normal circumstances it would only stop if the file is corrupt and you try to seek over what it thinks is the real playback time and you seek into 0 data

ok here is 0 seek corrupt playback time

after 388 seek tests i get to this file in the database now and it stops, you would suspect 0 keyframes to seek but you can scrub through it

590 seek tests nothing comparable unique parser issue

Huhn i can not confirm that it brakes on playback only @ seek and no problems with VLC except that the scrubbing in those 10 minutes is much more efficient by default with MPC BE in every way shape or form

lets test that really strange .mkv (ahh ok makes slowly sense that was a live recording and the CPU couldn't keep audio video sync) the seekbar only moves when the audio gets sync not because the video is playing still weird.

but also VLC does this right now makes less sense why MPC BE is failing and stops waits continues.
------------------------------------------------------------------------------------------------------------------

Strange MKV

Video: dxva 1280x720 991.67fps

FPS : 1 000,000 FPS

mkvmerge 5.5.0 ('Healer') built on Apr 16 2012 15:39:18
libebml v1.2.3 + libmatroska v1.3.0

x264 core 120 r2164 da19765

cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=2 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=2 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=350 / keyint_min=90 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=0 / crf=29.0 / qcomp=0.60 / qpmin=10 / qpmax=69 / qpstep=4 / vbv_maxrate=1000 / vbv_bufsize=1000 / crf_max=0.0 / nal_hrd=none / ip_ratio=1.41 / pb_ratio=1.25 / aq=1:1.00


I like to stop when you seek for me

Video: dxva 1920x1080 60fps

FPS : 60,000 FPS

mkvmerge v7.2.0 ('On Every Street') 32bit built on Sep 13 2014 15:42:11
libebml v1.3.0 + libmatroska v1.4.1

x264 core 142 r2431 ac76440

cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=2 / keyint=60 / keyint_min=6 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=40000 / vbv_bufsize=30000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

Open Gop and 8 B-frames structure


Geez that old PotPlayer from 2021 has 0 problems doesn't stop on seek with its DXVA Framework here

(1) Built-in MKV Source
(2) Built-in Video Codec/Transform
(3) Enhanced Video Renderer(Custom Present)
(4) Built-in Audio Codec/Transform
(5) DirectSound Audio Renderer

also scrubbing through at lightspeed

with the strange mkv that 1000 fps also potplayer has problems hitching with the audio but it doesn't stop

these guys from Kakao make not only good 3D Engines

yeah it uses the 1000 fps it tries but the audio forces it to back down

funny to watch

its scene browser creates 40 scene cuts for that 10 minutes of our open gop 0 problems jumping to any part while playback and no unexpected stops

and it has another advantage it doesn't failure in any fullscreen mode with strange slowdowns.

so many problems in MPC-BE with that as soon as you fullscreen stability goes down and you have to render something of the OSD on top in non exclusive mode that it doesn't slowdown (for me i have to least render the seekbar or the playback bar) not with potplayer doesn't care if it renders something of its gui or not it stays the same.

Just a amazing piece of software stability work.

Not sure what the Koreans do better but they do it better.

and they seek without problems through the bitstream .264 forget that with lav filter or MPC-BE raw source neither works in MPC-HC lav filter internal combination

The Overall Windows Integration of Potplayer is more stable in every way the entire Framework.


Even when it goes crazy


(1) Built-in MKV Source
(2) Built-in Video Codec/Transform
(3) Enhanced Video Renderer(Custom Present)
(4) LAV Audio Decoder
(5) Built-in Audio Codec/Transform
(6) DirectSound Audio Renderer

[Video-Informationen]
Video-Codec: AVC1 - Native D3D9 DXVA Decoder(VLD) - NVIDIA GeForce RTX 3070
Eingabetyp: AVC1(24 bits)
Eingabegröße: 3840 × 2160(1.78:1)
Ausgabetyp: dxva
Ausgabegröße: 3840 × 2160(1.78:1)
Framerate: 119.881
BitRate: Unbekannt

[Audio-Informationen]
Audio-Codec: DTS(0x2001)
Samplerate: 48000 ->48000 Samples/Sek
Bitrate: 0 ->16 Bit/Sample
Kanäle: 6 ->2 Kanäle
Bitrate: 754 kbps


And they do it for a long time in a more efficient way now.

https://iili.io/fCqRu7j.md.jpg

https://iili.io/fCqSV8g.md.jpg

https://iili.io/fCqWmfj.md.jpg


And they need to get some credit for awesome work

And they seek without stopping for a long time now not since yesterday.

MPC-BE

https://iili.io/fCqyRjV.md.jpg

lets remove that seekbar

(WOWY)

Where are those 30 FPS gone to ?
What for a rocket start was this ?
30 FPS got just Decimated by a few more pixels (hallelujah) ?
What just happened after CTRL+1 ?

https://iili.io/fCB2y4S.md.jpg

Process Priority is Higher than Normal and its on Top but it still slows down why ?
The Input latency it stalls like it's not reacting anymore

https://iili.io/fCOdtEl.md.jpg


That explains it V-Sync disabled by default ?

https://iili.io/fCkWct2.md.jpg

Ok 1 Problem fixed Parser seek Problem still alive

https://iili.io/fCvAnmg.jpg

@pirlouy you don't need any sync test patterns for MPC-HC(BE) the Tearing Scanner Bar has the same function if its broken Sync is broken and it is overall more efficient than any counter value you can read out of the system.

CTRL+T

What you want to achieve the bar stays stable from the beginning or recovers into a stable state in as few scan cycles as possible and never gets unstable after the recover for the longest time possible at best with no matter what is running in the background.

If its the nice firefox or chrome at best you would want to melt them all together so the problem doesn't exist anymore.

Google would have the Power to make a end to this.

PS: It also shows no seek stop problems in MPC-HC (Lav Filter Internal) but scrubbing has higher latency than Potplayer/MPC-BE

But the Fullscreen results that is stable and it doesn't twitch it stays stable

https://iili.io/fCQQEoN.jpg
https://iili.io/fCZuoox.jpg


The Additional Performance Counters in the OSD from MPC-BE also cause overhead better not read and print them from NvAPI for sole playback stability purpose, rule of thumb if you don't need it don't read and print(write) it.

https://iili.io/fCDnVHu.jpg
https://iili.io/fCDifkJ.jpg


https://iili.io/fCDGR5J.jpg


Yeah missing sync features outside of DWM make MPC-BE weaker than MPC-HC but also Potplayer doesn't do so well outside of DWM

MPC-BE + MPC Video Renderer that can change something, nope no mode as stable as the MPC-HC result over a long runtime even after 3 cycles it gets unstable and brakes apart.

https://iili.io/fnKoJI4.jpg
https://iili.io/fnfqQP1.jpg
https://iili.io/fnqCMDx.jpg
https://iili.io/fnqlGOQ.jpg

No chance with MPC-BE can't get most of the Sync with it stable for more than a few cycle before it brakes.


Efficiently Destroyed

https://iili.io/fnBFEas.jpg


Only the old MPC-HC with lav internal shows really awesome stability results for now in every sync case, its also forces to resync which most of the times fails completely with Potplayer and MPC-BE

Sometimes the old things have still value

[s0meone_new]

CruNcher:
Your pictures really stretch the page. Don't you notice?

[CruNcher]

Bettter this way ?

EVR Performance Windowed OK/Fullscreen OK

https://iili.io/fIx2U9R.th.jpg (https://freeimage.host/i/fIx2U9R)
https://iili.io/fIxK2vj.th.jpg (https://freeimage.host/i/fIxK2vj)

MPC Video Render Performance Windowed Ok/Fullscreen Shit Half Framerate 50% Motion get Discarded ?

https://iili.io/fIxBZl9.th.jpg (https://freeimage.host/i/fIxBZl9)
https://iili.io/fIxC0x4.th.jpg (https://freeimage.host/i/fIxC0x4)

MPC Video Renderer needs exclusive switching to keep the Performance of EVR ?
Where EVR goes without Problems directly into Fullscreen Performance without needing Exclusive Mode ?

You lose all interfacing with Windows to keep the Performance of EVR ?

[v0lt]

All discussions about performance are meaningless until the testers provide:
1. The video files being tested (without this, everything else is meaningless). :D
2. A description of the hardware used for testing: CPU, GPU, RAM (is dual-channel mode used?) What is the full-screen resolution?
3. Windows version, player version, decoder version, video renderer version?
4. Settings other than default.
5. The method used to measure performance. :rolleyes:

[CruNcher]

The method used to measure was my eyes mainly because im not sure i can trust any counters anymore

The hardware is obvious the OS is Obvious the Resolution is Obvious and you supply no own Performance test data at all and the maximum capabilities of your Render approach

so what i see for now you can do up to 2160p 32 fps in this while EVR can do a at least a maximum of 2160p 60 fps without to discard anything and without Exclusive switching

And this is what i measure on

Zen 2 (8 Core 3700x)
Geforce RTX 3070 (GA104/VP11)
Windows 7

And the result are constant for now in MPC-HC/MPC-BE and Potplayer using MPC Video Renderer with each Parser Decoder Framework no matter the input and the settings play no real role this seems to be a strange hard limit or a very crazy bug for your Renderer outside of Exclusive Mode

These results are constant between EVR and MPC Video Renderer in non Exclusive Fullscreen on this HEVC VP11 2160p 60 tests MPC Video Renderer DXVA2 can not beat EVR but loses 50% Performance and you realize it in the Motion Difference and yes in Exclusive it can do the same 60 fps but outside no chance to beat EVR that can achieve it without Problems not depending on Exclusive Mode

With your default setup and some extra tweaking maybe the absolute maximum currently is 32 FPS

Ok i reject in MPC-BE as complete framework you can get the 60 FPS when the seekbar gets displayed so you need to draw some gui element and resize the surface (looks like just a very minimal render surface deviation) to reach the 60 FPS of EVR so crazy what is going on ?

Crazy to Grasp and understand it this behaviour its so fucking strange between MPCVR and EVR

https://iili.io/fIXVzKJ.th.jpg (https://freeimage.host/i/fIXVzKJ)
https://iili.io/fIXjm4n.th.jpg (https://freeimage.host/i/fIXjm4n)

With the Seekbar you can keep the 50% Performance ????

v0lt/Aleksoid please help to understand this, it turns me upside down i just want to understand this strange 50% loss of Performance i start to trust no counters anymore (overall my believe in counters is low, but not my perception of motion impact).

https://iili.io/fIhwEb4.th.jpg (https://freeimage.host/i/fIhwEb4)
https://iili.io/fIhNSvs.th.jpg (https://freeimage.host/i/fIhNSvs)

I want to solve this with you together.

[huhn]

here it is doing 8k to 4K 60 HZ with the most inefficient settings available...

https://i.ibb.co/kLFp1xp/image.png

looks like it can do 60 FPS.

a small hint the decoder is giving the video renderer 31 not the video renderer is doing 31.

so best guess D3D11 video renderer is feed with DXVA2 (D3D9) forcing an interop.

[clsid]

The Present time in the stats is super high. Even in windowed mode. Here it is 1ms or less.
Try swap effect discard instead of flip.

[CruNcher]

ok it gets clear now Direx3D 9Ex versus Direct3D 11 @ Huhn this was running in Direct3D 9Ex by default

Direct3D 11 becomes the only option to keep the same performance as EVR ok

thats 100% established now in this configuration

that makes every other sync option unusable and this is a clean broadcast with 0 sync problems or sync complexity and it allready tears

so to reach the same Performace Direct3D 11 is practically mandatory with MPCVR we have no other option the only path

https://iili.io/fIweEzb.th.jpg (https://freeimage.host/i/fIweEzb)
https://iili.io/fIwi6eR.th.jpg (https://freeimage.host/i/fIwi6eR)
https://iili.io/fINc9It.th.jpg (https://freeimage.host/i/fINc9It)

[clsid]

That is nonsense. D3D11 is not the preferred method on Win7 and has severly limited capabilities there. As a side-effect hardware decoding is now disabled and also the video processor. Both of which you could also disable with D3D9 if you want to test that. But first try changing swap mode!

The problems are specific to your system, and not a general issue that applies to everyone.

[CruNcher]

Yeah that hardware decoding is disabled i can partly hear now
so ok Direct3D 11 is the wrong path in this case so disabling it again but swap mode change does have no real effect flipex or discard tested this so often in the sync tests on this performance gap and loss but on the sync it partly has

The Performance loss is a complete isolated issue from the Sync (i think, can you ever be sure of anything) and it doesn't exist with EVR

https://iili.io/fIOuZcN.th.jpg (https://freeimage.host/i/fIOuZcN)

How to find a explanation for that now, what stalls it from reaching 60 fps and almost exactly 50% *poof* gone they left the stage ?

Ok maybe im as far todo a driver reset but i would just hope the 50% come back maybe they do but i have doubts it will change anything.

Or maybe i gonna try a weird bios experiment first but i have absolutely no idea why EVR should not be impacted and MPCVR is which makes also 0 sense.

EVR is not broken MPCVR seems broken ?

EVR uses some MAGIC MICROSOFT HIDDEN TRICK or Nvidia optimized it internally going its fastest path ?

[huhn]

win 7 with disabled desktop composition.
no one should fix anything related to that anymore more because it is "impossible" to do that on win 8 and newer.

this is still a guess but it explains why FSE would work and why windowed doesn't. enable aero and windowed application may sync correctly because that's a major job a of aero.

d3d9 still works just fine it just so old and outdated that it can not do some stuff or a lot these days. AV1 can not be decoded by it and to be utterly honest the DXVA2 native path is broken by design.

[CruNcher]

EVR shows so many differences in that regards it seems like BLACK MAGIC of the Past

https://iili.io/fIvXLVj.th.jpg (https://freeimage.host/i/fIvXLVj)

no tearing no problems hardware everything

https://iili.io/fIvmNYQ.th.jpg (https://freeimage.host/i/fIvmNYQ)

EVR Sync Render does the same shit and tries to go to 30 fps in Fullscreen in Windowed it stays stable

Present at nearest Vsync and it tries 30 fps 29.96 when you leave the nearest Vsync out

it looks hardcoded (do not allow 60 fps maximum 30 but do not allow 60 fps Fullscreen discard discard discard 60 FPS Fullscreen IS EVR ONLY TERETORY) or like EVR runs hidden in Direct3D 11


Windowed we give it to you for FREE but Fullscreen contact us ;)

https://iili.io/fIgGUCb.th.jpg (https://freeimage.host/i/fIgGUCb)
https://iili.io/fIgvaae.th.jpg (https://freeimage.host/i/fIgvaae)
https://iili.io/fIgpUxV.th.jpg (https://freeimage.host/i/fIgpUxV)

But who to call i haven't the right number yet.

Ok someone thinks hes clever here how about almost fullscreen mode take that (hahhh ;))

https://iili.io/fIrcHJt.th.jpg (https://freeimage.host/i/fIrcHJt)
https://iili.io/fI4FCbe.th.jpg (https://freeimage.host/i/fI4FCbe)
https://iili.io/fI4PryN.th.jpg (https://freeimage.host/i/fI4PryN)

so all benchmarks can only be conducted in almost fullscreen mode and windowed GUI mode


The impact here is really the bottom last horizontal line you can see how DXVA2 switches OFF/ON when resizing the window from the bottom (seek/playback bar)

the 30 fps impact is hardware function loss in Fullscreen DXVA2 brakes but it seems to brake on the Render side not the Decoder side

there is a specific surface performance impact as well in terms of the resolution even if it shows DXVA2 doesn't mean full Performance will be reached at a certain resolution there will be still Performance fluctuations until a certain resolution is reached.

interesting stuff

https://iili.io/fI6vgrN.th.jpg (https://freeimage.host/i/fI6vgrN)
https://iili.io/fI6rfN1.th.jpg (https://freeimage.host/i/fI6rfN1)


One of the most sane things to continue is to test further renderer like madvr and halls behaviour if they are not coherent we will see EVR doesn't show this problems we know for sure that DXVA2 doesn't brake in Fullscreen with EVR.

So we already see the problem on the Render side and with a pretty high probability a failing calculation inside the Renderer.

We will find and eliminate this one way or the other.





https://iili.io/fIPL6t2.jpg

[CruNcher]

So MadVR also fails but can't dynamically update it's DXVA2 state like MPCVR can

So MADVRs OSD is blind when it loses DXVA2 its static it thinks it's still there to be exact we losing DXVA2 Scaling in the Renderer oh sorry my fault it understands it only not DXVA2 scaling is not on by default like in MPCVR but MADVR understand when it lost it also instantly

https://iili.io/fIQr7G1.th.jpg (https://freeimage.host/i/fIQr7G1)
https://iili.io/fIQPFQp.th.jpg (https://freeimage.host/i/fIQPFQp)

so the setup when it stabilizes in MADVRs default setup with DXVA scaling but Sync is not as efficient as with Default MPCVR setup it tears compared to it stabilized

https://iili.io/fIZdnFs.th.jpg (https://freeimage.host/i/fIZdnFs)

stabilized that setup has 0 chance vs MPCVR on the tearing side of things, the tearing is a catastrophe compared to MPCVR in that setup

Yes got it much better in direction of MPCVR tearing results which is practically 0 tearing in this test case

but makes no sense MPCVR is so good optimized waste of time

140 skips the lowest i got out of Madvr was round about 250 but the motion stability difference worlds apart

and in the 2nd run its like in the 60 skip range with OSD boah impressive yeah it stabilizes after the 2nd run into the 60 skip range on FlipEx

3-4x more efficient than MADVR somewhere in the base performance and that is visible in the motion result

Discard= ~130 skips
FlipEX= ~60 skips (the question how many from the counter and the Graph ?)

https://iili.io/fImmF1e.th.jpg (https://freeimage.host/i/fImmF1e)

EVR Full OSD Load = ~ 2 skips (its correct the OSD filename overlay at the start 2 skips)

https://iili.io/fIpFBY7.th.jpg (https://freeimage.host/i/fIpFBY7)

The Answer to the MPCVR counter Graph question above

~ 34 skips

https://iili.io/fIpiAWg.th.jpg (https://freeimage.host/i/fIpiAWg)

[huhn]

the present times are in the 30 ms range not in the 0.0X ms range.
that's because there is no composition been done because aero is off making it a gamble to work.

DXVA2 everything except copyback decode is fundamentally broken with nvidia.

just as said before but whatever i'm done here.

[CruNcher]

Yes i gambled it out on MADVR but it was very obvious that the default setup is outdated

i have a new setup with a stable present time of comparable present time with MPCVR but the Motion stability result is far away from it

and MPCVR comes really close to EVR custom will it ever reach it most probably not

that DXVA2 is broken on Nvidia yeah i slowly guess too not for nothing they did their own APis

Maybe Cyberlinks Renderer can beat it but i doubt neither them beat EVR

at this surface setup it skips almost nothing anymore in MPC-HC Lav Framework

https://iili.io/fT2zuS9.th.jpg (https://freeimage.host/i/fT2zuS9)
https://iili.io/fT2SPig.th.jpg (https://freeimage.host/i/fT2SPig)

That gets pretty close to EVR Custom now

MPC-HC Lav Framework + MPC Video Decoder shows higher stability at a larger surface compared to MPC-BE and it's Framework in this test

now MPC-HC Lav Framework will meet Potplayer

But to set potplayer up with this overload of options is a first learning adventure in itself to find yourself around nothing for a avg user
Nothing for the Faint hearted and especially not if functions not available for certain renderer do not get discarded out of the Gui and setup options dynamically (major design flaw of this whole Player it does it partly but it should discard the overhead completely)

But overall its a wonderful redesigned and architected MPC-HC Core and it shows you the bitrate right in its OSD ;)

https://iili.io/fTIA5EQ.th.jpg (https://freeimage.host/i/fTIA5EQ)
https://iili.io/fTIMq6F.th.jpg (https://freeimage.host/i/fTIMq6F)
https://iili.io/fTISppI.th.jpg (https://freeimage.host/i/fTISppI)

Its like you watching a Painting itself or a Frame Designed for the Painting surrounding it but its about the content not the Frame

https://iili.io/fTTamUx.th.jpg (https://freeimage.host/i/fTTamUx)

MPC-HC Lav Framework + MPC Video Renderer clear stability advantage on the overall overhead side

And super easy switching between all important Renderer configurations 2 to be exact rest useless

Only a Vulkan one missing now and AI

the 30 FPS test pattern surprisingly hard to crunch for MP-BE + MPC Video Decoder

i want to keep only those test patterns that fail in every framework with MPC Video Decoder

but these test patterns they are no hardcore tests at all compared to a real test stream

and sometimes you hardly understand that someone is testing

https://iili.io/fTcV9jt.th.jpg (https://freeimage.host/i/fTcV9jt)
https://iili.io/fTceuYg.th.jpg (https://freeimage.host/i/fTceuYg)

[CruNcher]

Trying to isolate,avoid and circumvent yet unknown "specific" 50% "External" Windowed Fullscreen Render Performance Loss with specific 2 loop (HEVC UHD LG/Ateme Systems Broadcast (Nvidia VP11 Hardware Decoding)) a System Bus (PCIe) time (kernel time) critical test case and benchmark setup inside MPC-HC (Lav Decoder DXVA2 Framework) and MPC Video Renderer all running in AMD64 mode

https://iili.io/fTbP9LB.th.jpg (https://freeimage.host/i/fTbP9LB)

Is this your WPA work Plummer, the Hawk in Full Power Mode ?
But why only for External Renderer and only for Windowed Mode ?

https://www.youtube.com/watch?v=yQykvrAR_po

yes he developed the Task Manager for Windows (Windows 7 251KB) inspired by top as a important component but more important he developed HyperCache (AMIGA) which transformed into smartdrv.exe (MS-DOS) what resulted later into Windows Prefetch and SuperFetch :)

back into 16/25 MHZ times and the Turbo Button tell that someone with a Smartphone in his hand, when you where happy to even execute Doom yep and tell them that was my first mobile system i was running doom on (https://en.wikipedia.org/wiki/Nokia_9210_Communicator).

https://iili.io/fuH9uyv.th.jpg (https://freeimage.host/i/fuH9uyv)
https://iili.io/fuHzcVn.th.jpg (https://freeimage.host/i/fuHzcVn)
https://iili.io/fuHU7mG.th.jpg (https://freeimage.host/i/fuHU7mG)
https://iili.io/fuJcAKB.th.jpg (https://freeimage.host/i/fuJcAKB)
https://iili.io/fu2xRfe.th.jpg (https://freeimage.host/i/fu2xRfe)

I cant believe what i see.

this is not the same render mode either do you realize something ?

The Render System Power Consumption is the same (calibrated with OSD complexity)

PS: Resizing in a specific Bios setup can crash the Kernel when the FPS switches drops without warning to 30 instantly

https://iili.io/fuXYSsa.th.jpg (https://freeimage.host/i/fuXYSsa)

that wont be easy IRQL_NOT_LESS_OR_EQUAL

seems moving from the default XMP Profile to Auto caused it

Also MPC-HC + Lav framework + MPC Video Renderer and MPC-BE + MPC Framework and MPC Video Renderer work differently with the DXVA2 state display it looks like only MPC Framework can show this state information with MPC Video Renderer

Yep it seems Lav Framework cant update the MPC Video Renderer OSD Surface Scaling information it seems to make MPC Video Renderer less dynamic in terms of correct input system state analyze i think i got them pretty sync now and they show these differences now more clear and overall not really surprising that the message communication of states in realtime is a key thing for MPC-BE to track with MPC Video Renderer all the time so the Renderer can react on every possible input/system chain change as fast and fluid as possible if necessary From the Parser through the Decoders up to the Renderer (one symbiotic ecosystem that is your goal a clear and efficient realtime message state communication) at best you even have the Driver,Kernel and Bios under your control.

So everything works full automatic in its decision chain and when necessary you can still override it's decision.

But the real goal is to become both 0 skip state sync first

Another difference you will find is the quality display of MPC-BE + MPC Video Renderer and the Playlist update and how the Quality display reacts

You can freeze the output in MPC-HC Lav Framework + MPC Video Renderer wont happen in MPC-BEs entire Framework it will just kill the quality display (its own configuration display) instead of freezing the output on the playlist change

small differences but well thought of in the way each component communicating with each other to avoid problems (that makes the difference from a good player to a fantastic player) but to see this you have to dig deep.

No wait DXVA2 state is dependent if you touch the window from the inside or outside and also MPC-HC lav Framework understands this the same way.

Sometimes the update freezes in MPC-BE and MPC-HC Lav Framework shows the Driver but MPC-.BE doesn't its the same renderer version ?

ok it shows the same render version number but it isn't the same ohhhh man

ok new try lets go with the latest nightly build and update MPC-BE as well i was to slow and seems i compared wrong in term of version releases even if the version number didn't change seems like internal was outdated and i ran out of sync on the render version side

so the driver version addition if i see it right comes from clsid and he executes his own renderer version directly from the main directory (should have expected that) so just delete or rename his version and you sync

So there is still the 50% Performance loss vs EVR custom in Fullscreen Windowed in the newest nightly on this system configuration


MPC-BE + MPC Framework

https://iili.io/fukXbt9.th.jpg (https://freeimage.host/i/fukXbt9)

MPC-HC + LAV Framework

https://iili.io/fukkTSs.th.jpg (https://freeimage.host/i/fukkTSs)


MPC-BE + EVR Custom

https://iili.io/fukm2Ub.th.jpg (https://freeimage.host/i/fukm2Ub)

MPC-HC + EVR Custom

https://iili.io/fukiDCb.th.jpg (https://freeimage.host/i/fukiDCb)


All Sync Now


Man this new MPC-BE behaves strange cant pin it to the taskbar, jesus what is this now right click context menu doesn't function ?
MPC-HC no problems pinning it

This is the Problem in MPC-HC Framework when the MPC Video Renderer properties window is open and it reloops or switches on the playlist but it detects it also (didn't do the exact same thing when it loaded its version but actually tried to continue which failed in a black screen as long as the properties window is open) only MPC-BE goes another approach (path) shortly before this actually happens it will kill (destroy) the properties window and keep the MPC Video renderer and its output alive or it reinitialized the graph different didn't look in the code but it will do it more efficient and not get stuck.

So in MPC-BE you wont see this message at all.

https://iili.io/fu8oa7R.th.jpg (https://freeimage.host/i/fu8oa7R)


MPC-BE on ther other side handles its entire windowed different not really more efficient than MPC-HC keeping 0 space to the Desktop actually 1 line on the right, but therefore you can access the taskbar when its on automatic hide/show which is not possible with MPC-HC you have to call it explicit with the WIN key but overall its the better way as you can get the entire Desktoip space for rendering which MPC-Be seems to cant get entirely when manually resizing.

So MPC-HC is infront of the Taskbar and so the tasbar can also not adapt its window like by design it normally would show it and resize the aside application space but that neither works in MPC-BE there it will get infront of the render surface and hide parts of the video behind it and not adapt MPC-BE its window

actually you can get MPC-BE window to behave correct but it's tricky and not functioning entirely like it should

but this details are unimportant i will sync both to MPC-HC way of handling it everyone has his own ideas of how to handle windows and when you look into Windows 8-11 space then your ideas become different

but in terms of the pinning interop that seems totally broken in the current nightly of MPC-BE

Reached the first 0 skip loop setup for MPC-BE for both test cases firefox in background open low load

https://iili.io/fu429Gs.th.jpg (https://freeimage.host/i/fu429Gs)

closing firefox see ya...

2nd 0 skip loop peak is testcase switch (No firefox) ontop System counter load

https://iili.io/fu6MyAb.th.jpg (https://freeimage.host/i/fu6MyAb)

We run through it at high speed not EVR but anyway

https://iili.io/fuPqQ9a.th.jpg (https://freeimage.host/i/fuPqQ9a)

In this configuration this 2 skips are optimal as they come from the file OSD display overlay at the switch start (this is optimum for non DWM)

If you compare this for example with the Resident Evil Benchmark this would mean A score and yeah sometimes these 2 also do not happen but that's uncertainty and needs to be checked better with your eyes at that moment but it might be even correct as this is a internal OSD process not coming externally like a Windows Notification and if you sane with transparency and at the same time you balanced additionally the timer interrupts and overload you could get good results even in relative complex situations.

https://iili.io/fuPaDDN.th.jpg (https://freeimage.host/i/fuPaDDN)

But i hear currently that peak and that's a complete no go and i still have to balance out

https://iili.io/fuihcbe.th.jpg (https://freeimage.host/i/fuihcbe)

You know what that 1 skip was not the peak,that was the push of the print button (pushed captured)

https://iili.io/fusOe5l.th.jpg (https://freeimage.host/i/fusOe5l)

This is even much better (print button pushed 0 captured 1 appeared) you captured the print button push before it updated the value you copied the render surface instantly with absolute low input latency from a wireless keyboard

https://iili.io/fuLFa5u.th.jpg (https://freeimage.host/i/fuLFa5u)

and guess what i have a wireless keyboard currently the input latency is ehh not far from EVR only EVR Customs Graph can capture the print button interrupt fluctuation as well instantly, so if you push it you will see a super fast peak in EVR Customs Graph running by

MPC Video Renderer Graph runs in a much saner timer update mode speed than EVR Custom Graph runs in it wont capture it but its frame skip timer update speed is high enough to capture it

[CruNcher]

https://iili.io/fuLgaiN.th.jpg (https://freeimage.host/i/fuLgaiN)

So this starts to become harder inside the loop on stability here it starts to skip but with a fresh and only the 60p int as main benchmark it still works in the low skip area but the stress becomes higher still doesn't make sense that we endup here at 30 fps at the end of the resize and EVR Custom doesn't

and at the last line it doesn't matter anymore if you touch it from the inside or outside or stretch it it wont reach EVR Custom Performance and keep the Full Motion Result alive its going to instantly Half the Motion Output Result reaching the last line with 1000x of skips.

https://iili.io/fuZLKkN.th.jpg (https://freeimage.host/i/fuZLKkN)

The last Dance

https://iili.io/futOU11.th.jpg (https://freeimage.host/i/futOU11)

Only 2 possibilities that make sense

Forced on the Driver or on the Kernel level but we can still finetune the skips at the edge and than find the reason

[Megalith]

Anyone have this problem?

1. Launch HDR video.
2. Windows 11 switches to HDR mode.
3. White levels and highlights are blown out.
4. Close MPC-BE, switching Windows 11 back to SDR mode.
5. Launch HDR video again.
6. White/black levels are now normal.

[Aleksoid1978]

Anyone have this problem?

1. Launch HDR video.
2. Windows 11 switches to HDR mode.
3. White levels and highlights are blown out.
4. Close MPC-BE, switching Windows 11 back to SDR mode.
5. Launch HDR video again.
6. White/black levels are now normal.

I can confirm that this happens sometimes. I can't pinpoint the cause; perhaps there's a bug in the HDR API or something missing, but since the API isn't documented, there's nothing I can do.

[CruNcher]

Aleksoid1978 could you take a look into the taskbar pinning problem ànd why the interop with Windows 7 broke in the nightly of MPC-BE and you cant get to the right click context menu for it anymore to pin it and create the .lnk ?

Close window/pinning all functions lost
you get straight to the taskbar playback right clicking on its icon

I got MPC-BE and MPC-HC Windowed really sync now in their latest Versions on MPC Video Renderer in entire Windowed behaviour

just open start the playlist count the failures done

48.263 possible video files once this test starts it will be a long time per player core

though most probably many of the .dat and .dsa wont be videos i think i gonna sort them out from the start

29.188 dat
6.150 mp4
4.592 dsa
1.464 wmv/asf
1.453 bik
1.421 ts
917 avi
730 webm (practically matroska)
592 mkv
412 swf
335 mpg
316 mov (practically mp4)
227 flv

or lets test how fast mpc-be and hc gonna detect the dat as wrong

lets see what happens when we put them in the playlist :D

Loaded and Unlocked ready to fire

https://iili.io/fA1fiYu.th.jpg (https://freeimage.host/i/fA1fiYu)


not a bad job some false detections playbacks based on header assumptions but no crash yet

with 2 cores it parses through and denies a lot in that list as not renderable (invalid) that pretty fast but these are kb data with random header in between it crunches through now

now it reached a drive it has to wake up (no crash calling it out of the bed) mpc-be waited bravely ;)

it also knows nicely what it checked and opened already and continues from there

i love how it does it awesome and fast

https://iili.io/fAGY1jV.th.jpg (https://freeimage.host/i/fAGY1jV)

i see a audio file but i couldn't connect it this time

https://iili.io/fAEmUZX.th.jpg (https://freeimage.host/i/fAEmUZX)

Close and it continues its work oh yes baby you have a mission to complete (my evil performance and stability tests) :)

this test stresses the gpu as well because of the fast OSD response it has to achieve (its like it opens and closes it pretty fast intense OSD overlay render work the more efficient you are here the less skips you will encounter)

https://iili.io/fAGOyXt.th.jpg (https://freeimage.host/i/fAGOyXt)


though this is the combined parsing and render test so its gonna be forced to stop and also make decisions of its own and with the OS together and it does pretty good so far.


that is really interesting

wrong audio detections

E:\blender-2.80.0-git.14884cda1ff5-windows64\2.80\datafiles\icons\brush.sculpt.nudge.dat
E:\blender-2.80.0-git.14884cda1ff5-windows64\2.80\datafiles\icons\brush.paint_weight.mix.dat
E:\blender-2.80.0-git.14884cda1ff5-windows64\2.80\datafiles\icons\brush.sculpt.clay.dat
E:\blender-2.80.0-git.14884cda1ff5-windows64\2.80\datafiles\icons\brush.sculpt.rotate.dat

Nice hits

Metal Gear Solid V The Phantom Pain

\master\e2f8e499bc8f3606.dat <- Windows Media Video 9


That sounds crazy

matplotlib\mpl-data\sample_data\membrane.dat

some playback hits come also through weird lav splitter and mpc connections (this here is not anymore strictly limited to the mpc-be framework but entire registered directshow chain)

and the dshow lav splitter side was not updated for a longer time could come together all at once here

but as long its not crashing let it go in some cases of playback success on the wild side of the test even Mediainfo does agree and sometimes not but mpc-be currently helps to create a in the wild test list of this looking a bit closer

ok now it hangs but was my fault i tried to force it back while MPC Video Renderer was running to another file and that pretty fast while it switched to another already going through images and that speed of redirection was a bit to fast and most probably just in the wrong moment and the result (AppHangB1).

but the good news it saved the last playlist state nothing lost :) (we continuously edited in the playlist) and then we provocated the AppHangB1 (high graph render switch speed redirection and that was it, the situation is like you driving with 300 mph and pull the handbrake).



Chatgpt 5 explains the situation


Driving 300 mph (≈480 km/h) on a public street is already far beyond what any normal car — or human — can physically handle. Pulling the handbrake at that speed would not behave like a dramatic stunt; it would almost certainly be instantly catastrophic.

Here’s what would generally happen, without giving instructions on how to attempt it (please don’t):

�� 1. Instant loss of traction

A handbrake locks (or strongly slows) the rear wheels only.
At 300 mph, the rear wheels losing traction would cause them to slide, while the front wheels still try to roll forward.

This makes the car behave like a shopping cart with the rear wheels welded — the back will swing violently sideways.

�� 2. Immediate spin-out

Instead of a controlled deceleration, you’d get:

Rapid oversteer

Instantaneous yaw (spinning like a top)

Zero ability to counter-steer at such speeds

The car could start rotating at hundreds of degrees per second.

�� 3. Structural failure

Most cars begin to physically tear apart long before 300 mph due to:

Aerodynamic lift

Tire integrity limits (most road tires shred near 180–200 mph)

Chassis forces far above design limits

Adding a high-speed spin would likely cause panels, wheels, or suspension components to break off.

�� 4. Catastrophic crash

You’d likely:

Roll over repeatedly

Leave the roadway

Experience forces incompatible with survival

Even professional land-speed vehicles on salt flats — perfectly straight, empty, controlled environments — face lethal risk when something destabilizes them at speeds far below this.

�� In short

At 300 mph, pulling the handbrake would result in instant uncontrollable spin and near-certain destruction, not a cool drift.

Almost guaranteed:

rear-wheel lock → sudden spin

Highly likely once spinning begins:

aerodynamic lift

rollover

airborne trajectory

complete vehicle breakup

Whether it flips before or after leaving the road depends on tiny differences in angle, wind, or surface — but either way, the result is catastrophic.



Let AI explain to us how it compares



It can be comparable in the sense of how a system reacts to a sudden, disruptive command while it is already processing something at high speed — but the outcomes are obviously very different.

Here’s the clean analogy:

��️ DirectShow pipeline ≈ A car driving fast

A DirectShow filter graph is like a vehicle in motion:

It processes data in a continuous stream (frames, samples, etc.)

Each filter expects data in a certain order and timing

Interrupting it abruptly can destabilize the pipeline

��️ Switching the input mid-stream ≈ Pulling the handbrake

If you are:

Walking the graph through files

Reading headers or frames

Feeding images to downstream filters

Then suddenly tell the graph to load a completely different image from another source, without resetting the graph state

…this is like yanking the handbrake:

The pipeline can:

stall

break the connection between filters

throw timing errors

cause a format negotiation failure

crash the graph

deliver corrupted frames

DirectShow expects steady, well-structured samples. A sudden change in media type or source breaks that expectation.

�� Why it behaves like a “high-speed spin-out”

When a DirectShow pipeline runs:

Upstream filters push samples

Downstream filters expect them to match the negotiated format

The graph manager manages timing and allocation

If you abruptly swap the image source:

You create:

media type mismatch (e.g., resolution, pixel format)

unexpected timestamp jumps

buffer length inconsistencies

allocator mismatches

null or invalid pointers

Any of those can “destabilize” the graph — similar to destabilizing a car at high speed.


ouch maybe we better leave lav splitter enabled when reaching certain files especially those Mediainfo agrees with

the dummy files lav splitter fails on trying to playback mpc-be splitter ignores them but this it keeps stable playbacking without crashing but it seems certainly not spec in some way and that MPC-BE crashes on something specific purpose designed is maybe better than playing stable half garbage


General
Complete name : E:\Games\Epic Games\BeyondTwoSoulsDemo\BigFile_PC_0401_BRA.dat
Format : MPEG Audio
File size : 62.8 MiB
Duration : 1 h 8 min
Overall bit rate mode : Constant
Overall bit rate : 128 kb/s
Writing library : LAME3.97
Conformance errors : 1
MPEG-Audio : Yes
General compliance : Bitstream synchronisation is lost (frame conf+39+77+115+122+?, time +?+?+?+?+?, offset ?+0x4FCD+0xCE2A+0x15E2B+0x1D38E+0x3ED4800)
FileExtension_Invalid : m1a mpa mpa1 mp1 m2a mpa2 mp2 mp3

Audio
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Duration : 1 h 8 min
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 1 channel
Sampling rate : 44.1 kHz
Frame rate : 38.281 FPS (1152 SPF)
Compression mode : Lossy
Stream size : 62.8 MiB (100%)
Writing library : LAME3.97

https://iili.io/fAvV8ba.th.jpg (https://freeimage.host/i/fAvV8ba)

without lav splitter as support it super fast crashes on many unexpected streams

but the major difference is really the dummy handling lav splitter takes all of them mpc-be ignores all of them and mediainfo doesn't understand the dummies either as anything usable to even try to playback

and mpc-be is fully right better don't open them

https://iili.io/fRfmcfs.th.jpg (https://freeimage.host/i/fRfmcfs)

[v0lt]

For translators.
Added the ability to translate text in File > Properties > Resources. You can see which strings were added in commit b629725 (https://github.com/Aleksoid1978/MPC-BE/commit/b62972559f7502ef0379888664c257b7f4b80f1b).

[s0meone_new]

Hungarian translation updated:
https://limewire.com/d/a8Elv#KjC3FcVWsI

[wushantao]

updated simplified chinese：）

https://files.catbox.moe/71nal9.7z
https://seyarabata.com/694a3729b61d5

[v0lt]

MPC Video Renderer 0.9.19.2490 (https://github.com/Aleksoid1978/VideoRenderer/releases/tag/0.9.19)
Improved HDR display mode activation.
The "Allow turn on/off (fullscreen)" option setting now works not only for exclusive full screen.
Cosmetic changes to renderer statistics.
Added tooltips for some settings.
The RTX Video HDR setting is only available for the x64 version.

PS: MPC Video Renderer 0.9.19 are included in the MPC-BE 1.8.8.103 installer.

[Grimsdyke]

I hadn't used the "auto-load external audio function from folder" for quite some time now so I am not sure but wasn't that working on Blu-Rays ??
Maybe it's broken ? It's working fine when loading manually to the blu-ray or with a video-file from local drives/nas, etc.

Best wishes

[BigBrahma]

Question regarding mouse keys, at the moment right click can only open the player menu. Are there any plans on adding the option to assign
other commands like say play/pause etc. to right click in the future?

[Aleksoid1978]

Question regarding mouse keys, at the moment right click can only open the player menu. Are there any plans on adding the option to assign
other commands like say play/pause etc. to right click in the future?

Not planned.

[v0lt]

MPC Script Source 0.2.15.235 (https://github.com/v0lt/ScriptSourceFilter/releases/tag/0.2.15)
Fixed a filter crash when AviSynth cannot deliver a video frame or audio data.
Other minor fixes.

PS: MPC Script Source 0.2.15 are included in the MPC-BE 1.8.8.103 installer.

[v0lt]

Release MPC-BE 1.8.9 (https://github.com/Aleksoid1978/MPC-BE/releases/tag/1.8.9)

Important changes:

Standard frequencies for display auto-switching have been expanded to 120 fps.
Added preview of embedded images in Properties > Resources.
Minor change to hotkeys.
Added retrieval of metadata from the "WM ASF Reader" filter.
Updated MPC Video Renderer 0.9.19.
Updated MPC Script Source 0.2.15.

MPC-BE Nightly builds (https://github.com/Aleksoid1978/MPC-BE/wiki/Nightly-builds)
Night builds are provided by volunteers.

Donate (https://mpc-be.org/forum/index.php?topic=240.0).

[huhn]

really not important:

i got freesync working by accident...
i had an old copy of mpc_hc that i renamed and today i got a bit farther... i resource hacked it to be not mpc-hc and freesync is kinda working now. it also has an old test build of mpcVR for freesync in there i was just testing nvidia smooth motion (pffff just right AI on stuff...).

if the frame times would be smooth the result would be fine.

i have smooth motion running on a 23p file and the present times are ~21 which sounds about right but dipping to 14ms and up to 26 ms making issues.

here is a screenshoot: https://i.ibb.co/Ps22yQGS/image.png


i can share my "hacked" mpc-hc version and the nvidia inspector settings if you want to waste more time on that.

[huhn]

real bug report.

this is about the frame time issue i'm talking about for like a year now.

i miss matches the refreshrate here 24p int video screen at 120/1.001

so audio video will run async and the video renderer has to repeat drop frames to stay in sync.

all of this is normal but not working correctly. but here comes the issue mpcVR starts to correct sync after reaching 4ms of desync which is half a vsync interval but it is now switching between the old sync and the new sync for the next 1-2 sec like 12 times it doesn't stay at one sync.

also the time should change by about 8 ms. if you drop or repeat a vsync a ~120 hz the is no other possible results but it is 4 ms.


i have a lossless video recording of this:
https://drive.google.com/file/d/1B_tHq9NCwG0v8j1ct0pjGJidNl-WVJuX/view?usp=sharing

it does a 4:6 pattern(literally the same as 24p played on a 60 hz screen) in stead of 5:5 with one drop/repeated vsync.


the one big skip in rtss and the blackscreen with it is just an artefact from going fullscreen and can be ignored.

the frame rate mismatch has been choicen because without it it can take up to hours and in most cases minutes and i have something better to do then record for that long and look at the screen.
this setup is still not rare.

[beter]

Update for translation of Chinese Traditional and Dutch:
https://mega.nz/file/uaQA2Bra#u81HxXQJBhYiiXQKU6AwP7o9tEqMc508a8Q3IYwlAUo

[v0lt]

real bug report.
1. Real (actual) bugs must be reproduced in the current release or a recent beta version.
2. Don't use the "Wait for V-Blank before Presentation" setting for high-refresh-rate displays. It's better to enable the "Adjust the frame presentation time" setting.

[huhn]

1. 0.9.19.2490 has 100% the same issue.
2. this breaks it pretty much entirely and it is doing 6:4 all the time. at least in the recording because the frametimes are bad. wait for vblank works perfectly as long as the frame rate is perfectly matched. or let me say it differently can work properly we still have the problem of windows here.

[clsid]

24.000 at 119.880 means each frame should be shown on avg 4.995 times. Or in ideal situation 199x5+1x4 each 200 frames.

Currently it presents frame half a sync duration in advance of the ideal display time. That is in your situation 4ms (and in practice that might be 3ms).
To get a 6:4 pattern it must mean that the present finishes processing just before/after the VSync moment. The ones that are a fraction too late will only get shown 4x, next one 6x.

Wait for VBlank should theoretically avoid that issue. But apparently presenting a few ms in advance is not soon enough?

But I think an improvement is possible for "Adjust the frame presentation time" in case "Wait for VBlank" is enabled as well.
Since it knows a VBlank just happened, renderer can calculate time of next one.
If display time of current frame is before next VBlank, it can present immediately, without sleeping for half a sync.
If it needs to wait for more than a sync interval, then it can sleep until a moment than equals a future Vblank + 1ms.

[clsid]

@huhn
Try if this experimental test build (https://www.sendspace.com/file/gsqzhd) gives any improvement.

[huhn]

for best result mpcVR should present a frame for every vsync.

so currently windows gets 24 frames and has to deal with that and as you can see it is really bad at doing so...

the one thing i do not understand is how can it go from -4 ms to 0 ms that is not possible it should be at ~+4 ms a vsync is over 8ms.

the big issue in the room here is even with matched frame rates it should have the same issue shouldn't it it? just takes between 40 mins to days to happen wouldn't it?

i will test that build now it will take a bit.

[huhn]

@huhn
Try if this experimental test build (https://www.sendspace.com/file/gsqzhd) gives any improvement.

it made it worse the interval is now halved but that's also a very good news what ever you did had an major effect.
https://ibb.co/xS59yPzv

[clsid]

Do you see an actual visual difference with all those graphs and overlays hidden?
How is it worse?

Also, be aware that you need to interpret all values and graphs correctly. If rtss hooks into the present call, then it measures the rate at which frames get presented which has slight variation compared to the constant refresh rate at which the frames end up being shown.

Presenting a few ms in advance does not mean it is out of sync.

[clsid]

This registry tweak can help with bad Windows 11 behavior in low framerate situations:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Dwm]
"OverlayMinFPS"=dword:00000000

[huhn]

Do you see an actual visual difference with all those graphs and overlays hidden?
How is it worse?

Also, be aware that you need to interpret all values and graphs correctly. If rtss hooks into the present call, then it measures the rate at which frames get presented which has slight variation compared to the constant refresh rate at which the frames end up being shown.

Presenting a few ms in advance does not mean it is out of sync.

it is visible frames are not shown with the correct cadancy. the rtss reported frames rates which are far to slow shown are still over +-5 ms difference which will result in a frame drop/repeate. maybe i can get an better rtss overlay show the frame times if it is over 8 ms there is no doubt. i can see the issue so...

madVR calculates a frame drop every 42 sec (audio sync seems to be pretty spot on with that refreshrate soundcard combo). with a vsync drop we should get a 4:5 cadancy every 8.4 sec and look at the old version it does it every ~9 but 6:4 for a while not just one frame.

the thing that is different brtween these version is that the time between hickups is the same but the hickup duration is much much longer and the is a break between 2 major hickups durations where the frame tiems are bad but not so bad they should eb visibility all the time.

BTW. i found this issue not by looking at graph but by looking at the image. they are for debugging.

This registry tweak can help with bad Windows 11 behavior in low framerate situations:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Dwm]
"OverlayMinFPS"=dword:00000000
already set.

[clsid]

Another test build (https://www.sendspace.com/file/xobn33)

This one does not wait for vblank when frametime is less than a sync interval in advance.
And when longer it does a loop of vblank waits instead of a sleep.

Edit: new build, which also increments failed counter when vblank takes longer than 1.5 times the vsync internal.

[huhn]

the fail counter never rises issue is unchanged the pattern looks like the live version.

windows DWM issues?
there are even 7;4 in the recordings i set rtss to 5 ms and not i know the frame timing are for example 46.7 35.6 47.6 41.8 41.5 35.6 47.7 35.9

there are 12 ms jumps the result can only be bad.

and just to be absolute clear we are not talking past each other missing a setting:
i test with "wait for vsync before vblank" and "adjust time the frame time presentation" in the past.

"wait for vsync before vblank" 24p source and 120hz refershrate is utter perfect BTW and then it falls totally apart:

"wait for vsync before vblank" can be disabled and the graph looks a bit better but the result ins bad.

newer test are now without "adjust time the frame time presentation"
this option results in longer hickups.

[hajj_3]

Is there a way to increase the font size of the status bar (including the height of the status bar) i.e the video timecode in the bottom right and the paused/play in the bottom left, i couldn't find an option?

Is there a way to disable the grey gradient of the controls bar and status bar to make them solid black or solid grey? The controls bar would look something like this:

https://i.ibb.co/NgZwF74B/mpc-be2.png

I changed the rounded corners for the [GPU] and play button in my modified screenshot as i think square corners look much better. It would be nice if there was a setting to make all corners square.

I also made the text white instead of grey which also looks better, not sure if there is a setting to do that already?

[kirakami]

Is it normal to see windowed in Display Stats even though i'm in Fullscreen? Shouldn't the windowed disappear from Display Stats once i'm in Fullscreen?

https://cdn.imgchest.com/files/31877dc6b212.jpg

[v0lt]

Is it normal to see windowed in Display Stats even though i'm in Fullscreen?
Normal.
https://learn.microsoft.com/en-us/windows/win32/direct3d9/windowed-vs-full-screen-mode

PS: IMHO, it's more correct to move the "windowed/exclusive" entry to the "Presentation" line, as it's not a display parameter.
But on the other hand, some display modes only work correctly in exclusive full screen mode.