View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
667 [madVR] bug crash random 2021-04-10 01:47 2021-04-10 18:56
Reporter: PhantomGamers Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-BE x64 1.5.6
Splitter (with version info): N/A?
Decoder (with version info): MPC Video Decoder
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: RTX 3090
GPU Driver Version: 465.89
Summary: Random Video Hanging with SVP + Avisynth Filter
Description: Hi, I've been working with the developer of Avisynth Filter on a recurring issue I've been having with videos hanging (video frame freezes, audio keeps playing).

The issue can be seen here: https://github.com/CrendKing/avisynth_filter/issues/41

I've been uploading dump files and the developer fixed some instances of hanging on their end but said the last dump I provided points to MadVR as the cause.

The dump file can be found here: https://mega.nz/file/RdhU3AiL#At4x6mW6E6Iokha_N-vv7_o58i5zXTk5HlEAHLBZKtY

If you have any questions or would like additional dumps let me know.
Tags:
Steps To Reproduce: Cannot be reliably reproduced.
Additional Information: I selected "Software" under the Decoding option but I'm not actually sure what MPC Video Decoder uses, I assume it's software but it may be something else.
Attached Files:
Notes
(0002796)
madshi   
2021-04-10 13:36   
When the problem occurs, can you please press Ctrl+Alt+Shift+Pause/Break, then wait a couple of seconds, then check if there's a "freeze report" on your desktop? If so, please post it here. Ideally, please try to get the debug symbols for the Avisynth Filter and copy them to the same folder where the Avisynth Filter's dll/ax files are located. That will help make the freeze report more useful.
(0002797)
PhantomGamers   
2021-04-10 16:22   
I will provide the freeze report when I hear back from CrendKing, the avisynth filter dev, about the debug symbols.

In the meantime I'd like to pass by this message he left on the issue over there:

"I managed to find a way to repro the hang you experienced. It is because unlike EVR, when being queried for media type change, madVR calls to source filter (most likely LAV Splitter) for its connection media type. This call tries to acquire LAV filter's lock, and consequently form a chain of dead lock.

Specifically,

Main thread: holds LAV m_csFilter, blocked on LAV m_csReceive
Streaming thread: holds LAV m_csReceive, blocked on avsf m_csReceive
avsf worker thread: holds avsf m_csReceive, blocked on LAV m_csFilter <- this is where the hang occurred

In contrast, EVR doesn't seem to make that call, thus no dead lock formed.

Now, I'm not saying this is a bug in madVR. They could do it for good reason. On my hand, I could change my logic to do output format change differently. It may take some time to try different approaches. So I might release a new version with this as a known issue."
(0002798)
madshi   
2021-04-10 18:56   
Seems he already figured it out. I'm not sure why madVR asks the source filter for its connection media type in that situation. There's probably a reason but I'd have to analyse my source code to find out.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
569 [madVR] bug major always 2018-07-31 23:08 2021-03-16 21:10
Reporter: shashank066 Platform:  
Assigned To: shashank066 OS:  
Priority: high OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.14
Media Player (with version info): PotPlayer 1.7.13622
Splitter (with version info): Built in Mp4
Decoder (with version info): HVC1 - OpenCodec(Nvidia Codec Decoder)
Decoding: CUDA
Deinterlacing: none (progressive)
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: 1080
GPU Driver Version: 389.12
Summary: Pink artifacts on 4k HDR video
Description: While playing "Sony Mont Blanc HDR UHD 4K Demo" with PotPlayer and MadVR, there are pink artifacts in the video. If the video is played with Windows 10 "Films and TV" software, no such artifacts are seen.
Tags:
Steps To Reproduce: 1. Download http://4kmedia.org/sony-mont-blanc-hdr-uhd-4k-demo/
2. Play with PotPlayer and MadVR
3. Pink artifacts can be seen
Additional Information: This was run on a computer with i9-8950HK, Nvidia 1080, 16GB Ram. I have tried various configs as well as defaults but the issue remains. Tried on internal laptop display as well as external monitor.
Attached Files: Untitled.png (4,003,973 bytes) 2018-07-31 23:10
https://bugs.madshi.net/file_download.php?file_id=293&type=bug
Notes
(0002325)
madshi   
2018-07-31 23:14   
(Last edited: 2018-07-31 23:15)
Can you try different decoders? E.g. try LAV Video Decoder. Both software decoding and DXVA.

(0002326)
shashank066   
2018-08-01 00:04   
Fixed after I reset PotPlayer settings to default and chose MadVR again. I didn't try reset PotPlayer before to avoid losing key bindings and other settings and thought PotPlayer might not be the issue.

The default settings for MadVR don't look as good as Windows "Films and Movies" player on a few 4k videos I am testing, but I will try other settings to figure that out. Thanks for the quick response.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
647 [madVR] bug major always 2020-06-26 19:29 2021-03-10 13:34
Reporter: B1gD4ddy Platform:  
Assigned To: madshi OS:  
Priority: immediate OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-BE.1.5.4.4969.x64
Splitter (with version info): -
Decoder (with version info): -
Decoding: <select>
Deinterlacing: <select>
DXVA2 Scaling Active: <select>
Aero / Desktop Composition: <select>
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: rtx 2080
GPU Driver Version: issue is with 45x.xx branch. last working is 446.14.
Summary: mpc be madvr hdr passthrough does not work anymore
Description: since nvidia changed the hdr code and/or hdr handling in 45x.xx driver branch madvr hdr passthrough does not work anymore.

instead of passthroughing hdr to the display madvr activates windows hdr and sends sdr to display.
Tags:
Steps To Reproduce: install 45x.xx.
install madvr.
activate hdr passthrough to display in madvr.
install mpc be and set madvr as renderer.
start a hdr mkv for example.
windows hdr will be activated and sdr movie will appear.
Additional Information: -
Attached Files:
Notes
(0002711)
B1gD4ddy   
2020-07-09 22:59   
problem is in new 451.67 whql still present.
(0002714)
Cineaste   
2020-07-19 12:19   
(Last edited: 2020-07-19 15:19)
It appears I am now at a point where I have to update the driver purely to keep on top of my games. madshi, do you know what they did to the API? Is it entirely new code?

(0002718)
zeus0r   
2020-07-27 15:32   
same problem here!

current "solution":

when activating win 10 desktop HDR madVR uses OS HDR instead of NV HDR and everything is fine. is there any way to tell madVR to always use OS HDR without enabling/disabling it all the time?
(0002719)
B1gD4ddy   
2020-07-27 16:10   
(Last edited: 2020-07-27 17:42)
ehm nope.

not same problem there since when you do it right like i described and like how everybody uses it currently madvr since 45x.xx always autoactivates os hdr instead of nv hdr and the movie is still washed out sdr.

what you call the solution and are asking for is the damn problem we have.

madvr hdr passthrough is build so nobody needs the disgusting os hdr and for auto activating/deactivating nv hdr at start/close of movie.

btw @ madshi: did you look into that? can you change something and make hdr passthrough work again with 45x.xx?

(0002720)
B1gD4ddy   
2020-07-27 18:02   
(Last edited: 2020-07-27 18:10)
this would be very nice because as we speak people research on dolby vision mkvs.

makemkv for example just added the new matroska 1.6.0 specs for storing dv metadata in mkv.

dolby vision mkvs already work when build with makemkv 1.15.2 and played back by a modified exoplayer apk in kodi!

having working madvr hdr and later on dolby viosion passthrough with 45x.xx+ would be gold.

please tell us the current status.

(0002721)
zeus0r   
2020-07-28 20:16   
ok sorry, that's weird B1gD4ddy.

i just tested it with the latest nvidia drivers (gtx1660 super):

win10 HDR enabled: madvr uses OS HDR & fullscreen windowed and everything works perfectly fine

win10 HDR disabled: madvr uses NV HDR & fullscreen exclusive and HDR is washed out although my display goes to HDR mode
(0002722)
B1gD4ddy   
2020-07-28 20:34   
(Last edited: 2020-07-28 20:36)
yes, when you manually activate win hdr and then start the movie everything works fine.

but when win hdr is turned off and you start the movie and let madvr turn on hdr on its own then it turns on win hdr automatically but movie is still washed out sdr.

but manually activating win hdr everytime before you start a movie is no solution, since we use the madvr hdr passthrough feature for the very reason that it automatically turns on nv hdr when you start the movie and it turns off nv hdr automatically when you close the player. win hdr had never to be touched. it always worked that way until nvidia released 45x.xx.

(0002724)
Cineaste   
2020-07-30 06:59   
Whilst we're waiting I have set up an AutoHotKey that toggles Windows HDR on/off by pressing a button. That button is mapped to a key on my remote so that all I have to do is use my Logitech Harmony (start Kodi > press button to toggle HDR > play movie > press button to automatically turn off HDR).

Not as convenient as madVR auto-switching but much better than manually having to fiddle with settings every time.
(0002725)
cccleaner   
2020-07-31 22:32   
can confirm this behavior too.

I hope madshi can find some time beside his big hardware project to keep the original source alive and properly working. please check this problem.

thank you so much.
(0002731)
cccleaner   
2020-08-15 17:40   
I was just trying to find out if other people have same issues in other forums and I am wondering why there are not more people noticing the same.

I thought MadVR is THE one and only filter out there to get the best HDR experience on a PC. MadVR is mentioned everywhere but nevertheless we have almost no reaction on this issue?

Is there a workaround? Or any config item I do not see?
(0002735)
B1gD4ddy   
2020-08-25 17:14   
madshi?????????????????????????????????
(0002736)
madshi   
2020-08-25 19:37   
This bug report is "assigned" which means I plan to work on it, when I find the time.

Please note that I've *always* recommended to users to stick to Windows 8.1, where you wouldn't have this problem. Also, you could go back to 44x.xx drivers where you also wouldn't have this problem. Also, you could complain to Nvidia for breaking what was once working. It's not a bug in madVR that this doesn't work, anymore. It's Nvidia's fault, they *intentionally* broke the API that madVR (and several games) have been using for years.

IMHO what Nvidia did was bad, not just because they broke a nicely working solution, but also because the new solution they implemented IMHO completely sucks. They got the OS involved, and I fear (although I'll have to double check to be 100% sure) that this will result in the HDR output not being lossless, any longer. With 44x.xx drivers and the old API madVR was able to achieve perfectly lossless output quality. Every bit output via HDMI was fully defined by madVR and not modified by Nvidia drivers or the OS behind madVR's back. I assume that with 45x.xx drivers this will no longer be the case. Which could potentially hurt image quality. But, as I said, I'll have to double check to be sure.
(0002737)
B1gD4ddy   
2020-08-25 20:42   
(Last edited: 2020-08-25 20:44)
thank you. would love to hear back from you.

the current workaround is to manually activate winhdr and then start the movie with mpc be madvr hdr passthrough.

do you think that is losless or not?

(0002738)
madshi   
2020-08-25 20:46   
Most likely not.
(0002739)
B1gD4ddy   
2020-08-25 20:48   
thats shit.
but dont want to annoy you any longer.
would just love to hear back from you in the future when you had time to analyze that more.
thank you!
(0002740)
Cineaste   
2020-08-26 06:32   
madshi, not wanting to add fuel to the fire but it appears Nvidia are playing the blame game:

https://old.reddit.com/r/nvidia/comments/ibfawg/game_ready_driver_45206_faqdiscussion/g1vmsuc/

According to their rep it is an app bug (yours?) and that a workaround will be provided with the next driver. Perhaps you don't need to do anything after all?
(0002741)
madshi   
2020-08-26 10:28   
Haha, sure, it's all my fault. :-D Not.

Nvidia did contact me, they said they changed the way their API works, but that it should still work fine in FSE mode. And I could make it work for windowed mode, as well, by calling some additional APIs.

So yes, I should be able to make it work, by adding more code. But it's a change in API behaviour that Nvidia requires me to do now which wasn't necessary before.

Plus, I was being told that everything should still work fine in FSE mode. Seems that's not the case?

Plus, I fear that the new solution may no longer be lossless, but I can't be 100% sure about that because I haven't tested it yet.
(0002742)
cccleaner   
2020-08-26 19:17   
hello Madshi

Thank you to react! Please understand, there is nothing else than a windows 10 pc as the main center of my multimedia rig anymore. I am directly depending on such problems like HDR Passthrough throuhg Nvidia GFX card to my 75" tv. .

I have no clue how to interact with nvidia in such matters but believe me I need full passthrough through windows 10 and nvidia GFX card with latest GFX Driver at all times..

how can I help you ?


Can we add some AI and Cloud computing to it and use agile mthodology (not) ?

:-)


Sorry.. sometimes I am tired of IT..
(0002743)
cccleaner   
2020-08-28 17:58   
I just tested the FSE Mode again but I have the same behavior. HDR Mode is not switched on automatically. I have Nvidia Driver 452.06 installed.

What my setup always does when I start a Movie, it switches to 23Hz. (TV turns black for 2 Secs in FSE and Normal Mode, and during that switch HDR was also turned on.
(0002744)
huhn   
2020-09-01 00:08   
what ever it is worth games don't really care about the driver version and HDR work with them.

the only game i tested that nearly for sure uses the nvidia API has some special needs to enter HDR mode.
it only uses FSE at all times and the image(windows desktop) get's totally disrupted when you tab or anything. so i wanted to test the only FSE mode from MPC-HC but that option has been removed for madVR.

i can later try a different game that may uses the nvidia API but that game doesn't even have finished HDR support...
(0002745)
B1gD4ddy   
2020-09-17 15:31   
(Last edited: 2020-09-17 15:37)
good and bad news guys.
nvidia stated in changelog of new driver 456.38 that they fixed the issue.

[madVR][MPC-HC]: Various HDR issues occur when using the madVR renderer with MPC-HC. [3038381]

but thats only halftrue, in fact they added more annoying things.

while it is true that when you now start a movie via mpc-be madvr hdr passthrough windows hdr indeed keeps being turned off, but hdr is still applied to the whole screen instead of only to the player.

that leads to the problem that as long as the player is windowed it shows washed out sdr. you have to make the player fullscreen so that you finally see hdr.

next very very annoying bugs that got added in this new driver are

1. when you touch the scroolbar of the player to jump through the video the video turns washed out sdr. you have to leave the scroolbar and put the cursor back on the video to make it hdr again.

2. whenever you window/fullscreen the player or resize the player the whole screen flickers atleast 2 times.

3. sometimes when closing the player the screen keeps being extremely brightend up.

tldr: bug: hdr is applied to hole screen instead of only the video player which makes the video washed out sdr until fullscreened + the 3 new problems i described.

(0002746)
madshi   
2020-09-17 15:36   
> but hdr is still applied to the whole screen instead of only to the player

But that was always this way in 44x.xx drivers (and older)! Or is it different now compared to 44x.xx drivers?

(the scrollbar and flickering things are new, of course)
(0002747)
B1gD4ddy   
2020-09-17 15:57   
(Last edited: 2020-09-17 16:04)
no, it was just perfect.

456.38

you start a movie and tv insta activates hdr and the complete screen is brightend up and player shows washed out sdr. you have to go fullscreen to see hdr. plus the problems 2 and 3

446.14

you start a movie and tv does not turn on hdr, everything is normal and fine and player shows sdr not washed out sdr. when you go fullscreen tv activates hdr and turns it off when you close player or go windowed.


btw i now also have the scrollbar problem with 446.14...odd, did my memory fool me or is it a windows 20h2 problem? i dont remember havin problem 1 ever.

(0002748)
madshi   
2020-09-17 16:03   
Ok, I'll have a look at 45x.xx some point "soon". Soon means could be weeks... :-(
(0002749)
Cineaste   
2020-09-17 16:20   
I suppose the above is a non-issue for me since I set up mpc-BE to always start in fullscreen as an external player in Kodi, meaning it used to activate HDR the moment I pressed play for as long as I remember.
(0002750)
B1gD4ddy   
2020-09-17 16:25   
(Last edited: 2020-09-17 16:41)
still problem 1 and 3 and maybe the flickering of 2

(0002751)
huhn   
2020-09-17 17:07   
i only have the "issue" of 3. that it takes a sec or longer to leave HDR mode when the player is closed.

i have a delay when switching between full screen and windowed but nothing major windowed HDR works totally fine here to even through the windows desktop is over saturated
(0002752)
B1gD4ddy   
2020-09-17 17:11   
(Last edited: 2020-09-17 17:15)
my 3 is that it stays ultra bright.

yes windows desktop is over saturated since hdr is applied to the whole screen, no matter if player is full screen or a little window, unfortunately

you have no hdr turnoff when using or hovering over scrollbar of player when in fullscreen hdr movie with 456.38?

and no screen flickering when resizing player with 456.38?

(0002753)
huhn   
2020-09-17 20:32   
no none of that but i'm using overlay rendering.
(0002754)
cccleaner   
2020-09-18 16:45   
indeed very special behavior:

(not using FSE:)

when I start a HDR movie my TV switches into HDR Mode although windows is not switched automatically to HDR mode (before windows always fully switches to HDR)

Desktop colors seem to be oversaturated little bit but this is because the frequency changes to 23Hz I thinks.

When I go fullscreen with MPC BE the HDR seems to be correct and when I move the cursor down the slider appears and the movie goes back to SDR washed out.

So it seems the player makes an isolated HDR pass through not touching the Windows setting and my TV recognizes the HDR Stream directly from the player. As soon as a windows overlay jumps in the setting does not apply anymore and uses the windows setting (no HDR Mode)

that is indeed very new.. For me it is till not clear how I should use HDR on a windows PC. Movies and Games should switch my TV to HDR when started like before?

Or can I always switch HDR Mode on?


I'd love to leave windows always in HDR mode but the OS seems still not to be designed to have a beautiful HDR Surface..

So what does the Windows HDR mode stand for anyhow?
(0002755)
B1gD4ddy   
2020-09-19 08:49   
(Last edited: 2020-09-19 10:13)
hey buddy,
did you read my last posts?

you experience the exact same 456.38 behavior as i do and don't forget the 2time flickering i described.

and i noticed when i go back to 446.14 i still have the touch-slider-hdr-gone-thing.
i don't remember having this when 446.14 was current. do you?
maybe a win 20h2 problem?!

(0002756)
ParadoxDelta   
2020-09-19 16:42   
(Last edited: 2020-09-19 16:42)
Not entirely shure if this is related: I got NV HDR working with MadVR 0.92.17 and driver 452.06 by right clicking the .exe of MPC-HC and PotPlayer -> Properties -> Compatibility -> and checking "Disable fullscreen optimization". Now the faded colors disappear when I enter exclusive fullscreen mode. Worked for both players.

(0002757)
B1gD4ddy   
2020-09-19 16:53   
(Last edited: 2020-09-19 16:55)
we already have nv hdr fullscreen working since win hdr is turned off and keeps being turned off when starting a movie with madvr hdr passthrough and 456.38.

that never was a problem.

but we have alllll the other problems i listed.

btw i started a thread in geforce forum, got insta 3 downvotes and got told im too dumb to use madvr...oh the humanity...deleted the thread in this cancer forum again.

maybe someone else wants to try.

(0002758)
cobravision   
2020-09-20 15:35   
I recall when using madvr for the first time around April 2019 that any change from fullscreen (windowed or activating OSD) would disable HDR passthrough and change the colors and switching out of HDR caused the screen to blink. There was some driver change that I can't pinpoint where HDR passed through at all times.
(0002759)
cccleaner   
2020-11-24 14:25   
Hi all

Sorry for late reply.
@B1gD4ddy: unfortunately I cannot remember when exactly the issue started. I did not check after all windows and updates carefully enough.
At the moment with 4Nvidia 457.30 and Windows 20H2 OS build 19042.630 everything seems to be working. Windows however does not switch to HDR Mode anymore and when I touch the slider the Player switches from HDR to SDR. So far I can live very well with this.

However please allow me to mention the following on my current odyssey to hit the perfect screen refresh rate of 23.976Hz for my mkv files, which in the end actually even confused me much more. I was not sure anymore about if the player is really sending 10bit HDR content to my Samsung 10bit Panel or not:

When I checked the Overlay Information of my player I noticed that my display is almost at 23.976Hz but only > (8bit, RGB, full)
Further in fullscreen the next output information was displaying D3D11 windowed fullscreen (8bit)

so all this confused me even more (madVR is REALLY doing a superb job regardless if you use HDR or the HDR simulation on SDR, the difference is not obvious) and I started to mess around with the settings again to head for REAL 10bit HDR output with following conclusion:

It is out of a sudden possible to switch Nvidia Driver to 23Hz AND 12bit(!) output color depth, while color format is RGB and output dynamic range is Full. And when the player switches to 23Hz the color depth remains at 12bit (!?) Is this new or was I just sleeping?
GREAT!

the D3D11 output in my app chain (MPC BE, LAV Filters, madVR) can obviously only be set to REAL 10bit output if I disable the ThumbNailPreview Service for Icons in the Windows Explorer View Setting. This Service is obviously producing a windows layer over the player that lets it stick to 8bit (and yes this holy crap I only figured out by using the thankful debug mode.)
GREAT!

So only now I am really sure that my setup outputs 10bit HDR content to the Samsung Panel.

My only issues for now is I have still some juddering when I activate the Smooth Motion in the Samsung Options. I still dont get it how I setup the perfect 23.976Hz. (tried CRU utility, Windows Custom Resolution)In fast motion pictures I have judders and blurs and small black and white detailed patterns are starting to flicker badly.

It is clear that the Smooth Motion Option has issues with this, but I think the root cause is based on this unbelievably complicated pull down between frames and frequency.

That mess is hopefully finally soon resolved with the new worldwide standardized and harmonized media presenting technologies ((I forgot the name of this new Master Film Studio Standard)

So to cut a long story short: for me its almost everything perfect, I believe I really get what my hardware is supposed to be delivering.

Looking forward to 4k120Hz, replacing again GFX Card, AV Receiver and TV ;-) and thanks again to madshis superb work.
(0002795)
B1gD4ddy   
2021-03-10 13:34   
with new nvidia drivers hdr passthrough works again.
also no hdr off for me when putting mouse on scroll bar.

but as madshi said the passthrough is not lossless anymore.
i hope he can do something about that.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
666 [madVR] bug major always 2021-03-02 01:52 2021-03-02 14:27
Reporter: SoilnRock Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: latest 0.92.17
Media Player (with version info): 1.9.8.137 (bf256c5f0)
Splitter (with version info): 0.74.1.92
Decoder (with version info): MinGW-w64 GCC 9.3.0
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: <select>
Aero / Desktop Composition: <select>
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: RX 560
GPU Driver Version: latest
Summary: mirroring (alt + Num6) not working
Description: (Horizontal) mirroring isn't working. Rotation and vertical mirroring are doing fine though.
Tags:
Steps To Reproduce:
Additional Information: MPC-HC (Nightly, 64-bit)
------------------------

Build information:
    Version: 1.9.8.137 (bf256c5f0)
    Compiler: MSVC v19.26.28806
    Build date: Jan 14 2021

LAV Filters:
    LAV Splitter: 0.74.1.92
    LAV Video: 0.74.1.92
    LAV Audio: 0.74.1.92
    FFmpeg compiler: MinGW-w64 GCC 9.3.0

Operating system:
    Name: Windows NT 10.0 (build 19042)
    Version: 10.0 (64-bit)

Hardware:
    CPU: AMD FX-8320E Eight-Core Processor
    GPU: Radeon RX 560 Series (driver version: 27.20.14535.3005)
Attached Files:
Notes
(0002792)
madshi   
2021-03-02 13:28   
Rotation is supported by madVR, mirroring is currently not supported. That's not a bug. You could say it's a missing feature. But honestly, I'm not sure what it would be good for? Rotation can make sense, in case you use a monitor in rotated view, or if someone recorded a video rotated, for some reason. But I don't see the purpose of mirroring, to be honest...

Anyway, it's very easy to do with a custom pixel shader.
(0002793)
SoilnRock   
2021-03-02 14:15   
Thx for your quick reply - why does vertical mirroring work though? :-)
(0002794)
madshi   
2021-03-02 14:27   
I've no idea, I don't think it's madVR's doing! :-O


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
662 [madVR] bug major always 2021-02-05 01:11 2021-02-15 11:21
Reporter: goraelec Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 1.9.8.148
Splitter (with version info): LAV 0.74.1.92-git
Decoder (with version info): LAV 0.74.1.92-git
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: <select>
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: Vega Frontier Edition
GPU Driver Version: 20.Q4
Summary: non-DXVA chroma upscaling produces severe banding
Description: I first noticed this while using the builds from https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector.2954506/page-486#post-60235595 . I started getting severe banding whenever I switched to one of those builds. I tried this again today with 123b and got the same banding. This is what I did to troubleshoot:
1. Called up debug menu with Ctrl+J on 123b and noted down what I saw there
2. Reverted to the latest stable build and did the same

The first difference I noticed was that the stable build showed `chroma > DXVA` while 123b showed `chroma > Jinc AR` which is what I actually set up in `chroma upscaling`. I reverted back to the latest stable build and unchecked `use DXVA for chroma upscaling...` in `trade quality for performance` options and reproduced the same banding I saw on 123b. So there are two issues here, I think:
1. non-DXVA chroma upscaling produces severe banding
2. builds 122-123b (these are the only ones I used) don't follow `use DXVA for chroma upscaling...` settings
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002785)
goraelec   
2021-02-05 01:12   
To add, I tried all possible options besides Jinc AR and got the same banding on all of them
(0002786)
madshi   
2021-02-08 18:57   
It's probably DXVA Native decoding which causes this (?). Have you tried DXVA Copyback or Software decoding?
(0002790)
goraelec   
2021-02-15 09:35   
I don't have any banding when DVXA is turned on, actually. Copyback doesn't make a difference
(0002791)
madshi   
2021-02-15 11:21   
Not sure what to say, nobody else has reported a similar issue. Maybe reverting to the madVR default settings helps, by double clicking the "restore default settings.bat" batch file?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
665 [madVR] bug major always 2021-02-14 05:42 2021-02-14 05:42
Reporter: Booty156 Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 113
Media Player (with version info): Latest with codec pack mega
Splitter (with version info): Latest with codec pack mega
Decoder (with version info): Latest with codec pack mega
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: yes
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: RTX 3080
GPU Driver Version: Latest
Summary: MadVR HDR API not as good as windows API
Description: Having issue with MadVR and HDR on my new display. HDR content in playing in madVR HDR is okay at best. Dark areas are really crap tho. Playing same movie in windows crappy player shows dark scenes much well. And brighter scenes are much more brighter vs madVR. Theres a bug to get windows API to run with MPC/madVR but only in windowed mode that really shows the difference.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
664 [madVR] bug minor always 2021-02-11 03:26 2021-02-11 03:50
Reporter: Venue Platform: Windows  
Assigned To: OS: Windows 10 Home 64-Bit 20H2  
Priority: normal OS Version: Build 19042.804  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.13, v0.92.14, v0.92.15, v0.92.16, v0.92.17
Media Player (with version info): MPC-HC (64-bit) Version 1.9.8 (6281da8a8)
Splitter (with version info): LAV Filters 0.74.1.75
Decoder (with version info): D3D11 (Direct3D® Version 9.14.10.01443)
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: Radeon Vega 3 Mobile GFX (Ryzen 3 3200U CPU)
GPU Driver Version: 2D Driver Version 8.1.1.1634
Summary: Unable to load arve curves.
Description: I'm unable to load a custom arve curve for tone mapping in madVR.


I understand that madVR's own tone mapping is better since it's dynamic, but figured I could try loading arve curves into madVR to see how they would perform in my projector.

Once I select 'arve custom curve' in 'tone mapping curve' an explorer window opens where it lets me select the .conf file, once selected/loaded by pressing 'Open', madVR instead selects 'BT.2390'.

If I select 'BT.2390' from the list, I cannot 'Apply' it, because it has already been applied by trying to load the custom arve curve.


Support for arve curves was implemented in v0.92.13, I've tried that build, and all builds up to the most recent build, no luck at all.

You cannot load arve curves with the latest HDR build installed/patched, so obviously those builds are not installed.


I've tried two different curves, one with 'eo' set to 'eotf_pq' and one set to 'eotf_gamma_2_4' but none seem to bite.

Can anyone of you replicate the issue?


I'm using Javs V3 curve, from AVSforum, specifically the '1200nitv3' curve which is 'eotf_pq', you'll find it below.

When attempting a 2.4 gamma curve, I converted the 'eotf_pq' curve to 'eotf_gamma_2_4'.

https://www.dropbox.com/s/xbwz9fyt62...%20v3.zip?dl=1


Thanks!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002787)
Venue   
2021-02-11 03:29   
I also posted this on Doom9 forums, copy/pasted the post, as you can see.
(0002788)
Venue   
2021-02-11 03:30   
D3D11 was not selectable in 'Decoding' in the submission form, so I chose 'Software'.
(0002789)
Venue   
2021-02-11 03:50   
I've also just recently tried to create a 2.4 gamma curve from scratch in the Arve tool, still no luck.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
659 [madVR] bug major always 2021-01-31 07:01 2021-02-03 09:14
Reporter: goraelec Platform: Windows  
Assigned To: OS: Windows 10  
Priority: high OS Version: 2004  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 1.9.8.109
Splitter (with version info): LAV Splitter 0.74.1.92-git
Decoder (with version info): LAV Decoder 0.74.1.92-git
Decoding: DXVA2 Copyback
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: AMD
GPU Model: Vega Frontier Edition
GPU Driver Version: 20.Q4
Summary: HDR Metadata is not sent when tone mapping with 3DLUT
Description: HDR settings contain an option "tone map HDR using external 3DLUT", which has 3DLUT selectors for 3 different color spaces and a separate section that says "send the following HDR metadata to display", which allows to specify a color space and target peak nits. Even with a valid 3DLUT and valid parameters for the metadata, no metadata is actually sent to the display and display doesn't switch to HDR mode.

When switched to "passthrough HDR to display", the display switches to HDR confirming that metadata is present.
Tags:
Steps To Reproduce: 1. Have an HDR display or another way to verify that metadata is passed to the display
2. Have a valid 3DLUT for HDR tonemapping
3. Set the 3DLUT in HDR settings
4. Fill in metadata and click apply
5. Enter full screen

The display won't switch to HDR mode
Additional Information: OS HDR is not engaged
Attached Files:
Notes
(0002774)
madshi   
2021-01-31 08:48   
Does this also occur using the latest HDR test build?

http://madshi.net/madVRhdrMeasure122.zip

Btw, using a 3DLUT for HDR tone mapping is no longer recommended because it results in static tone mapping, while the latest HDR test builds do very high quality dynamic tone mapping. You will need a reasonably fast GPU to use those new algorithms, though.
(0002775)
goraelec   
2021-01-31 17:55   
Yes, build 122 also has this issue. I'm using 3DLUT for HDR in order to correct some of its inaccuracies in the neutral axis. Is there any way to have dynamic tone mapping with 3DLUT in the future?
(0002776)
madshi   
2021-01-31 18:00   
You can let madVR do dynamic tone mapping and combine that with a BT.2020 or DCI-P3 SDR 3dlut. That should give you the best of both worlds.

Actually doing calibration while sending the display HDR is rather questionable because the 3DLUT cannot really know what the display's tone mapping algorithm will do. Unless it's so simple and stupid that it's predictable for the 3DLUT, but if it is, then it must be really bad.
(0002777)
goraelec   
2021-01-31 18:08   
It's simple and stupid in my case. It has FALD, and in each zone, it looks at the brightest pixel and sets the backlight brightness to that value, but it does not exceed the maximum content light level (at least, this is what I observe)
(0002778)
goraelec   
2021-02-01 00:46   
It would be great if there was a way to determine how tonemapping works on a display precisely using madTPG and measurement software like ArgyllCMS and find ways to correct for that
(0002779)
madshi   
2021-02-01 00:54   
That's a job for the calibration software, not for madTPG. madTPG simply renders whatever test pattern the calibration software asks for. How to actually make use of the measured data is the job of the calibration software.
(0002782)
omarank   
2021-02-02 18:28   
Interestingly, I too have been thinking about HDR dynamic tone mapping via 3DLUTs. I think I should describe my idea:

madVR's dynamic tone mapping has two attributes which are dynamic:

1. Dynamic max light and tone map target calculation: madVR dynamically calculates a rolling-average based max light for each frame/scene and also the dynamic target for tone mapping (if DTN is enabled)

2. Dynamic colorimetric processing: madVR dynamically adapts the tone mapping curve depending upon the max light and the dynamic target etc.

For dynamic 3DLUT tone mapping, madVR should just expose the settings/functionality for 1. Even in that, it should just provide the settings for determining the max light (i.e. the optimized maxCLL per frame/scene) and expose the max light as a profile variable. The user can then set up profiles to use different HDR 3DLUTs for different max light ranges. So, when an HDR video is played, madVR will switch between different 3DLUTs depending upon the max light value of the frame/scene.

Certainly, there may be brightness jumps in certain places (or maybe you can take care of them), but all in all it should be possible to have a good dynamic tone mapping experience with 3DLUTs taking care of tone mapping.

What do you think?
(0002783)
madshi   
2021-02-02 18:58   
This is a bug report. I don't think it's the right place to discuss potentially adding support for dynamic tone mapping with 3DLUTs.

Anyway. madVR adapts the tone mapping curve even within each scene, which would not be possible with a 3DLUT solution - unless madVR would load a number of 3DLUTs for different "maxCLL" values and then interpolate between them as needed. That would require a much smaller 3DLUT size, though, to make real-time interpolation reasonable. In any case, there's very very little interest from either madVR or Envy users for having tone mapping baked into the 3DLUT atm, so there's very little chance that I'll spend precious development resources on that, when so many other things are begging for attention.
(0002784)
omarank   
2021-02-03 09:14   
I understand that this may not be the right place to discuss this idea. So, I will not continue here. But I will just make some remarks. My comments are inline:

"madVR adapts the tone mapping curve even within each scene, which would not be possible with a 3DLUT solution - unless madVR would load a number of 3DLUTs for different "maxCLL" values and then interpolate between them as needed. That would require a much smaller 3DLUT size, though, to make real-time interpolation reasonable."

Yes, I understand that madVR adapts the tone mapping curve within scenes too. But that is the colorimetric aspect of madVR's implementation, which we are not concerned about for 3DLUT based tone mapping. A 3DLUT is always going to be a static tone map. I was referring to a very basic dynamic implementation, where on the basis of the range in which maxCLL lies, madVR gently switches between LUTs. And all that interpolation or any complex processing is not really needed. Nor we need a large number of LUTs. Typically, I and others (some projector owners who I provided HDR tone mapping+calibration LUTs) felt just the need for two 3DLUTs. One for very dark scenes and the other for all other scenes. Basically, people were quite satisfied with my LUTs except for one issue that the dark scenes were looking too dark. I believe with just 2 to 4 3DLUTs, the users can have a very good HDR experience with dynamic tone mapping.


"there's very very little interest from either madVR or Envy users for having tone mapping baked into the 3DLUT atm, so there's very little chance that I'll spend precious development resources on that, when so many other things are begging for attention."

Fair enough. Maybe I can bring this up again in future to hear your thoughts then. I will just share my perspective though:

madVR's HDR tone mapping is quite resource intensive. I am sure you will optimize it, but still it is going to be heavy. 3DLUT based tone mapping can provide flexibility to some users to allocate more resources to scaling algorithms or other processing algos or use less powerful GPUs while still getting a good dynamic tone mapping experience.

madVR already supports tone mapping HDR LUTs, so why not make that feature more useful?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
660 [madVR] bug minor always 2021-02-01 00:41 2021-02-01 00:55
Reporter: goraelec Platform: PC  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 2004  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): madTPG
Splitter (with version info): N/A
Decoder (with version info): N/A
Decoding: DXVA2 Copyback
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: Vega Frontier Edition
GPU Driver Version: 20.Q4
Summary: madTPG stops sending HDR metadata if user clicks away
Description: If HDR option is enabled, clicking away from madTPG window, even in full screen, causes it to stop sending HDR metadata. This is true for both overlay and exclusive modes
Tags:
Steps To Reproduce: 0. Have two monitors: interface and target
1. On target, launch madTPG
2. Enable HDR
3. Enter full screen
4. On the interface monitor, click anywhere

HDR metadata abruptly stops transmitting
Additional Information:
Attached Files:
Notes
(0002780)
madshi   
2021-02-01 00:55   
This is probably a limitation of the AMD driver, but I'm not 100% sure.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
661 [madVR] bug minor always 2021-02-01 00:45 2021-02-01 00:45
Reporter: goraelec Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: n/a
Media Player (with version info): n/a
Splitter (with version info): n/a
Decoder (with version info): n/a
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: Intel
GPU Model: n/a
GPU Driver Version: n/a
Summary: No HTTPS on madvr.com and bugs.madshi.net
Description: There's no https on madvr.com and bugs.madshi.net, which is not acceptable by modern web standards and should be easy to fix. Without HTTPS, any data between the client and the website is transmitted as plain text. This includes passwords and potentially other sensitive information, such as notes marked "private" on this website
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
657 [madVR] bug crash sometimes 2021-01-22 14:21 2021-01-29 14:24
Reporter: vindy Platform:  
Assigned To: OS:  
Priority: immediate OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): KMPlayer 2020.12.22.30
Splitter (with version info): LAV Splitter 0.74.1.64-git
Decoder (with version info): LAV Video & Audio 0.74.1.64-git
Decoding: CUDA
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GeForce GTX 950M
GPU Driver Version: 461.09
Summary: Random crash that cause video paused
Description: madVR reports :
- resetting Direct3D device failed (8876086c)
Tags:
Steps To Reproduce: Just play any video, wait for a moment, and the video will paused and showing the error report
(This is randomize, sometimes need to wait a longer, sometimes only a few minutes, sometimes a few seconds.)
Additional Information:
Attached Files: madVR - log fix.rar (2,170,814 bytes) 2021-01-22 14:21
https://bugs.madshi.net/file_download.php?file_id=332&type=bug
Notes
(0002771)
madshi   
2021-01-23 13:10   
No idea why this would happen. Seems most (all?) other users don't have this problem. You could try using different settings in "madVR\rendering\general". E.g. try enabling or disabling automatic fullscreen exclusive mode and/or use Direct3D11 for presentation.
(0002772)
vindy   
2021-01-29 14:24   
My mistake sorry, it happen because of overclocked GPU. After revert changes on clock and volt, it work normally. Thanks for helping


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
654 [madVR] bug minor always 2020-11-26 19:03 2020-11-26 19:10
Reporter: el Filou Platform: GeForce 1050 Ti / Core 2 E7400  
Assigned To: OS: Windows 10 Pro 64-bit  
Priority: normal OS Version: SAC 1909  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC x86 1.9.8, or MediaPortal 1.26
Splitter (with version info): LAV Splitter x86 0.74.1-90, or MediaPortal TS Reader 5.2.3.43
Decoder (with version info): LAV Video Decoder x86 0.74.1-90
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: NVidia
GPU Model: GeForce 1050 Ti
GPU Driver Version: 451.77
Summary: Picture freezes when switching video streams with D3D11 native
Description: When using D3D11 native decode, if the media being played has multiple video streams available, then switching between them during playback freezes the picture. You see two frames from the previously chosen video stream that flicker back and forth. The OSD correctly displays the information about the new video stream, and if you use a TV tuning app, you also hear the audio for the new channel and see the information in the OSD for the new channel video.
Pausing or seeking does not fix it and the only way is to stop playback.
Tags:
Steps To Reproduce: - Set LAV Video Decoder to D3D11 native
- Play media with multiple video streams, here is a sample: https://filehorst.de/d/dIheueFg (bonus from a Blu-ray). This also happens if you zap between different channels with a TV tuning app that supports madVR.
- Try switching video streams with the file playback, or change channel with the TV app
Additional Information: Also happens with:
- HDR test build v113, and earlier madVR versions since 0.92.0
- previous MediaPortal versions
- previous NVIDIA driver versions
- on a Radeon HD 7870 with identical software config, all driver versions
- previous Windows 10 versions

- Only happens with D3D11 native (not selectable in the bug report form)
- Happens with both progressive and interlaced media
- Happens with both MPEG2 and H.264 (did not test HEVC)
- Happens both if the new video stream is of different dimensions/framerate, and if it is exactly the same

- Does not happen with MPC Video Renderer with D3D11 native decode when using the same software config, so would indicate the problem is on madVR side and not LAV
System Description
Attached Files:
Notes
(0002760)
el Filou   
2020-11-26 19:10   
Issue seems to cause the same visual glitch as this other one: http://bugs.madshi.net/view.php?id=586


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
653 [madVR] bug major always 2020-11-24 23:27 2020-11-26 15:45
Reporter: Nooj Platform:  
Assigned To: madshi OS: Windows 10 x64  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: madVRhdrMeasure114
Media Player (with version info): MPC-BE 1.5.5 (build 5433)
Splitter (with version info): LAV Splitter 0.74.1
Decoder (with version info): LAV Audio Video 0.74.1
Decoding: DXVA2 Native
Deinterlacing: auto mode
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 1660 Super
GPU Driver Version: All
Summary: Source black level keyboard shortcuts
Description: source black level increase/decrease and source brightness increase/decrease no longer works with keyboard shortcuts
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
652 [madVR] bug minor always 2020-08-22 03:03 2020-08-22 20:53
Reporter: huhn Platform: x64  
Assigned To: OS: windows  
Priority: normal OS Version: 19041  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 92.17
Media Player (with version info): mpc-be
Splitter (with version info): mpc-be
Decoder (with version info): mpc-be
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: 1060
GPU Driver Version: 452.06
Summary: heavy chroma artifacts with p210 apple prores codec
Description: chroma is displayed wrongly with this file: https://drive.google.com/file/d/1FRBxetUKH1mIfZiF4aj6MTYPVdh_tfxn/view when mpc-be with internal filter is used.
other video renderer doesn't show this issue it only happen with this combination.
i talked with Volt about it which ended with madVR uses DXVA2 and DXVA2 can't do p210. mentioning that DXVA2 is optional in madVR doesn't seem to change this mind that DXVA is clearly not the issue here because it's not used.
but fair enough that madVR could be the issue here.
Tags:
Steps To Reproduce: use MPC-BE with default filter setting and madVR as the renderer. play the apple prores file.
Additional Information:
Attached Files:
Notes
(0002732)
madshi   
2020-08-22 08:54   
You probably mean deinterlacing artifacts, not chroma artifacts?

In any case, it seems that the DXVA deinterlacer used by madVR doesn't handle this file well. I'm not sure why, and I'm not sure why other video renderers don't have this problem. You can achieve the best quality (better than other video renderers) with this file by telling LAV Video Decoder to downconvert the video to NV12, and then by activating madVR's forced film mode. But of course it's very ugly to have to do this.
(0002733)
huhn   
2020-08-22 20:04   
well i mean this: https://abload.de/img/corruptionflj9s.png
when lavfilter is used deint is not very good but that's not different with EVR.

are you maybe doing a p210 to YUY2 to make it DXVA2 compatible?
beware that unlike lavfilter MPC-BE internal filter send crop information that madVR honour correctly but it looks like it is "double" applied to the chroma.
(0002734)
madshi   
2020-08-22 20:53   
Oh ok, I don't see that here, but I'm using MPC-HC with external LAV filters. This is probably caused by madVR not handling the crop information correctly, as you say.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
650 [madVR] bug crash always 2020-08-07 04:43 2020-08-10 05:34
Reporter: TBlazeWarriorT Platform: PC (GTX 750 1GB, i5 9400F, 16GB)  
Assigned To: OS: Windows  
Priority: normal OS Version: Windows 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version:
Media Player (with version info):
Splitter (with version info):
Decoder (with version info):
Decoding:
Deinterlacing:
DXVA2 Scaling Active:
Aero / Desktop Composition:
Problem occurs with mode:
GPU Manufacturer:
GPU Model:
GPU Driver Version:
Summary: 'ACESS VIOLATION' crash when "image upscaling = NGU sharp" and using SVP in fullscreen
Description: Error message: https://imgur.com/5xOxmqR
Happens when I turn this on: https://i.imgur.com/QKjBqNZ.png
FFMPEG tooltip info: https://imgur.com/Fo98flk

The playback always crashes, almost instantly when certain MadVR settings are on.
Seems to only happen when I have SVP on (SmoothVideoProject 4.0.0-6), I'm using MPC-HC 64-bit 1.9.6 and madVR 0.92.17.

This might be a SVP bug, but seems to be directly affected by madVR. I downloaded madVR and MPC-HC through the SVP mainteinance tool.

Seems related to http://bugs.madshi.net/view.php?id=527
Tags:
Steps To Reproduce: The bug seems to only happen if I meet all 3 of the following requirements:
- Have SVP on (performing frame rate conversion)
- Have MPC-HC on a big window so upscaling kicks in (for example, fullscreen a 720p video)
- Have "Image Upscaling" set to "NGU Sharp" in settings
- Might only happen on my CPU/GPU setup (but probably affects all/most setups), can't test.

Closing SVP, watching in windowed mode, or changing Image Upscaling to Jinc either greatly lowers the chance for the crash to happen (like from 99% per second to 1%) or fully stops it (didn't test for long periods of time).
Additional Information: Error message: https://imgur.com/5xOxmqR
Happens when I turn this on: https://i.imgur.com/QKjBqNZ.png
FFMPEG tooltip info: https://imgur.com/Fo98flk

I'm a basic user, I don't know what the decoding, splitter and decoder fields below are, I hope I typed the right thing but probably not. Don't know how to check.

RELATED TO: http://bugs.madshi.net/view.php?id=527
Attached Files:
Notes
(0002727)
TBlazeWarriorT   
2020-08-07 04:49   
The website duplicated my other issue ( http://bugs.madshi.net/view.php?id=651 ). I tried to upload a text file, it said it wasnt published because .txt was invalid and asked me to press back on my browser and change it. I made minor changes to this bug report and submitted again, but then realized the website published both for some reason.
(0002729)
madshi   
2020-08-07 08:48   
Your GPU has rather little RAM, maybe that's causing the issue? I'm not sure, just guessing. You could try lowering the size of the CPU Queue and GPU Queue settings in the madVR settings under "rendering -> general settings".
(0002730)
TBlazeWarriorT   
2020-08-10 05:34   
Nope, GPU Queue at minimum (4) and CPU Queue at 8 (half the default, cause my CPU is decent) and it still crashes if I set Chroma Upscaling and Image Upscaling to something complex/heavy (maxed out NGU).
This time, it became a slideshow for a few seconds (MPC almost crashing, displaying 1 frame per second) and then crashed with the same error.
Using Jinc on both still works fine


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
651 [madVR] bug crash always 2020-08-07 04:46 2020-08-07 07:57
Reporter: TBlazeWarriorT Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: Windows 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 64-bit 1.9.6
Splitter (with version info): ffvshow video decoder raw. Input: YV12 (uncompressed). Output: NV12
Decoder (with version info): ffvshow video decoder raw. Input: YV12 (uncompressed). Output: NV12
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: Gigabyte GTX 750, 1GB VRAM
GPU Driver Version: 451.67 (more info: https://hastebin.com/atakijavar.nginx )
Summary: 'ACESS VIOLATION' crash when "image upscaling = NGU sharp" and using SVP in fullscreen
Description: Error message: https://imgur.com/5xOxmqR
Happens when I turn this on: https://i.imgur.com/QKjBqNZ.png
FFMPEG tooltip info: https://imgur.com/Fo98flk

The playback always crashes, almost instantly when certain MadVR settings are on.
Seems to only happen when I have SVP on (SmoothVideoProject 4.0.0-6), I'm using MPC-HC 64-bit 1.9.6 and madVR 0.92.17.

This might be a SVP bug, but seems to be directly affected by madVR. I downloaded madVR and MPC-HC through the SVP mainteinance tool.

Seems related to http://bugs.madshi.net/view.php?id=527
Tags:
Steps To Reproduce: The bug seems to only happen if I meet all 3 of the following requirements:
- Have SVP on (performing frame rate conversion)
- Have MPC-HC on a big window so upscaling kicks in (for example, fullscreen a 720p video)
- Have "Image Upscaling" set to "NGU Sharp" in settings
- Might only happen on my CPU/GPU setup (but probably affects all/most setups), can't test.

Closing SVP, watching in windowed mode, or changing Image Upscaling to Jinc either greatly lowers the chance for the crash to happen (like from 99% per second to 1%) or fully stops it (didn't test for long periods of time).
Additional Information: Error message: https://imgur.com/5xOxmqR
Happens when I turn this on: https://i.imgur.com/QKjBqNZ.png
FFMPEG tooltip info: https://imgur.com/Fo98flk
Detailed NVidia Driver info: https://hastebin.com/atakijavar.nginx

I'm a basic user, I don't know what the decoding, splitter and decoder fields below are, I hope I typed the right thing but probably not. Don't know how to check.

RELATED TO: http://bugs.madshi.net/view.php?id=527
Attached Files: 5xOxmqR.png (2,247,559 bytes) 2020-08-07 04:46
https://bugs.madshi.net/file_download.php?file_id=331&type=bug
Notes
(0002726)
TBlazeWarriorT   
2020-08-07 04:48   
The website duplicated my other issue ( http://bugs.madshi.net/view.php?id=651 ). I tried to upload a text file, it said it wasnt published because .txt was invalid and asked me to press back on my browser and change it. I made minor changes to this bug report and submitted again, but then realized the website published both for some reason.
(0002728)
TBlazeWarriorT   
2020-08-07 07:57   
Upon further testing, seems like other upscaling modes can also cause crashes.

Maxed out quality NGU Sharp causes a very instant crash, but only if SVP is running. I can't reproduce the crash at 24/30 frames per second. Jinc causes very rare crashes.

Crash chance/time until crash does seem to be directly related to how complex the upscale method is, but is not limited to NGU. SVP also gave me some messages like "Could not access video player. Did you try running it as an admin?" yesterday but that did not fix it and did not happen today.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
644 [madVR] bug block always 2020-05-26 10:57 2020-07-22 14:15
Reporter: phbgjf Platform: PC  
Assigned To: OS: Windows  
Priority: high OS Version: 7 x64 SP1  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: madVR v0.92.17
Media Player (with version info): DisplayCAL 3.8.9.3
Splitter (with version info): none
Decoder (with version info): none
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 1070
GPU Driver Version: 441.66
Summary: Profiling has not been finished
Description: When profiling finished with madTPG in DisplayCAL a dialog with "Profiling has not been finished" and halts the process. It happens walway with 115 patches, and most of the time with 79 patches, taking hours to hit a succesful calibration process.
Tags:
Steps To Reproduce: Calibrate and profile with madTPG in DisplayCAL. Tested with a Spyder 3 and an i1 DisplayPro Plus
Additional Information: Not real solutions, all I could find on DisplayCAL forum:
https://hub.displaycal.net/forums/topic/aborted-profiling-has-not-been-finished/
https://hub.displaycal.net/forums/topic/profile-has-not-been-finished-madvr-3d-lut/
Attached Files:
Notes
(0002701)
madshi   
2020-05-27 18:49   
IIRC, the DisplayCAL dev made some improvements to help with issues like this, but it seems you're already using the latest DisplayCAL build, so I'm not sure what it could be. Are you using WLAN or wired LAN? Try wired LAN, maybe?

Might make sense to ask once more on the DisplayCAL forums? After all, the threads you linked to are both from 2018, which is quite some time ago.
(0002704)
phbgjf   
2020-05-28 12:36   
Now that you say that I am going to try with the firewall disabled. Not that I'm positive with that since I could get some calibrations with 79 patches. Florian is very intermittent and all I could read from him was to run as admin or reinstall madVR, which I already did -as admin- (it's a trivial thing).
(0002709)
phbgjf   
2020-06-19 10:49   
I tested with firewall disabled and had the same issue. And again only profiling with 79 patches finished successfully. Would like to run longer tests for more accuracy.
(0002710)
madshi   
2020-06-19 16:04   
Are you using the official madVR build? If so, maybe you can try this one, as a test (just overwrite the files)?

http://madshi.net/madVRhdrMeasure113.zip

I'm not sure if that will change anything, though, but might be worth trying, due to lack of better ideas right now. If DisplayCAL has a "madHcNet32/64.dll" in its directories somewhere, also please replace that with the latest build from the zip above.
(0002712)
phbgjf   
2020-07-16 12:30   
I tested yesterday and overwrote the folder, curious not to see madTPG there.

It failed again at 175 patches. I think it might have to do with network settings, I had issues connecting to my laptop in the past as a local network. But I just don't know what's required for madVR to communicate, open ports, remote access, and so on... Also I use tinywall firewall, in case that's a known issue.

On another note, I observed an issue on the calibration targets, they (or maybe only the blue one) is off compared to DisplayCAL Rec.709 targets so I can't use the same monitor hardware settings for both madVR and Windows. I will open a ticket if there's none open already.
(0002713)
phbgjf   
2020-07-16 16:15   
I was using a correction file so forget about the color targets thing.
(0002715)
phbgjf   
2020-07-20 16:25   
Ok, have been trying to calibrate my monitor for the last two days without success after about 10 attempts (testing different things).
I'm a little bit fed up so I went and created a madVR LUT out of my previous monitor calibration (large patch count). Is this ok or does madVR targets have something different than default?
(0002716)
madshi   
2020-07-22 00:17   
Sorry for the lack of replies. I'm currently extremely busy. Some weeks from now I might look into the whole topic of calibration once more. Right now, there's not too much I can say. Whether or not you can convert your previous monitor calibration into a madVR LUT with DisplayCAL is not something I know. Might make more sense to ask that question in the DisplayCAL forum.
(0002717)
phbgjf   
2020-07-22 14:15   
No prob. I asked already there. Will report back if doing so is an option (as a workaround at least).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
648 [madVR] bug crash always 2020-07-14 01:54 2020-07-14 01:54
Reporter: kathampy Platform:  
Assigned To: OS: Windows 10  
Priority: high OS Version: 2004 (19041.329)  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-BE x64 1.5.5.5274
Splitter (with version info): LAV 0.74.1
Decoder (with version info): LAV 0.74.1
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: NVidia
GPU Model: RTX 2080 Ti
GPU Driver Version: 451.67
Summary: display modes - freeze & crash when media player goes fullscreen
Description: I've configured "switch to matching display mode ... when media player goes fullscreen" and "restore original display mode ... when media player leaves fullscreen". I use fullscreen windowed mode and not exclusive mode.

When switching to fullscreen, the refresh rate changes as expected, but most of the time the video freezes while audio continues to play. If I leave the video frozen, eventually the audio will slow down and stutter.

I can leave fullscreen mode, but the refresh rate doesn't change back. If I terminate the media player, sometimes the refresh rate changes back.

The problem does not occur if I configure "switch to matching display mode ... when playback starts".

The problem does not usually occur when using the MPC-BE's built-in fullscreen resolution change. This also freezes once in a while, but usually only when leaving fullscreen mode.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
593 [madVR] bug major always 2019-01-14 23:02 2020-06-16 12:21
Reporter: tp4tissue Platform: AMD  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 1809  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 09217,09214
Media Player (with version info): MPCHC, last released
Splitter (with version info): Lav 0.73.1
Decoder (with version info): Lav 0.73.1
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: RX 580
GPU Driver Version: 18.50.11.01
Summary: Madtpg will not kick into HDR mode
Description: Trying to use displaycal.

When engaging Madtpg, the HDR button is press-able, however the display will not kick into HDR mode, EVEN if the entire displaycal process launches with (madtpg) in fullscreen mode.

Normal mpchc+madvr playback operation will kick TV into HDR mode when engaged to fullscreen.

Dispcal HDR process works with my nvidia setups.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002473)
tp4tissue   
2019-01-16 14:46   
Just to clarify, It is my AMD rx580 setup during MadTPG-fullscreen which will not pop into HDR during displaycal calibration.
(0002490)
sat4all   
2019-02-11 09:53   
I have the same issue with gtx1060 and 481.18 nv driver, switching between FSE and Windowed mode doesn't help while madVR playback switch to HDR normaly either FSE or windowed.

Regards
(0002496)
FiSHxFiSH   
2019-03-03 16:02   
same issue with gtx1060,419.17 nv driver,potplayer1.7.17508,madVR 0.92.17,madVR playback can't switch to HDR.
OSD said it's NVHDR mode, but my monitor OSD said it's still SDR.
HDR from OS works but looks ugly as usual
(0002497)
sat4all   
2019-03-04 10:16   
reverting back to 398.11, fixed my problems.
Anyway you don't wanna use newer drivers because of the wrong HDR metadata.
(0002708)
rxp   
2020-06-16 12:21   
Getting the same issue on the latest Nvidia drivers. HDR kicks in fine with MPC-BE on playback of any HDR file - but Madtpg will refuse to kick into HDR.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
646 [madVR] bug minor always 2020-06-13 19:01 2020-06-13 19:01
Reporter: onur Platform: 32/64  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.17
Media Player (with version info): MPC-BE.1.5.4.4850.x86
Splitter (with version info): LAV 0.74
Decoder (with version info): LAV 0.74
Decoding: DXVA2 Copyback
Deinterlacing: none (progressive)
DXVA2 Scaling Active: yes
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: AMD + Intel
GPU Model: Intel UHD 620
GPU Driver Version: 26.20.100.7463
Summary: "Move subtitles" not working correct if "Crop black bars" is selected
Description: Filter: XySubFilter
Subtitles are in croped area when "Crop black bars" is selected.
when deselect "Crop black bars" subtitles are in active(not in black bar) video area.
Tags:
Steps To Reproduce: setup player to use XySubFilter

setup madvr:
move subtitles: ...into active video area
automatoc detect hard coded black bars
Crop black bars

load video with black bars and subtitles.
now the subtitles are croped
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
645 [madVR] bug minor sometimes 2020-06-07 13:40 2020-06-07 13:40
Reporter: misterix Platform: Intel  
Assigned To: OS: Windows  
Priority: normal OS Version: 7  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17.0
Media Player (with version info): MPC HC 1.9.4.1
Splitter (with version info): LAV 7.41.3.4.-git
Decoder (with version info): LAV 7.41.3.4.-git
Decoding: DXVA2 Copyback
Deinterlacing: auto mode
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 670
GPU Driver Version: 9.18.13.4788
Summary: MPC-HC x64 crashes MADVR64 fault after closing a movie file
Description: After I watch a movie on Media Player Classic and close it I get a crash. This is annoying because if I want to go back to the spot I left off it won't work.
Tags:
Steps To Reproduce: Open a movie file with MPC, close it.
Additional Information: Problem signature:
  Problem Event Name: APPCRASH
  Application Name: mpc-hc64.exe
  Application Version: 1.9.4.1
  Application Timestamp: 5eda7415
  Fault Module Name: madVR64.ax
  Fault Module Version: 0.92.17.0
  Fault Module Timestamp: 5baf57ff
  Exception Code: c000041d
  Exception Offset: 000000000001d001
  OS Version: 6.1.7601.2.1.0.256.48
  Locale ID: 1033
  Additional Information 1: 7de2
  Additional Information 2: 7de2dc044f6f9d38324e11567c940b1e
  Additional Information 3: 3ba3
  Additional Information 4: 3ba36b358f0e09f763b10194b08fb25d
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
638 [madVR] bug minor always 2020-02-19 12:43 2020-05-29 05:36
Reporter: zeus0r Platform: PC  
Assigned To: OS: Win 10  
Priority: normal OS Version: latest  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.17
Media Player (with version info): MPC-HC
Splitter (with version info): 1.7.13 (64-bit)
Decoder (with version info): LAV Filters 0.74.1
Decoding: DXVA2 Copyback
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: NVidia
GPU Model: Geforce GTX 980
GPU Driver Version: 442.19 - WHQL (latest)
Summary: wrong black levels SDR/HDR
Description: i'm not 100% sure but i think it started with the latest nvidia driver update. i've been using this setup for quite some time without any problems but i recently noticed wrong black levels for HDR content while SDR content is fine. (madvr hdr passthrough enabled)

rgb full range (0-255) is enabled in madvr settings and it currently gives me correct black levels for SDR content but i need to change it to 16-235 in order to get correct black levels for HDR content. (otherwise blacks are grey)

i checked this with some black level test files where 0-16 should be black and 17-25 flash.

0-255: correct SDR black levels but greyish blacks for HDR content
16-235: correct HDR black levels but bad black crush for SDR content

could this be a nvidia bug? or is there someting i am missing here? would it be possible to add another black level setting for HDR content so i don't need to switch?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002667)
madshi   
2020-02-20 17:10   
Have you forced the Nvidia GPU to RGB Full Range output? That's the recommended configuration.
(0002673)
zeus0r   
2020-02-21 11:22   
okay, now i'm even more confused.

i'm pretty sure i actually chose "RGB/full range/12 bit" in nvidia settings but when i just checked "YCbCr/limited/8 bit" was active. and even weirder: i can't change it to RGB, it's just not there.

so i changed the resolution to 1080p/60 (2160p/60 before) and then i can pick RGB/full/12bit. so i checked black levels again but the problem was still there:

0-255: correct SDR black levels but greyish blacks for HDR content
16-235: correct HDR black levels but bad black crush for SDR content

then i tried pretty much every combination possible and with RGB/limited/12bit: correct black levels for SDR and HDR.

wtf?! why can't i choose RGB with 2160p anymore? and why is limited the correct choice now when it was full range before?!
(0002674)
madshi   
2020-02-21 13:09   
Not being able to choose RGB for 2160p60 means that whatever device your HTPC is connected to (display or AVR or whatever) seems to report that this device's HDMI port doesn't have enough bandwidth for 2160p60 RGB. The HDMI input port of the display/AVR needs to be 18Gbps for that to work. Seemingly it's only being reported as 10Gbps instead.

I don't know why RGB Full doesn't work for you. It works for most other users, including myself. Not sure how to fix it. It's probably some sort of Nvidia driver issue. Try reinstalling the Nvidia drivers in "cleanup" mode, maybe?
(0002675)
zeus0r   
2020-02-21 13:40   
okay, interesting. i'll try that, thank you!
(0002676)
huhn   
2020-02-21 15:51   
there are more than one report of user needing or getting different level between HDR and SDR in the past days.

if listed they where Phillips Tvs.
(0002702)
Deam   
2020-05-28 04:49   
(Last edited: 2020-05-28 04:50)
I would just add to this, and it may very well be an Nvidia bug. I am using MadVR with Kodi DS player (for HDR passthrough). Win 10, GTX 1050ti, Vizio P659-G1 Tried latest drivers and reverted to older ones.

Specifically, if I leave it as a "full" color space path (i.e. MadVR, Kodi DS Player, Nvidia CP and TV), SDR works fine, as confirmed with test clips for black level clipping. However, once I try HDR, the black levels get blown out (such that the entire black level clipping video turns grey and I can see all the bars whether or not they are flashing).

If I then set the TV to limited range (or set Nvidia control panel to limited and leave TV to auto), HDR works. However, unlike the issue noted, my SDR is also displayed correctly verified with clipping test videos.

I'm just noting this here, as it may not necessarily be a MadVR issue as this issue occurs for me when using other Kodi HDR forks that rely on Windows HDR API and not MadVR. I am forced to have the GPU set to limited as I use the PC for other purposes and thus can't have the color clipping using the other options.

(0002703)
madshi   
2020-05-28 11:09   
If you can, it's always a good idea to force your display to treat the HTPC input as having specific levels instead of using "Auto", for the simple reason that the HTPC doesn't always inform the display about the correct levels. Nvidia sometimes reports the levels to the display which you set in the Nvidia GPU control panel, and sometimes Nvidia doesn't report any levels at all, so the display has to guess.

However, if you're talking about HDR passthrough using Nvidia's private API (= *not* turning the OS HDR mode on), then I think it's more likely that Kodi might be doing something wrong, like e.g. rendering TV levels although Kodi is set to PC levels. But I can't say for sure. Just guessing here. My personal experience with madVR is that HDR passthrough works fine and doesn't screw up levels, but maybe it depends on the circumstances, driver version or whatever.
(0002705)
Deam   
2020-05-28 17:46   
Thank you, Madshi. Yes, I have just set the TV to accept YCBCR (limited range) for the time being - the issue being this combination of factors requires the less optimal setting of the GPU doing a color space conversion.
 
It's a Vizio television, and you are correct, it could be a Kodi/DS Player issue, or possibly an issue with the TV receiving a full range signal with HDR metadata. I've read it can be "resolved" by lowering the brightness from 50 to 32 (though I also understand you shouldn't really fiddle with the brightness slider in HDR mode as this doesn't so what it normally does).

I have a ps4 pro and may test forcing it to use rgb full range and engaging hdr to see what happens with the tv. I’ll have to wait until evening as it’s too bright to really see anything.

Thanks for the feedback (and recognize this may not be a Madvr bug at all, so am appreciative of that)
(0002706)
madshi   
2020-05-28 23:24   
FWIW, HTPCs are inherently bad at outputting YCbCr. Usually it's recommended to set the GPU control panel to RGB with PC levels.
(0002707)
Deam   
2020-05-29 05:25   
(Last edited: 2020-05-29 05:36)
It appears for this combination of equipment that I am using I won't have a choice. For posterity (as this is nothing to do with MadVR), I tested the combination with the PS4 Pro running in HDR. I set it to RGB/Full. However, it sends HDR in YCBCR regardless of that setting (so limited color space). This was confirmed by checking the receiver signal, which shows Bt2020 YCBCR vs. BT2020 RGB that the PC sends if left in RGB full. And setting the TV's color space to auto worked as expected. I'm not sure if keeping it at least in RGB format going into the TV, albeit at limited range, is better or worse than having the GPU convert to YCBCR as you've noted.

I'm left to conclude that it may be something with the TV, or the receiver and TV, in which an HDR signal being sent through RGB (full) causes problems requiring a change in the brightness setting in the HDR picture mode. This wouldn't necessarily be a problem, except given the receiver there is only one input being used in the TV and so it would required changing the picture mode/settings going between the PS4 Pro and the PC.

One solution I will look at is whether I can change, in Nvidia Control Panel, the color range for different resolutions, such that when it switches to 23hz it goes to limited RGB, but reverts to RGB full at 60hz.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
643 [madVR] bug minor always 2020-05-08 17:41 2020-05-08 18:47
Reporter: CompEx Platform: Intel NUC8  
Assigned To: OS: Win  
Priority: low OS Version: 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): JRiver 24
Splitter (with version info): Standard
Decoder (with version info): Standard
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: Intel
GPU Model: Iris Plus 655
GPU Driver Version: November 2019
Summary: AR not shown in Info when selected with SoftCubic
Description: When selecting SoftCubic50 with AR enabled for Chroma- und Image-Upscaling, Info-Screen (ctrl+j) shows "Softcubic50"; it should show "SocftCubic50 AR".

Info Screen is correct with AR and Cubic75, Lanczos4, Jinc...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002698)
madshi   
2020-05-08 18:29   
That's not a bug. AR is not useful for SoftCubic, it would only harm image quality, that's why madVR "refuses" to activate AR when using SoftCubic.
(0002699)
CompEx   
2020-05-08 18:34   
Hm, maybe madvr shouldn't offer the ar-option with softcubic, so there won't be any confusion.
(0002700)
madshi   
2020-05-08 18:47   
Maybe. But there are more important things than that... :-)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
627 [madVR] bug crash always 2019-11-29 19:56 2020-05-05 19:11
Reporter: tomeq82 Platform: Windows 10  
Assigned To: OS: 1903  
Priority: normal OS Version: 18362.476  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 1.8.8.22
Splitter (with version info): LAV Splitter 0.74.1.30 (MPC-HC bulit in)
Decoder (with version info): LAV Video Decoder 0.74.1.30 (MPC-HC bulit in)
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: NVidia
GPU Model: 1050 Ti
GPU Driver Version: 436.02
Summary: after entering fullscreen exclusive playback stops/pauses and can't resume
Description: This issue is more or less prevailing in each madVR version I have ever tried.
I'm using MPC-HC since ever, the issue exist in latest versions of both.

Whenever I set automatic screenmode change and fullscreen exclusive with mode change on playback start (or player start, it doesn't really matter) playback stops and i'm unable to resume it. Play and pause buttons are inactive. MPC-HC seems to hang. I'm switching to 2160p resolutions with corresponding refresh rates. All is defined in madVR settings. I have set delay in exclusive screenmode to 3 seconds as my TV is taking long time to switch modes of operation.

Issue doesn't exist when I first switch to desired screen mode manually then start playback.
Tags:
Steps To Reproduce: 1. use MPC-HC for playback with madVR used
2. set madVR to change screenmode to allign with video
3. launch playback
4. screenmode will change but playback will stop on very first frame (or few frames further) and never resumes and i'm unable to resume
Additional Information:
Attached Files: madvr_1.png (174,505 bytes) 2019-11-29 20:00
https://bugs.madshi.net/file_download.php?file_id=322&type=bug
madvr_2.png (166,674 bytes) 2019-11-29 20:00
https://bugs.madshi.net/file_download.php?file_id=323&type=bug
madvr_3.png (158,669 bytes) 2019-11-29 20:01
https://bugs.madshi.net/file_download.php?file_id=324&type=bug
madvr_4.png (204,180 bytes) 2019-11-29 20:01
https://bugs.madshi.net/file_download.php?file_id=325&type=bug
madVR_debug_1-FSE.txt.zip (160,368 bytes) 2019-12-02 15:17
https://bugs.madshi.net/file_download.php?file_id=326&type=bug
madVR_debug_2-FSE_disabled_delay.zip (2,395,965 bytes) 2019-12-02 18:54
https://bugs.madshi.net/file_download.php?file_id=327&type=bug
Notes
(0002583)
tomeq82   
2019-11-29 20:18   
If there is need for more debugging, reproduction scenarios etc. i'm ready - quite power user so nothing really scares me much ;-)
(0002584)
tomeq82   
2019-12-01 17:16   
I have performed some debugging myself and the problem seems to be in the way the madVR is trying to do exclusive fullscreen mode, switch to fullscreen or some sort of interop between MPC-HC:
- when I set the player to start playback in fullscreen mode+switch screnmode when playback starts, the video starts playback, but after "initialization" it drops back to window + desktop. This causes 3 times switching the resolution: from desktop resolution 4k 60hz, to 4k 24hz, then back do desktop and if I want full screen I need to AGAIN push MPC-HC to fullscreen. My TV is switching the resolution for 3-5 seconds (Panasonic TX-50CX700E) so this is extra annoying.
- setting MPC-HC to not go to fullscreen+set madVR to switch screenmode when playback starts, ofcourse removes one mode switch, but still screen blinks during madVR init and additional action is needed from me (go fullscreen after playback start) - this is safest setting
- setting madVR to switch to matching display mode when media player goes fullscreen + set MPC-HC to go fullscreen after playback starts causes drop to desktop from fullscreen, mode swtiching many times and usually "forever pause" or black window, no video,just audio. This is worst setting to have in my scenario.
- when I set "delay playback start until render queue is full" mostly 100% of video launches with mode switching ends in "forever pause" mode. No matter what other settings are set to.
- when I set "delay switch to exclusive mode by 3 seconds" it ends in audio only video, black screen or current frame stand still. Same as above it kills playback.

I must say it is a mess. I never managed to have stable solution for this and dropped using madVR in my htpc setup.
(0002585)
madshi   
2019-12-01 17:19   
Have you tried using windowed mode instead of FSE? In Windows 10 fullscreen windows mode is not so bad.
(0002586)
tomeq82   
2019-12-01 18:16   
I tried - the effect is less painful indeed but MPC-HC never enters fullscreen automatically in that mode. Despite the setting explictly set to start playback in fullscreen, It ends in a window on desktop, I need to manually go fullscreen (doubleclick, alt+enter whatever) None of the madVR settings in windowed mode caused MPC-HC to go fullscreen automatically.
(0002587)
madshi   
2019-12-01 18:21   
That's weird, that seems to work for me. I also don't have the FSE problem you're reporting. Sadly, HTPCs are a mess and every user has different issues.
(0002588)
tomeq82   
2019-12-01 18:52   
Hm, I meant "htpc" is a normal computer for home entertrainment, nothing sophisticated :) nVidia 1050Ti, Pentium G4500 Gold and B360 chipset based board. All standard. The only thing I didn't change since I had those issues is the TV and AVR receiver. Reinstalled windows number of times, I tried with 1030 card and Intel GPU with DP-> HDMI active converter (which caused separate set of problems with 4K output). What puzzles me much is why the player skips out to windowed mode no matter what. It looks like it times out waiting for TV to change display mode and skips out to "safe" mode which is desktop? Is it possible at all?
(0002589)
madshi   
2019-12-01 18:55   
The PC doesn't know or care when the TV switches. That information isn't sent through HDMI.
(0002590)
huhn   
2019-12-02 00:43   
i had this problem too.
with pretty much the same TV TX55CXW704. pretty sure it had nothing todo with it but just saying.

there are 2 different "types" of FSE on windows now.
the normal one that allows overlays from the notification centre, game DVR, geforce experience and so much more. which could be the issue.

sou you could try getting rid of these for a test.

use with cautious:
then we have the original FSE which can be accessed by right clicking the mpc-hc64.exe -> properties -> compatibility -> disable fullscreen optimisation.
(0002591)
tomeq82   
2019-12-02 08:33   
Will do some tries with FSE and disabling all overlays (I think I did but I will check again), but let's say I will stick to windowed mode - as it seems switching screen modes is the real issue here.

When video is launched via mpc-hc -> open file, it willl never get to fullscreen, it will stay on desktop I need to make it fullscreen manually, but here we will have 100% of success in playback, it will switch screenmode, etc.

When I open video via "open with" or doubleclick video icon it will go fullscreen (i see fullscreen logo of mpc-hc for a while), change screen mode and most probably:
- drop from fullscreen to mpc-hc window, but video can be played then (it will normally run)
- stay fullscreen (yay! finally!) but will not start playing automatically (why?) and here another problem branching: will end on audio only or forever pause. SOMETIMES it will just play correctly. I tried maaaaany different videos to find any common denominator, which video plays normally, which don't. I'm unable to.

Ofcourse none of the issues are here when the screenmode is already set or I don't use screenmode change feature in madVR.
(0002592)
madshi   
2019-12-02 09:54   
> disable fullscreen optimisation

I didn't even know that one!
(0002593)
tomeq82   
2019-12-02 14:27   
checked - no overlays, nvidia or Windows Game Overlay enabled. Disabled full screen optimization for mpc-hc64.exe. Same story. No change. Just to be sure, checked with FSE and windowed fullscreen. No change in behavior.

Expected behavior is:
- MPC-HC has option "start playing in fullscreen enabled"
- despite the option in madvr is set: FSE or windowed fullscreen I got video played on fullscreen :) no matter if "doublecliked" video icon, used "open with" from right click menu or "open file" in MPC.

This is something I can't achieve....
(0002594)
tomeq82   
2019-12-02 15:18   
(Last edited: 2019-12-02 18:55)
attached debug with FSE enabled, 4K HDR file opened from right click, open with. Screenmode changed, then black screen. Didn't even started and ctrl+j not able to open....

second log is with disabled delay playback until render queue is full. It gets further though not without a problems. Audio is on, video is "one frame" and debug memu pops-up.

(0002600)
kristoffer   
2019-12-16 19:36   
I just wanna chime in and say I think I have the same issue.
Just built a new pc primarily for use with mpc-hc and madVR, and have been sorting through issues for two days now.

Although my issue doesn't seem to occur all of the time, more like in cycles. Last night it worked well, today i'm having issues 80-90% of the time.

I'm using the same software, and also have an nVida gpu (2070rtx).
(0002601)
tomeq82   
2019-12-16 20:27   
@kristoffer, you say "cycles" I would say bugless playing depends on if I do fresh restart of the pc or if the pc is working for a while and display is being switched to pc. Those two scenarios differ, it fail when I switch my audio receiver to pc and try to play video.
(0002602)
kristoffer   
2019-12-16 22:32   
That resembles my experience. last night for whatever reason I rebooted my pc, and it was working fine afterwards. Don't recall why I rebooted, could be when I tried to re-install mpc-hc and madVR. Today it didnt work.

Anyways, I've settled with your workaround for the time being, opening my movies in windowed mode before I go fullscreen.

If I can help with anything to figure out this bug just ask. Just tell me how and i'll provide logs and try stuff.
(0002690)
Daniel715   
2020-04-23 17:26   
(Last edited: 2020-04-23 17:36)
I have exactly the same bug but I can confirm it 100% depends on the File.
I encountered this issue recently and have confirmed that some Files (mkv) regardless of SDR or HDR just can't start playback, you can skip in the File and you get a proper still image but it is impossible to start playback.
I have not found a solution for this yet and it's very annoying.
The only thing i noticed is that in the madVR OSD it shows that on the "faulty" Files the "present queue" hangs at 1-1 / 8

My System:
Win10 1909 Build 18363.778
Nvidia RTX 2070 Driver 445.87
MPC-BE 1.5.4
madVR 0.92.17

File 1 "RO HDR" works not
Mediainfo:
https://pastebin.com/8FJ8wr7E
madVR OSD:
https://imgur.com/a/ZyVAJn3

File 2 "KDL SDR" works not
Mediainfo:
https://pastebin.com/L4vGL99W
madVR OSD:
https://imgur.com/a/4jTDHut

File 3 "KDL HDR" works not
Mediainfo:
https://pastebin.com/We5UdtBC
madVR OSD:
https://imgur.com/a/1a9roNX

I want to help resolve this so ask me anything

Greetings

(0002693)
Daniel715   
2020-05-03 15:47   
Heres another 3 Files that don't work:

File EP1
Mediainfo:
https://pastebin.com/pHf0iuxz
madVR OSD:
https://imgur.com/a/35QiDZl

File EP2
Mediainfo:
https://pastebin.com/yXbL2rU4
madVR OSD:
https://imgur.com/a/j9kR0Ow

File EP3
Mediainfo:
https://pastebin.com/GiYd82f5
madVR OSD:
https://imgur.com/a/ZaqcvAo

Seems like the files that can't play get more common since recently.

Greetings
(0002694)
cgbug   
2020-05-03 22:43   
Could be an audio driver issue. Test with NULL audio renderer.
(0002695)
Daniel715   
2020-05-04 21:20   
@cgbug:
I just confirmed it is not related to the audio driver.
It is unclear to me why these files can't play back properly but still show the correct still image if you seek around.
Maybe it is some weird encoding that madVR can't handle?

I don't know and we still have to hear from madshi, maybe he has some advice.

Is there a way to output a log file for further diagnostic means?
(0002696)
cgbug   
2020-05-04 22:38   
madVR can handle such files without issues, and the player/codecs that you use as well.

Test with DXVA hardware decoding disabled in the player. If that works the problem is the fault of the graphics driver.
(0002697)
Daniel715   
2020-05-05 19:11   
I'm not using DXVA at all as you can see in the madVR OSD screenshots.
I also tested going back to the previous Nvidia Driver since some users on doom9 reported issues with the latest 445.87 and HDR. But it didn't solve it.

Its very unlikely that the graphics driver or the player is the issue here.
Since most Files play without issues, it is just on some files where it can't start playback.

The issue is somewhere in the "present queue" since the decoder, upload and render queue are full.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
642 [madVR] bug minor always 2020-04-29 01:02 2020-04-29 16:27
Reporter: Furgiuele Platform: Jriver MC26  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 113
Media Player (with version info): Jriver Media Center 26
Splitter (with version info): HDFury Integral 2
Decoder (with version info): HQRedOctober
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: yes
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: RTX 2060
GPU Driver Version: Last
Summary: FPS issue
Description: Hi, I'm Italian, sorry for my bad english.
I've an htpc with Nvidia RTX 2060 gpu and I use Jriver MP26 with last Madvr release (113) for 2160 upscaling, and hdr to sdr tone mapping for my Sony vpl-vw870es projector.
I've a lot of blu ray discs ripped of concerts and movies. But I can't play well 3 concerts because the source frame rate is 29.970, but Madvr set display mode on 23.980 fps.
I try everything! I create a Profile Group with two display modes, with this rule: if (srcFps > 25) "Profile 1" else "Profile 2"; profile 1 is with display modes 2160p50, 59 and 60, profile 2 is with 2160p23, 24, 25 and 30.
But it doesn't work! Madvr set always that 3 concerts on 23.980 fps, with a lot of dropped frames and stuttering.
The only way to play at the right frame rate is erasing low frame rates in display modes, but then I can't see well all my 23.976 fps videos!
Maybe the issue depends from soft telecine or uncorrect fps data from the ripped files.
Can you help me? There's a way to force Madvr to set 29.970 (or 59...) fps for that videos?
Many thanks in advance.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 20200429_005444.jpg (971,791 bytes) 2020-04-29 01:02
https://bugs.madshi.net/file_download.php?file_id=330&type=bug
Notes
(0002691)
Furgiuele   
2020-04-29 11:40   
I created a directory named frameRate=29p deint=Off and I dragged the 3 videos inside. Now they work perfectly!
(0002692)
madshi   
2020-04-29 16:27   
A frame rate of 29.970 usually means it's interlaced content which after deinterlacing either turns into 23.976 or into 59.940, depending on which type of content it is. madVR can apply IVTC to turn telecined film content into 23.976, or madVR can apply DXVA deinterlacing to turn natively interlaced content into 59.940p content. But because it's not clear which type of content we're talking about, it's hard for madVR to make the right decision about which frame rate to switch to.

But seems you already found the "solution" which is to use file name tags to tell madVR what to do.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
641 [eac3to] bug tweak always 2020-04-28 08:29 2020-04-28 08:29
Reporter: begna112 Platform: Windows  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.34
Summary: Add compact & silent output options. Remove process completed/error noises.
Description: When using eac3to programmatically, I would like less verbose options.

For example:
py -3 "E:\Tools\audio\extract_audio_eac3to.py" -I "E:\BDMVs\Full Metal Panic\[BDMV] Full Metal Panic! Invisible Victory [BDBOX1~3Fin]\BD\[KAXA-7637][FULLMETAL_PANIC_IV_1]\BDMV\STREAM\00000.m2ts"
M2TS, 1 video track, 4 audio tracks, 0:24:11, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: RAW/PCM, Japanese, 2.0 channels, 24 bits, 48kHz
3: DTS Master Audio, Japanese, 5.1 channels, 24 bits, 48kHz
   (core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: DTS Master Audio, Japanese, 2.0 channels, 24 bits, 48kHz
   (core: DTS, 2.0 channels, 768kbps, 48kHz)
5: DTS Master Audio, Japanese, 2.0 channels, 16 bits, 48kHz
   (core: DTS, 2.0 channels, 768kbps, 48kHz)
a02 Extracting audio track number 2...
a02 Reading RAW/PCM...
a02 Swapping endian...
a02 Writing WAV...
a02 Creating file "E:\BDMVs\Full Metal Panic\[BDMV] Full Metal Panic! Invisible Victory [BDBOX1~3Fin]\BD\[KAXA-7637][FULLMETAL_PANIC_IV_1]\BDMV\STREAM\00000_2.wav"...
a02 The original audio track has a constant bit depth of 24 bits.
Video track 1 contains 34792 frames.
eac3to processing took 19 seconds.
Done.

All of this text should be confined to a verbose output level.

Proposed arguments for modified behavior:

- default: current behavior
- compact: returns a compact string or json of output information on success, returns exit codes for success or failure.
- silent: returns only exit codes for success or failure.
- verbose: current behavior.
- progress: include the progress bar, regardless of the output verbosity.

Additionally, please include an option to remove the loud beep and alarm sounds for success and failure. Honestly, you might consider removing them entirely, as there is no means of controlling the volume on it and it's very loud.
Tags:
Steps To Reproduce: use eac3to
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
639 [madVR] bug crash always 2020-04-08 22:46 2020-04-17 13:32
Reporter: radarnyan Platform: Windows  
Assigned To: OS: Windows 7 x64  
Priority: normal OS Version: SP1  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 64-bit 1.9.2.12 (943e342dd)
Splitter (with version info): LAV Splitter 0.74.1.34-git
Decoder (with version info): LAV Video Decoder 0.74.1.34-git
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX1060 6GB
GPU Driver Version: 425.31 (last version supports 3D Vision officially)
Summary: MPC-HC crashes when stereoscopic 3D is enabled in Nvidia Control Panel
Description: madVR crashes MPC-HC as soon as video starts to play if stereoscopic 3D (3D Vision) is enabled in Nvidia Control Panel.

Using non-madVR renderer (like EVR) or switch off stereoscopic 3D, MPC-HC no longer crashes and can play video normally.
Tags: installation
Steps To Reproduce: 1. Enable stereoscopic 3D in Nvidia Control Panel
2. Try play any video (2D or 3D, any format)
3. MPC-HC would crash
Additional Information: I'm using 3D vision in passive mode (line alternative)
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
623 [madVR] bug major always 2019-10-30 03:37 2020-03-02 17:38
Reporter: meowmeow Platform: Windows  
Assigned To: OS: Windows 10 Education 64 bit  
Priority: normal OS Version: 1903  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.17
Media Player (with version info): MPC-HC (64bit) 1.8.8 (82efc58f7) by clsid2
Splitter (with version info): LAV Splitter 0.74.1.24-git
Decoder (with version info): LAV Decoder 0.74.1.24-git
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: EVGA 2080 Ti FTW3 Ultra
GPU Driver Version: 436.48
Summary: Presentation glitches occur when "after copy to backbuffer" set to "don't flush"
Description: Define SETTING = "after copy to backbuffer" in Windowed Mode under Rendering
Define ACTIONS = "go to fullscreen or jump during a video playback"

With SETTING default to "don't flush", whenever I perform ACTIONS, presentation glitches almost always (95% of the time) occur. However if I change SETTING to "fush" or "flush & wait(sleep)" and repeat the same ACTIONS, presentation glitches NEVER occur.

I have repeated this experiment with a variety of video files, including 720p, 1080p, 2160p, HDR, SDR, and 10bit SDR, all produce the exact same result.

I also experimented with another setting "after D3D presentation" and it has no effect on presentation glitches wether it's set to "don't flush" or "flush" or "flush & wait".

Considering "don't flush" is the current default value for SETTING and that it causes the glitch problem, may I suggest that the default change to "Flush & wait" in future releases? Or will there be any negative effect from that? "Flush" also works but it uses much more CPU (about 7-8% on a 9900k, compared to 1-2% used by "Flush & wait").
Tags:
Steps To Reproduce:
Additional Information: Note: the "Decoding" is done by "D3D11" however this option is not avaiable in the drop-down menu below so I list it here. Please ignore my selection below.

My monitor is 144hz, 8bit+FRC. I selected "10bit(or higher)" under devices/properties. In NVidia control panel I have set the display profile to use 144hz, 10bit, RGB, Full.
Attached Files: This_is_with_default_setting.PNG (331,862 bytes) 2019-10-30 03:42
https://bugs.madshi.net/file_download.php?file_id=319&type=bug
Notes
(0002574)
meowmeow   
2019-10-31 05:15   
Another observation: if I set the number of frames to be presented in advance to 2, 3, or 6, then I will not need to do flushing at all (all 4 flushing options down below can be set to "don't flush") and will not get any presentation glitch. However any other number of presented frames in advance, including 1, 8, 10, etc., will give me lots of presentation glitch.
(0002577)
madshi   
2019-10-31 17:31   
This is often somewhat "random". Changing the defaults might make things better for you, but could potentially introduce issues for other users.

Anyway, if these glitches only occur if you perform some kind of "action", it's not overly important, anyway. The important thing is that playback is completely smooth while you just sit there and enjoy the movie.
(0002685)
Medea   
2020-02-29 15:55   
You mentioned your monitor is 144Hz. Do you happen to have a second monitor with a different refresh rate?
I've been having many presentation glitches per second (during regular playback, and even when paused) on my 144Hz monitor. Any redraw of my other, 60Hz, monitor will cause glitches.
This is a known issue with Windows and might (mostly) be fixed soon thanks to this update: https://blurbusters.com/new-windows-update-fixes-mixed-hz-multimonitor/

But for now, this made watching videos in windowed mode on my main monitor unbearable, and lately even fullscreen mode is having this issue for me. ("regular" fullscreen, not exclusive mode which I can't even get to work)
So I googled my issue, found this bug report and tried your solution.
I can confirm that changing "after copy to backbuffer" to "flush & wait (sleep)" (or any of the other flush modes) completely eliminates the glitches, and so does changing the number of frames to be presented in advance from 8 to 6 (or anything less than 8).

I don't know if I should create a separate report for my issue, but I just wanted to say thank you meowmeow for posting a working solution.
(0002686)
huhn   
2020-03-02 17:38   
composition rate mismatches are a common issue with windows 10 and 7.

another workaround is overlay rendering it avoid this whole problem.
i had a report about composition rate here before.
it was out of his hands or something like that it's been years.
what so ever windows 8 fixed it too.

if you want to try getting FSE working again you can try this: with mpc-hc you can go to the properties of the exe-> compatibility and check "disable fullscreen optimisation" this restored FSE to it older glory but i have bad experience doing that in new windows versions. so do that at your own risk.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
633 [madVR] bug minor always 2020-01-29 19:05 2020-02-29 15:35
Reporter: justsomemadvrdude Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.17 final, madVRhdrMeasure113
Media Player (with version info): Kodi DSPlayer x64
Splitter (with version info): LAV Filters 0.74.1
Decoder (with version info): D3D11 -> Automatic (Native)
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: AMD + Intel
GPU Model: RX 580 (Win 10 x64), Intel GPU (Win 7 x64)
GPU Driver Version: All
Summary: madVR + Kodi DSPlayer: Bug with vertical shift (only) when video is playing in background (Home Screen)
Description: Hey madshi,

i made multiple screenshots which should easily illustrate the problem with some examples.

Download of all screenshots in one ZIP:
http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/k-madvr-verticalshift.zip

Single links:

http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/001_a.jpg
http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/001_b.jpg

http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/002_a.jpg
http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/002_b.jpg
http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/002_c.jpg

http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/003_a.jpg
http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/003_b.jpg
http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/003_c.jpg

http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/004_a.jpg
http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/004_b.jpg
http://nakunana24519x.bplaced.net/_tmp/k-madvr-verticalshift/004_c.jpg

(The sreenshots were created on my office system - so please don't wonder why frame rate switching etc. is not enabled)


It happens consistent on every test system with Kodi DSPlayer + madVR i tried. No matter what OS, GPU or LAV Filters version (both internal and external) is used.



At first i had in mind that this bug could be fixed in Kodi DSPlayer itself, but since i'm maintaining an updated Kodi DSPlayer x64 version for some time now i found no hint in the source that it could be a problem in Kodi DSPlayer itself.

My best guess would be that it's a problem regarding the communication of the desired scaling and vertical shift parameters between Kodi and madVR. (?)
The communication between Kodi and madVR seems to work incorrectly when Kodi is on home screen while playing the video in the background rather than being in VideoFullScreen/VideoOSD where everything seems flawless and rock solid. (even when combining zoom and vertical shift. No problems here whatsoever!)


If you need more input or information, don't hesitate to let me know.


This bug is the only problem we encounter on our many DSPlayer x64 + madVR setups i setup for me or friends with higher end projectors (Sony VW 570).


Although i know it's mostly a cosmetic GUI issue, it would be great if we could find a way to fix this.
It would really enhance the final "retail-ish" GUI experience of the otherwise great software combination of DSPlayer + madVR.


Thanks very much.
...and greetings from the AVS FORUM hdr2sdr thread! :-D
Tags:
Steps To Reproduce:
Additional Information: Side note:

I don't know if you ever use Kodi DSPlayer these days, but since you are the original author of the very old Kodi GUI scaling cristism ( https://forum.kodi.tv/showthread.php?tid=200401&pid=1757094#pid1757094 ), you may want to have a look here:
https://forum.kodi.tv/showthread.php?tid=348790
This is an updated DSPlayer x64 build with better GUI scaling which we use on many systems without problems while using HDR 2 SDR tone mapping.
Example of the fixed GUI: http://nakunana24519x.bplaced.net/_tmp/k-bettergui/pixelation_example_22353425.png

(Just to make it clear:
The described bug of this ticket happens on all builds of Kodi DSPlayer, so it's not an issue of the updated build)
Attached Files:
Notes
(0002628)
madshi   
2020-01-30 10:31   
I think the problem is that madVR tries to interpret what the media player wants (zoom, AR and shift), and fails to do so properly in this specific case. The reason why madVR tries to interpret the media player wishes is that madVR automatically detects black bars in the image and zooms them away and also supports CIH, CIW and CIA front projection setups (if the user has activated these features in the madVR settings).

Have you already seen this document?

http://madshi.net/89notesForDevs.pdf

It's quite old, but still applies.

You say you're maintaining a DSPlayer build - does that mean you're a developer and can also do changes (at least minor ones)? If so, if it's not too difficult, it would be great if you could teach DSPlayer to communicate its wishes to madVR clearly, by using the madVR communication interfaces. See 1c) in the PDF above. I believe that would fix all the issues.
(0002629)
justsomemadvrdude   
2020-01-30 13:43   
(Last edited: 2020-01-30 15:03)
Thanks for the unexpected fast reply and the PDF (which i have not seen before).

If relevant:
Black bar detection ("automatically detect hard coded black bars" is disabled on the test setup. (madVR "zoom control" settings tab all checkboxes unchecked)
I tried finding a workaround and did experiement with all settings i thought might do the trick.
Could not find any workaround in the end.

Now that you know that this happens while "automatically detect hard coded black bars" being disabled, does that change any of your assumptions?


So if i understand correctly, it looks like my wary suspision was correct, that in case of the existing DSPlayer, madVR interprets what the user has set in DSPlayer and acts on it (zoom/ar/shift) and Kodi itself is _not_ telling madVR what to do by sending commands to it or something like that.

I tried to think about what is different when Kodi has the video playing in the background rather then playing it in VideoFullScreen/VideoOSD (where madVR interprets everything flawless as it seems).
When VideoFullScreen/VideoOSD is used in Kodi, there is not even a "videowindow" control-tag in the Kodi skin, because it's most likely is all done by the Kodi core.
As soon as you switch to the home screen while playing video, the skin uses a very simple <control type="videowindow"></control> where the video is then displayed.
Looks like madVR does not get the information (zoom/ar/shift) it wants from this somehow "other" video player window.
As you can see it in the screenshots madVR seems to get _some_ information (even if they end up wrong) from the "background-video", because if that would not be the case you would assume that the background video maybe just would be displayed without any zoom/shift at all, but at least always be of correct AR.


I'm not really a C developer, but coming from the ux/ui/qa/web-dev world i have some background in coding php/js.

I have a machine set up which is able to compile DSPlayer x64 successfully.
I did create the build with the fixed/better gui scaling via mipmapping for Linux and Windows and was able to add some smaller(!) changes and backports to make DSPlayer a little more future proof.


I checked 1c) of the PDF and seem to understand your intent regarding implementing SetDestinationPosition/SendCommandX to have Kodi always tell madVR exactly and directly what Kodi wants to avoid the misinterpretation in this background-video-case.
Although i'm not shy of the work hours and happy to have a further look into the DSPlayer code, i have to assume that such more videoplayer related programming will be above my abilities.


In case i can't implement this on my own, do you have any further assumptions why madVR interprets DSPlayers user zoom/ar/shift flawless (even in the most exotic combinations) when being VideoFullScreen/VideoOSD in opposition to the video playing in background?
The discrepancy of the flawless interpretation on the one hand and the messup on the other hand is what really irritates me.
IF madVR's interpretation in VideoFullScreen/VideoOSD would also only be "mostly correct, but still not flawless" i would think that implementing IMadVRCommand::SendCommandStr would most likely be the only clean and rock solid way to go.
But at this point i would still have hope that we may find a way to change whatever is different in Kodi when the video is playing in background so madVR acts exactly like it does when playing in VideoFullScreen/VideoOSD.


So far for my quick feedback.
As said, i'm happy to have a deeper look at the code, but i don't want to get my/our hopes up about me implementing SetDestinationPosition/SendCommandX. :-/ :-)


Thanks again for your time.

(0002632)
madshi   
2020-02-03 12:41   
madVR tries to interpret the media player wishes by looking at things like changes to the rendering window size, changes to the parent window size, and calls to IVideoWindow::SetWindowPosition etc. Depending on these things, and the timing and order of changes to these properties, madVR tries to "understand" what the media player wants to achieve. And usually that works reasonably well, but occasionally it may fail. I assume if not the full screen is covered with the video, it makes things more difficult for madVR to understand fully.

I'm not sure if you can fix this by just playing around with the current code. I think you would waste a lot of time doing that. It would be more effective if you tried to use the madVR "SendCommandStr" API. It can't imagine that it would be very difficult. I think the key things you would have to do are:

1) Locate all code places in DSPlayer which call IVideoWindow::SetWindowPosition.
2) Find a way to access IMadVRCommand at all the same code places.
3) Try to understand the IVideoWindow::SetWindowPosition code. How does DSPlayer call the numbers to feed into SetWindowPosition? I assume DSPlayer will access the DSPlayer settings and then do some math to calculate the numbers.
4) Based on your understanding of 3), call SendCommandStr() with the appropriate zoom mode.

I'm not sure which of these 4 things will be the most difficult to achieve. In theory they could all be easy. Or difficult.
(0002633)
justsomemadvrdude   
2020-02-04 00:49   
(Last edited: 2020-02-04 03:35)
Thanks for the guidance.


Before your update note i already made some first searches regarding the code places of SetDestinationPosition.

With your further hints and proposed steps (especially mentioning to focus on SetWindowPosition, not SetDestinationPosition) i have some success to report.


I made a test build with some kodi debug notifications to understand when and which area of the code triggers.


After some hours of getting used to the new area of programming and code i now have some first test builds which already go in the right direction.

I'm now using multiple SendCommandX which are also documented in the mvrInterfaces.h file.


Just a code snippet to get a feel of what i'm trying:
_____________________________________________________________________________
if (Com::SmartQIPtr<IMadVRCommand> pMadVrCmd = m_pDXR)
{
  if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_ViewMode != ViewModeOriginal)
    pMadVrCmd->SendCommandString("setZoomMode", L"touchInside");
  else
    pMadVrCmd->SendCommandString("setZoomMode", L"100%");

  pMadVrCmd->SendCommandString("setZoomAlignX", L"center");
  pMadVrCmd->SendCommandString("setZoomAlignY", L"center");
  pMadVrCmd->SendCommandDouble("setArOverride", 0.0);

  if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_ViewMode == ViewModeNormal)
  {
    pMadVrCmd->SendCommandDouble("setZoomFactorX", 1.0);
    pMadVrCmd->SendCommandDouble("setZoomFactorY", 1.0);
  }
  else
  {
    pMadVrCmd->SendCommandDouble("setZoomFactorX", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount);
    pMadVrCmd->SendCommandDouble("setZoomFactorY", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount);
  }

  if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift > 1.0)
    pMadVrCmd->SendCommandDouble("setZoomOffsetY", -(1.0 - CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift));
  else if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift < -1.0)
    pMadVrCmd->SendCommandDouble("setZoomOffsetY", (1.0 + CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomVerticalShift));
  else
    pMadVrCmd->SendCommandDouble("setZoomOffsetY", 0.0);

  CGUIDialogKaiToast::QueueNotification(CGUIDialogKaiToast::Info, "DSPlayer", "madvr debug", TOAST_MESSAGE_TIME, false);
}
_____________________________________________________________________________


This direction of progress already results in a stable and predictable madvr video on homescreen with correct vertical shift and zoom. (Not possible before outside Kodi videofullscreen/videoosd window)

As we hoped for, madVR now strictly follows what is set above, no matter in which kodi window the video is displayed.

Still some work to do though. The custom video "pixel ratio" setting is not implemented yet for example.



Will report further on progress or roadblocks. :-)

(0002634)
justsomemadvrdude   
2020-02-04 01:55   
(Last edited: 2020-02-04 03:36)
Questions for the meantime:

1)

Let's say everything works out as discussed regarding adding robust zoom/vshift/originalsize-mode/custom-aspectratio support - there is one thing i don't know if i have to account for it in the code:

3D content

I have absolutely no experience on how original Kodi or even DSPlayer-Kodi-madVR handles 3D.
Do i have to account for anything in that regard?

My only experience with home cinema 3D content is on retail hardware players with retail 3D BD.



2)

Is madVRs "setArOverride" what should be used to adapt the Kodi optional custom video "pixel ratio" feature/setting?
Or is this the wrong approach and should i maybe just use additional conditions for setZoomFactorX/Y instead?

Something like this seems to work to adapt the setting:

_____________________________________________________________________________
pMadVrCmd->SendCommandDouble("setZoomFactorX", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount);
pMadVrCmd->SendCommandDouble("setZoomFactorY", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount);

if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio != 1.0)
{
  if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio < 1.0)
  {
    pMadVrCmd->SendCommandDouble("setZoomFactorX", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount * CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio);
  }
  else if (CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio > 1.0)
  {
    pMadVrCmd->SendCommandDouble("setZoomFactorY", CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomZoomAmount * CMediaSettings::GetInstance().GetCurrentVideoSettings().m_CustomPixelRatio);
  }
}
_____________________________________________________________________________



Thank you

(0002635)
madshi   
2020-02-04 08:55   
Glad to hear you made good progress! :-)

I assume (hope) that Kodi's "pixel ratio" option has a default value which is something like "auto detect" or "don't change" or something like that? I think using "setArOverride" is preferred over adjusting the zoom factors manually, because really this option sounds like it's primary purpose is to modify the AR, right? The end effect might be the same, though. Still, I tend to prefer "setArOverride" in this case.

I'm not completely sure about 3D content in this case. I'd suggest that you start by ignoring it and treating it like 2D. If that doesn't work for some reason just let me know, then we can brainstorm about it.
(0002636)
madshi   
2020-02-04 09:01   
Btw, great work on the improved downscaling, it's really hard for me to understand how the Kodi main devs don't seem to feel a need to fix this.

I don't suppose you managed to port DSPlayer to Leia? Last time I checked it still seems to be stuck on the previous release.
(0002640)
justsomemadvrdude   
2020-02-05 17:19   
(Last edited: 2020-02-22 00:12)
Here we go with a test build. :-)
I also handed it to a friend and will throw some everyday-testing at it myself:

Edit: Removed old links


custom video pixel ratio:
-------------------------
Yes, Kodi's per video custom video "pixel ratio" defaults to 1.0 (which is the neutral value doing nothing) and the setting itself is just another simple per-video setting like "zoom".
According to the wiki it's just a correction option for videos which have a messed up AR for example.

The slider ranges from 0.5 to 2.0

0.5 results in 50% image width while keeping the height untouched, meaning: keeping height at whatever size it's already at
1.0 is neutral and changes nothing
1.5 results in 150% image height while keeping the width untouched, meaning: keeping width at whatever size it's already at
2.0 results in 200% image height while keeping the width untouched, meaning: keeping width at whatever size it's already at

For now i went with the setZoomFactor implentation for the setting. It just seemed to work so solid and my previous attempts at using "setArOverride" instead ended up not working correct for some reason.

Is there some more background info regarding on which "setArOverride" values are allowed and what they will do exactly in order to maybe achieve the above mentioned?
It seemed like i ended up with a blank black video if "setArOverride" has been set to a value it did not seem to like.

I'm open to changing the implementation to "setArOverride" if i know how. :-)


3D:
---
+1
Let's ignore it for now and hope that it's not affected by the changes.
I already asked in the DSPlayer thread if someone is willing to test 3D on an old DSPlayer+madVR build vs the new build.
Maybe this confirms easily if 3D works as good (or bad) as before. I think this is all we would want to know.
I'll report if i found some willing testers.

(0002641)
madshi   
2020-02-05 17:27   
Sorry, no time to test the test build, unfortunately. I'm extremely busy working on the Envy atm. However, based on your description of the Kodi "pixel ratio" feature, I'd say that probably using "setZoomFactor" is a good choice instead of "setArOverride". So I think you should just leave it like that.
(0002642)
justsomemadvrdude   
2020-02-05 17:34   
(Last edited: 2020-02-05 17:34)
No worries, just wanted to post it here for informational/archival purposes.

Okay, let's keep the setZoomFactor variant at least for now then.

Thanks for the input, i'll just update when there is further feedback or progress.

Good look with your work on the Envy.

(0002643)
madshi   
2020-02-05 18:25   
Thx!
(0002677)
justsomemadvrdude   
2020-02-22 00:16   
Just for the archives:

From now on, builds with the implemented correct "API-communication" solution (and some more changes/backports/fixes for other stuff) can be found here:

Kodi 17.7 DSPlayer x64 BETTERGUI
https://forum.kodi.tv/showthread.php?tid=351534
(0002678)
madshi   
2020-02-22 00:38   
Great stuff - thanks!
(0002681)
justsomemadvrdude   
2020-02-29 13:12   
I got so used to the fixed "non-picture-squeezing" behaviour that i'm now irritated when i have to use an old build for a short time for debug reasons. :-)


Regarding 3D feedback after API-picture-size-stuff changes:

I got not much but some feedback by 2 users which sounded like 3D works as before. (Since our goal was to not brake it or make it worse, it should be okay.) Would have preferred to test myself also, but since that's not an option...


--


Bonus question while working on some additional stuff for DSPlayer:

In regards of DSPlayer<>madVR i was wondering about the "preset queue" setting:

- Preset queue (windowed+exclusive) is set to 8 (default) via madVR tray settings
(rendering->windowed mode, rendering->exclusive mode)
- The madVR-overlay shows that it uses the setting of 8 correctly (x/8)

But:

When Kodi DSPlayer has _any_ own GUI element showing on top of the playing madVR video, madVR changes the "present queue" maximum count temporarily from 8 to 2 - as long as DSPlayer shows said GUI elements. (See screenshots)
As soon as all Kodi-GUI elements are hidden again, the temporary reduced count jumps back to 8 instantly.
Just to be sure: I'm not talking about how filled the present queue is, but shown maximum count x/8. It jumps to x/2 for the temprary situation.


Is this bevaviour intentional and maybe unavoidable for some technical reasons?

http://nakunana24519x.bplaced.net/_tmp/k-mvr/mvr_present_queue_001.jpg
http://nakunana24519x.bplaced.net/_tmp/k-mvr/mvr_present_queue_002.jpg
http://nakunana24519x.bplaced.net/_tmp/k-mvr/mvr_present_queue_003.jpg


Side notes:
- I suspect this behaviour is handled from inside madVR itself, since my build of DSPlayer does not set any "preset queue" setting
- I cleaned the build of being able to change madVR settings. Everything is configured via madVR tray settings. Besides the discussed picture-size-API-stuff DSPlayer does not "control" madVR in any further way anymore.


Thanks!
(0002682)
madshi   
2020-02-29 13:28   
It's intentional. Having a queue size of 8 means that for 24fps, that would be 333 milliseconds latency/delay. So you press a key to move the Kodi "cursor"/focus, and it takes 333+ milliseconds for that to become visible. That's not good, of course, which is why madVR limits that to 2 frames when any active GUI is visible, to make GUI feel less sluggish.
(0002683)
justsomemadvrdude   
2020-02-29 15:10   
(Last edited: 2020-02-29 15:14)
Interesting, thanks.

1) I'm aware of the typical sluggishness in 23hz/low-fps scenarios which feels about identical on all devices (apple tv 4k @ 23hz, kodi devices @ 23hz etc.)

In the discussed matter we are talking about an additional "present-queue"-delay which would add even on top of the known typical 23hz-sluggishness - do i understand that correctly?

2) Is this implementation Kodi DSPlayer specific?

3) Would it be possible to consider a future madVR setting for DSPlayer to use like:

Variant A (most simple but already very helpful):

m_pSettingsManager->SetBool("preRenderFramesReductionOnGUI", false);

OR

Variant B (more flexible):

m_pSettingsManager->SetBool("preRenderFramesReductionOnGUI", true); // Should be true by default, of course.
int framesCount = 3;
m_pSettingsManager->SetInt("preRenderFramesReductionOnGUICount", framesCount); // Purely optional override of the default value of 2

    
There would be _no_ need for a setting in the madVR-settings-UI itself. The existence of any option itself to be used by DSPlayer code would be very sufficient.


Reasons:

Besides having control for special use cases there are higher end 21:9 projection screen users which for example use a standard projector resolution of 3840x2160 while using a Kodi skin with additional features to mask all the visible content which is outside of their 21:9 screen.

These features are therefore detected as GUI by madVR which leads to these users being stuck with an absolute maximum present queue count of 2.

Besides this example i can think of more use cases which would make Kodi show GUI permanenty on top of a playing video while there is no user input/navigation going on.

(0002684)
madshi   
2020-02-29 15:35   
> do i understand that correctly?

Yes.

> Is this implementation Kodi DSPlayer specific?

No.

> Would it be possible to consider a future madVR setting

You already have some control over it. Please check "mvrInterfaces.h". If you search for "low latency" you'll find what you need.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
634 [eac3to] bug minor always 2020-02-08 17:54 2020-02-24 13:45
Reporter: Bandits Platform: Windows  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 1903  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.34
Summary: h265/HEVC video stream parameters not detectable.
Description: First Pass Video stream reports:

h265/HEVC, 2160p24 /1.001 (16:9)

Second Pass Video stream reports:

h265/HEVC, unknown parameters
Tags:
Steps To Reproduce: Execute eac3to.exe on UHD or folder containing UHD data.
Additional Information: First Pass:

eac3to v3.34
command line: "C:\eac3to.exe" "C:\XXXXX" -log="C:\log.txt"
------------------------------------------------------------------------------
1) 00000.mpls, 00001.m2ts, 2:13:12
   - Chapters, 16 chapters
   - h265/HEVC, 2160p24 /1.001 (16:9)
   - DTS Master Audio, English, multi-channel, 48kHz
   - AC3, Spanish, multi-channel, 48kHz
   - AC3, French, multi-channel, 48kHz
   - AC3, English, stereo, 48kHz
   - DTS, English, stereo, 48kHz

Second Pass:

eac3to v3.34
command line: "C:\eac3to.exe" "C:\XXXXX" 1) -log="C:\log.txt"
------------------------------------------------------------------------------
M2TS, 1 video track, 5 audio tracks, 5 subtitle tracks, 2:13:12, 11.987p
1: Chapters, 16 chapters
2: h265/HEVC, unknown parameters
3: DTS Master Audio, English, 7.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: AC3, Spanish, 5.1 channels, 640kbps, 48kHz
5: AC3, French, 5.1 channels, 640kbps, 48kHz
6: AC3 Surround, English, 2.0 channels, 224kbps, 48kHz
7: DTS, English, 2.0 channels, 768kbps, 48kHz
8: Subtitle (PGS), English
9: Subtitle (PGS), French
10: Subtitle (PGS), English
11: Subtitle (PGS), French
12: Subtitle (PGS), Spanish
Attached Files:
Notes
(0002644)
madshi   
2020-02-08 18:17   
Can you upload a small sample somewhere? Just a couple of MBs might suffice. Just enough for eac3to to reproduce the problem on the sample.
(0002661)
Bandits   
2020-02-15 17:52   
https://www.dropbox.com/s/ly9e37infi1vkh1/00000.m2ts?dl=0

This was a small as I could make it without eac3to giving error.
(0002679)
Bandits   
2020-02-23 07:22   
https://www.dropbox.com/s/j5o7ek0mnk96asm/00001.m2ts?dl=0

New sample same issue.
(0002680)
madshi   
2020-02-24 13:45   
Thanks, got the samples. Might take a while until I get to this, though.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
630 [madVR] bug major always 2019-12-21 14:27 2020-02-20 17:17
Reporter: mclingo Platform: windows  
Assigned To: OS: 10  
Priority: normal OS Version: 1809  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.17 + 112b madvrm beta
Media Player (with version info): all players, main drivers / kodi ds / mpc-hc
Splitter (with version info): lav 0.74.1
Decoder (with version info): lav 0.74.1
Decoding: DXVA2 Copyback
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: MSI amd rx 5700 8gb oc
GPU Driver Version: 19.12.3
Summary: Low colour saturation when using AMD API on AMD 5700 series cards - not apparent on old RX 4/500 series
Description: When using AMD HDR APi in MADVR colours are very unsturated, it has been suggested BT2020 is not being selected for output by MADVR for this generation of cards.

So far this has been reported and confirmed by a number of people including huhn on the MADVR forum.

Tags:
Steps To Reproduce: Play and HDR movie using MADVR, output in HDR must be selected.
Additional Information: If Windows HDR switch is used instead and AMD API is disabled in MADVR colours are correct and normal so this seems to be an issue with how MADVR and AMD API are interacting, we cant tell if this is a MADVR or AMD issue.

However this has been an issue since day one of this series of cards and AMD still havent fixed it, can a workaround be added to MADVR mabe to force BT2020 output?
Attached Files:
Notes
(0002612)
mclingo   
2020-01-09 17:16   
Hi, just some more info on this from user DMU on doom9, this is a support request he sent in to AMD which I dont think he's had a reply on yet, just thought it might be useful to you in case you had any ideas on a workaround as going forward its likely all new AMD will have this bug of this generation and it hasnt been fixed for months, so might not get fixed.



Hi there.
You have entered support for HDR mode. The agsSetDisplayMode() function used to set a specific display in HDR mode, does its job perfectly: it sends metadata to the display device, which is defined in section 6.9 «Dynamic Range and Mastering InfoFrame» according to Table 5 of the CTA-861 standard. But in the same Table 5 there is also «Auxiliary Video Information (AVI)» defined in section 6.4. And all display devices are required to use the color space (colorimetry) from this data section (AVI InfoFrame) for the current video signal.
Suppose we are in SDR mode with the standard sRGB color space. And we want to switch to the HDR mode with the BT.2020 color space, which is the main one for this mode. By calling the agsSetDisplayMode() function, we put the display device in HDR mode. And we see distorted or unsaturated colors. This is because the display device did not receive the corresponding flag from the GPU in the AVI InfoFrame and is trying to display our BT.2020 color space in its sRGB.
Please tell me, do you think that such HDR support in AGS_SDK is sufficient? If yes, then advise what else needs to be done so that the display device passes into the correct color space when activating the HDR mode using AGS?
(0002645)
DMU   
2020-02-12 07:29   
(Last edited: 2020-02-12 13:06)
Received response from gareththomasamd.
https://github.com/GPUOpen-LibrariesAndSDKs/AGS_SDK/issues/33
Cool, but with 20.2.1 version the AMD AGS HDR does not work at all.

(0002646)
madshi   
2020-02-12 16:27   
AGS HDR has a few requirements, e.g. it has to be D3D11, fullscreen and 10bit. Are all those requirements met in your case? Which is the last driver with which AGS HDR worked at all for you?
(0002647)
mclingo   
2020-02-12 16:32   
Hi, yeah I have all those requirements in place, the fact that HDR works in MADVR with windows HDR turned on it quite telling though, it suggests that windows is locked at BT2020 and overrides MADVR somehow. with the 5700 series none of the drivers have worked with MADVR HDR unfortunately :(

So thw workaround right now is to turn on windows HDR then use video app + MADVR as normal, this works fine but it looks like we'll need some sort of force BT2020 switch in MADVR for AMD NAVI cards for the forseable future.
(0002648)
madshi   
2020-02-12 16:35   
Oh wow, so the dynamic HDR switch doesn't work at all with 5700, with any driver version? That's disappointing, for sure.

Have you tried the sample garththomasamd linked? Does that sample have the same problem? Or does that sample actually manage to switch to HDR mode, with the OS HDR switch turned off?
(0002649)
mclingo   
2020-02-12 16:44   
Hi, no its never worked, its a shame as its a really great card with MADVR, just glad there is a workaround as your recent tone mapping work is incredible.

I had a look at those links and could not find the actual samples other than some freesync stuff. i'm currently downloading everything on there but its taking ages for some reason.
(0002650)
madshi   
2020-02-12 16:46   
Thx, glad you like my tone mapping!

Would be great if you could find and test that sample. If that sample works, maybe I can figure out why madVR doesn't. But if the sample also fails, then it's clear that it can't be madVR's fault.
(0002651)
mclingo   
2020-02-12 16:54   
they all look to be code samples no actual video samples as such, I cant see anything to test i'm afraid.
(0002652)
madshi   
2020-02-12 16:56   
So just source code, no EXE files to run? That's a pity. No time atm to compile that stuff for you. Maybe garththomasamd can provide a simple EXE sample for you to try?

Might help if you told him that madVR worked fine with AMD 4xxx series (using AMD AGS), but never worked with AMD 5xxx series?
(0002653)
mclingo   
2020-02-12 17:11   
ive asked for a sample but I dont think we'll learn anything to be honest, I think we're all now sure its not a MADVR issue as it still works with last gen RX400/500 cards and they are using the same API, it must be something to do with the NAVI driver itself.
(0002654)
mclingo   
2020-02-12 18:48   
thanks for having a look though, we know you're super busy with envy / tone mapping.
(0002655)
DMU   
2020-02-12 20:55   
(Last edited: 2020-02-12 21:05)
I can check using HDFury. But I am not a programmer and I can not create code for verification. And the following is required:
https://gpuopen.com/using-amd-freesync-premium-pro-hdr-code-samples/
---------------------------------------------------------
After confirming the monitor supports HDR, the swap chain is created using standard DX12 code. It is important to initialize its color format to the required HDR color format that we want to support. This would be DXGI_FORMAT_R10G10B10A2_UNORM for DisplayNative or Gamma22 and DXGI_FORMAT_R16G16B16A16_FLOAT for scRGB. The app also needs to setup its window to get exclusive full screen mode via the Windows® API. This is achieved by creating a window with borderless full screen flags and making its size and resolution match that of the monitor.
---------------------------------------------------------
All that is needed is to create a full-screen window according to their requirements. And I will launch the AGS in it.

PS
This problem concerns not only AMD Navi video cards, but Vega too.

(0002656)
mclingo   
2020-02-12 21:21   
sorry you're quite right, its just polaris which isnt affected I think.

let us know what you find out DMU
(0002657)
madshi   
2020-02-12 21:33   
> After confirming the monitor supports HDR, the swap
> chain is created using standard DX12 code.

FWIW, madVR uses DX11. But other than that, all the requested details are fulfilled by madVR.
(0002658)
huhn   
2020-02-13 00:36   
polaris cards work totally fine with your current code as confirmed.

so you have to yet again workaround a driver bug if you want to change something about this situation.
maybe it works with dx12 correctly. who knows. AMD doesn't seem to really care about video playback at the moment and other stuff that doesn't crash the driver.
(0002659)
mclingo   
2020-02-13 01:06   
i guess if we could find a game that uses dx12 and amd api we could test that theory Huhn, i had a look for one a while back but its impossible to get this sort of info without looking at every single game in detail one by one.
(0002660)
DMU   
2020-02-13 08:31   
(Last edited: 2020-02-13 08:34)
Microsoft has a sample DX12 fullscreen code.

https://github.com/microsoft/DirectX-Graphics-Samples/tree/master/Samples/Desktop/D3D12Fullscreen

I tried to introduce the AGS HDR into it - the result is negative (no BT.2020 flag).
But I'm not a programmer, maybe I did something wrong.

(0002662)
mclingo   
2020-02-17 17:00   
Hi Madshi, do you think you'll be able to create some sort of workaround within MADVR itself at some point when ENVY is released, it doesnt look like AMD are going to move on this any time soon with all the other issues they have at the moment.
(0002663)
madshi   
2020-02-20 16:57   
As you said earlier:

> I think we're all now sure its not a MADVR issue

So I'm not really sure what I could do here.
(0002664)
mclingo   
2020-02-20 17:05   
Hiya, could you maybe set MADVR to always force BT2020 output for all HDR movies somehow, or maybe create a switch we can turn on or off using a profile?

The fact that it works fine in MADVR when windows HDR is also turned on suggests that MADVR can be forced to output BT2020, if you see what I mean.
(0002665)
madshi   
2020-02-20 17:08   
My understanding is that it's just the HDMI InfoFrame BT.2020 flag which is missing. Which I have no control over. The pixel data madVR renders and outputs seems to be correct, as far as I understand.
(0002666)
mclingo   
2020-02-20 17:10   
another option would be to add windows HDR API back in so that could be selected over the GPU private API.
(0002668)
madshi   
2020-02-20 17:11   
Windows API is supported. You can manually switch the OS into HDR mode, and madVR should happily output HDR that way.
(0002669)
mclingo   
2020-02-20 17:14   
Hi, yes but it can only be switched on manually, we're already using that as a workaround, is it not possible to bake in windows HDR so that HDR can be turned on automatically like it does for AMD/NVIDIA API?
(0002670)
madshi   
2020-02-20 17:15   
Maybe.
(0002671)
mclingo   
2020-02-20 17:16   
a "use windows HDR" switch that could be toggled in MADVR so it bypasses the other API's
(0002672)
mclingo   
2020-02-20 17:17   
I know you are super busy with ENVY though mate so we're not expecting anything from you at all right now, but something you could maybe think about for V1.0 relese :)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
631 [madVR] bug major always 2019-12-31 15:44 2020-02-04 19:42
Reporter: totalz Platform: Windows  
Assigned To: OS: 10  
Priority: high OS Version: 1709  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.17
Media Player (with version info): KMPlayer 64X_2019.11.18.03
Splitter (with version info): LAV 0.70.2
Decoder (with version info): LAV 0.74.1
Decoding: DXVA2 Copyback
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: AMD
GPU Model: RX570
GPU Driver Version: 2020 12 02 WHQL
Summary: Disabled(unchecked) automatic full screen exclusive mode, but still entered exclusive mode while full screen.
Description: If seems that I cannot totally disable full screen exclusive mode.
Tags:
Steps To Reproduce: Once enabled, cannot fully disable, not even system restart
Additional Information:
Attached Files:
Notes
(0002607)
madshi   
2019-12-31 21:24   
Some media players override the madVR settings. Maybe that's what's happening here? I'm not very familiar with KmPlayer. Maybe there's a setting for that in the KmPlayer options?
(0002608)
totalz   
2020-01-02 04:02   
(Last edited: 2020-01-02 07:29)
Actually, I think KMPlayer is now closely and kind of identical to MPC-HP. And I don't think there's any HDR setting in KMPlayer.

After more testing, I found that the issue happens when Windows HDR is off. But then I only enabled the fullscreen exclusive mode while Windows HDR was off. I'm not dare to test the mode while Windows HDR is on. I did try clean install display card driver, but that didn't fix the problem.

Device HDR setting in madvr set to "passthrough HDR to display", and checked "send HDR metadata to the display". Is the HDR metadata for HDR10+ & Dolby Vision?

I'm wondering if madvr has to enter "fullscreen exclusive" in order to passthrough HDR to display. Cause whenever I need to access KMPlayer's menu, the screen goes black, wait 3 sec if that option is checked in exclusive mode. And there are times that I couldn't get the menu, video picture shown, then back to black screen for 3 sec... And color can be all wrong when playback resumes, 50% of times it goes to Black&White. Windows 10 itself could be the issue here when Windows HDR is off.

(0002609)
madshi   
2020-01-03 09:29   
madVR should never go fullscreen exclusive unless you either have it enabled in the settings, or if the media player overwrites your settings.

The HDR metadata is simple HDR10. Dolby Vision and HDR10+ are not supported at the moment.

For best HDR quality I'd recommend using the latest test build from AVSForum and letting madVR do the tone mapping. That requires a good GPU, though.
(0002610)
totalz   
2020-01-03 09:53   
The effect of switching to fullscreen exclusive mode is very obvious, and I never see that in KMPlayer unless I use madVR as the Video Renderer and enabled fullscreen exclusive mode. Except in this case I couldn't disable it...
(0002611)
madshi   
2020-01-03 09:56   
What does the madVR OSD say (Ctrl+J)? Does it say fullscreen exclusive mode?
(0002615)
dom   
2020-01-16 12:17   
I'm encountering the same issue with MPC-HC.
The display goes black for a moment and then comes back - exact behavior of my display when mode/resolution/whatever is changed.
- Only occurs with MadVR
- Switch to exclusive happens a few seconds after going to full-screen in MPC
- No matter what options are set in MadVR - it always occurs
- All mode-switching and exclusive options in MPC are disabled as well

This is made worse by the fact that I'm also experiencing something sort of similar to issue 0000596 (http://bugs.madshi.net/view.php?id=596).
However, in my case, the image is significantly darker only after the switch has occurred -> dark in FSE and better-looking in FSW - i.e. the other way around.
If I watch the video in normal windowed mode (no full-screen whatsoever) then it looks fine.
-> This is what leads me to believe that the display switch that occurs after a few seconds is to full-screen exclusive
(0002617)
pittyh   
2020-01-20 11:06   
Created a account here, just confirm i am having the same issue.

Windows 10 1909
9900K
2080ti
Nvidia driver version 441.12
Potplayer 1.7.20977

 Disabled(unchecked) automatic full screen exclusive mode, but still entered exclusive mode while full screen.

I just cannot get fullscreen windowed without it going exclusive.
Changing to EVR renderer in potplayer allows fullscreen windowed no problem.
(0002618)
madshi   
2020-01-20 11:11   
Again guys, I've asked but you didn't answer:

What does the madVR OSD say (Ctrl+J)? Does it say fullscreen exclusive mode?
(0002619)
pittyh   
2020-01-20 13:07   
(Last edited: 2020-01-20 13:24)
Hi madshi,

Nope it says D3d11 fullscreen windowed (10Bit) but it's acting like it's fullscreen exclusive, because if i mouse over the seek bar or adjust volume, screen flashes black

Also lists "1 frame drop every 1.00 seconds" appears when in windowed mode, and disappears in fullscreen

Link to madvr settings image - windowed mode
https://imgur.com/DFGDyX0


Fullscreen mode
https://imgur.com/a/C1ROtoQ

(0002620)
pittyh   
2020-01-20 13:49   
Think i fixed it by totally uninstalling madvr and reinstalling.
(0002621)
madshi   
2020-01-21 23:43   
FWIW, Windows 10 has a special mode called "direct scanout", which is automatically activated by the OS and GPU driver in fullscreen windowed mode. The OS and GPU driver do this directly, practically behind the back of madVR. Which is normally fine, because this mode improves performance to near FSE levels. Plus it allows 10bit output in fullscreen windowed mode.

My best guess is that this "direct scanout" mode is somehow causing these issues for you. There's not much I can do about that, unfortunately.

Not sure why uninstalling and reinstalling madVR would fix that, though. That seems weird.
(0002626)
dom   
2020-01-26 16:09   
(Last edited: 2020-02-01 09:13)
uninstall/reboot/reinstall/reboot does NOT seem to help on my end.

It says D3D11 fullscreen windowed - the same BOTH immediately after going fullscreen in MPC-HC - and after the delay of a few seconds elapses and the screen switches and the HDR display becomes much darker.

After the "switch" it definitely behaves like fullscreen exclusive, even if MadVR debug OSD doesn't say so.
E.g.: Just mouse right-click to bring up the MPC context menu causes another switch (to what really is FSW, I think) - with the display becoming more light again... after dismissing the context-emu, there is again a "switch" (back to FSE) with display becoming much darker again.

As I mentioned before, the FSE dark display is too dark - it is unusable for watching movies.
Grey value 72 is just barely visible an non-black on my (admittedly weak) HDR display.
If in windowed mode, it is 66.
It's not just the low end - the curve seems different, e.g. dark/FSE 100 looks equal to light/FSW 80

I'm the above I'm using this: "01. black-level-v1.mp4" from "Mehanik HDR10 test patterns" (https://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set.html)


EDIT 2020-02-01: inserted important NOT in first line (ouch typo!) and fixed other minor typos

(0002627)
madshi   
2020-01-26 16:13   
As I said, it's a "feature" of Windows 10. There's nothing I can do about it. Maybe you can work around it by choosing appropriate GPU driver settings. E.g. make sure you're using "RGB Full" in the GPU control panel etc.

It's also possible that it only occurs when using D3D11 presentation or when using 10bit output. You could try disabling D3D11 presentation or force 8bit output instead.
(0002630)
dom   
2020-02-01 10:20   
@madshi: For my understanding, please:
What are the parameters under which this "direct scanout" gets activated?

With your tips, I experimented a bit:
- "Full RGB" was always set in nvidia settings
- "tone map HDR with pixel shaders" always set in madVR HDR settings (200, BT.2390, balanced, medium)
- the "switch" only occurs if HDR is enabled in Windows display settings (OD HDR) and "output video in HDR" is disabled in MadVR
- no difference if 8 or 10 Bit selected in nVidia settings
- If I disable OS HDR and enable "output in HDR" in MadVR (NV HDR), there also is no switch when going fullscreen (but one when the player starts, obviously). However, the image quality is bad in this NV HDR mode (way too dark)
(0002631)
madshi   
2020-02-03 10:15   
It is usually recommended that you disable the OS HDR switch and instead let madVR do the tone mapping by using pixel shaders. If you do that, I would recommend that you disable "output in HDR". Unless you're using an LG OLED display? In that case using "output in HDR" might be beneficial because the OLED might then run in a higher brightness setting.

Hopefully you're using the latest (or one of the latest) madVR HDR test builds from AVSForum? E.g. try this one:

http://madshi.net/madVRhdrMeasure112b.zip
(0002637)
dom   
2020-02-04 18:58   
My display is an ASUS PA24AC - not very good at HDR - but better than nothing.

It has a normal and an HDR mode - if I leave both "OS HDR" and "output in HDR" (NV HDR) off - then it never switches into HDR mode...
My understanding so far was that tone-mapping alone won't be good enough in this situation...?

No, I have the normal public version... I try this newer build in the next few days, Thanks.
(0002638)
madshi   
2020-02-04 19:02   
Your display doesn't do anything magical if it's in HDR mode. It practically only means that your display applies tone mapping. If you let madVR do the tone mapping instead it's better to keep your display in SDR mode, so tone mapping isn't applied twice. So the recommended approach is to disable the "output in HDR" option.

Might make sense to double check image quality, of course.
(0002639)
dom   
2020-02-04 19:42   
will do - likely will only have time next weekend, though


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
632 [madVR] bug minor always 2020-01-24 22:01 2020-01-26 14:22
Reporter: Matching_Mole Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.17
Media Player (with version info): J River MC25 or 26
Splitter (with version info): LAV Filters 0.74.1
Decoder (with version info): LAV Filters 0.74.1
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: RTX 2070 super (but the two other PC was with ATI Rage Nano or HD 7900)
GPU Driver Version: 441.87
Summary: madVr + J River MC25 (or 26) = issue with external subtitles for DVD playback
Description: J. River (MC25 or 26) allow to use external subtitles (as SRT files) with official DVD-video support (ifo+vob) using "browse" function in Subtitle sub-menu.

When using madVr as video renderer, the loaded external sub file is not used but still the potential internal subtitles track from the DVD.And so even if the external subtitles file entry in the J River subtitle sub-menu is indicated as selected.

To force the "switch" to the external sub, it requires to first select the "Off" entry from the J. River Subtitles sub-menu and then, with the same sub-menu, to select again the external subtitles file entry added after the initial loading. If this actions are done again (select "Off" and then whatever subtitles from the list), no subtitles is working any more (inner or external).

If other video renderer than madVr is used (as EVR), everything works as intended. This issue was reproduced in the exact same way with 3 different computers, two with Windows Seven x64, one with Windows 10 x64.
Tags:
Steps To Reproduce: Step 1: play a DVD-video in J River (MC 25 or 26) with madVr as video renderer.
Step 2: load an external subtitles file in SRT format using "browse" function in J River Subtitle sub-menu.
Step 3: madVr is still playing the potential internal subtitles even if the external subtitles file entry in the J River subtitle sub-menu is indicated as selected.
Step 4: select the "Off" entry from the J. River Subtitles sub-menu. No subtitles should be played by madVr.
Step 5: select the external subtitles file entry (added in the step 2) in the J River subtitle sub-menu. Now the external subtitles is played by madVR.
Step 6: redo the steps 4 and 5 (choosing the internal or external subtitles track). No Subtitles will work anymore.
Additional Information: If other video renderer than madVr is used (as EVR), everything works as intended.
Attached Files:
Notes
(0002622)
madshi   
2020-01-25 21:38   
Does the same problem occur with other media players? It could be a bug in the media player just as well as a bug in madVR. Other renderers working fine doesn't prove anything just yet, because the MC subtitle implementations for each renderer are probably different.
(0002623)
Matching_Mole   
2020-01-26 14:15   
I have no such issue with MPC (BE or HC) but I think they work differently from J River for the specific case of DVD-video. I suspect that the subtitles renderer of River is not the same for the internal DVD subtitles (image based) and external subtitles (text based). The action to load external subtitles seems to require a kind of change (pins change?) that is not correctly working with madVr. For instance, there is no such issue with Blu-ray Video file in J River as no such change seems required even with external subtitles due, I think, to the specifications of the Blu-ray video standard.

Currently J River team consider they have no issue from their player as all works as intended with EVR renderer. If you consider that the issue is with J River and no madVr so we are in kind of loop hole.
(0002624)
madshi   
2020-01-26 14:18   
I've no idea where the issue is. It could be their fault or mine. Just saying that it be either. Atm I'm busy working on the Envy, which doesn't have subtitle support. So it will probably take a while until I get a chance to look into this.
(0002625)
Matching_Mole   
2020-01-26 14:22   
No Problem, this is perfectly understandable. The issue is kind of minor and a workaround is existing (even if it is kind of boring).


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
596 [madVR] bug major always 2019-02-06 21:24 2020-01-16 12:22
Reporter: DMU Platform: AMD Ryzen 3 2200G  
Assigned To: OS: Windows 10 Pro  
Priority: normal OS Version: 1809  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC (64-bit) 1.8.4
Splitter (with version info): LAV 0.73.1
Decoder (with version info): LAV 0.73.1
Decoding: DXVA2 Copyback
Deinterlacing: forced film mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: AMD
GPU Model: Vega 8
GPU Driver Version: 19.1.1
Summary: HDR video is much darker in Fullscreen Windowed (FSW) mode.
Description: MadVR is in AMD HDR mode. In FSE mode all HDR video looks great. In FSW - much darker.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: fsw_dark.jpg (903,172 bytes) 2019-02-06 21:24
https://bugs.madshi.net/file_download.php?file_id=303&type=bug
fse.jpg (972,161 bytes) 2019-02-06 21:35
https://bugs.madshi.net/file_download.php?file_id=304&type=bug
Notes
(0002616)
dom   
2020-01-16 12:19   
I'm experiencing the exact opposite of this!

The HDR video looks ok in windowed mode ( no full-screen at all) and in FSW.
In full-screen exclusive, it is much MUCH darker to the point of being unwatchable.

This matter is made worse by the fact that I cannot get MadVR to stay in FSW mode - after a few seconds delay, it always switches to FSE (not matter what full-screen options are set/unset)
-> issue 0000631 (http://bugs.madshi.net/view.php?id=631)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
628 [madVR] bug major always 2019-12-07 17:55 2020-01-14 11:02
Reporter: onur Platform: 32/64  
Assigned To: madshi OS: Windows 10  
Priority: normal OS Version: 10  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.17
Media Player (with version info): MPC-BE.1.5.4.4850.x86
Splitter (with version info): LAV starting from 0.71.0
Decoder (with version info): LAV starting from 0.71.0
Decoding: DXVA2 Native
Deinterlacing: auto mode
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: Intel
GPU Model: Intel UHD 620
GPU Driver Version: 26.20.100.7463
Summary: MadVR and LAV possible Bug
Description: Playing specific files from specific resume pos is not working (black screen).
(i think when pos is short bevor keyframe everything is ok).

LAV starting from 0.71.0 is not working.
newest mpc-hc has integrated LAV 0.70.2 which is working.
EVR Renderer is working with all versions of LAV.
Tags:
Steps To Reproduce: 1.)
mpc-be player - with prefered external filter (LAV Splitter Source and LAV Video Decoder)
https://drive.google.com/file/d/12T5jjOuCUKzfylkc_wT86iWpHT637GRw/view
or
https://drive.google.com/uc?export=download&id=1PFk0HyHuFZebrNTUbctI83souI_aGTEb
(load file with resume pos 01:04)

now we have a black screen.


2.)
test with source code:
First we need a Stopped Graph, with the test file Samsung Wonderland Demo.ts
Filter Graph with LAV Source and LAV Decoder and MadVR Renderer.
when we start file playing with resume pos the screens is black.

not working:
REFERENCE_TIME rtResume=640000000;
pMSeek->SetPositions(&rtResume, AM_SEEKING_AbsolutePositioning, NULL, AM_SEEKING_NoPositioning);
pMC->Run();

not working:
REFERENCE_TIME rtResume=640000000;
pMSeek->SetPositions(&rtResume, AM_SEEKING_AbsolutePositioning, NULL, AM_SEEKING_NoPositioning);
pMC->Pause();
pMC->Run();

working:
REFERENCE_TIME rtResume=640000000;
//first seek to keyframe
hr = pMSeek->SetPositions(&rtResume, AM_SEEKING_SeekToKeyFrame, NULL, AM_SEEKING_NoPositioning);
pMC->Pause();
                
//wait until Ready
__int64 endclock = GetTickCount64() + 2000;
OAFilterState pfs;
while (pMC->GetState(10, &pfs) == VFW_S_STATE_INTERMEDIATE || pfs != State_Paused)
{
   Sleep(10);
   if (GetTickCount64() > endclock)
     break;
}

//now seek to Real Pos
hr = pMSeek->SetPositions(&rtResume, AM_SEEKING_AbsolutePositioning, NULL, AM_SEEKING_NoPositioning);
Additional Information:
Attached Files: mpc-hc.zip (4,692 bytes) 2019-12-24 14:53
https://bugs.madshi.net/file_download.php?file_id=328&type=bug
Notes
(0002599)
madshi   
2019-12-10 23:15   
So latest LAV doesn't work, but older LAV builds work? I guess it's a 50/50 chance that it's a bug in madVR or in LAV. Have you tried asking nevcairiel about it? If it worked in older LAV builds but not in the latest, that would suggest that some change in LAV caused this issue. But it could of course still be madVR's fault (as well).
(0002603)
onur   
2019-12-20 16:07   
answer of nevcairiel:
TS files are not always perfectly seekable, its just the nature of the format - its designed for broadcast and streaming. If you need flawless seeking, remux to MP4 or MKV.

my adoption:
newer LAV with EVR, EVR-CP is working without problems.
maybe LAV Source is reporting wrong size/format on start, then switch to right format, and madVR cannot handel dynamic changes on size/format?

but you are the developer, you can debug.
(0002605)
onur   
2019-12-24 14:58   
to make testing easier,
i have uploaded mpc-hc.zip which has mpc-hc.ini for mpc-hc.
you must use new version of mpc-hc from here,
https://github.com/clsid2/mpc-hc/releases
because new version uses new LAV.

and you must place "Samsung Wonderland Demo.ts" in mpc-hc folder, then you can start file from fav menu.
thanks, onur
(0002606)
madshi   
2019-12-25 15:25   
Thanks. Are you clsid?

I'll look into this when I find some time, but atm I'm extremely busy working on the Envy, so it could take a while... ;-(
(0002613)
onur   
2020-01-14 00:56   
?clsid dont know what you mean?
its ok, look at it, when you have time.

i have another question.
Is it possible that AMT/ATI Vega Graphics can output BT2020 (Windows 10).
My Display dont reports BT2020.
i have BT2020 only if i activate HDR in Windows Settings, but then its fake BT2020 (i think) (wrong nit and..).
thanks for your work, regards, onur
(0002614)
madshi   
2020-01-14 11:02   
It's a bug in the AMD driver that it doesn't report BT.2020 to the display when madVR switches the AMD into HDR mode. You can ask AMD support to fix it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
624 [madVR] bug crash always 2019-10-30 20:01 2019-12-23 19:55
Reporter: Serpic Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 1.7.13 (e37826845)
Splitter (with version info): LAV 0.70.2.1-git
Decoder (with version info): LAV 0.70.2.1-git
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: <select>
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 980
GPU Driver Version: 26.21.14.3648
Summary: MPC-HC crashes after starting the video.
Description: MPC-HC crashes after starting a video with madVR. Without it, everything works. On version 1.8.8 I received this error.
https://cdn.discordapp.com/attachments/317922941205610531/639165974779789312/unknown.png
On version 1.7.13, program simply closes without errors.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002573)
madshi   
2019-10-30 23:31   
Unfortunately the crash information is so limited that I can't really do anything about it. You could try using DXVA2 copyback instead of native decoding, but the chance that this fixes the crash is rather small.
(0002575)
Serpic   
2019-10-31 10:50   
Sometimes the problem is solved by rebooting PC, sometimes not. I still do not understand why this is happening.
(0002576)
madshi   
2019-10-31 17:30   
I've no idea, either. Most users don't seem to have this problem.
(0002578)
Serpic   
2019-11-06 23:28   
So far, everything is fine, but here is the last dump.
https://cdn.discordapp.com/attachments/317922941205610531/641765718379200553/mpc-hc64.exe.2548.rar
(0002579)
madshi   
2019-11-12 16:50   
Unfortunately that's a crash dump for MPC-HC, not for madVR. Normally, when madVR crashes, it produces a nice crash report for me. Which doesn't seem to happen here (for unknown reasons).
(0002604)
cgbug   
2019-12-23 19:55   
These kind of crashes are often caused by third party software which "hook" their code into other processes.

For example your virusscanner. But also NVIDIA 3D Vision Driver, RivaTuner, and more other similar tools.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
629 [madVR] bug feature have not tried 2019-12-17 13:18 2019-12-17 13:18
Reporter: orenc Platform: Windows  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 1903  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-BE v1.5.4 (build 4850)
Splitter (with version info): LAV 0.74.1
Decoder (with version info): LAV 0.74.1
Decoding: DXVA2 Native
Deinterlacing: auto mode
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: Geforce GTX 1070 ti
GPU Driver Version: 425.31
Summary: Ability to toggle 3D stereo playback by keyboard
Description: Ability to control the operation of 3d stereo via keyboard would be of a great help.
If possible, adding a keyboard shortcut to control the toggle of Rendering -> stereo 3D -> "enable stereo 3d playback".
 This would be a very "couch & kids" friendly feature to force playing 3D movies in 2D when needed. Thank you!
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
542 [eac3to] bug major always 2018-03-02 14:29 2019-12-07 16:55
Reporter: bananajoe25 Platform:  
Assigned To: madshi OS:  
Priority: urgent OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.34
Summary: Sync issues when demuxing UHD BluRays with seamless branching.
Description: when demuxing the UHDs of Straight Outta Compton Unrated (2015), Coco (2017), Bad Santa 2 Unrated (2016), Close Encounters of the Third Kind (1977), Independence Day (1996), and many other UHDs, Audio and subtitles will get out of sync. eac3to "2ndpass/fixing" will make it go out of sync. sometimes the audio and subtitles will get out of sync even when using "-no2ndpass". for some reason -no2ndpass doesn't apply to subtitles. I've been using MakeMKV in the meantime. No sync issues with that program.
Tags:
Steps To Reproduce: Coco (2017)
just try demuxing the 800.mpls playlist. Atmos won't be able to get "fixed", but the ac3 track will. when you merge the streams with mkvmerge, you can hear atmos is in sync, but the ac3 track isn't. subtitles are also out of sync.

Straight Outta Compton (2015)
I've been trying to demux it with no2ndpass and 2ndpass. both times audio and subtitles are out of sync.

Additional Information: eac3to is useless for UHD BluRays that have seamless branching. eac3to can demux UHD BluRay Playlists with just one m2ts file completely fine no sync issues.
Attached Files: UHD_Dolby_Audio.zip (2,281 bytes) 2018-04-25 09:25
https://bugs.madshi.net/file_download.php?file_id=282&type=bug
UHD_DDPlus.zip (4,225 bytes) 2018-04-26 18:28
https://bugs.madshi.net/file_download.php?file_id=283&type=bug
Notes
(0002280)
SLKabaker   
2018-04-24 04:25   
eac3to does not have a problem with UHD and Seamless Branching for extracting Chapter Information and Video Streams. The problem seems to be with extracting Dolby TrueHD and Dolby Atmos (specifically with creating the embedded AC-3). The root of this problem looks to be with "libav/ffmpeg"; when using "-nero" (Nero 7 with Blu-ray/HD DVD Plug-in) there is no error. I was able to successfully extract Chapters, Video and Audio from an UHD with Seamless Branching by either doing the Chapters & Video without Audio or all three by including "-nero". Only when trying to extract audio and using the default "libav/ffmpeg" does the extraction have errors & fail. I have not tried a disc with DTS (DTS-HD MA or DTS-X), yet (ArcSoft or "libav/ffmpeg").
(0002281)
SLKabaker   
2018-04-25 09:36   
I decided to double check that it was "libav/ffmpeg" causing the problem. So, I attempted to extract the Dolby TrueHD (Atmos) track to LPCM (W64) from an UHD with Seamless Branching. It, still, had all the same errors. I uploaded the LOGs from using Nero and "libav/ffmpeg".
(0002283)
SLKabaker   
2018-04-26 18:35   
I have UHD Blu-rays with E-AC-3 Audio as well. I decided to see if, along with Dolby TrueHD (Atmos), eac3to had an issue with UHD Dolby Digital Plus. It turns out, yes, that eac3to cannot extract E-AC-3 Audio from UHD Blu-ray Discs. The UHD Blu-ray Discs with E-AC-3 Audio are, also, seamless branching discs. I do not have any UHD Blu-rays with E-AC-3 Audio that are not seamless branching. So, I cannot verify if this is exclusive to seamless branching like Dolby TrueHD (Atmos) is. However, it seemed likely since both are Dolby. I uploaded the logs from my attempts to extract E-AC-3 Audio with and without Nero; as well as, extracting the AC-3 Core.
(0002456)
nautilus7   
2018-12-28 13:16   
(Last edited: 2018-12-28 19:25)
I have the same issue. It happens with seamless branching discs. eac3to detects gaps for every kind of track.

-no2ndpass seems to give correct results (in sync) for ac3 and dts tracks. I was able to compare them with the audio tracks (same format) extracted from a blu-ray disc of the that movie. dts and ac3 tracks from uhd bd and bd seemed identical.

For truehd (with atmos) eac3to doesn't produce correct output (in sync). It's confirmed. -no2ndpass doesn't make any difference since gaps cannot be fixed in the truehd bitstream.

For e-ac3 I was not able to test if with -no2ndpass the output is correct.

Please madshi fix this! eac3to is one of a kind tool and provides functionality no other software does.

Thanks for the support!

(0002598)
deathbringer   
2019-12-07 16:55   
Having the same problem with the Dolby Atmos track from the seamless branching BD and UHD of Baywatch (https://www.amazon.it/Baywatch-Blu-Ray-4K-UltraHD/dp/B072FP6TBN/). The audio gets mor out of sync with the video, the longer the video lasts.

I came here, trying eac3to as a workaround suggested by Moritz Bunkus from MKVToolNix (https://gitlab.com/mbunkus/mkvtoolnix/issues/2684).

According to Nevcairiel from LAV Filters, the TrueHD streams have a timestamp, which has to be continuous and needs to be patched when (de)muxing from a seamless branching disc. (https://github.com/Nevcairiel/LAVFilters/issues/282)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
597 [madVR] bug minor always 2019-02-07 17:48 2019-12-06 11:38
Reporter: Ashkaan Platform: Windows  
Assigned To: OS: Windows 10 Pro  
Priority: low OS Version: 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 1.7.13
Splitter (with version info): LAV 0.70.2.1
Decoder (with version info): LAV 0.70.2.1
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 1080 Ti
GPU Driver Version: 417.71
Summary: OSD in MPC disappears when using MadVR
Description: Whether in full screen or windowed, when MadVR is running, the OSD stops displaying.
Tags:
Steps To Reproduce: Ensure MadVR is preferred. Play anything.
Additional Information:
Attached Files: madshi.zip (35,454 bytes) 2019-02-07 19:35
https://bugs.madshi.net/file_download.php?file_id=305&type=bug
Notes
(0002475)
madshi   
2019-02-07 18:30   
Which OSD do you mean exactly?
(0002476)
Ashkaan   
2019-02-07 18:31   
The MPC-HTC OSD. The one that tells you the time/time remaining and the filename when you first open a file.
(0002477)
madshi   
2019-02-07 18:32   
It seems to work fine for me. Is this with MPC-HC default settings?
(0002478)
Ashkaan   
2019-02-07 18:38   
Yes, totally default. Admittedly, I played with some of MadVRs settings to try to get this to work, so I don't remember what default was. Here are my settings:

Checked:
delay playback start until...
delay playback start after...
enable windowed overlay...
use a separate device for presentation...

Unchecked:
enable automatic fullscreen...
disable desktop composition...
use Direct3D...
use a separate device for DXVA...

Greyed:
only when media player...
present a frame...

CPU queue size: 16
GPU queue size: 8
(0002479)
madshi   
2019-02-07 18:41   
Did it ever work?

FWIW, I don't remember anyone ever reporting this issue yet. So it must be really rare/weird.

You can reset madVR settings to default by double clicking "restore default settings.bat" in the madVR folder.
(0002480)
Ashkaan   
2019-02-07 18:55   
I installed MadVR with Chocolatey and the .bat file isn't in the install location.
(0002481)
madshi   
2019-02-07 18:57   
Don't really know what to say. It works here. If I can't reproduce the problem, it's hard for me to do anything about it.
(0002482)
Ashkaan   
2019-02-07 18:58   
With those exact settings, it's working fine?
(0002483)
Ashkaan   
2019-02-07 19:05   
I'm trying to upload my settings for testing, but it won't let me. What format can I upload?
(0002484)
madshi   
2019-02-07 19:15   
Try zipped.
(0002485)
Ashkaan   
2019-02-07 19:36   
Nice! Zip worked. 7z didn't.
(0002486)
madshi   
2019-02-07 20:33   
I tried, activating each of your 3 monitors, and it always works fine for me with your settings.

Suggestions:

1) Try downloading MPC-BE, just as a test. Same problem there?
2) Try downloading madVR and install it in a separate folder, just as a test. Does it work then?
(0002487)
Ashkaan   
2019-02-07 22:06   
1) I just downloaded a portable MPC-BE with default settings, I added MadVR as preferred under external filters, and same problem.

2) I downloaded madVR portable, ran the install script, totally default, same problem (in both HC and BE).
(0002488)
madshi   
2019-02-07 22:15   
I've no explanation.

FWIW, when using madVR, the MPC-HC/BE OSD is no longer drawn by MPC, but by madVR instead. Which means that it looks different. But it should still appear. At least it does for me.

Maybe try a different GPU driver? But I really have no hope for that. Nobody else has ever reported this problem, so I've no idea what's going on.
(0002489)
Ashkaan   
2019-02-09 20:07   
PS: This guy has the same issue:

https://www.reddit.com/r/software/comments/25std5/mpcbe_with_madvr_no_osd/

I bet a lot of people have it, but they just don't notice. Any other ideas or leads for me to try? How does it work? Does it rely on GPU in any way?
(0002491)
madshi   
2019-02-11 15:19   
I'd say we should wait for the next official madVR build (I don't have an ETA for that yet). The next build will have some changes which could change the OSD behaviour. If the problem then still occurs, we'll have to do some debugging/digging. So I'll leave this bug report open until then.
(0002492)
Ashkaan   
2019-02-11 17:02   
Thank you
(0002596)
niczoom   
2019-12-06 04:15   
Ok, I had madvr setup under 'External Filters' and under 'Playback\Output' was EVR (custom pres.). This setup had no OSD showing. When I removed madvr from the 'External Filters' and set it under 'Playhback\Output' the OSD now works.
(0002597)
madshi   
2019-12-06 11:38   
Yes, it's recommended to set madVR under "Output", because otherwise MPC will think it renders with EVR, and thus behave differently.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
585 [madVR] bug major always 2018-11-21 20:07 2019-11-25 08:13
Reporter: jmonier Platform:  
Assigned To: madshi OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 92.17 (probably any version that supports HDR)
Media Player (with version info): Zoomplayer 14
Splitter (with version info): LAV
Decoder (with version info): LAV
Decoding: DXVA2 Copyback
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 1060, 1070
GPU Driver Version: 416.94
Summary: Cannot activate HDR via DisplayPort
Description: I have a problem with activating HDR via DisplayPort. This is with a LG 34BK95U - 5120x2160 which requires DP 1.4 to get the full width. HDMI (which limits it to 3840 width) works fine.

Basically, it seems that madVR does not recognize that HDR is supported via DP, and thus always does tonemap HDR instead. (And I HAVE checked that HDR can be activated otherwise via DP.)
Tags:
Steps To Reproduce: It only occurs with the above monitor (or probably with the 34WK95U which is identical) and only on the Displayport (1.4). Other than that, just play a HDR file with "passthrough HDR to display" set and "send HDR metadata to the display" checked and note that the HDR indicator does not appear and that the resulting image is from "tonemap HDR ..." instead.

I've included a log.

 
Additional Information: It may or may not be related, but the "identification" for this monitor is wrong, e.g. it shows NVIDIA for the manufacturer (among other things). (Again, this is only on the DisplayPort 1.4 input to this monitor - the HDMI input is fine and DisplayPort (1.2) inputs on other LG monitors are fine.) And Moninfo shows correct data for this DP 1.4 input.

Even stranger, additional identical identification entries keep getting added, always 2 at a time (but I don't know what triggers it). The data is identical for all, with all but the last grayed out. (I'm currently at 23 entries.)
Attached Files: madVR - log.zip (389,651 bytes) 2018-11-21 20:07
https://bugs.madshi.net/file_download.php?file_id=301&type=bug
Untitled.png (115,761 bytes) 2019-08-22 04:29
https://bugs.madshi.net/file_download.php?file_id=314&type=bug
Notes
(0002441)
jmonier   
2018-11-21 20:15   
For some reason, OS data did not appear. The problem occurs on both Win 8.1 and 10.
(0002443)
madshi   
2018-12-04 19:37   
That's really weird. I'll have to create a special build to collect more information, when I find some time...
(0002471)
jmonier   
2019-01-15 13:20   
Note that another user has reported (on Doom) what seems like exactly the same problem.
(0002472)
Dreamfall   
2019-01-16 04:49   
I have exactly the same problem. It seems that there's something wrong with NVIDIA driver 416.94 or above, 416.81 is the last working driver version. MadVR said my display does not support HDR after I upgrade to 417.22, after rolling back to 416.81 everything works fine.

Here's a thread I found in NVIDIA forum, maybe it's helpful:
https://forums.geforce.com/default/topic/1082012/geforce-drivers/hdr-not-working-with-movies-in-hdr-in-potplayer-madvr-with-new-drivers-416-94-and-newer/
(0002474)
jmonier   
2019-01-16 14:49   
(Last edited: 2019-01-16 15:10)
The problem reported directly above is NOT "exactly" the same problem as originally reported. On Win 8.1, the problem originally reported still exists with the Win 8.1 416.81 driver. I have not tested Win 10 with the 416.81 driver since I mostly use Win 8.1, although I previously tested it on Win 10 with more recent drivers.

Also, my problem is unique to to the Displayport connection on the 34WK/BK95 monitor. The HDMI port on this monitor is fine. I don't have any other monitor with both HDR and a Displayport so I don't know about any other monitor.

Information on the monitor used and whether it is on a Displayport would be very helpful.

(0002542)
zaockle   
2019-08-22 04:29   
(Last edited: 2019-08-22 04:32)
I am also having this exact same issue with an LG monitor (34GK950F). I haven't tried an HDMI connection, but it might behave like the others have reported. What's interesting that I'll add is that if I turn on the OS HDR, madVR WILL properly force output back to SDR when fullscreen with no context menu's open. But it won't work in reverse. Currently running studio driver 431.70 on a 2070S, LAV using CUVID, MPC-HC 1.8.7. Adding a screenshot.

(0002582)
zaockle   
2019-11-25 08:13   
Just following up, I was actually able to resolve this. I had to run DDU in safe mode a couple times in a row to completely remove all old drivers and monitor registry entries. Afterwards I installed the latest driver (441.28 studio) and it seems like madvr can read the EDID correctly now showing LG instead of NVIDIA as the manufacturer. it can aslo activate HDR from Win10 SDR mode when opening an HDR video.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
625 [madVR] bug crash always 2019-11-16 12:13 2019-11-16 12:13
Reporter: Dingguo Lee Platform: PC  
Assigned To: OS: Windows  
Priority: high OS Version: Windows10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.17
Media Player (with version info): Potplayer(64 bit) 1.7.19955
Splitter (with version info): LAV Splitter 0.74.1
Decoder (with version info): LAV Video Decoder 0.74.1
Decoding: DXVA2 Native
Deinterlacing: auto mode
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: 2080ti
GPU Driver Version: 441.12
Summary: Crashed every time I minmized the potplayer
Description: When I minmized the potplayer, it always popped up an alert as showed in the picture. And then the potplayer crashed anyway.
Tags: compatibility
Steps To Reproduce:
Additional Information:
Attached Files: bug madvr.png (10,075 bytes) 2019-11-16 12:13
https://bugs.madshi.net/file_download.php?file_id=320&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
622 [madVR] bug crash always 2019-10-02 07:56 2019-10-02 10:20
Reporter: cutedavyjones Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): PotPlayer 1.7.20538
Splitter (with version info): Built-In
Decoder (with version info): Built-In (From RN: Built-in FFmpeg HEVC H/W Decoder)
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: Radeon 5700XT
GPU Driver Version: 19.9.3
Summary: Amd Radeon 5700XT crashes on playback
Description: I was able to play and scroll through video for a bit, but it eventually crashes the GPU. Then GPU restarts and in 80-85% cases I need to restart PC (I tried this at least several times and only once the video came back and I had to kill the player process). Attaching video stream info.
Not sure how to obtain the crash logs from either video card or madvr.
Also, not sure about decoding settings because I am using built-in decoder (maybe not the best idea), so I made a guess.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: media-info.zip (1,638 bytes) 2019-10-02 07:56
https://bugs.madshi.net/file_download.php?file_id=318&type=bug
Notes
(0002570)
madshi   
2019-10-02 09:17   
Is that with default madVR settings? How much RAM does the GPU have? Stability issues like this are usually the fault of the GPU driver or it could be a hardware issue.

Sometimes stability issues like this can also happen if the GPU runs out of VRAM. But with 1080p video that seems unlikely, unless you've increased the madVR GPU queue size a lot?
(0002571)
cutedavyjones   
2019-10-02 09:19   
This is with default madvr settings. GPU has 8GB of RAM. It's possible that it could be a driver issue, and just in case I wrote to AMD support. What can I do to get more information about the issue?
(0002572)
huhn   
2019-10-02 10:20   
the RX 5700 series has serious driver issue related to video playback and high refreshrate displays.

this is a line out of driver 19.9.2 from the "fixed" part:
"System instability may be experienced on some Radeon RX 5700 series graphics system configurations when watching video content in a web browser."
the system was throwing an blue screen now the driver "only" crashes.
you can check the windows event viewer -> windows logs -> system the event id is 4101 for a driver recovery i recommend sorting by event id.

the AMD forum is full of it.
the RX 5700 series is suppose to run best with only one 60 hz screen and if you have an zen 2 with x570 board some user recommend not using PCIe 4.0 but 3.0 instead and recommend updating to a bios with agesa 1.0.0.3abba.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
619 [madVR] bug minor always 2019-09-24 06:21 2019-09-30 20:24
Reporter: fireattack Platform: PC  
Assigned To: madshi OS: Windows  
Priority: normal OS Version: 7  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-BE 1.5.3 (build 4488)
Splitter (with version info): MPC-BE built-in
Decoder (with version info): LAV video decoder 0.73.1
Decoding: Software
Deinterlacing: forced video mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 1050
GPU Driver Version: 430.86
Summary: Forced deinterlacing video mode or deint=on flag has no effect
Description: Forcing deinterlacing (type=video) doesn't seem to work.

The OSD will say "deinterlacing on" but no deinterlacing is happening.
Tags:
Steps To Reproduce: 1. Make sure deinterlacing feature in other parts of the playback is disabled, such as in player or decoder for testing purpose (I use LAV and just I set it to always output "progressive" flag).

2. Open a video which has actual content being (truly) interlaced.

3. Either:

1) Manually turn on deinterlacing using the shortcut (I think the default is ctrl+shift+alt+D) during the playback.

2) or simply add "deint=on" to the filename.
Additional Information: It *works* for IVTC, however.

If I put deint=film, or toggle on deinterlacing on and then toggle the type to "film", it can do the IVTC properly on telecined video.
Attached Files: bug-madvr.png (808,666 bytes) 2019-09-24 06:21
https://bugs.madshi.net/file_download.php?file_id=316&type=bug
Notes
(0002555)
madshi   
2019-09-24 08:21   
According to the OSD, deinterlacing seems to be active. Maybe the Nvidia DXVA deinterlacing simply fails to properly deinterlace this video, for some reason? Have you tried multiple different videos?
(0002556)
fireattack   
2019-09-24 08:42   
(Last edited: 2019-09-24 08:43)
Yes, it happens on all the videos.

I should mention that *AUTO* deinterlacing actually works (on this or any interlaced videos, when they have proper interlaced tag), only the forced one doesn't.

(0002558)
huhn   
2019-09-30 11:02   
i can confirmed this. it's quite odd and needs a change in the lavfilter settings to happen.

take a file that works with deinterlacing out of the box set lavfilter to deinterlacing to disabled (progressive) play the file press control+shift+alt+d for deinterlacing DXVA processing is loaded but doesn't do anything.
(0002559)
fireattack   
2019-09-30 11:05   
(Last edited: 2019-09-30 20:24)
Because this bug only happens to forced deinterlacing, not when there is a proper tag from upstream.

Alternatively, you can try with a video that has interlaced content but wrongly encoded/tagged as progressive (the principle is the same.)



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
604 [madVR] bug minor always 2019-03-10 12:32 2019-09-10 20:40
Reporter: vanden Platform: DL580G5+GTX650Ti  
Assigned To: OS: Windows 10 Ent x64  
Priority: normal OS Version: 1809  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC HC x64 1.84 + MPC HC x86 1.8.4
Splitter (with version info): LAV 0.73.1
Decoder (with version info): LAV 0.73.1
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: NVidia
GPU Model: GTX650Ti
GPU Driver Version: 417.71
Summary: madVR can use DXVA for chroma upscaling in 8bit (NV12 and RGB32) and in 16bit (P016) but not in 10bit (P010)
Description: For all the tests following LAV is in SOFTWARE Decoding Mode, File 1440p 10bit HDR (MPCHC x64).

If I uncheck P010 in LAV : LAV makes the converssion 10bit->16bit and in madVR I enter in 16 bit 420 (P016) and madVR makes a chroma upscaling in DXVA Mode !!!
I guess the HDR ton mapping is done in 16bit in this case ? but it does not have to be really embarrassing.
it works well GPU stable @ 58% CPU @ 15% :
https://imagizer.imageshack.com/img921/6238/o79YuP.jpg

If I uncheck P010 and P016 in LAV : LAV makes the convention 10bit->16bit in madVR I enter in 8bit 420 (NV12) and madVR makes a chroma upscaling in DXVA Mode !!!
I guess the HDR ton mapping is done in 8bit in this case ? Not ideal if that's the case.
it works well GPU stable @ 55% CPU @ 12% :
https://imagizer.imageshack.com/img923/9442/UcpGTF.jpg

If I uncheck all 420 (NV12, YV12, P010 and P016) and 422 (YuY2, UyUV, P210, v210 and P216) in LAV : In madVR I enter in RGB32 (LAV does chroma upscaling with I do not know what algorithm + convention YUV to RGB).
I guess the HDR ton mapping is done in 8bit in this case ? Not ideal if that's the case.
it does not work well, some presentation glitches GPU @ 79% CPU @ 19% :
https://imagizer.imageshack.com/img922/3079/WpxyNY.jpg

If I have everything checked in LAV : in madVR I enter in 10bit 420 (P010) and madVR does a chroma upscaling using TextureUnits/PixelShader (Bilinear, Cubic ...) and it does not work GPU @ 92% CPU @ 17% :
https://imagizer.imageshack.com/img924/3286/fv9OiE.jpg

If I have everything checked in LAV and screen set @ 2944x1656 : in madVR I enter in 10bit 420 (P010) and madVR makes a chroma+Luma upscaling (2560x1440->2944x1656) in DXVA Mode.
it works well GPU stable @ 71% CPU @ 16%
https://i.goopics.net/wEv2y.jpg

So madVR can use DXVA for chroma upscaling in 8bit (NV12 and RGB32) and in 16bit (P016) but not in 10bit (P010) ! it's very weird anyway !


[U]Edit :[/U]
For all tests following LAV is in SOFTWARE Decode Mode, File 3840x1606 10bit HDR (MPCHC x86 + Reclock). Screen in 3104x1756 and in MPCHC : Video Frame/Normal Size.

All the tests by modifying LAV does not work (NV12, P016, RGB32), example in NV12 :
https://imagizer.imageshack.com/img921/8541/1MFFhC.jpg

On the other hand If everything is ticked in LAV (P010) and I put -2% on the zoom in MPCHC (the image is resized in 3766x1576 / via DXVA chroma+Luma upscaling) it goes :
https://imagizer.imageshack.com/img922/2303/Fw3uXy.jpg

I guess in P010 and just DXVA choma upscaling it would be perfect ...
Tags:
Steps To Reproduce: alway with all P010 files
Additional Information:
Attached Files:
Notes
(0002500)
vanden   
2019-03-10 12:37   
(Last edited: 2019-03-10 16:10)
if I uncheck P010 and P016 in LAV : LAV makes the convention 10bit->8bit

i't's not 16 but 8 ....


Scaling algorithms (For all tests) :
- chroma upscaling = Bilinear
- image downscaling = DXVA2
- image upscaling = DXVA2

(0002554)
vanden   
2019-09-10 20:40   
No news ??


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
612 [madVR] bug minor always 2019-07-20 17:33 2019-08-03 23:11
Reporter: kathampy Platform:  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 1903  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-BE (64-bit) 1.5.3 (build 4488)
Splitter (with version info): LAV Splitter 0.74.1
Decoder (with version info): LAV Video Decoder 0.74.1
Decoding: DXVA2 Native
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: NVidia
GPU Model: GeForce RTX 2080 Ti
GPU Driver Version: 431.36
Summary: NVAPI HDR does not activate on primary display but works on secondary display
Description: I have two HDR capable displays:
Acer Predator X27 (Primary, DisplayPort, G-SYNC HDR)
LG B7 (Secondary, HDMI 2.0)

HDR is switched off in Windows for both displays.

When setting the desktop to "Second screen only" to use the LG B7, madVR is able to use NVNAPI to switch on HDR automatically.

However when setting the desktop to "PC screen only" or "Extend" to use the Predator X7, madVR is unable to switch on HDR automatically. I must switch on HDR in Windows manually for this monitor. I'm not sure if the correct HDR metadata is even being sent to the display.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002538)
kathampy   
2019-07-20 17:49   
I noticed in madVR Settings > Devices that the Predator X7 entry does not become bold, indicating madVR does not think it's running on the display at all.

Each time I launch madVR it creates a new "Identification <N>" under the device, and there is a huge list of old entries.

The "Display Modes" settings also have no effect on this monitor, further confirming madVR is not correctly detecting that it's running on this display.
(0002541)
kathampy   
2019-08-03 23:09   
(Last edited: 2019-08-03 23:11)
I found the cause of the bug. I have a 3rd physically unplugged display configured in madVR which I rarely use. However the presence of this display in the "devices" list causes madVR to malfunction and apply this display's settings (display modes, 3D LUT, etc) to the primary display. Deleting this entry from madVR while the display is unplugged makes the primary display settings start working. However this is still a bug because I need to reconfigure the 3rd display in madVR each time I plug it in.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
615 [madVR] bug minor have not tried 2019-08-03 05:08 2019-08-03 05:36
Reporter: ted423 Platform: x64  
Assigned To: OS: windows  
Priority: normal OS Version: 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): mpc-be
Splitter (with version info): mpc-be
Decoder (with version info): mpc-be
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: yes
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: gtx 960
GPU Driver Version: newest
Summary: can't use custom modes optimize data
Description: still show testmode no apply
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: 2019-08-03 11_06_31-.png (587,118 bytes) 2019-08-03 05:08
https://bugs.madshi.net/file_download.php?file_id=313&type=bug
Notes
(0002540)
ted423   
2019-08-03 05:36   
GPU Driver Version 431.60


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
614 [madVR] bug minor always 2019-07-31 23:34 2019-07-31 23:34
Reporter: cgbug Platform: Windows  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 1809  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 1.8.7
Splitter (with version info): LAV 0.74.1.20
Decoder (with version info): LAV 0.74.1.20
Decoding: DXVA2 Copyback
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: Radeon RX480
GPU Driver Version: 19.7.3
Summary: Video is displayed in upper left quadrant
Description: MPC-HC launched from uTorrent. The player inherits compatibility settings from the parent process.

To be specific:
__COMPAT_LAYER = PerProcessSystemDPIForceOff GdiDPIScaling DPIUnaware

DPI is set to 150%

Problem occurs with resolution set to 4K, but not with 1080p. Launching player from explorer works correctly.
Tags:
Steps To Reproduce: 1) Open command prompt
2) set the environment variable:
set __COMPAT_LAYER=PerProcessSystemDPIForceOff GdiDPIScaling DPIUnaware
3) Launch player from same command prompt.
Additional Information: http://codecs.forumotion.net/t3232-madvr-4k-playback-issue
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
611 [madVR] bug major always 2019-06-16 15:39 2019-06-16 15:39
Reporter: DMU Platform: AMD Ryzen 3 2200G  
Assigned To: OS: Windows 10 Pro  
Priority: normal OS Version: 1903  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC (64-bit) 1.8.6
Splitter (with version info): LAV 0.74.1
Decoder (with version info): LAV 0.74.1
Decoding: DXVA2 Copyback
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: Vega 8
GPU Driver Version: 19.6.1
Summary: Profiles not working properly
Description: "HDR" boolean value in profile rules not working properly. Have to use "bitDepth" to select the appropriate profile.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: madshi ticket.png (5,532,341 bytes) 2019-06-16 15:39
https://bugs.madshi.net/file_download.php?file_id=311&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
610 [madVR] bug minor always 2019-06-07 18:44 2019-06-07 18:44
Reporter: tickled_pink Platform: 64  
Assigned To: OS: Windows  
Priority: normal OS Version: 7 and 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-BE v1.5.3
Splitter (with version info): Lav 0.74.1
Decoder (with version info): Lav 0.74.1
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: AMD + Intel
GPU Model: AMD 7750 and Intel HD3000
GPU Driver Version: N/A
Summary: Device profile corruption after resume from sleep
Description: I setup a “profile group” for "display modes". The first profile (50hz) has only “1080p50” on the “list all display modes...” line with "restore original..." checked. The second profile (59hz) has only “1080p59” on the “list all display modes...” line with “restore original...” unchecked.
The “profile auto select rule” looks like:
if (deintFps = 50)
"50hz"
else
"59hz"
Tags:
Steps To Reproduce: When I put the PC to sleep and then wake it up and login via RDP (with Concurrent RDP Wrapper), the 59hz profile is gone and the 50hz profile has the 59hz profile settings.
Additional Information: I know madVR crashes if I try to make changes to a “device” over RDP but it normally keeps them when setup directly from the attached monitor.
My intent with this rule is to use smooth motion with 25fps video and only switch the display to 50Hz with 50fps video. I know this isn’t technically the best option but I don’t like excessive display switching/flickering and it still looks good to me.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
608 [eac3to] bug major always 2019-04-20 23:50 2019-04-20 23:50
Reporter: overdrive80 Platform: Intel  
Assigned To: OS: Windows NT  
Priority: urgent OS Version: Win 10 1809 x64  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: Lastest
Summary: Process freeze when pass1 file reach 1GB
Description:  I am trying use this line command in batch file: "-24.000 -changeTo23.976 -down32 -normalize -resampleTo48000 -r8brain", but process stop (blocked or paused) when *.pass1 file reach 1 GB.

Source file:

Origin: NTSC
Samplerate: 96000 Hz
Bitdepth: 32 float
Size: 3GB


Batch file:

@echo off
Title NTSC to FILM
COLOR A8

set "eac3to=C:\Portables\MeGUI\tools\eac3to\eac3to.exe" rem Put you directory for eac3to

md %~dp0Completed

for %%@ in (*.wav) do (

    "%eac3to%" "%%@" "%%~dpn@_FILM.wav" -24.000 -changeTo23.976 -down32 -normalize -resampleTo48000 -r8brain -log=NUL
    move "%%@" "%~dp0Completed" /Y
)

pause&exit

https://forum.doom9.org/showthread.php?p=1872274#post1872274
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
607 [eac3to] bug minor always 2019-04-19 12:22 2019-04-19 15:10
Reporter: overdrive80 Platform: Intel  
Assigned To: madshi OS: Win 10  
Priority: high OS Version: 1809  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: Last
Summary: Convert audio from 24.000 to 23.976
Description: Convert audio from 24.000 to 23.976 has issue of precision. https://forum.doom9.org/showthread.php?p=1872119#post1872119
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002518)
madshi   
2019-04-19 15:10   
libSSRC wants to use the source and target sampling rates as integer values, so no floating point. Which means I have to round them.

An additional inaccuracy comes from the use of 23.976 vs 24.000/1.001. Currently, my libSSRC code uses 23.976 instead of 24.000/1.001. I suppose that's something that I could (and should) improve.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
546 [madVR] bug crash always 2018-03-11 18:18 2019-04-17 15:39
Reporter: mclingo Platform: windows  
Assigned To: madshi OS: windows  
Priority: normal OS Version: windows 10  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: all versions I have tested, at least the last 5
Media Player (with version info): MPC-BE/HC - KODO DS
Splitter (with version info): LAV - all versions
Decoder (with version info): LAV - al versions
Decoding: DXVA2 Copyback
Deinterlacing: none (progressive)
DXVA2 Scaling Active: yes
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: AMD RX 550 and NVIDIA GTX 1050
GPU Driver Version: all recent versions
Summary: black screen, loss of HDMI or PC crash changing from 3D mode back to 4k desktop
Description: When playing a 3D MVC movie in any player, KODI DS, MPC-HC / MPC-BE for instance, it will play perfectly fine, smooth playback even when skipping with no frame drops or skips. However when you stop the movie and the MADVR has to switch back from 1080p MVC 3D MODE it fails, you either get a black screen or on some occasions it can totally freeze you PC.
Tags:
Steps To Reproduce: Play movie, stop movie
Additional Information: There are two workarounds.

1. Put your desktop in 1080p mode first before starting the movie, this way when it comes out of 3D mode it doesnt have to change resolution, this is where MADVR is falling over.

2. Use you media player to refresh rate switch instead, this works very well in KODI DS and MPC versions, however this is no use for NVIDIA card users who need to be able to set custom CRU.
Attached Files:
Notes
(0002378)
madshi   
2018-09-17 23:43   
It seems to work fine for me. Most other users don't seem to have this problem, either, I think? Have you tried different GPU driver versions?
(0002386)
mclingo   
2018-09-18 00:15   
ive had this problem for as long as I can remember through many driver versions but also two completely fresh PC rebuilds - and 3 different AMD cards.

could it be something to do with the way i have MADVR setup, when I use KODI DS refresh rate switching I have no problems at all, this only happens when I deploy MADVR refresh rate switching.

I used to be able to DEVCON reset to get the screen back but no i have to reboot, thats the only thing thats changed with driver versions.

Pretty sure other people have this problem to with AMD cards, thing is, there arent that many people with 3D 4K TV's so i'm not surprised this doesnt come up often on the forum.
(0002517)
mclingo   
2019-04-17 15:39   
Hi, i've been looking at this again, its actually got worse with the latest stable version, i've had to go back to v0.92.14.

3D movies open in a small square top right hand side of screen and not full screen, I also get HDMI loss when closing movie as usual.

If I untick FSE the movie opens and plays fine but I still get HDMI loss on stopping movie.

on V0.92.14 movie opens and plays fine and when I stop the movie it drops back to GUI fine (i'm using KODI DS)

Is there any difference with how MADVR is dealing with FSE between these versions maybe?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
606 [madVR] bug feature always 2019-03-28 10:01 2019-03-28 10:01
Reporter: Error404 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): Kodi 17.6
Splitter (with version info): lavfilter
Decoder (with version info): lavfilter
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: 1060
GPU Driver Version: 417
Summary: [Feature Request] make madvr profile variables useable for external programs or scripts
Description: If a madvr profile is activated an external program can be executed.
It would be nice if you could pass parameters to the program based on the profile variables of madvr.

As an example:
If we can enter something like this in the
"command line to execute when this profile is activated" field:
C:\myCinema.bat %srcWidth% %srcHeight% %fps% %ar%

With this, it would be possible to use this parameters in a batch file to control something in the Homecinema like screen masking.


(Many Thx for your great software,
I hope here is the right place to put the feature request in.)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
605 [madVR] bug major always 2019-03-17 10:40 2019-03-25 09:45
Reporter: kryptonite Platform: PC, MPC-HC + MadVR  
Assigned To: OS: Windows 10 x64  
Priority: high OS Version: 10.0.17763.379  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: MadVR v0.92.17 or madVRhdrMeasure78
Media Player (with version info): MPC-HC v1.84
Splitter (with version info): LAV v0.73.1
Decoder (with version info): LAV v0.73.1
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: NVidia
GPU Model: GTX 1060 6GB
GPU Driver Version: 417.75
Summary: Incorrect HDR nits reported
Description: Config:
Windows 10 x64 on the latest patches
MPC-HC v1.84
MadVR v0.92.17 or madVRhdrMeasure78
NVIDIA GTX 1060 6GB, drivers v417.75
LG C8 TV

Download files from here:
https://drive.google.com/drive/folders/17z94AGSQN7m0VLS1oDEkViQlr0wvpWhG

You'll that some of these files are mastered at higher than 1000 nits, but I don't see that reflecting in the madvr stats
Tags:
Steps To Reproduce:
Play 01. 240-1000nits.mp4 on MPC-HC + MadVR:
-when you press Ctrl+J on madvr, 1000 nits is correctly reported

Play 03. 900-4000nits.mp4 (or) 05. 700-10Knits.mp4 (or) 07. 3600-10Knits.mp4 or on MPC-HC + MadVR
-you'll still continue to see 100 nits reported
-Expected to see 4000 nits / 10,000 / 10,000 nits respectively

Since the max nits is being reported incorrectly, my TV tone maps accordingly only upto 1000 nits, and everything above >1000 nits is being clipped

If you however copy these files on usb drive and play them from the LG C8 TV directly, I see the TV tone map all these files very well upto 3800~4000 nits
03. 900-4000nits.mp4
05. 700-10Knits.mp4
07. 3600-10Knits.mp4

which leads me to believe the files themselves are fine, and the issue lies somewhere in the Windows -> Madvr -> NV drivers chain
Additional Information:
Attached Files: 03. 900-4000nits.mp4 on PC with Madvr.jpg (1,825,202 bytes) 2019-03-17 15:57
https://bugs.madshi.net/file_download.php?file_id=307&type=bug
03. 900-4000nits.mp4 on PC with Madvr with debug OSD enabled.jpg (2,185,878 bytes) 2019-03-17 15:58
https://bugs.madshi.net/file_download.php?file_id=308&type=bug
03. 900-4000nits.mp4 on TV directly via USB.jpg (1,767,167 bytes) 2019-03-17 15:58
https://bugs.madshi.net/file_download.php?file_id=309&type=bug
Notes
(0002501)
madshi   
2019-03-17 11:48   
It's a known issue with the newer Nvidia drivers. I've already reported this to Nvidia, but they've not fixed it yet. I hope it will be fixed in a future driver version. For now you can downgrade to an older driver version. I think the last one that sent correct metadata to the display was 397.93.
(0002502)
kryptonite   
2019-03-17 14:33   
(Last edited: 2019-03-17 14:41)
Hi,
I just tried drivers 385.25 through 398.11, and with the same files, I still see HDR 1000 nits in the madVR stats for these clipping tests, so something is still off.

I should have mentioned this before, there are other videos/movies in my collection @ 4000 nits and # 10,000 nits and madVr shows the rights stats for these, irrespective of whether I use driver 385.25 or 417.75, so I guess my issue is specific to these files. And these files themselves seem to be fine because they cleanly tone map on my TV upto 4000 nits if played directly from the TV via USB, but only upto 1000 nits when played through madvr.

Would be great if you could please take a look.

Thanks.

(0002503)
madshi   
2019-03-17 15:38   
What do you mean with "madVR stats" exactly?
(0002504)
kryptonite   
2019-03-17 15:59   
I'm referring to the debug OSD - the CTRL + J shortcut.
Also attaching 3 pictures

1) 03. 900-4000nits.mp4 on PC with Madvr.jpg
-where I'm playing the "03. 900-4000nits.mp4" file on my PC with Madvr on my LG C8 and you can see the blocks upto 1000 nits are lit, others are clipped

2) 03. 900-4000nits.mp4 on PC with Madvr with debug OSD enabled.jpg
-where I'm playing the "03. 900-4000nits.mp4" file on my PC with Madvr on my LG C8 with the debug OSD enabled and you can see HDR 1000 nits being reported, which also explains why everything above 1000 nits is being clipped as seen in (1). I think this file is at 4000 nits.

3) 03. 900-4000nits.mp4 on TV directly via USB.jpg
-where I'm playing the "03. 900-4000nits.mp4" file on my LG C8 TV directly via USB, and you can see the TV is tone mapping to almost 4000 nits, beyond which it's clipped
(0002505)
madshi   
2019-03-17 16:06   
You mean the "HDR 1000 nits" information in the OSD? That's information madVR receives from the splitter/decoder. Which decoder are you using? LAV Video Decoder?
(0002506)
kryptonite   
2019-03-17 16:10   
->You mean the "HDR 1000 nits" information in the OSD?
Yes, correct

->That's information madVR receives from the splitter/decoder. Which decoder are you using? LAV Video Decoder?
Yup, LAV 0.73.1, also tried 0.74 that was released yesterday.
(0002507)
madshi   
2019-03-17 16:51   
Ok, I've checked file "900-4000nits.mp4". It has the following metadata:

Mastering Display Peak: 1000 nits
MaxCLL: 4000 nits
MaxFALL: 1600 nits

All of this data is incorrect, though. madVR actually measures more than 6000 nits.

Anyway, the latest madVR test build should forward the proper metadata to the display, when using a proper Nvidia driver version. I'm not sure right now if the official madVR build also does that. You can try the latest test build here:

http://madshi.net/madVRhdrMeasure78.zip
(0002508)
kryptonite   
2019-03-17 17:06   
I'm actually right now on http://madshi.net/madVRhdrMeasure78.zip, and I've set it to pass through to display

With this madvr build, I tried 385.25 through 398.11 and also the latest 417.x and 419.x drivers, but nothing helps tone map to 4000 nits really.

With 385.25 & 398.11, I see peak white tone map to 1000 nits, I see one or 2 colours extend to about 1500 nits maybe, but cyan for example doesn't even tonemap to 700 nits, clips way before that

With 417.x & 419.x, I see peak white and all colours tone map very well to 1000 nits, but nothing beyond.

And everything is very different when natively played on the TV, where peak white and colour all tone map well upto 3000 nits+.

So, I'm not sure where the issue is
(0002509)
madshi   
2019-03-17 17:19   
I don't really know. Of course the video is going through very different processing paths when playing with the internal TV player vs when being fed via HDMI. So it's possible the TV doesn't handle HDR input via RGB very well.

I suppose you've already set your GPU and madVR and your TV all to RGB Full (0-255), right?
(0002510)
kryptonite   
2019-03-17 17:26   
(Last edited: 2019-03-17 17:27)
MadVR and NVIDIA Video player settings are at 0-255
Display is at 3840x2160, YCBCR 4:2:2, 12bit, 60Hz, which will be 16-235, can't do RGB 10/12bit over HDMI 2.0b
HDMI Deep colour is enabled on TV to switch to HDR on demand

If I set display to 3840x2160, RGB Full (0-255), 8bit, 60Hz, then the TV tone maps to 600-650 nits with these files, and clips everything after that, which is even worse

(0002511)
madshi   
2019-03-17 17:35   
I've no idea what happens if you send YCbCr to the TV. The Nvidia driver will convert my RGB rendered pixels to 4:2:2, using an unknown color matrix, an unknown chroma downscaling algorithm, and possibly no dithering. It's really really bad. RGB 8bit should be *much* better. Have you tried that with a proper driver, e.g. 397.93 or older?

People worry too much about bitdepth, to be honest. 8bit RGB is perfectly fine, if you use lossless high quality dithering. We do need as high as possible bitdepth for lossy content encoding. But during lossless HDMI transport, dithered 8bit is plenty good enough.
(0002512)
kryptonite   
2019-03-17 17:56   
(Last edited: 2019-03-17 18:00)
Appreciate your quick responses mate, I hadn't tried, but just did.

Driver = 397.93
Madvr set to pass through
RGB 8-bit Full 0-255 set in NV display settings
MadVR settings, NVIDIA video color settings, LAV settings set to 0-255

And I got exactly the same thing as

Driver = 417.75
Madvr set to pass through
YCBCR 12bit Limited 16-235 set in NV display settings
MadVR settings, NVIDIA video color settings, LAV settings set to 0-255

Both tone map up to 1000 nits (whites & all the colours), that's it. They're identical.

(0002513)
madshi   
2019-03-17 18:55   
Maybe the LG ignores MaxCLL when receiving RGB via HDMI? The Mastering Monitor Metadata is only 1000 nits, maybe the LG uses that in this situation? I'm only guessing, of course.
(0002514)
kryptonite   
2019-03-18 12:42   
Might very well be the case, I've made a post there on the creator's thread, hope he could share some ideas:
https://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set-7.html
(0002515)
kryptonite   
2019-03-20 12:54   
Hi,
Hope you had a chance to follow the discussion here:
https://www.avsforum.com/forum/139-display-calibration/2943380-hdr10-test-patterns-set-8.html

I think we've provided that Mastering display level has an effect on the TV's tonemapping when using MPC-HC + MadVR, but if the same file is played through the TV's internal player via USB, it responds to MaxCLL instead.

While the author of the files has offered to re-encode the files using matching MDL/maxCLL values, I was wondering if there is anything we should do on the madvr front to help the TV respond to maxCLL instead of MDL while using MPC-HC + madVR (we know the TV does repond to maxCLL when using it's internal player via USB)
(0002516)
madshi   
2019-03-25 09:45   
What are you suggesting? That I set MDL to maxCLL? The problem with this approach is that maxCLL doesn't have to be accurate. So if I set MDL to the same value as maxCLL, this might make things worse for some movies/display combinations. E.g. there are several movies which have these values set to some standard values which can be far too low, which would result in clipping, if the display actually made use of those values.

Actually these test patterns don't have accurate maxCLL values, either. madVR detects that by looking at whether the numbers are rounded to xxx50/xxx00. If both maxCLL and madFALL are rounded that way, there's a 99.96% chance that they were manually set and not properly calculated. In that case madVR completely ignores the maxCLL and maxFALL data.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
603 [madVR] bug block always 2019-03-09 05:32 2019-03-09 05:40
Reporter: huhn Platform: x64  
Assigned To: OS: win 10  
Priority: normal OS Version: 17134  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): mpc-hc 1.8.4
Splitter (with version info): lav 73.1
Decoder (with version info): lav 73.1
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: NVidia
GPU Model: 1060 6 gb
GPU Driver Version: 419.35
Summary: system lock after using an windows hot key
Description: the system can lock and needs to be power cycled when an hot key is used to move the player from one screen to another one.
Tags:
Steps To Reproduce: general settings checked:
delay playback until render queue is full
delay playback start after seeking. too
enable windowed overlay
use d3d11 for presentation
present a frame for every VSync
use seperate device for presentation
use seperate device for DXVA

these settings where taken from the person that report the bug i didn't try other settings system hardlock are not fun to deal with.

i moved the player from a 1080p60 screen to a 1080p120 screen using shift+windows+ü right arrow key.
the system will hang after doing this.
Additional Information: i got a debug log it's mostly way to long i needed to hard cycle the system to stop it from recording
Attached Files: madVR - log.zip (5,907,604 bytes) 2019-03-09 05:32
https://bugs.madshi.net/file_download.php?file_id=306&type=bug
Notes
(0002499)
huhn   
2019-03-09 05:40   
it'S shift+windows+right arrow key sorry.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
602 [madVR] bug block always 2019-03-09 05:30 2019-03-09 05:30
Reporter: huhn Platform: win 10  
Assigned To: OS: OS Name Microsoft Windows 10 Pro  
Priority: normal OS Version: 17134  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version:
Media Player (with version info):
Splitter (with version info):
Decoder (with version info):
Decoding:
Deinterlacing:
DXVA2 Scaling Active:
Aero / Desktop Composition:
Problem occurs with mode:
GPU Manufacturer:
GPU Model:
GPU Driver Version:
Summary: system lock after using an windows hot key
Description: the system can lock and needs to be power cycled when an hot key is used to move the player.
Tags:
Steps To Reproduce: general settings checked:
delay playback until render queue is full
delay playback start after seeking. too
enable windowed overlay
use d3d11 for presentation
present a frame for every VSync
use seperate device for presentation
use seperate device for DXVA

these settings where taken from the person that report the bug i didn't try other settings system hardlock are not fun to deal with.

i moved the player from a 1080p60 screen to a 1080p120 screen using shift+windows+ü right arrow key.
the system will hang after doing this.
Additional Information: i got a debug log it's mostly way to long i needed to hard cycle the system to stop it from recording
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
555 [madVR] bug major always 2018-05-08 14:38 2019-03-04 12:35
Reporter: Alessa Platform: Windows  
Assigned To: madshi OS: Windows 7 x64 Service Pack 1  
Priority: normal OS Version: 7601  
Status: feedback Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 1.7.9
Splitter (with version info): 0.68.1.33-git
Decoder (with version info): 0.68.1.33-git
Decoding: DXVA2 Native
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 970
GPU Driver Version: 390.77
Summary: anoying Osd nag to update LAV filters always on with no way to disable it..
Description: I have to use the old version of LAV audio decoders because the new one makes a sound of lesser audiophile quality.
the anoying Osd nag "Please update Lavfilters to the latest version..." is always on at the begining of every video.
I could not find any way to disable it.
It prevents me from being able to make Public presentations of videos playlists using Madvr because it ruins the experience to have this OSD message at the begining of every video..
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002285)
madshi   
2018-05-08 22:36   
How do newer LAV versions reduce audiophile quality? Isn't this something you should discuss with the LAV developer?

I've been regularly receiving crash reports from older LAV versions. The crash occurs in LAV, but madVR detects the crash and reports it to the user. As a result, it's me getting all the crash notifications and user support requests. These crashes only occurred with older LAV versions and were fixed in newer builds. That's why madVR complains about LAV versions which are known to cause crashes.
(0002286)
Alessa   
2018-05-09 01:21   
Thanks, I understand your reason for making this update LAV message impossible to remove, and you are right I should discuss the diminishing audiophile quality of newer audio LAV filters with LAV devellopers.
It is just in the mean time I was hoping to find a workaround to avoid seeing always "Please update Lavfilters to the latest version..." until the newer LAV version get better audio quality.
(0002287)
madshi   
2018-05-09 09:00   
Well, you're the only user asking for this, so the question for me is if it's worth spending development time on just adding a new feature for one user. My development time is very limited at the moment, anyway. So I prefer to spend my time on things that are beneficial to as many users as possible.

I'd say if there's a valid technical reason why older LAV versions had better audio quality, and if nevcairiel refuses to fix the issue, for some reason, then I'd be willing to add an undocumented hack for you to disable the madVR warnings message. But otherwise please have patience and let nevcairiel take care of the problem. Of course you should properly report it to him, with as many details and explanations as necessary for him to understand and fix the problem.
(0002288)
Alessa   
2018-05-09 10:18   
(Last edited: 2018-05-09 11:28)
Thanks, i will try to pinpoint at wich LAV filter version the audio start lost quality exactly and report the issue to nevcairiel in the hope that it can get fixed.

(0002380)
madshi   
2018-09-17 23:47   
I'll close this for now. If there's a need to reopen, feel free to do that.
(0002494)
Muhd   
2019-03-03 14:30   
This is still happening with newest version of LAV and newest version of madVR
(0002495)
madshi   
2019-03-03 14:52   
Is it possible you have multiple LAV installations on your PC? E.g. some media players ship with their own private LAV installation. If madVR complains about the LAV version, it's *probably* a correct warning.
(0002498)
Muhd   
2019-03-04 12:35   
(Last edited: 2019-03-04 12:35)
Ah yes that's what happened. The media player was using LAV from another player's installation. I updated the LAV in that directory and now it is actually using the newest version.

Thanks



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
601 [madVR] bug minor always 2019-02-26 06:57 2019-02-26 06:57
Reporter: krthebee Platform: Windows  
Assigned To: OS: 8.1  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 1.7.13
Splitter (with version info): LAV Splitter 0.70.2.1-git
Decoder (with version info): LAV Video Decoder 0.70.2.1-git
Decoding: DXVA2 Copyback
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 970
GPU Driver Version: 388.13
Summary: Long startup when the internet connection is limited.
Description: My internet connection was down and I tried to watch a video with MPC-HC + MadVR and noticed videos taking abnormally long to start(10+ seconds). After the video had loaded switching to another video was quick like normal, but if I closed MPC-HC and tried opening another video it would be slow again.

When using a different renderer in MPC-HC this problem did not occur. I reset both MPC-HC and MADVR's settings and it didn't not fix the issue.

Disabling my ethernet adapter made the issue go away. And now that my internet is back and working MadVR is behaving normally again.
Tags:
Steps To Reproduce: I disabled the ethernet adapter and madvr behaved normally, but I could reproduce it by enabling the ethernet adapter and loading another video.
Additional Information: I have "delay playback start until render queue is full" enabled. Without it selected the video would take less time to start playing, but would play for a few seconds with a black screen and drop hundreds of frames.

Sorry, if I did anything wrong, first time submitting a bug and thank you for all your hard work on the program!
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
600 [madVR] bug minor always 2019-02-25 15:57 2019-02-25 15:57
Reporter: tp4tissue Platform: Intel z68/z97/ amd gpu  
Assigned To: OS: Win 7/10  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 94.17
Media Player (with version info): mpchc last
Splitter (with version info): lav filter 73.1
Decoder (with version info): All
Decoding: DXVA2 Copyback
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: 1060, 580, 7970, 7870
GPU Driver Version: Happens regardless of version
Summary: Blackbar detection not working correctly with NGU
Description: For example

If using NGU, the scalar creates a double of 1918 or 1919 width, This causes madvr to do Lanzcos again to reach the destination width of 3840

In normal scalar, black bar detection can be set to ignore scalar if pixel change is small. but I suppose this is not run a second time to disable scalar after NGU.

This eats quite alot of performance depending on the video spec and is certainly undesirable since NGU is already giving us the goods, why put lanczos on top of that just to cut away 1 pixel vertical bar.
Tags:
Steps To Reproduce:
Additional Information: For most wide screen video cases, a quick fix would be to disable vertical bar detection, but keep horizontal bar detection. because they're usually small if they exist, and I think most users can live with that to preserve the performance and straight NGU output.

Also, detection could be run again after NGU, that way maybe the Ignore scaling function would work.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
599 [madVR] bug minor always 2019-02-23 06:18 2019-02-23 08:48
Reporter: glc650 Platform: i3-3220 3.3, 4GB RAM, 256GB SSD  
Assigned To: OS: Windows 10 Pro  
Priority: normal OS Version: 1809  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 92.17
Media Player (with version info): mpc-hc 1.8.4
Splitter (with version info): LAV 0.73.1
Decoder (with version info): LAV 0.73.1
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: NVidia
GPU Model: GTX 1060
GPU Driver Version: 418.91
Summary: frames in advance = 16 but shows x/15 on osd
Description: Present several frames in advance is enabled with 16 but present queue shows x/15 on the OSD. Doesn't seem to affect anything.
Tags:
Steps To Reproduce: just select the above settings...soon as I change to something else (say 14) it shows up correctly on the osd
Additional Information: decoding is actually NOT software but handled by LAV d3d11 cb direct
Attached Files:
Notes
(0002493)
madshi   
2019-02-23 08:48   
This is not a bug but a Direct3D limitation. It doesn't go above 15.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
17 [madVR] bug minor always 2013-02-24 13:28 2019-02-21 13:32
Reporter: DarkSpace Platform: x64  
Assigned To: madshi OS: Windows 7 Ultimate  
Priority: normal OS Version: 6.1.7601  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.86.1
Media Player (with version info): MPC-HC 1.6.5.6366 (744df1c)
Splitter (with version info): Haali Media Splitter 1.11.288.0
Decoder (with version info): LAV Video Decoder 0.55.3
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: Radeon HD 6970M
GPU Driver Version: 2D Driver 8.01.01.1162, Direct3D 7.14.10.0841, OpenGL 6.14.10.10834
Summary: Display Aspect Ratio changes too early
Description: When playing files that change the Video Aspect Ratio mid-stream, the Target Rectangle changes too early so that the last few frames of the un-AR-changed sequence appear distorted.
Tags:
Steps To Reproduce: Any file that changes Display Aspect Ratio mid-stream should do, the attached files achieve this via Ordered Chapters, so it's irrelevant which file you open as the order stays the same:
Each of the files contains 50 frames and the respective frame numbers (0-49 and 50-99) displayed on the right side.
Frames 0-49 are to be displayed in 16:9 Aspect Ratio, and frames 50-99 in 4:3 Aspect Ratio.
Additional Information: The other renderers I tested (EVR-CP, EVR Sync and Haali Renderer) worked fine regarding the time at which the Aspect Ratio switch was supposed to happen.

How much earlier than it's supposed to the switch happens appears to be somewhat connected to the CPU Queue size (the larger, the earlier), but it also happens earlier in Windowed Mode than it does in FSE Mode.


I'm not yet sure if the fact that madVR only displays up to frame 98 is a bug in madVR or in the player or somewhere else, as all my tests with EVR stopped at a much earlier frame than 98, and Haali Renderer displays a blank screen instead of the last frame.
Attached Files: test.rar (397,960 bytes) 2013-02-24 13:28
https://bugs.madshi.net/file_download.php?file_id=2&type=bug
Notes
(0000046)
madshi   
2013-03-16 11:10   
I was aware of this issue, but didn't get around fixing it yet. Not sure how difficult it will be to fix. Which means that I don't know how soon I'll be able to implement this.
(0000051)
DarkSpace   
2013-03-17 19:30   
Well, the samples were unnecessary then, it seems. Anyway, thanks for the response, I appreciate your looking into it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
598 [madVR] bug feature always 2019-02-19 22:20 2019-02-19 22:20
Reporter: ParcelRot Platform:  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 1809  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC 1.7.x
Splitter (with version info): LAV 0.73
Decoder (with version info): LAV 0.73
Decoding: DXVA2 Copyback
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: Geforce GTX 1080
GPU Driver Version: 399.24
Summary: Support for 47 hz and 48 hz
Description: Recent NVIDIA drivers have made it extremely difficult to use my nearly-perfect 23.976 hz custom resolutions. NVIDIA created a 23.9775 hz, which conflicts with the 23.976 hz settings I've been using for the last 3 years.

I cannot play 24 hz and 23.976 hz videos if I create a 47.952 hz custom resolution (see additional information for my reasons for doing this).

My workaround is to create a 47.952 hz resolution. Unfortunately, MadVR fails to use this if I also have 1080p24 in the display modes line.

If my display mode line contains 1080p47 but does NOT contain 1080p24, it works fine. If 1080p47 AND 1080p24 is defined, MadVR always selects 1080p24, which is incorrect and I get repeated frames.
Tags:
Steps To Reproduce: Define a 47.952 hz 1920x1080p custom resolution. Assuming late version NVIDIA drivers (399.24 and later is a good baseline). This mode works on my Sony HW40ES projector, which was very surprising.

Add the following to MadVR Display Mode: 1080p47, 1080p24.

Play a 23.976 hz video file. MadVR will always select the 1080p24, ignoring the proper 47.952 hz, resulting in repeated frames.

Edit the Display Mode to only contain 1080p47. Now the 23.976 hz file plays back at 47.952hz as expected.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
594 [madVR] bug major always 2019-01-18 17:12 2019-01-18 17:12
Reporter: tp4tissue Platform: Intel z68, z97, AMD gpu.  
Assigned To: OS: Windows 10, Windows 7  
Priority: normal OS Version: 1809,  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPCHC
Splitter (with version info): LAV
Decoder (with version info): Latest
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: 7870xt, RX 580
GPU Driver Version: catalyst 15.11 (last one for 7870xt, Tested 18.5.1 and 19.1.1 w/ RX580
Summary: Measure frame nits does not show up on OSD, Highlight Recovery does not work
Description: I do not know if the measure nits function is working, but it does not show up on the OSD, like on my Nvidia setup.

Highlight recovery produces no change between off -- minimum -- max

I've tested both on my amd 7870xt and rx 580
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
592 [madVR] bug crash always 2019-01-12 11:25 2019-01-14 14:40
Reporter: kathampy Platform:  
Assigned To: OS: Windows 10  
Priority: normal OS Version: 1809  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-BE x64 1.5.2 (build 4105)
Splitter (with version info): LAV SPlitter 0.73.1
Decoder (with version info): LAV Video Decoder 0.73.1
Decoding: DXVA2 Native
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: RTX 2080 Ti
GPU Driver Version: 417.58
Summary: Minimizing player on Monitor 1 causes display mode change on Monitor 2
Description: Monitor 1 does not have any "display modes" settings.
Monitor 2 has "switch to matching display mode" configured.
The desktop is set to "Extend" mode.
MPC-BE is playing on Monitor 1.
Monitor 2 has no windows on it.
Tags:
Steps To Reproduce: Minimize MPC-BE or press Win+D.
Monitor 2 has its display mode change unnecessarily.

Restore the window.
Video playback may freeze. MPC-HC hangs on closing the window.
Additional Information:
Attached Files:
Notes
(0002467)
madshi   
2019-01-13 11:12   
Hmmmm... Which is your primary monitor? Monitor 1 or 2?
(0002468)
kathampy   
2019-01-14 14:34   
(Last edited: 2019-01-14 14:37)
Monitor 1 is primary. I do not use Monitor 2 at all in extended desktop mode - it's offscreen in the top left corner for HDMI audio output only. When I do use Monitor 2 (for HDR), I use it exclusively as the only display, hence I've set the display modes on it.

A related problem is when I maximize an application window on Monitor 1 and it touches the top left corner, the animation stutters, probably due to it copying the framebuffer to Monitor 2. This should only happen when moving the window into Monitor 2's space, but it happens even on maximize.

However for this bug report, MPC-BE is not maximized and runs in a small window on Monitor 1. Minimizing it does not cause it to touch anything close to the top left corner where Monitor 2 is.

(0002469)
madshi   
2019-01-14 14:36   
Hmmmm... If you use monitor 2 only for HDMI audio output, why do you have "switch to matching display mode" activated?

My best guess is that in minimized state, for some reason madVR considers the media player to be on monitor 2. Not sure why, though...
(0002470)
kathampy   
2019-01-14 14:38   
(Last edited: 2019-01-14 14:40)
I use Monitor 2 exclusively sometimes for HDR and I need the display modes to correctly use it's built-in frame interpolation.

Even if it switches the display mode on Monitor 2 due to a bug, it shouldn't crash or freeze on restoring the window.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
590 [madVR] bug minor always 2019-01-03 21:40 2019-01-07 18:51
Reporter: Dreamject Platform: Laptop i7-3632QM HD4000  
Assigned To: OS: Win10  
Priority: normal OS Version: Last  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): any PotPlayer
Splitter (with version info): internal PP splitter
Decoder (with version info): interdan ffmpeg/lav
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: Intel
GPU Model: HD4000
GPU Driver Version: 10.18.10.5059
Summary: Dropped frames on bigger than 1.0 speed
Description: If I play files faster than 1.0 speed , I have more and more dropped frames, the result is unwatchable. Maybe my config is not enought, but, for example, if I have 24 fps movie and speed it to 1.5, I get 36 frames. But if I use svp with multiplers to make 60fps and 1x speed, madvr works well.

Even if I select worst quality settings and increase speed, my GPU and CPU loaded <50% but I still have lot of dropped frames
Tags:
Steps To Reproduce: Increase playback speed (at least in PotPlayer)
Additional Information:
Attached Files:
Notes
(0002466)
madshi   
2019-01-07 18:51   
Which refresh rate does your monitor/display have when you increase the playback speed with e.g. a 24fps movie?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
588 [madVR] bug minor always 2018-12-23 20:48 2018-12-23 22:03
Reporter: truexfan81 Platform: desktop  
Assigned To: OS: Windows 10  
Priority: normal OS Version: any  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: any
Media Player (with version info): any
Splitter (with version info): any
Decoder (with version info): any
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: any
GPU Driver Version: any
Summary: display mode changes refresh rate even when a matching mode is not specified
Description: when playing a pal 25fps video, madvr changes the refresh rate to 29.97fps resulting in choppy playback. expected behavior: when no mode is specified for 25fps it should leave the screen at default refresh rate.
Tags:
Steps To Reproduce: play a 25fps video on a screen that doesn't support 25fps
Additional Information:
Attached Files:
Notes
(0002455)
madshi   
2018-12-23 22:03   
Currently madVR by design picks one of the modes from your list and activates that. That's not a bug, but intended behaviour.

Sooner or later I'm going to redesign the whole display mode section. But for now, it's not going to change, sorry.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
377 [eac3to] bug minor always 2016-01-02 21:10 2018-12-13 19:35
Reporter: GCRaistlin Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: Converting dts to wav with big negative delay produces incorrect results
Description: Duration of True.Lies.1994.1080i.MVO-НТВ+.ac3 is 01:21:38.
Command line:
eac3to "True.Lies.1994.1080i.MVO-НТВ+.ac3" "True.Lies.1994.1080i.MVO-НТВ+.wavs" -3600000ms
produces wavs which duration is 52:42 (instead of expected 21:38).

True.Lies.1994.1080i.MVO-НТВ+.ac3: http://mir.cr/DNQ1WYKF
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002454)
GCRaistlin   
2018-12-13 19:35   
The issue is still present in 3.34. The command line:
eac3to 00000.track_4353.ac3 [e]00000.track_4353.wav -6514000ms
produces file which duration is 1:38:12 instead of expected 0:05:00 (as 00000.track_4353.ac3 is 1:53:34).

00000.track_4353.ac3: https://drive.google.com/open?id=1oYteOwBXFnIiyeYHxzeQPyJftvKZfY7C


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
374 [eac3to] bug minor always 2016-01-02 17:08 2018-12-09 22:10
Reporter: GCRaistlin Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: Cyrillic chars are being displayed incorrectly
Description: eac3to output is ANSI while the console is OEM. It has no effect for Latin chars but Cyrillic chars are being displayed like a garbage. Screenshot 1 shows how it looks and screenshot 2 shows how it should look.
For other command-line tools with the similar output issue it is possible to use a batch wrapper (that's how I got the screenshot 2):
util.exe %*| iconv.exe -c -f cp1251 -t 866
But it's actually useless for eac3to 'cause nothing is displayed until the process finished.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: eac3to1.png (9,860 bytes) 2016-01-02 17:08
https://bugs.madshi.net/file_download.php?file_id=190&type=bug
eac3to2.png (11,927 bytes) 2016-01-02 17:08
https://bugs.madshi.net/file_download.php?file_id=191&type=bug
Notes
(0002446)
GCRaistlin   
2018-12-09 21:51   
(Last edited: 2018-12-09 22:10)
Workaround - eac3to.cmd:

@echo off
for /f "tokens=2 delims=:" %%A in ('chcp') do set CP=%%A
>nul chcp 1251
eac3to.exe %*
if errorlevel 1 pause
>nul chcp %CP%



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
586 [madVR] bug minor always 2018-11-29 21:12 2018-12-05 10:58
Reporter: MK36 Platform: Acer Aspire VX5-591G  
Assigned To: madshi OS: Windows 10 Home  
Priority: low OS Version: 1809 64-bit  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC-HC (Nightly, 64-bit) 1.8.3.8 (fc4fb469a)
Splitter (with version info): LAV Splitter: 0.73.1.0
Decoder (with version info): LAV Video: 0.73.1.0
Decoding: <select>
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia + Intel
GPU Model: NVIDIA GeForce GTX 1050
GPU Driver Version: 25.21.14.1701
Summary: Unable to play some videos with DXVA11 (Native) hardware acceleration
Description: Repeating frames of two parts of the video displayed indefinitely(attachment).
Problem occur with 10bit HVEC video, only when using DXVA11 (Native) hardware acceleration AND ordered chapters.
No bugs with ordinary 10bit HVEC videos.
No bugs on this configuration when playing AVC 10bit with ordered chapters.
No bugs on different hardware acceleration profiles including DXVA11 copy-back.
Tags:
Steps To Reproduce: 1)Open mkv (10bit?) HVEC file with ordered chapters.
2)Jump to any time in video file.
3)Enjoy!
Additional Information: MPC-HC (Nightly, 64-bit)
------------------------

Build information:
    Version: 1.8.3.8 (fc4fb469a)
    Compiler: MSVC v19.14.26433
    Build date: Nov 24 2018

LAV Filters:
    LAV Splitter: 0.73.1.0
    LAV Video: 0.73.1.0
    LAV Audio: 0.73.1.0
    FFmpeg compiler: MinGW-w64 GCC 7.3.0

Operating system:
    Name: Windows NT 10.0 (build 17763)
    Version: 10.0 (64-bit)

Hardware:
    CPU: Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz
    GPU: NVIDIA GeForce GTX 1050 (driver version: 25.21.14.1701)
System Description Codec Tweak Tool | Log file | Generated at 2019-01-04 14:52:34

##### System Information #####

OS: Windows 10 Home (10.00.17763) (x64)
CPU name: Intel(R) Core(TM) i5-7300HQ CPU @ 2.50GHz
CPU speed: 2496 MHz (4t)
Memory: 16256 MB
Screen size: 1920x1080 (32bits) (60Hz)
Video card 1: Intel(R) HD Graphics 630
              VendorID: 8086, DeviceID: 591b
Video mem: 1024 MB
Video driver: igdumdim64.dll (Version 25.20.100.6471) (12-10-2018)
Video card 2: NVIDIA GeForce GTX 1050
              VendorID: 10de, DeviceID: 1c8d, SubSys: 11281025
Video mem: 4096 MB
Video driver: nvldumdx.dll (Version 25.21.14.1735) (12-11-2018) (NV 417.35)
Audio device: NVIDIA Virtual Audio Device (Wave Extensible) (WDM)
              VendorID: 0955, DeviceID: 9000
Audio driver: nvvad64v.sys (Version 4.11.1.0) (8-22-2018)

##### K-Lite Codec Pack #####

KLCP version: 14.6.2 (base 14.6.1)
KLCP type: full

Speaker conf: 2.0

MPC renderer: madVR
MPC subs: ISR
MPC audio: System Default

##### Decoder Settings #####

LAV Video:
H264=D3D11VA HEVC=D3D11VA VP9=D3D11VA VC1=D3D11VA MPEG2=D3D11VA MPEG4=1 WMV3=0

LAV Audio:
MP3=1 AC3=B DTS=B DTSHD=B EAC3=B TRUEHD=B AAC=1 Vorbis=1 LPCM=1 WMA=0

##### DirectShow Filters (64-bit) #####

Description: 3DYD Youtube Source
File name: c:\program files (x86)\3dyd youtube source\source_filter64.ax
File version: 1.9.6.0
File size: 6054912 bytes
File MD5: 8a62452f5f59ce775295bbab6c2b906e
CLSID: {55C39876-FF76-4AB0-AAB0-0A46D535A26B}
Merit: 00600000 = MERIT_NORMAL

(A total of 70 filters, 1 shown, 69 hidden)

##### ICM Class Manager (64-bit) #####

(A total of 2 filters, 0 shown, 2 hidden)

##### Default source filters (64-bit) #####

.vob {B98D13E7-55DB-4385-A33D-09FD1BA26338} LAV Splitter Source

(A total of 56 default source filters, 1 shown, 55 hidden)

##### ACM and VFW Codecs (64-bit) #####

Description: RivaTuner Video Codec
ID: VIDC.RTV1
File name: C:\WINDOWS\system32\rtvcvfw64.dll
File size: 246272 bytes
File MD5: af47d6660569dfa46bc4e1cd21e1624b

(A total of 14 codecs, 1 shown, 13 hidden)
Attached Files: mpc-hc64_nvo_2018_11_29_19_55_15_108~1.mkv (1,389,404 bytes) 2018-11-29 21:12
https://bugs.madshi.net/file_download.php?file_id=302&type=bug
Notes
(0002442)
madshi   
2018-12-04 12:50   
Do you have a small video sample with which I might be able to reproduce the problem on my PC?
(0002444)
MK36   
2018-12-05 10:45   
https://drive.google.com/open?id=1zNGCanU1u780z3iLykUFoUIKBsL50PDk OP standalone plays just fine, problem apparently lies in the first file.
(0002445)
madshi   
2018-12-05 10:58   
Thanks, files are downloaded, and I can reproduce it. So you can remove the files again, if you like. I'll have a look at this, when I find some time. Might take a big, though.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
584 [madVR] bug major always 2018-11-21 20:06 2018-11-21 20:11
Reporter: jmonier Platform: PC  
Assigned To: OS: Windows  
Priority: normal OS Version: 8.1, 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version:
Media Player (with version info):
Splitter (with version info):
Decoder (with version info):
Decoding:
Deinterlacing:
DXVA2 Scaling Active:
Aero / Desktop Composition:
Problem occurs with mode:
GPU Manufacturer:
GPU Model:
GPU Driver Version:
Summary: Cannot activate HDR via DisplayPort
Description: I have a problem with activating HDR via DisplayPort. This is with a LG 34BK95U - 5120x2160 which requires DP 1.4 to get the full width. HDMI (which limits it to 3840 width) works fine.

Basically, it seems that madVR does not recognize that HDR is supported via DP, and thus always does tonemap HDR instead. (And I HAVE checked that HDR can be activated otherwise via DP.)
Tags:
Steps To Reproduce: It only occurs with the above monitor (or probably with the 34WK95U which is identical) and only on the Displayport (1.4). Other than that, just play a HDR file with "passthrough HDR to display" set and "send HDR metadata to the display" checked and note that the HDR indicator does not appear and that the resulting image is from "tonemap HDR ..." instead.

I've included a log.

 
Additional Information: It may or may not be related, but the "identification" for this monitor is wrong, e.g. it shows NVIDIA for the manufacturer (among other things). (Again, this is only on the DisplayPort 1.4 input to this monitor - the HDMI input is fine and DisplayPort (1.2) inputs on other LG monitors are fine.) And Moninfo shows correct data for this DP 1.4 input.

Even stranger, additional identical identification entries keep getting added, always 2 at a time (but I don't know what triggers it). The data is identical for all, with all but the last grayed out. (I'm currently at 23 entries.)
Attached Files:
Notes
(0002440)
jmonier   
2018-11-21 20:11   
Sorry for the extra report. It apparently occurred when I tried to upload a .7z file. 585 is the complete report and this one can be ignored.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
450 [eac3to] bug major always 2016-11-24 03:24 2018-10-21 20:36
Reporter: tebasuna51 Platform:  
Assigned To: madshi OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: don't support some eac3 files
Description: Problems with some eac3 files reported by eac3to with core like this:
E-AC3, 7.1 channels, 0:01:23, 768kbps, 48kHz, dialnorm: -27dB
(core: AC3, 5.1 channels, 0:01:23, 448kbps, 48kHz, dialnorm: -27dB)

eac3to Sample.eac3 without_DN.eac3
Removing AC3 dialog normalization...
Applying (E-)AC3 delay failed. <ERROR> ????
Aborted at file position 262144. <ERROR>

eac3to Sample.eac3 Decoded.wav <ABORT ALSO>

DelayCut v1.3.0 show wrong info, etc.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Sample.zip (7,786,293 bytes) 2016-11-24 03:24
https://bugs.madshi.net/file_download.php?file_id=227&type=bug
Notes
(0001927)
madshi   
2017-11-18 21:25   
Tried to do a quick fix, but failed. It's of course fixable, but it will take a bit of time which I currently don't have, so it will have to wait.

FWIW, using "-core", decoding seems to work.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
582 [madVR] bug minor always 2018-10-11 07:56 2018-10-11 10:36
Reporter: mkver Platform:  
Assigned To: madshi OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): 1.5.2 (build 4000) beta
Splitter (with version info): Internal MPC-BE Splitter from version 1.5.2 (build 4000) beta
Decoder (with version info): Internal MPC-BE Decoder from version 1.5.2 (build 4000) beta
Decoding: DXVA2 Native
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: Intel
GPU Model: i3 4005U
GPU Driver Version: 10.18.14.4889
Summary: Matroska/Upstream cropping doesn't work in DXVA2 Native mode
Description: Hello,

the Matroska/Upstream cropping doesn't work correctly in DXVA2 Native mode. The size of the rectangle and the aspect ratio is right, but the choosen pixels aren't: It doesn't crop at the top, but only at the bottom (and it crops more than it should there -- so much that the size is right). Here is the pin info MPC-BE reports:

- Connection media type:

Video: dxva 1280x720 (16:7) 25fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_NV12 {3231564E-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 1382400
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,80)-(1280,640)
rcTarget: (0,80)-(1280,640)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000 (25.000 fps)

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000081
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 7
dwControlFlags: 0x0000a581
- VideoChromaSubsampling: 5
- NominalRange : 2 (16-235)
- VideoTransferMatrix : 1 (BT.709)
- VideoLighting : 0
- VideoPrimaries : 0
- VideoTransferFunction : 0
dwReserved2: 0x00000000
Tags:
Steps To Reproduce: Play the file "Matroska.Container.Cropping.mkv" in MPC-BE with its internal filters with DXVA2 native enabled. You'll see a black bar at the top and you'll also see that the white rectangle isn't centered, but below the middle of the video (it should be a white square in the middle of the video and you shouldn't see black bars at all).
Additional Information: I have already reported it on doom9 here: http://forum.doom9.org/showthread.php?p=1854410#post1854410
The EVR and EVR-CP renderers are able to correctly crop in DXVA2 mode (if the cropping doesn't respect the subsampling, they are off by one, but I'd be satisfied with this).
It works correctly when not in DXVA2 native mode.
LAV Filters ignores the Matroska container cropping parameters and can therefore not be used to reproduce this issue. But MPC-BE's internal filters work.
Attached Files: Matroska.Container.Cropping.mkv (2,208,576 bytes) 2018-10-11 07:56
https://bugs.madshi.net/file_download.php?file_id=300&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
581 [madVR] bug crash sometimes 2018-10-03 08:22 2018-10-03 08:22
Reporter: noob00224 Platform: MPC HC  
Assigned To: OS: Win7 x64  
Priority: normal OS Version: Ultimate  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.17
Media Player (with version info): MPC HC Nightly 1.8.2.4
Splitter (with version info): Lav 0.72.0.15
Decoder (with version info): Lav 0.72.0.15
Decoding: DXVA2 Copyback
Deinterlacing: auto mode
DXVA2 Scaling Active: yes
Aero / Desktop Composition: On
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: NVidia
GPU Model: GTX 1060 6GB
GPU Driver Version: 411.70
Summary: MPC HC crash
Description: I have ripped a 3D bluray with DVDFab with the 3D MKV MVC shell. I have to activate 3D stereoscopic from NVCP manually.
It plays fine in windowed mode. When I try to play it in fullscreen MPC HC crashes. The PJ resets itself to 3d frame packing when I go fullscreen.
OS is Win7 x64, 398.82 driver version, latest MPC HC/Lav/madvr. Output is from a GTX 1060 via HDMI to a Benq W2000(HT3050).
Also tried Make MKV and Any DVD ripper, same issue.

LE: I updated to 411.70, still crashed. I accidentally played a 2D movie (while the PJ was in 3D mode) and when it went to fullscreen it crashed. Tried an mkv and an mp4.
Strange that some 3D ripped files (3D MKV) did go into fullscreen (witout 3d effects). Also changed the Hardware Accelaration fron dxva2 copyback to all the other alternatives in Lav Video decoder to no avail.
FSE is active. I am able to view 3d movies (from disc) with WinDVD.
Tags:
Steps To Reproduce: Fullscreen has error in 3d stereoscopic mode.
Additional Information: Problem signature:
Problem Event Name: BEX
Application Name: mpc-hc.exe
Application Version: 1.8.2.4
Application Timestamp: 5bace0b2
Fault Module Name: nvwgf2um.dll
Fault Module Version: 24.21.13.9882
Fault Module Timestamp: 5b5f4be7
Exception Offset: 0015cc4a
Exception Code: c0000409
Exception Data: 00000000
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: bf80
Additional Information 2: bf8015ebbd3b4897e1fb57b607478160
Additional Information 3: fe8e
Additional Information 4: fe8e20b1fa58fc8d6a6c0b521c8da54c

And Event Viewer:

Log Name: Application
Source: Microsoft-Windows-WMI
Date: 03-Oct-18 7:03:23 AM
Event ID: 10
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer:
Description:
Event filter with query "SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99" could not be reactivated in namespace "//./root/CIMV2" because of error 0x80041003. Events cannot be delivered through this filter until the problem is corrected.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-WMI" Guid="{1edeee53-0afe-4609-b846-d8c0b2075b1f}" EventSourceName="WinMgmt" />
<EventID Qualifiers="49152">10</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2018-10-03T04:03:23.000000000Z" />
<EventRecordID>49639</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>Application</Channel>
<Computer> </Computer>
<Security />
</System>
<EventData>
<Data>//./root/CIMV2</Data>
<Data>SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA "Win32_Processor" AND TargetInstance.LoadPercentage > 99</Data>
<Data>0x80041003</Data>
</EventData>
</Event>
Attached Files: default.rar (166 bytes) 2018-10-03 08:22
https://bugs.madshi.net/file_download.php?file_id=299&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
573 [madVR] bug minor always 2018-09-01 19:27 2018-09-30 19:42
Reporter: FortMax Platform: PC  
Assigned To: madshi OS: Windows 10  
Priority: normal OS Version: 1803  
Status: feedback Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.3 through current
Media Player (with version info): MPC-HC CCCP build 1.7.8.162
Splitter (with version info): LAV Splitter 0.65.0.5 (not active for DVD video)
Decoder (with version info): LAV Video 0.65.0.5 (not active for DVD video)
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: AMD
GPU Model: Radeon HD 6800 series
GPU Driver Version: 15.201.1151.1008
Summary: screenshots of DVD menus fail (getDIB failed,hr=80004005)
Description: Any attempt to take a screenshot of a DVD menu fails.
MPC-HC will freeze, and after a while it will unfreeze and give the error "getDIB failed,hr=80004005"
Tags:
Steps To Reproduce: Play a regular old DVD
Get to the DVD's menu.
Try to take a screencap of the menu using MPC-HC's screencap function
Additional Information: Works fine on Mad VR 0.92.2, still broken as of 0.92.14
Attached Files:
Notes
(0002346)
madshi   
2018-09-01 19:29   
Ouch, this could be complicated. DVD menus are a very special case, very different to normal video. I'll have a look at this, but it might take a while until I get to that. For now you could simply use the PrintScreen (will not work in Fullscreen Exclusive Mode, though).
(0002347)
FortMax   
2018-09-01 19:53   
My current workaround is going back to 0.92.2 where it works fine.
(0002348)
madshi   
2018-09-01 19:54   
Makes sense. That's the last build before all the new screenshot related functionality.
(0002431)
madshi   
2018-09-30 19:42   
I've tried with a DVD sample here, and it seems to work fine for me, using v0.92.17. Can you test if you still have this problem with v0.92.17? If so, can you maybe upload a small video/DVD sample, with which I/you can reproduce the problem?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
556 [madVR] bug minor always 2018-05-10 10:15 2018-09-18 00:04
Reporter: sat4all Platform:  
Assigned To: madshi OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.14
Media Player (with version info): Kodi Dsplayer 16.4
Splitter (with version info): LAVFilters-0.71.0-34
Decoder (with version info): LAVFilters-0.71.0-34
Decoding: DXVA2 Native
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 1060
GPU Driver Version: 397.64
Summary: madtpg+displaycal hdr calibration problem
Description: Hi madshi,

I think there is a bug in madtpg, the hdr calibration never finish when matpg "disable osd" is enabled, displaycal report error3 and stop after taking couple of patch measurements.
[code]2018-05-08 17:26:19,568 ', using delay of 100 msec & 0 msec inst reaction\r\npatch 1 of 175'
2018-05-08 17:26:21,427 '\rpatch 2 of 175'
2018-05-08 17:26:22,407 '\rpatch 3 of 175'
2018-05-08 17:26:23,301 '\rpatch 4 of 175'
2018-05-08 17:26:24,362 '\rpatch 5 of 175'
2018-05-08 17:26:36,559 '\rpatch 6 of 175'
2018-05-08 17:26:48,746 '\rpatch 7 of 175'
2018-05-08 17:26:51,901 '\rpatch 8 of 175'
2018-05-08 17:26:54,543 '\rpatch 9 of 175'
2018-05-08 17:26:57,135 '\rpatch 10 of 175'
2018-05-08 17:26:59,263 '\rpatch 11 of 175'
2018-05-08 17:27:00,279 'White drift was 0.000000 DE\r\nThe instrument can be removed from the screen.\r\n'
2018-05-08 17:27:00,380 'dispread: Error - dispd->read returned error code 3\r\n\r\n'[/code]

Untick "disable osd" fix the problem immediatly, with sdr calibration all is fine.
I've reported to fhoech and he asked to report to you.

Kind Regards
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
575 [madVR] bug major always 2018-09-05 16:02 2018-09-05 16:20
Reporter: elelunicy Platform: PC  
Assigned To: elelunicy OS: Windows 10  
Priority: high OS Version: 1803  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.92.14
Media Player (with version info): Potplayer 1.7.13963
Splitter (with version info): LAV Splitter 0.72
Decoder (with version info): LAV Video Decoder 0.72
Decoding: Software
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: Titan X (Pascal)
GPU Driver Version: 399.07
Summary: Hissing/static noises from speakers when MadVR is enabled
Description: So I'm having the problem when I start playing a video the speakers would make very slight hissing sound/static noise for about 10 seconds and then it stops. It's very slight but can be heard when the room is quiet. Increasing/decreasing the volume does not make the noise quieter/louder.

I've tried both Potplayer and MPC-BE and the noise issue happens with both. The issue is gone after disabling MadVR. Resetting MadVE's settings to defaults does not fix the issue. No noise issue either when using other players that don't use MadVR.

I also tried switching between LAV audio decoder and the built-in decoder and it doesn't make a difference. Changing the audio renderer between DirectSound/WaveOut/WASAPI made no difference either. It also doesn't matter what the audio format is (AAC, DTS, or TrueHD) and the noise is always there. There's no noise, however, when playing an audio only file.
Tags:
Steps To Reproduce:
Additional Information: I'm using a pair of powered stereo speakers connected to an external USB DAC.
Attached Files:
Notes
(0002351)
madshi   
2018-09-05 16:07   
It's probably the GPU running at max power for a couple of seconds. This happens because madVR fills up its internal queues, by rendering multiple video frames ahead as fast as possible. This is done to ensure smooth video playback without frame drops.

You could try using some GPU clock tool to limit the GPU clocks, or something.

Anyway, it's really nothing I can anything about. If the GPU makes noise when under full load, it's out of my control.

Maybe you could try lowering the size of the GPU queue in the madVR settings. That should reduce the number of seconds the GPU is under full stress at the start of a movie.
(0002352)
elelunicy   
2018-09-05 16:19   
That was it. I thought it was from the speakers but after listening very carefully it was indeed just GPU coil whine. I'm upgrading my GPU soon so hopefully the new GPU won't have the problem.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
558 [eac3to] bug feature always 2018-05-21 21:50 2018-05-21 21:53
Reporter: tebasuna51 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version:
Summary: DTS-HRA not recognized
Description: When load a DTS-HRA extracted from a BD UHD eac3to show:

The format of the source file could not be detected. <ERROR>

ffmpeg inform it like: DTS-HD HRA, 48000 Hz, 7.1, and it can decode, or extract the core, without problems.

Sample added.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: sample.zip (6,981,251 bytes) 2018-05-21 21:53
https://bugs.madshi.net/file_download.php?file_id=284&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
522 [eac3to] bug minor have not tried 2017-11-06 14:18 2018-04-10 09:12
Reporter: kron Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 32
Summary: Warning message
Description: Hi, first of all, congratulations for such excellent program.

Well, respectfully, does this Warning message ("XLL output not lossless") means any problem?
When I use eac3to 31 it doesn't happen, so I ask you if there is a possibilty to make it disapears in version 32?

Thank you for the attention.
Tags:
Steps To Reproduce: When converting audio DTSHD MA to flac using eac3to 32
Additional Information: eac3to v3.32
command line: "C:\Program Files\eac3to\eac3to.exe" "C:\Users\James\Desktop\Audio HD\Overdrive.2017.BluRay.1080p.DTS-HD.MA.5.1.AVC.REMUX-FraMeSToR_track2_eng.dts" "C:\Users\James\Desktop\Audio HD\Overdrive.2017.BluRay.1080p.DTS-HD.MA.5.1.AVC.REMUX-FraMeSToR_track2_eng.dts_.flac" -progressnumbers -log="C:\Program Files\eac3to\UsEac3To.log"
------------------------------------------------------------------------------
DTS Master Audio, 5.1 channels, 24 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
Decoding with libDcaDec DTS Decoder...
libDcaDec reported the warning "XLL output not lossless". <WARNING>
Encoding FLAC with libFlac...
Creating file "C:\Users\James\Desktop\Audio HD\Overdrive.2017.BluRay.1080p.DTS-HD.MA.5.1.AVC.REMUX-FraMeSToR_track2_eng.dts_.flac"...
The original audio track has a constant bit depth of 24 bits.
eac3to processing took 10 minutes, 51 seconds.
Done.
Attached Files:
Notes
(0001902)
madshi   
2017-11-08 10:52   
eac3to just passes the message on to you, which the decoder reports to eac3to. There's nothing I can do about it. Of course I could silently surpress the warning. Or maybe updating to a newer decoder build would remove the warning. But this is not really a bug in eac3to.
(0001903)
kron   
2017-11-08 13:28   
Thank you for answering, madshi.

Well, I was worried because it didn't happen in eac3to 31. It's good to know there's nothing wrong at all.

BTW would it be easy to update the decoder, I mean could it be done just replacing it (the new version) into the eac3to's folder?

I hope you can forgive me for so many questions...

Thanks again, my friend.

P.S.: I don't know why my post is repeated, how can I delete the others?
(0001904)
madshi   
2017-11-08 15:44   
If the decoder interface stayed the same you could just drop in a new version of the dll.
(0001911)
kron   
2017-11-09 17:04   
Hi, madshi,

I've just done it, and the message's now gone.

Thanks for your attention, my friend.
(0001913)
madshi   
2017-11-09 18:07   
Great, where did you get the new version from?
(0001918)
kron   
2017-11-11 20:58   
I'm not sure, madshi... I just had this file here and decided to try with eac3to, fortunately it did work. I think I got it from eMule.
(0002273)
GL1zdA   
2018-04-10 09:11   
Version 0.2.0 can be found in releases here:
https://github.com/foo86/dcadec
But the auhtor also recommends using ffmpeg now since it's integrated there.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
288 [eac3to] bug major always 2015-05-04 01:46 2018-03-11 18:06
Reporter: nautilus7 Platform:  
Assigned To: madshi OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.29
Summary: Cannot extract pgs/sup subtitles from mkv files
Description: PGS/SUP subtitles cannot be demuxed correctly from mkv files. This happens with all files I have tried. It's happening now for quite a long time, if not forever.

Only way to demux pgs/sup from mkv is using mkvextract, since eac3to outputs a broken file.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002242)
mkver   
2018-03-11 08:16   
eac3to currently ignores whether the track in the Matroska file has been compressed (picture based subtitles are very compressible, so mkvmerge uses zlib compression for them by default) and simply extracts the data out of the file as is; it does not decompress it at all.
(0002243)
madshi   
2018-03-11 18:06   
That makes sense, eac3to doesn't support zlib decompression atm.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
177 [madVR] bug minor always 2014-03-12 20:22 2018-01-21 21:37
Reporter: huhn Platform: x64  
Assigned To: madshi OS: windows 7  
Priority: low OS Version: 7601  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 87.6
Media Player (with version info): mpc-hc 1.7.3
Splitter (with version info): lavfilter 60.1
Decoder (with version info): lavfilter 60.1
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: AMD
GPU Model: r9 270
GPU Driver Version: 14.1
Summary: playback to fast when exclusive fullscreen and SM is used with a 120 fps file on a 60 fps screen.
Description: sample http://www.file-upload.net/download-8681857/120fpssample2--1-.mkv.html
Tags:
Steps To Reproduce: play a 120 fps file on a 60 fps file in fullscreen exclusive and with active smoothmotion.
Additional Information: i can't reproduce this on my nvidia dual monitor system with a 144 hz screen.

cyberbeing got something like that too: http://forum.doom9.org/showthread.php?p=1671894#post1671894
Attached Files: madVR - log.zip (594,154 bytes) 2014-04-02 06:05
https://bugs.madshi.net/file_download.php?file_id=85&type=bug
Notes
(0000543)
madshi   
2014-04-01 18:22   
I've tried here, but I can't reproduce the problem with 60Hz FSE. How can I reproduce the problem? How do I even know that it's playing too fast?
(0000559)
huhn   
2014-04-02 06:05   
(Last edited: 2014-04-02 06:07)
i can make a file with audio but if it runs to fast you will get an black screen or see the last screen for the rest of the playback time after the last frame is rendered.

i just managed to reproduce this on my dual monitor system the file was finished after ~ 20 sec with bilinear chroma resizing so it looks like madvr fse with smoothmotion plays HFR files as fast as possible. so you may need a gpu/cpu that can run 1080p at over ~ 120 fps to reproduce this error.
if it runs to fast all queue drop except present frames in advanced. and i get ~ 100% cpu usage.

i added a log but i think it is way easier to reproduce this.

edit: don't add ~ and a number without a space!

(0000568)
madshi   
2014-04-02 22:11   
The speedup problem is caused by the GPU not being fast enough to render 120fps + SmoothMotion FRC. If you dial down the algorithms so that the GPU gets fast enough, playback should run at the normal speed. I'll keep this bug open to be fixed at some point in the future, but I consider it very low priority atm.
(0002140)
madshi   
2018-01-16 17:30   
This also occurs for me with 60p content on 23Hz, sometimes even in Windowed playback. Sometimes I need to switch to FSE to make the problem appear.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
479 [madVR] bug minor always 2017-05-14 21:47 2018-01-21 05:44
Reporter: mcn2 Platform: x86_64  
Assigned To: madshi OS: Windows  
Priority: normal OS Version: 8.1  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.91.8 (32-bit)
Media Player (with version info): MPC-HC 1.7.11 (32-bit)
Splitter (with version info): LAV Filters 0.69.0 (32-bit)
Decoder (with version info): LAV Filters 0.69.0 (32-bit)
Decoding: CUDA
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 680
GPU Driver Version: 382.05
Summary: Delay before playback starts
Description: Since version 0.91.0 I have a noticeable delay (more than 10 seconds) before playback starts.
With the more recent versions the audio starts with a delay of about 5 seconds, but the video still waits about 10 seconds.
Version 0.90.24, and the previous ones, don't have this issue.

This also happens after resetting madVR settings.

Some details on my configuration (apart from the OS everything else is 32-bit):

Nvidia GTX 680 with drivers 382.05

Windows 8.1 x64

MPC-HC 1.7.11
LAV Filters 0.69.0
madVR 0.91.8

This also happens with DVB Viewer Pro 5.5.0.0 instead of MPC-HC.

I checked the changelog for 0.91.0 but I can't see anything that might cause this.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: madVR - log.zip (1,460,468 bytes) 2017-05-17 18:20
https://bugs.madshi.net/file_download.php?file_id=243&type=bug
Notes
(0001643)
madshi   
2017-05-15 17:48   
Can you create a debug log, zip it and attached it here?
(0001644)
mcn2   
2017-05-17 18:20   
Here's the log.
I closed MPC-HC when the image appeared, approximately 8 seconds in.
(0001645)
madshi   
2017-05-17 22:43   
Hmmmm... The rendering thread seems to be stuck, but in my source code I can't find anything that would explain that. Are you 100% sure that this was introduced in v0.91.0? If you downgrade to v0.90.24 now, the problem really goes away?

Nobody else has reported a problem like this, so I wonder if it's maybe something specific to your PC. But I've no clue what it could be right now.
(0001646)
mcn2   
2017-05-18 13:45   
Yes, I made various tests and this problem only appears with v0.91.0 and later.

To add even more confusion I noticed that starting the Diablo III launcher fixes the problem, at least for some hours. Then it starts again.
This might happen with other applications too, I suppose.

However, as you say, I'm afraid it might very well be an issue with my PC.
After all, I'm still affected by this:
http://forum.doom9.org/showthread.php?p=1746207#post1746207

Thanks for your time.
(0002019)
madshi   
2018-01-14 12:32   
Sorry for the very late reply. Does this problem still occur with the latest builds? If so, I suppose I could make a few test builds to find out which exact change between v0.90.24 and v0.91.0 introduced the issue, if you still need this to be looked at?
(0002135)
mcn2   
2018-01-16 03:45   
At the moment I'm on 0.89.16, since newer versions used to often give me high CPU usage when a video gets paused (but only after some time that it has been paused).

During the week-end I'll check out the latest version and let you know.

By the way do you think that this issue:
http://forum.doom9.org/showthread.php?p=1746207#post1746207
could be caused by VRAM exhaustion on the GPU?
(0002138)
madshi   
2018-01-16 10:24   
I've no idea what causes that issue. Nobody else has ever reported a similar issue to me yet.
(0002159)
mcn2   
2018-01-21 05:44   
I'm still affected by this issue with 0.92.11.

When opening a file MPC-HC status bar shows 'Opening...' for about 4 seconds, then the audio starts and after approx. 8 seconds the video starts too.

Also, if I drag and drop a file on an instance of MPC-HC that already is showing a file the playback starts immediately as expected.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
372 [madVR] bug minor always 2015-12-29 08:24 2018-01-16 09:21
Reporter: omarank Platform:  
Assigned To: madshi OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.89.19
Media Player (with version info): MPC-HC V.1.7.10.40 32 bit
Splitter (with version info): LAV Splitter v0.67.0-29
Decoder (with version info): LAV Video Decoder v0.67.0-29
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: AMD
GPU Model: AMD HD8970M
GPU Driver Version: v13.12
Summary: Still images getting stretched in FSE when Display Mode Changer is active and LAV decoder is used
Description: If keep the Display Mode Changer active with refresh rates 50Hz and 60Hz while "switch to matching display mode": "when media player goes fullscreen" is selected, and open a still image file (e.g. png file) such that decoding is done by LAV Video decoder, in FSE mode the image gets stretched.
Tags:
Steps To Reproduce: 1. Keep at least two refresh rates in the Display Mode Changer setting box in madVR: 50Hz and 60 Hz.

2. In that display modes page, select "switch to matching display mode": "when media player goes fullscreen"

3. Open a png file in madVR such that LAV video decoder is used

4. Switch to Fullscreen for FSE mode
Additional Information:
Attached Files:
Notes
(0002099)
madshi   
2018-01-14 20:35   
I'm sorry for the extremely late reply.

I think this issue should be fixed in the latest madVR build? Can you confirm?
(0002136)
omarank   
2018-01-16 09:21   
There is still some problem in the latest madVR build. Although the image does not get stretched now, it looks terribly blurred and there is no seekbar. The steps that I mentioned to reproduce the problem should be helpful.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
353 [madVR] bug crash always 2015-10-25 02:48 2018-01-15 14:01
Reporter: net147 Platform: Intel  
Assigned To: madshi OS: Windows  
Priority: normal OS Version: 7 64-bit SP1  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.89.12
Media Player (with version info): MPC-HC 1.7.9 846eff0 64-bit
Splitter (with version info): LAV Splitter 0.65.0
Decoder (with version info): LAV Video Decoder 0.65.0.9-git
Decoding: DXVA2 Native
Deinterlacing: auto mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: windowed mode
GPU Manufacturer: NVidia
GPU Model: GeForce GTX 760
GPU Driver Version: 355.82
Summary: Moving MPC-HC player window from primary to secondary monitor causes playback to stop
Description: If you open a H.264 video, it starts playback on primary monitor. Dragging the player window to the secondary monitor causes the playback to pause for a few seconds or so and then changes to either Stopped or Paused state. Clicking play again causes audio to play for a fraction of a second and then go back to Stopped or Paused state.
Tags:
Steps To Reproduce: See description.
Additional Information: It used to work fine in older MadVR versions - playback would pause for a few seconds or so and then continue.

0.86.11 - ok
0.87.10 - ok
0.87.13 - ok
0.87.14 - ok
0.87.15 - bad
0.87.16 - bad
0.87.21 - bad
0.88.11 - bad
0.89.12 - bad
Attached Files:
Notes
(0001218)
net147   
2015-10-25 02:50   
I mistyped the media player version. It should be "MPC-HC 1.7.9 846eff0 32-bit" not 64-bit.
(0001236)
lanboost   
2015-11-21 15:41   
Can confirm this is a issue for

Windows 10 x64 (build 10240)

Nvida gtx 960 (358.91)
MPC-HC (1.7.10)
madVR 0.89.17

Doesn't matter what video I watch, freezes and doesn't replay when moving to other monitor
(0001331)
Ede_123   
2016-05-10 21:17   
Same issue here with
 - madVR 0.90.17
 - MPC-HC 1.7.10 (including LAV Video Decoder 0.66.0)
 - Windows 10 x64

When closing MPC-HC or starting a new video after playback got stuck in the mentioned state there's the following madVR report shown for a fraction of a second:
 - creating Direct3D device failed (80070005)

The issue can be worked around by disabling DXVA2 video decoding in LAV Video Decoder (obviously undesirable)
(0001351)
Ede_123   
2016-05-22 03:15   
Possibly related: bug 404
http://bugs.madshi.net/view.php?id=404
(0002027)
madshi   
2018-01-14 13:17   
Does it happen for all of you only with DXVA2 native video decoding?
(0002029)
Ede_123   
2018-01-14 13:58   
For me it happens with "DXVA2 (native)" mode.
Setting it to "DXVA2 (copy-back)" solves the issue.

My current system information:
 - madVR 0.92.10
 - MPC-HC 1.7.13 (including LAV Video Decoder 0.70.2.1-git)
 - Windows 10 x64
 - Intel(R) HD Graphics 520 (driver version: 22.20.16.4836)
(0002030)
madshi   
2018-01-14 14:25   
How about lanboost and net147?

@Ede, have you tried D3D11 native decoding with a nightly LAV build? Does the same issue occur with that?
(0002125)
net147   
2018-01-15 11:22   
@madshi Works for me using "DXVA2 (copy-back)" instead of "DXVA2 (native)" in "Video decoder" internal filter settings.

madVR 0.92.10
MPC-HC (64-bit) 1.7.13
Windows 7 SP1 64-bit
NVIDIA GeForce GTX 760
(0002126)
madshi   
2018-01-15 14:01   
Ok, thanks, so we can probably conclude that the issue only occurs with DXVA Native decoding. Will have to double check that...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
534 [eac3to] bug minor always 2018-01-14 22:33 2018-01-14 22:51
Reporter: Bandits Platform:  
Assigned To: madshi OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.34
Summary: HEVC stream detected with unknown parameters and when demuxed results in a corrupt video stream
Description: The HEVC stream from the sample is detected with unknown parameters. Once demuxed from the m2ts it becomes unrecognizable as a video stream. The original m2ts is playable without issues.
Tags:
Steps To Reproduce: Execute first pass with eac3to.exe to see unknown parameters. Demux m2ts to get corrupt video stream. Cannot reproduce with the 8meg sample.
Additional Information: The submitted 8meg sample demuxes with a usable video file. The issue happens within the first 15megs. I cannot submit a 15meg file.
Attached Files: 00001_0.m2ts (7,340,032 bytes) 2018-01-14 22:35
https://bugs.madshi.net/file_download.php?file_id=277&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
322 [madVR] bug minor always 2015-07-06 21:33 2018-01-14 20:06
Reporter: 6233638 Platform: x64  
Assigned To: madshi OS: Windows 8.1 Pro  
Priority: normal OS Version: 6.3 (Build 9600)  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.88.15.0
Media Player (with version info): NA
Splitter (with version info): NA
Decoder (with version info): NA
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: NVidia
GPU Model: GTX 570
GPU Driver Version: 353.06
Summary: madTPG not entering FSE mode when used as a pattern source for CalMAN 5.5.1
Description: madTPG is not entering FSE mode (10-bit output) when used as a pattern source for CalMAN on a single display. (CalMAN's new "force fullscreen" option)
Tags:
Steps To Reproduce:
Additional Information: Looks like it may be entering FSE on the first pattern (or series of patterns) but after that it only switches to windowed mode.
 
Log contains two series' of reads from 0-100.
The first appears to be entering FSE mode (or doing something which is reinitializing the display) while the second does not.
System Description
Attached Files: madVR - log.rar (6,152,916 bytes) 2015-07-06 21:33
https://bugs.madshi.net/file_download.php?file_id=163&type=bug
Notes
(0001103)
madshi   
2015-07-06 22:34   
I can see that switching into FSE mode fails, but it's hard to say why. Does this only happen with 10bit output? Or only with DX11 output? Or does it also happen with 8bit / DX9 output? What happens if you try to switch into and out of and back into fullscreen mode manually? Does madTPG then manage to enter FSE mode multiple times?
(0001104)
6233638   
2015-07-06 22:44   
It happens with 8-bit DX11 or DX9.
Manually switching into full-screen mode by double-clicking the pattern window seems to enter FSE mode every time. (or at least re-initializes the display as if it is)
(0001105)
madshi   
2015-07-06 22:47   
Ok, I guess I'll have to test that myself, but that might take a while. Should still work alright without FSE mode, right? (No 10bit then, of course.)
(0001106)
6233638   
2015-07-06 23:11   
Yes it works fine, it's just that the output is 8-bit.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
513 [madVR] bug minor always 2017-10-19 15:28 2018-01-14 12:05
Reporter: Larwood Platform:  
Assigned To: madshi OS: Windows 10  
Priority: normal OS Version: Fall Creators  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.92.7
Media Player (with version info): MPC-HC 1.7.13
Splitter (with version info): internal LAV 0.70.2.1
Decoder (with version info): internal LAV 0.70.2.1
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: fullscreen exclusive mode
GPU Manufacturer: NVidia
GPU Model: 980 Ti
GPU Driver Version: 387.92
Summary: Fullscreen exclusive seek bar kills present queue
Description: When in fullscreen exclusive mode whenever you mouse over to make the seek bar appear the present queue will drop to 1-2/2. This also causes playback to be slightly stuttery, although no frames are dropped. Seems to happen regardless of the format being played, and regardless of using DXD11 or DXD9.

Has the additional side-effect of causing playback to momentarily speed up and slow down when the seek bar is shown or hidden, if using D3D11 without "present a frame for every VSync."
Tags:
Steps To Reproduce: Use seek bar in fullscreen exclusive.
Additional Information:
Attached Files:
Notes
(0001865)
Larwood   
2017-10-19 15:31   
I just noticed, the playback being slightly stuttery also only applies when not presenting a frame for every VSync
(0001866)
madshi   
2017-10-20 11:40   
The present queue size is intentionally limited to 2 frames as soon as any user interface is displayed which supports user interaction. The reason for that is that a big full present queue automatically results in increased user interface latency. Latency doesn't matter at all during video playback. But if the user interface takes a full second to react to anything you do, that would feel rather bad.

Of course stuttering is not a good thing, either, maybe I can improve that. Or maybe I should reduce the queue size to 3 instead of 2, maybe that would already solve the problem (although increasing latency again).

Playback speeding up without "present a frame for every VSync" probably depends on the GPU driver implementation. I'm not sure if I can change that.
(0002009)
madshi   
2018-01-14 12:05   
FWIW, I've just noticed that the "low latency" mode runs smoothly on my AMD GPU but does stutter on NVidia, for some reason. I'll have to investigate why that happens. Should be something fixable, I suppose...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
512 [eac3to] bug minor always 2017-10-15 08:04 2017-11-19 04:46
Reporter: msg7086 Platform:  
Assigned To: madshi OS: Windows 10  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.32
Summary: Exit silently when scanning capped HEVC 4k in TS files
Description: The video in question is a commercial capped from a 4k TV station, broadcasting free of charge at that moment.

When scanning this file using eac3to 3.32, it exits silently after a fraction of second.

eac3to 3.31 was working partially since it does not try to parse HEVC stream, and at least the audio can be extracted correctly (without correct audio delay detected, of course).

The same issue applies to all similar video clips, HEVC+AAC inside TS files.
Tags:
Steps To Reproduce: 1. eac3to 4k-test.ts
Additional Information: Also expect eac3to to detect the correct audio delay so we don't have to manually sync video with audio.
Attached Files: 4k-test.ts (8,226,348 bytes) 2017-10-15 08:08
https://bugs.madshi.net/file_download.php?file_id=260&type=bug
4k-test2.ts (8,213,080 bytes) 2017-10-15 20:39
https://bugs.madshi.net/file_download.php?file_id=261&type=bug
Notes
(0001850)
madshi   
2017-10-15 20:33   
With that TS file eac3to reports "The format of the source file could not be detected" on my PC. Maybe the file is too short?
(0001851)
msg7086   
2017-10-15 20:42   
My apologies, when cutting the file to get around the size limitation I seemed to cut in a weird position.

Double checked this time and uploaded a new sample.

Thank you for your time.
(0001920)
madshi   
2017-11-15 15:02   
Is it fixed in this build?

http://madshi.net/eac3toHevcTest.rar
(0001921)
msg7086   
2017-11-15 20:46   
(Last edited: 2017-11-15 20:46)
Testing 4k-test2.ts
----------
Testing 01.ts
-
Testing 02.ts

Testing 03.ts
-
Testing 04.ts

Testing 05.ts

Testing 06.ts

Testing 07.ts

Testing 08.ts
-

9 negatives. log.txt file shows nothing useful.

(0001928)
madshi   
2017-11-18 21:55   
Hopefully fixed in v3.33?

http://madshi.net/eac3to.zip

The attached file was too short to properly detect the HEVC properties, but at least it doesn't exit silently, anymore.
(0001930)
msg7086   
2017-11-19 04:11   
Testing 4k-test2.ts
TS, 1 video track, 1 audio track, 0:00:03, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 185kbps, 48kHz, -740ms

Testing 01.ts
TS, 1 video track, 1 audio track, 0:30:21, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 185kbps, 48kHz, -1063ms

Testing 02.ts
TS, 1 video track, 1 audio track, 0:30:21, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 179kbps, 48kHz, -652ms

Testing 03.ts
TS, 1 video track, 1 audio track, 0:30:09, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 185kbps, 48kHz, -1040ms

Testing 04.ts
TS, 1 video track, 1 audio track, 0:30:27, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 191kbps, 48kHz, -601ms

Testing 05.ts
TS, 1 video track, 1 audio track, 0:30:37, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 191kbps, 48kHz, -713ms

Testing 06.ts
TS, 1 video track, 1 audio track, 0:30:23, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 192kbps, 48kHz, -613ms

Testing 07.ts
TS, 1 video track, 1 audio track, 0:30:15, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 186kbps, 48kHz, -570ms

Testing 08.ts
TS, 1 video track, 1 audio track, 0:30:17, 30p /1.001
1: h265/HEVC, unknown parameters
2: AAC, 2.0 channels, 191kbps, 48kHz, -882ms

I'll upload a longer example for further testing. Also I'll report if the audio delay is correct after comparing with my previous test.
(0001931)
msg7086   
2017-11-19 04:46   
https://drive.google.com/file/d/1vQUNV32Wu64jaqjNZYsAMLxmbRzje7q6/view?usp=sharing

Should be long enough for HEVC properties.

Regarding the audio delay, here's what I ear-detected against videos encoded with DGNV avisynth source filter.

01.ts: eac3to reports -1063ms, ear detected -700ms.
02.ts: eac3to reports -652ms, ear detected -600ms.
03.ts: eac3to reports -1040ms, ear detected -600ms.
04.ts: eac3to reports -601ms, ear detected -650ms.
05.ts: eac3to reports -713ms, ear detected -750ms.
06.ts: eac3to reports -613ms, ear detected -600ms.
07.ts: eac3to reports -570ms, ear detected -450ms.
08.ts: eac3to reports -882ms, ear detected -850ms.

Since those video clips are just landscapes with music, no accurate sync point can be found. And we wouldn't know how DGNV determines its first usable frame either, so this is for reference only.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
487 [eac3to] bug major always 2017-07-13 09:08 2017-07-14 20:38
Reporter: TheLastOfUs Platform: PC  
Assigned To: madshi OS: Windows  
Priority: urgent OS Version: 10  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: Slowdown / ChangeTo23.976 BROKEN on EAC3TO
Description: So I slowed down a file with EAC3To using -ChangeTo23.976 and -slowdown (same results).

I then took the original file and slowed it down -4.096% (Audacity) and it claims the runtime should be 23.06.675 NOT 23.06.649 as EAC3To is doing.

This is a difference of 36 ms....not to mention EAC3To keeps adding a 10 ms delay relative to the video, whereas the original 25 FPS file HAS NO DELAY on the audio. (I'm unclear if the delay is due to AAC encoder Nero AAC but maybe!)

Slowdown is 4.096%! Not 4.094%! It's off by 2%.
Tags:
Steps To Reproduce: Find 10.002s (in my case) minute sample of any audio file.

In audacity slow it down using .959 multiplier (Speed Change) or -4.096%.

It will state - 10min 25 . 628 as proper slowed down runtime of 23.976 FPS.

Do the same with EAC3To on this exact sample (any format - FLAC, WAV, M4A to M4A - FLAC TO FLAC, WAV TO WAV - doesn't matter).

Import into Audacity.

Check runtime....Audacity reports it is 10.25.602 (a whole 26 ms shorter!)

Nowhere close.
Additional Information: This is super disappointing. I trusted EAC3To in being accurate, but I have been incredibly let down and feel deceived.
Attached Files: 2017-07-12_23-57-45.png (109,050 bytes) 2017-07-13 09:11
https://bugs.madshi.net/file_download.php?file_id=246&type=bug
NEWTEST.png (125,604 bytes) 2017-07-13 22:23
https://bugs.madshi.net/file_download.php?file_id=247&type=bug
betterpic.png (185,017 bytes) 2017-07-13 22:25
https://bugs.madshi.net/file_download.php?file_id=248&type=bug
best.png (177,370 bytes) 2017-07-13 22:26
https://bugs.madshi.net/file_download.php?file_id=249&type=bug
newtestagain.png (147,001 bytes) 2017-07-13 22:29
https://bugs.madshi.net/file_download.php?file_id=250&type=bug
Notes
(0001713)
TheLastOfUs   
2017-07-13 09:25   
eac3to v3.31
command line: eac3to "WAVPCM.wav" "wow.m4a" -slowdown
------------------------------------------------------------------------------
WAV, 2.0 channels, 0:10:00, 32 bits <float>, 2822kbps, 44.1kHz
Reading WAV...
Changing FPS from 25.000 to 23.976...
Reducing depth from 64 to 32 bits...
Encoding AAC <0.50> with NeroAacEnc...
Original audio track: max 32 bits, average 29 bits, most common 29 bits.
The processed audio track has a constant bit depth of 32 bits.
eac3to processing took 19 seconds.
Done.
(0001714)
TheLastOfUs   
2017-07-13 09:26   
^ Runtime of the top is 10.25.602. Not the correct 10.25.626.

Difference always varies from 24ms to 26 ms.
(0001715)
madshi   
2017-07-13 11:15   
I've just done the following test with the Robin Hood (Disney) audio track:

1) "eac3to English.flac Stereo.wav -downStereo". Audacity reports final audio file to be 1:23:01.984.

2) "eac3to Stereo.wav Slowdown.wav -slowdown". Audacity reports final audio file to be 1:26:34.756.

Now let's do the math:

1:23:01.984 = ((1 * 60 + 23) * 60 + 01) * 1000 + 984 = 4981984 milliseconds
4981984 * 25 / (24.000 / 1.001) = 5194756 milliseconds
5194756 / 1000 / 60 = 86 minutes
5194756 - 86 * 60 * 1000 = 34756 milliseconds

So final length should be 1:26:34.756 - which is exactly what eac3to produced! So we have a *perfect* match. At least in this specific test I just made.

Two things you might not have been aware of:

A) 23.976 is really 24.000 / 1.001 = 23.976023976023976023976023976...

B) When decoding from or encoding to some compressed formats like e.g. AC3, DTS, AAC etc, audio gets either shortened or lengthened to match the compressed format's frame size. So for a really exact test both your source and target format should ideally be WAV(64), because WAV is one of the very few formats which doesn't partition the audio data into frames of a specific size.
(0001716)
TheLastOfUs   
2017-07-13 21:57   
Dear Madshi

Thanks for your response.

I did try WAV of a 10 minute sample as you can see in my 1st note. That 10 minute sample ends up becoming 10.25.602 .WAV and not 10.25.626 like a simple -4.096 on Audacity is doing.

Did you try on Audacity? I mean I am adding 23.976 (i may not be putting in 023976023976023976023976) but then how come the audio is shorter (especially wav)?

Please try just 10 minute sample of any audio.
(0001717)
madshi   
2017-07-13 22:06   
I'm not interested in whether Audacity resamples to a different duration than eac3to. I'm only interested in whether eac3to does things correctly. And as you can see in my previous comment, in my test it produced perfect results.

Your log includes AAC, which can screw everything up.

You're welcome to repeat my test with any file of any (reasonable) runtime. But if you do, please don't compare with what other software is doing (when slowing down). Instead just do the math manually to double check if eac3to is doing things correctly or not. That's the only thing that counts! And if you do this test, please use WAV for both input and output.
(0001718)
TheLastOfUs   
2017-07-13 22:11   
Ok....

I honestly can't say I know the math entirely.

eac3to v3.31
command line: eac3to wavpcm.wav nice.wav -slowdown
------------------------------------------------------------------------------
WAV, 2.0 channels, 0:10:00, 32 bits <float>, 2822kbps, 44.1kHz
Reading WAV...
Changing FPS from 25.000 to 23.976...
Reducing depth from 64 to 24 bits...
Writing WAV...
Creating file "nice.wav"...
Original audio track: max 32 bits, average 29 bits, most common 29 bits.
The processed audio track has a constant bit depth of 24 bits.
eac3to processing took 9 seconds.
Done.

For 10 minute sample at 25FPS runtime is 600000
(0001719)
TheLastOfUs   
2017-07-13 22:15   
600000 * 25 / (24/1.001) aka 15000000/23.976023976 = 625625 ms

Audacity says EAC3To audio is 10 minutes 25 seconds 592 milliseconds

10 mins = 600000 ms
25 seconds = 25000ms
592 ms = 592ms

total:

625,592 ms......

Crap
(0001722)
madshi   
2017-07-13 22:19   
Did you really repeat the test, using WAV input and WAV output? Or did you just do a writeup based on your older tests?
(0001723)
TheLastOfUs   
2017-07-13 22:23   
(Last edited: 2017-07-13 22:23)
I did a new test....attached for your reference. Apologies but it still isn't adding up right...wouldn't waste your time with lies! I'm trying hard to figure this out on my end.

(0001724)
TheLastOfUs   
2017-07-13 22:25   
Sorry I'm adding craptastic pictures. I'm adding a better one...
(0001725)
TheLastOfUs   
2017-07-13 22:27   
On the right - is the NICE.WAV i converted to.
(0001726)
TheLastOfUs   
2017-07-13 22:27   
On the left is the original nice wavpcm.wav file
(0001727)
TheLastOfUs   
2017-07-13 22:28   
I am willing to teamviewer if necessary but yes...tried WAV to wav..I will try again....
(0001728)
TheLastOfUs   
2017-07-13 22:31   
Newtestagain.png added. Wavpcm.wav to nice.wav

Final result is 10.25.592 as reported by audacity. Not 625625 ms as I calculated with your exact ratio. If I try a bigger file - up to 30 minutes, same discrepancy in numbers
(0001729)
madshi   
2017-07-13 22:49   
Strange. Why does it work on my PC? My file is not float32, though, but I don't think that's likely to make a difference. Can you upload the "Wavpcm.wav" somewhere? Then I'll try to reproduce the problem here with the exact same file you've been testing with.
(0001730)
TheLastOfUs   
2017-07-13 23:00   
Sure thing boss!
(0001731)
TheLastOfUs   
2017-07-13 23:08   
https://www.amazon.com/clouddrive/share/4YcJaGELKcf44BwzmTMZ7HvXBCCmu8NcWUykOPr8Efu?ref_=cd_ph_share_link_copy
(0001732)
madshi   
2017-07-13 23:40   
Interesting. It seems to be the sampling rate. When I convert the audio to 48khz, slowing down produces perfect results. But at 44.1khz it's not perfect.

After checking my source code it seems that the libSsrc library I'm using for resampling has "integer" parameters for source and target sampling rate, not "floating point". Which means the sampling rates are rounded down, no decimals supported. I'm not sure if there's much I can do about this.
(0001733)
TheLastOfUs   
2017-07-13 23:46   
Ah...wow that would explain a lot. Yes all my audios I work on are 44.1 - and yes I don't think there's anything you could do about it....thank you for looking into this.

Is there a way for the audio to be converted to 48 Khz right from within EAC3To or would it require me to use Audacity > save to wav > then process?
(0001734)
madshi   
2017-07-13 23:50   
Why are your audio files 44.1khz? I mean usually slowdown is needed for *movie* tracks, and both DVDs and Blu-Rays (and UHD Blu-Rays and HD DVDs) are all 48khz, IIRC. So I don't understand where you would get 44.1khz movie tracks from? Except maybe from Laserdisc or something?

For non-movie tracks of course it isn't nice if slowdown isn't perfect, but it's probably not a too dramatic problem, either, because there's no matching video track that lipsync needs to match with. But if there's no video track, I don't think slowdown would ever be useful, anyway?

eac3to can directly resample, e.g. "eac3to source.wav target.wav -resampleTo48000", but then you resample twice: From 44.1khz to 48khz, and then afterwards the slowdown, which isn't ideal.
(0001735)
TheLastOfUs   
2017-07-14 00:07   
(Last edited: 2017-07-14 00:27)
It's a laserdisc of winnie the pooh from Europe. Which is why it's probably 44.1 KHz....

wouldn't resample be just once? eac3to source.wav (resampled) -slowdown ?

Oh you mean the audio gets manipulated twice? I thought it was close to perfect if your sources are lossless?

(0001740)
TheLastOfUs   
2017-07-14 00:41   
I did Resampleto48000 and it changed the file length from 22.09.876 to 22.09.853 difference of 24 ms.

Basically if I work with any 44.1 KHz file - no go in terms of libSsrc I am guessing....now I understand what you mean by resampling 2wice.
(0001741)
madshi   
2017-07-14 01:25   
Yeah. Don't know how to solve it. I mean I could lie to libSsrc about the sampling rate and pretend it were 48khz instead of 44.1khz, but I don't know enough about the technical aspects of resampling. It might harm audio quality if I lie, I don't know for sure.
(0001742)
TheLastOfUs   
2017-07-14 04:07   
Is it possible to humbly request to you - a build in which any 44.1 KHz file is interpreted as 48 KHz?

Thank you....
(0001743)
madshi   
2017-07-14 09:47   
I don't really want to do that by default, because I don't know if it might not harm audio quality. I could add it as an (undocumented) option. It's not a matter of 5 minutes to add this, though, so it will have to wait...
(0001744)
TheLastOfUs   
2017-07-14 20:38   
An undocumented option would be MAGNIFICENT. Totally understand it isn't a 5 minute thing. Thank you for all your help brother :)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
469 [eac3to] bug minor always 2017-02-15 20:36 2017-02-15 21:23
Reporter: ramicio Platform:  
Assigned To: madshi OS:  
Priority: low OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: Clipping when converting to floating-point PCM
Description: It shouldn't need to do a 2nd pass to reduce volume if one is converting to a floating-point format.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
468 [eac3to] bug feature N/A 2017-02-10 13:10 2017-02-10 13:46
Reporter: ndjamena Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: Output track IDs of input files.
Description: When a program reads the EAC3To output I'd like a sure way to match the track info to the output of other programs (MediaInfo/MKVMerge). Outputting the PIDs and Matroska Track Numbers would be the surest way of achieving that.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0001586)
madshi   
2017-02-10 13:46   
Please post feature requests to the doom9 forum. This is a bug tracker, intended only for bug reports, not for feature wishes. Thanks.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
453 [eac3to] bug minor always 2016-12-08 14:47 2016-12-08 15:18
Reporter: kempniu Platform: x86-64  
Assigned To: madshi OS: Windows  
Priority: normal OS Version: 7  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: Questionable gaps in AC-3 tracks of MPEG-TS DVB captures
Description: How exactly does eac3to determine that there are gaps in the source file?

eac3to v3.31 often finds gaps in AC-3 tracks of my MPEG-TS DVB captures. The problem is that I cannot tell why. Consider this attached raw, unprocessed sample (17 MB) straight from the capture device:

https://www.sendspace.com/file/h91rl2

"eac3to -check" claims there is a 21 ms gap in this file at playtime 0:00:03. How is this calculated? PES packets which are part of stream 0x13F0 have continuous PTS, continuity counters in TS packet headers are correct, each PES packet has exactly four AC-3 frames, there are no playback issues. So where is the alleged gap?

The gap warning is displayed regardless of the AC-3 decoder used, "-no2ndpass" also does not help. What is even more confusing is that if you cut off the _last_ megabyte or so of this sample, "eac3to -check" no longer displays the message in question. This looks like a bug in eac3to.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: audio-has-a-gap-of-21ms-at-playtime-0-00-03.7z.001.zip (7,735,835 bytes) 2016-12-08 15:06
https://bugs.madshi.net/file_download.php?file_id=229&type=bug
audio-has-a-gap-of-21ms-at-playtime-0-00-03.7z.002.zip (7,735,835 bytes) 2016-12-08 15:07
https://bugs.madshi.net/file_download.php?file_id=230&type=bug
Notes
(0001516)
madshi   
2016-12-08 15:03   
It's somewhat complicated. Looking over all the timings, if the first and last audio samples are stretched too far, eac3to reports that as a gap. Where exactly the gap is can be hard to determine because there can be a lot of jitter in the timings.

I'll put this on my to do list to have a closer look at, but atm I'm mostly concentrated on madVR development, so it could take a while.

The "-no2ndpass" switch will not stop the warnings from being displayed, but at least eac3to should not try to repair the gap.
(0001517)
kempniu   
2016-12-08 15:12   
Thanks for a lightning fast response. Taking a closer look when you find the time is all I can ask for, thanks! I also appreciate the explanation of what "-no2ndpass" does, it might come in handy.

In case the SendSpace link expires, I attached the sample in question to this ticket, after jumping through some hoops to make the upload form happy. To extract the sample, download both files (yes, they are equally sized, to the byte), strip the ".zip" extension off both of them and then extract "audio-has-a-gap-of-21ms-at-playtime-0-00-03.7z.001".
(0001518)
madshi   
2016-12-08 15:18   
Attaching is a good idea, thanks.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
373 [eac3to] bug minor have not tried 2015-12-29 16:39 2016-11-24 02:50
Reporter: shr3k Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: AC3 encoder delay
Description: Hi, a some time ago I found that AC3 encoder in eac3to produces some delay in output file. With comparison in Audacity it can be compensated by adding -5ms to command line (produced AC3 will be still 16 samples at 48 kHz behind the original source).
Tags:
Steps To Reproduce: Take some sound file. Encode it to AC3. Decode it to FLAC. Open in Audacity and compare waveform.
Additional Information:
Attached Files: delay.zip (927,678 bytes) 2015-12-29 16:39
https://bugs.madshi.net/file_download.php?file_id=189&type=bug
Notes
(0001503)
tebasuna51   
2016-11-24 02:50   
All encoders, even commercial ones, produce a delay in output because need initialize the soft and send a initial silence before send the input audio.

AC3 encoders send 256 PCM samples of silence, at samplerate 48000 is 5.333... ms

A workaround using Aften encoder is use the parameter -pad 0, but don't know a equivalence using ffmpeg.

BTW the problem is not related with eac3to but with each encoder.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
438 [eac3to] bug major always 2016-10-05 21:48 2016-11-24 02:34
Reporter: co5mo Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: any
Summary: AC3 poping issue on certain hardware decored
Description: hi I have a sound poping issue on z906 Logitech 5.1 speakers encoded using eac3to

it does not appear on any factory? Original DVD or iTunes encoded ac3 files

test file
https://mega.nz/#!zBZBlTaR!Pk_5qMdl55lenVF-gUAtzQTPJNF24p5yIpc6yPQ-P2w

is there anything that could be done about this? thanks!
Tags:
Steps To Reproduce: only on z906 speakers
Additional Information:
Attached Files:
Notes
(0001472)
co5mo   
2016-10-12 20:27   
more info here also http://forum.doom9.org/showthread.php?t=172212
(0001502)
tebasuna51   
2016-11-24 02:34   
Like is a problem of Aften encoder, and encoding with ffmpeg solve the problem, a workaround is encode with pipe, for instance:

eac3to INPUT stdout.w64 | ffmpeg -i - -c:a ac3 -b:a 640k -center_mixlev 0.707 OUTPUT.ac3

Of course is better if eac3to can include the ffmpeg encoder without need the pipe.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
439 [eac3to] bug feature always 2016-10-17 12:57 2016-10-17 12:57
Reporter: nautilus7 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: Name output files based on blu-ray playlist number instead of m2ts number
Description: Currently, when eac3to demuxes a blu-ray playlist via e.g "eac3to 1) -demux" command, the files created are named after the first m2ts file in that playlist.

So if the playlist begins with the 00000.m2ts file, the output file names will begin with 00000, e.g. "00000 - 2 - h264, 1080p24.h264".

If another playlist from the same blu-ray is also demuxed and that playlist also starts with the same m2ts file, 00000.m2ts, then the output files will have the same name and thus been overwritten.

I suggest change this behavior and base the output file name on the actual playlist number (00000.mpls --> 00000, 00001.mpls --> 00001, 00800.mpls --> 00800, etc), instead of the first m2ts file.

Doing so, it will be possible to demux all playlists in a blu-ray without any naming conflicts.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
253 [madVR] bug minor always 2015-02-14 08:51 2016-02-13 10:30
Reporter: Neroldy Platform:  
Assigned To: madshi OS: Windows  
Priority: normal OS Version: 8.1  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.87.13
Media Player (with version info): MPC-HC.1.7.8.x86
Splitter (with version info): LAV Splitter Source 0.64 x86
Decoder (with version info): LAV Video Decoder 0.64 x86
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: HD8650G + HD8790M
GPU Driver Version: Catalyst 14.501.1003
Summary: XySubFilter + madVR for cropped movie
Description: I'm sorry for my bad English.
I use XySubFiler + madVR for cropped movie, such as 1280x534, the PGS subtitle's shape will changed. But for 1280x720, everything will be fine. And if I use XySubFilter + EVR-CP, the situation will not happen.
I will upload 2 pictures.
Tags:
Steps To Reproduce: Just using XySubFilter + madVR play cropped video with PGS subtitle.
Additional Information:
Attached Files: xysub.JPG (28,267 bytes) 2015-02-14 08:51
https://bugs.madshi.net/file_download.php?file_id=114&type=bug
normal.JPG (20,060 bytes) 2015-02-14 08:52
https://bugs.madshi.net/file_download.php?file_id=115&type=bug
sample .part1.rar (5,242,880 bytes) 2015-02-15 07:21
https://bugs.madshi.net/file_download.php?file_id=116&type=bug
sample .part2.rar (5,242,880 bytes) 2015-02-15 07:24
https://bugs.madshi.net/file_download.php?file_id=117&type=bug
sample .part3.rar (5,242,880 bytes) 2015-02-15 07:27
https://bugs.madshi.net/file_download.php?file_id=118&type=bug
sample .part4.rar (3,985,704 bytes) 2015-02-15 07:30
https://bugs.madshi.net/file_download.php?file_id=119&type=bug
Notes
(0000706)
madshi   
2015-02-14 09:53   
Can I have a small sample of the video + PGS, please? The sample may be very short, I just something to reproduce the problem on my PC.
(0000707)
Neroldy   
2015-02-15 07:21   
Of course, I will upload the sample. It has 4 parts.
(0000812)
madshi   
2015-03-22 16:42   
Hmmmm... This is a difficult problem which needs some discussion:

The PGS is 1920x1080. The movie was 1280x720 and was then cropped to 1280x534. Now madVR has to scale down the PGS subtitles somehow. Currently the PGS X and Y downscaling factors are simply calculated by doing x=1920/1280 und y=1080/534. However, this results in the AR ratio of the subtitles changing.

Now I wonder what the best solution is? Probably I should be using the same scaling factor for both X and Y? But how should I calculate the scaling factor? Should I calculate both factors and simply use the smaller one?

One additional problem is that currently subtitles are drawn in a moment when madVR still only renders the active video rect. Which means that drawing subtitles into the black bars currently doesn't work yet. This will be fixed in a future version.
(0000817)
cyberbeing   
2015-03-22 19:10   
If you were going to allow PGS typesetting, I'd assume you'd need to:

Resize PGS Width to Output Width.
Resize PGS Height with the same factor used for PGS Width (maintain AR)

1920x1080 PGS + 1920x800 Output
=
1920x1080 as-is, display centered vertically on the output frame.

1920x1080 PGS + 1280x534 Output
=
Resize to 1280x720, display centered vertically on the output frame.

The problem, is that you would need to support rendering to black bars or else dialog may be hidden. If you wanted madVR to behave intelligently, you'd have a fallback behavior when black bars were not present or too small to fit the entire PGS frame in original aspect ratio.

__

One fallback solution could be to crop the top and bottom edges of the PGS frame and move them inside the video frame, though you'd probably need to double check your crop lines were transparent:

1920x1080 PGS + 1920x800 Output
=
1920x1080 cropped to 1920x800 Center + 1920x140 Top + 1920x140 Bottom. Top and Bottom crop shifted inside Center crop and displayed.

1920x1080 PGS + 1280x534 Output
=
Resize to 1280x720, crop to 1280x534 Center + 1280x93 Top + 1280x93 Bottom. Top and Bottom crop shifted inside Center crop and displayed.

__

Another fallback solution could be to resize the frame to fit inside the Output frame, while maintaining aspect ratio. This would be at the expense of typesetting positions and subtitle size:

1920x1080 PGS + 1920x800 Output
=
Resize to 1422x800, display centered horizontally on the output frame.

1920x1080 PGS + 1280x534 Output
=
Resize to 949x534, display centered horizontally on the output frame.

__

The last solution is what madVR currently does, stretching the PGS frame to match the output frame, ignoring Aspect Ratio:

1920x1080 PGS + 1920x800 Output
=
Resize to 1920x800, display.

1920x1080 PGS + 1280x534 Output
=
Resize to 1280x534, display.

__


My only concern for any solution is that fixing this for PGS does not break VSFilter compatibility in regards ASS subtitles and anamorphic video, particularly when the "Render to Original Video Size" option is enabled.
(0000819)
madshi   
2015-03-22 19:22   
Rendering in black bars is planned for a future version, so that's what I'll be doing.

The question is which scaling factor I should be using. You're saying I should only look at the width. But what happens if a 4:3 Blu-Ray is cropped? Then the encoded movie would be 960x720. In this case I'd have to look at the height, wouldn't I? I think I should calculate both X and Y downscaling factors and pick the smaller one, no?

I don't think any of this should break ASS subtitles. ASS subtitles are supposed to be rendered by XySubFilter in exactly the resolution I need, so no scaling needs to be done there. Any changes I'll do because of this bug report it going to be only for subtitle images that need scaling.
(0000825)
cyberbeing   
2015-03-22 21:26   
(Last edited: 2015-03-22 21:28)
> Rendering in black bars is planned for a future version, so that's what I'll be doing.

You'll still need some kind of fallback for situations where black bars may not exist, like Windowed mode?


> I think I should calculate both X and Y downscaling factors and pick the smaller one, no?

Yes, that sound right.

1920x1080 PGS + 1440x1080 Output
=
1920x1080 as-is, display centered horizontally on the output frame.

1920x1080 PGS + 960x720 Output
=
Resize to 1280x720, display centered horizontally on the output frame.


> Any changes I'll do because of this bug report it going to be
> only for subtitle images that need scaling.

Which is why I feared it would affect XySubFilter's "Render to Original Video Size" option, unless I'm forgetting how madVR handles that option. From the point of view of madVR, that option causes XySubFilter to report the size of ASS bitmaps in a similar way to PGS. If madVR blends subtitle bitmaps which match originalVideoSize immediately, prior to anamorphic and other scaling, it shouldn't be an issue.

(0000828)
madshi   
2015-03-22 21:59   
If the subtitle frame's "GetOutputRect()" happens to match the unscaled video resolution then I *think* madVR should not apply any scaling.
(0000857)
kasper93   
2015-03-25 13:39   
(Last edited: 2015-03-25 13:41)
It is indeed tough case to handle. We did add so called "best fit" in MPC-HC's renderer. Subtitles have always preserved aspect ratio and scaled to the video (if needed). Idea here is that to always get perfect (source like) subtitle placing and sizing also on cropped video frames. Of course in this case user need to simulate "black bars" in case there are subtitles to be drawn there. Otherwise they will be cropped. But this is by design.

(Additionally I wanted to add adaptive mode to scale down subtitles (preserving AR) if they don't fit in window rect, but we didn't decide to do that after all.)

For reference here is my commit with all math to calculate target rect. All magic is there to handle cropped 4:3 and alike.
https://github.com/mpc-hc/mpc-hc/commit/752ba8d9e651e3f19d2f2dd74cd5b391cab14cbf
We did exclude anamorphic videos later on because DVB subtitles doesn't play well with this logic, I mean it works fine but subtitles are not corrected for anamorphic since we always preserve aspect ratio of sub frame. DVB subtitles are ment to be drawn on video and streched along with it. Though I never seen cropped anamorphic sample ;p

(0000858)
madshi   
2015-03-25 14:47   
Thank you kasper95, I'll have a look at your implemention when I get around to implement/fix this.
(0001280)
fawarion   
2016-02-13 10:30   
Yeahhh.... I have Get the Same problem
when Using DXVA for Chroma Upscaling or Chroma Downscaling in HP Pavilion G4-1314au VGA is AMD APU radeon(tm) HD 6480G, if use another scaling alogarithms except DXVA. Scaling from DXVA in AMD are bettter colour from another scaling but got Cropped display.

When i have using same configuration setting in my Dell notebook with AMD ATI Radeon, there are no crooped display, nothing seriuously problem.

I'am Using same new Catalyst version 15.7.1

AMD HD Radeon APU was better than AMD ATI radeon.
Whats wrong ......? ?_?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
376 [eac3to] bug minor always 2016-01-02 19:26 2016-01-02 19:26
Reporter: GCRaistlin Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: Channels in output wavs mixed up
Description: 1. Download http://mir.cr/135KAWKA

2. Run:
eac3to 1.ac3 "1.wavs" -4259000ms -edit=0:10:00,-8518000ms
eac3to 1.ac3 "2.wavs" -edit=0:10:00,-8518000ms

3. Listen to 1.L.wav @ 01:05 and to 2.C.wav @ 09:50. You'll hear the same.
1.C.wav doesn't contain voices @ 01:05.

(I understand that the combination of options in the 1st command line is probably senseless, I just tried to find a way to cut a piece from the middle of the file)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
375 [eac3to] bug minor always 2016-01-02 18:32 2016-01-02 18:32
Reporter: GCRaistlin Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.31
Summary: Incorrect processing of the particular ac3 file
Description: The problematic file http://mir.cr/HM0IZ9W2 seems to be an mp3 with WAV header compressed to ac3. It's correct duration - 02:14:57 (recognized by MPC-HC and BeSweet). eac3to determines its duration as 04:29:55.
Command line:
eac3to "True Lies.track_423.ac3" "True Lies.track_423.wav"
produces wav with duration 02:36:19. It's played slowed down.
Command line:
eac3to "True Lies.track_423.ac3" "True Lies.track_423.wavs"
produces wavs with duration 06:44:52. They're played incorrectly, too.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
87 [eac3to] bug major always 2013-06-11 11:22 2015-11-03 10:05
Reporter: r0lZ Platform:  
Assigned To: madshi OS:  
Priority: high OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.27 and 3.30
Summary: Failure to demux subtitle tracks from SSIF or MPLS of a 3D-BD
Description: When there are subtitle tracks in the M2TS file corresponding to the dependent view of a 3D-BD, eac3to issues a lot of "The source file seems to be damaged (discontinuity)" error messages, then fails with "The SUP reader received unknown data. Aborted at file position #."

This is probably due to the presence of two times the SAME subtitle stream in the SSIF file: one time for the base view, and one time for the dependent view.

Many 3D-BDs have no subtitle in the M2TS file corresponding to the dependent view, and in that case, eac3to has no trouble demuxing them. But when there are subtitle streams in the dependent view M2TS, it fails always.

Note: Demuxing the same subtitle stream from the base or dependent M2TS file works perfectly. The problem occurs only and always when demuxing from the SSIF (combined) file, or from the MPLS.
Tags:
Steps To Reproduce: Demux any subtitle track from the SSIF or MPLS file of the movie of a 3D BD with subtitle streams associated to the dependent view.

Some examples of 3D-BDs that have subtitles in the dependent view:
Avatar
Chicken Little
Hugo Cabret
Las aventuras de Tadeo Jones
Step Up
Tangled (Disney)
Toy Story 2 (Disney/Pixar)
The Lion King (Disney)
Additional Information: More info here:
http://forum.doom9.org/showthread.php?p=1632419#post1632419
Attached Files:
Notes
(0000184)
madshi   
2013-06-11 11:24   
Ok, I have Tangled, will see if I can reproduce it, if I find some time (can take a while).
(0000270)
Shevek   
2013-07-04 03:37   
This is also happening on Shark Night 3D
(0000717)
madshi   
2015-03-10 20:18   
My Blu-Rays are currently out of reach, due to being boxed up during my recent move. Is there any way you can provide a small sample?
(0001224)
madshi   
2015-11-01 14:46   
Closed due to lack of reply.
(0001230)
r0lZ   
2015-11-03 10:05   
Sorry, I have not been notified of your comment asking for a sample.
But finally, here it is: http://download.videohelp.com/r0lZ/tmp/DTS_HD_MAsync_bug_sample.dts

It's the beginning of the file, because if I cut later, eac3to doesn't recognise the format any more. As a consequence, demuxing the subtitles from the sample produces only some discontinuity warnings, and the subtitle can be demuxed. With the full original SSIF (20.4 GB), after a lot of discontinuity warning, the demux is aborted with this message:

[...]
s07 0:26:43 The source file seems to be damaged (discontinuity).
s07 0:26:46 The source file seems to be damaged (discontinuity).
process: 47%
s07 0:26:51 The source file seems to be damaged (discontinuity).
s07 0:26:51 The source file seems to be damaged (discontinuity).
s07 The SUP reader received unknown data.
s07 0:26:55 The source file seems to be damaged (discontinuity).
Aborted at file position 10261364736.

The same problem happens with all 3DBDs containing subtitles in the M2TS of the dependent view. It's not always the case and I don't understand why some BDs (notably the Disney and Pixar BDs) include the subtitles in the dep view. As far as I know, it's totally useless.

For your information, here is the analysis of the files of the Tangled movie by eac3to:

E:\>eac3to Z:\BDMV\PLAYLIST\00004.mpls 1)
M2TS, 2 video tracks, 4 audio tracks, 5 subtitle tracks, 1:40:16, 24p /1.001
1: Chapters, 17 chapters
2: h264/AVC (left eye), 1080p24 /1.001 (16:9)
3: h264/MVC (right eye), 1080p24 /1.001 (16:9)
4: DTS Master Audio, English, 7.1 channels, 24 bits, 48kHz
   (core: DTS, 5.1 channels, 1509kbps, 48kHz)
5: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
6: AC3, Russian, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
7: AC3, Ukrainian, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
8: Subtitle (PGS), English
9: Subtitle (PGS), Russian
10: Subtitle (PGS), Ukrainian
11: Subtitle (PGS), Russian
12: Subtitle (PGS), Ukrainian

E:\>eac3to Z:\BDMV\STREAM\SSIF\00000.ssif
M2TS, 2 video tracks, 4 audio tracks, 5 subtitle tracks, 0:59:21, 24p /1.001
1: h264/AVC (left eye), 1080p24 /1.001 (16:9)
2: h264/MVC (right eye), 1080p24 /1.001 (16:9)
3: DTS Master Audio, 7.1 channels, 24 bits, 48kHz
   (core: DTS, 5.1 channels, 1509kbps, 48kHz)
4: AC3 Surround, 2.0 channels, 320kbps, 48kHz
5: AC3, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
6: AC3, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
7: Subtitle (PGS)
8: Subtitle (PGS)
9: Subtitle (PGS)
10: Subtitle (PGS)
11: Subtitle (PGS)

E:\>eac3to Z:\BDMV\STREAM\00000.m2ts
M2TS, 1 video track, 4 audio tracks, 5 subtitle tracks, 0:59:21, 24p /1.001
1: h264/AVC, 1080p24 /1.001 (16:9)
2: DTS Master Audio, English, 7.1 channels, 24 bits, 48kHz
   (core: DTS, 5.1 channels, 1509kbps, 48kHz)
3: AC3 Surround, English, 2.0 channels, 320kbps, 48kHz
4: AC3, Russian, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
5: AC3, Ukrainian, 5.1 channels, 640kbps, 48kHz, dialnorm: -27dB
6: Subtitle (PGS), English
7: Subtitle (PGS), Russian
8: Subtitle (PGS), Ukrainian
9: Subtitle (PGS), Russian
10: Subtitle (PGS), Ukrainian

E:\>eac3to Z:\BDMV\STREAM\00001.m2ts
M2TS, 1 video track, 5 subtitle tracks, 0:59:21, 24p /1.001
1: h264/MVC (right eye), 1080p24 /1.001 (16:9)
2: Subtitle (PGS), English
3: Subtitle (PGS), Russian
4: Subtitle (PGS), Ukrainian
5: Subtitle (PGS), Russian
6: Subtitle (PGS), Ukrainian

00001.m2ts is the M2TS of the dep view. As you can see, it contains also the same subtitle streams. The stream IDs are identical. Therefore, in the SSIF, the same streams with the same ID are included two times! It's probably the cause of the problem.

Demuxing the subtitles directly from one of the two M2TS work fine, without any warning. The bug occurs only when demuxing the MPLS or SSIF.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
357 [eac3to] bug minor always 2015-11-02 11:58 2015-11-02 11:58
Reporter: zhang Platform: x64  
Assigned To: OS: Windows  
Priority: normal OS Version: 10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.30
Summary: Error removing E-AC3 normalization when demuxing TrueHD
Description: When demuxing the Bluray with TrueHD+AC3 audio track into audio.thd+ac3, it will stop working at the following step.

a03 Extracting audio track number 3...
a03 Removing E-AC3 dialog normalization...
(a03 is a TrueHD/AC33 5.1 channel track)

If I add -keepdialnorm it will work fine, so the problem lies in removing normalization.
Tags:
Steps To Reproduce: I'm using the new Leon remaster bluray source, so the clip in 0000345: https://www.sendspace.com/file/cmgie6 can be used to reproduce this issue which I have verified. Use "eac3to.exe clip.m2ts -demux"
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
150 [madVR] bug minor always 2014-02-08 08:28 2015-03-23 09:33
Reporter: turbojet Platform: Windows  
Assigned To: madshi OS: Windows 7  
Priority: normal OS Version: SP1  
Status: acknowledged Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 87.4
Media Player (with version info): Potplayer, MPC-BE
Splitter (with version info): Internal
Decoder (with version info): LAV Filters
Decoding: Software
Deinterlacing: forced film mode
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: 250 and 650
GPU Driver Version: 327
Summary: 60i 3:2:3:2:2 cadence should produce 25fps, but madVR switches to 23Hz
Description: This is originally 25 fps source converted to 30 fps by duplicating every sixth frame.

http://www.mediafire.com/download/jd5s4c5qz4x5tlm/4%3B2cadence.mpg
Tags:
Steps To Reproduce: 1. enable deinterlace and film mode.
2. play the file
3. see good frames being removed
4. osd usually shows 3:2:3:2:2 cadence
Additional Information:
Attached Files:
Notes
(0000389)
turbojet   
2014-02-28 15:48   
Here's 3:2 detected as 4:2:2:2 http://www.mediafire.com/download/150g9d9f7ahmph2/3_2_as_4_2_2_2.mpg
(0000407)
huhn   
2014-03-03 15:59   
are you sure the 3:2:3:2:2 sample is 4:2? if the sample is 4:2 that would mean it is 20 fps.
after a short look at it. it is 3:2:3:2:2 or something like that at least 3:2 is in there. and the output fps should be 25 fps. and 3:2:3:2:2 should result in 25 fps.
the problem is not the wrong cadence detection, because they are both totally right. the problem is the decimation and frame rate control.

i'm just looking here because i was going to report a 4:2:2:2 issue where the wrong frame is droped when played with 23p like your 3_2_as_4_2_2_2.mpg
(0000418)
turbojet   
2014-03-03 22:45   
The file in the original post is 4 good, 2 duplicate frames, isn't that 4:2? Madvr should remove the second duplicate and output 24.975 fps and switch display to a multiple of 25hz.
(0000419)
huhn   
2014-03-04 09:47   
that's not how telecine work.
i think this is a bad place to talk about telecine and top/odd field so you can read the Frame rate differences part from http://en.wikipedia.org/wiki/Telecine .
you are right about the 25fps and that madvr drops the wrong frame but the source of this issue is not the cadence.

a 30i source like ntsc tv got 60 fields per sec and if these fields are 3:2:3:2:2 it should result in 25 fps. but madvr switches to 23p and drops more frames then it should be. on top of it it got quiet some cadence breaks too.
(0000420)
madshi   
2014-03-04 09:50   
madVR currently always switches to 23Hz when having forced film mode on while playing 59i content. Yeah, with some cadences 23Hz is not the optimal refresh rate. But that's not so easy to solve, especially because cadence detection can be unstable. E.g. what happens if cadence detection switches between 3:2 and between 3:2:3:2:2 all the time? Should madVR then always switch between 23Hz and 25Hz all the time, in the middle of playback? This is a problem I'll have to revisit later, but I don't consider it a "bug" right now. It's as intended, even it might not be the best (or even the correct) solution.
(0000421)
madshi   
2014-03-04 09:55   
I've downloaded the sample, added it to my cadence collection, and added an entry to my to do list to look at which refresh rates to switch to with different cadences. But as mentioned above, this will not be easy to do well, because we don't want to switch back and forth between different refresh rates all the time. So this will have to wait until I get back to the whole deinterlacing topic. For now I'll close this bug entry.
(0000422)
madshi   
2014-03-04 10:02   
P.S: Actually, I think there *is* a cadence misdetection of some sort here. Haven't had the time to look at it in detail, but this is different than just failing to switch to the correct framerate. As such I'll leave this open, after all, but it will take some time before I get to this.
(0000423)
huhn   
2014-03-04 10:19   
should i at least create a bug report for a problem with 2:2:2:4 or 4:2:2:2? because in this case madvr drops the wrong frame and the output should be 24 fps. i even found a cadence like this on a bd.
(0000424)
madshi   
2014-03-04 10:31   
Just send me a sample (or multiple samples) via PM or eMail. Thanks.
(0000453)
turbojet   
2014-03-05 00:08   
I thought cadence worked on frames instead of fields, 3:2 would be correct on either but thanks for the info.

I wouldn't expect madvr to change refresh rate every time the cadence changed but I'd expect FRC to toggle on the fly which it already can do without any noticeable change. Refresh rate changes take seconds on 2 displays here. While this wouldn't fix the issue using 24/25/30 hz displays it should work fine using higher multiples, which in some cases should be used currently.

The original post file plays wrong when 50hz is forced, like huhn said it's probably removing the wrong frame.
(0000454)
madshi   
2014-03-05 00:11   
FWIW, the cadence is for fields, not frames. E.g. the typical NTSC 3:2 cadence has one field repeated 3 times and one repeated 2 times.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
245 [eac3to] bug feature N/A 2014-12-05 19:57 2014-12-05 19:57
Reporter: nautilus7 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.27
Summary: Ability to create thd+ac3 blu-ray compatible stream from already existing ac3 stream
Description: Currently, creating .thd+ac3 blu-ray compatible audio stream is only done by inputting an thd stream and on the fly encoding (using aften) an ac3 stream to multiplex with.

This feature would allow to use ac3 streams created with dolby media producer (marginally better quality streams in comparison to aften), but it would also allow to use ac3 streams with completely different content that the thd stream.
Tags:
Steps To Reproduce:
Additional Information: It should be really easy to add such feature. The command line could remain unchanged e.g eac3to input.thd output.thd+ac3

1. Check whether file input.ac3 exists in the same directory as input.thd.

2. If not, then use old method: create .thd+ac3 using aften encoded .ac3 stream.

3. if there is input.ac3 then mux input.thd and input.ac3 together.

In pseudo code:

if (exists input.ac3)
{
    mux(input.ac3, input.thd)
}
else
{
    encode(input.ac3)
    mux(input.ac3, input.thd)
}
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
109 [madVR] bug minor always 2013-07-14 12:42 2014-04-01 19:42
Reporter: nakomaru Platform: x64  
Assigned To: madshi OS: Windows 7 Ultimate  
Priority: normal OS Version: 6.1 (Build 7601)  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: v0.86.8
Media Player (with version info): MPC-HC v1.6.8.7417 Jun 15 2013
Splitter (with version info): Haali Media Splitter 1.13.138.14 or MPC Internal MP4 Splitter (shown)
Decoder (with version info): MPC Internal Decoder (Worse) or ffdshow tryouts rev4515 (shown)
Decoding: Software
Deinterlacing: <select>
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GeForce GTX 460
GPU Driver Version: 320.49
Summary: Irregular frame rates when playing back at non-default speed in MPC-HC
Description: When using MPC-HC/madVR to play back video/audio at a faster than normal rate, for example, at 2.0x speed, the video stream appears to drop frames or stutter.

While using EVR or EVR-CP, the video playback appears to be very smooth and drops few/no frames.

This occurred for me with all of the filter chain combinations indicated, as well both with the ffdshow audio decoder and the built in MPC AAC decoder.

Just after finishing putting together some example files, I noticed that this does not occur in madVR when there is no audio stream. So smooth playback during fast forward is definitely possible in MPC-HC/madVR.
Tags:
Steps To Reproduce: 1. Begin playing a video file with audio in MPC-HC with madVR.
2. Increase the playback speed by some amount. (even 1.25x is noticeable)
3. Video appears to drop frames or has an irregular frame rate cadence.
Additional Information: When playing back at higher speeds such as 2.0x, the video appears to drop frames. This is demonstrated in dustforce_fastforward_evrcp_vs_madvr.mkv with evr on the left at 2.0x and madVR on the right at 2.0x. The source video dustforce_panning_60fps.mp4 provided is 60fps footage with a good amount of panning which shows this effect well. Although the comparison video is also captured at 60fps and necessarily drops half the frames, evrcp still appears smooth. I have included a 30fps capture as well to make sure this was not a high framerate issue.

When playing back at moderately increased speeds such as 1.25x, the frame rate cadence appears to be irregular. What seems to be happening is it will play ~0.5 seconds at 0000001:0000001.3x, then ~0.1 seconds at ~0.5x speed, and so on, or something to that effect. This should be obvious when the character jumps in the 30fps footage.

In addition to the 30fps audio/video mp4 capture, there is also an mkv version to show this happens with both containers, and a no audio version to show this doesn't happen with video only streams.

http://home.comcast.net/~nakospace/dustforce_panning_60fps.mp4
http://home.comcast.net/~nakospace/dustforce_fastforward_evrcp_vs_madvr.mkv
http://home.comcast.net/~nakospace/dustforce_panning_30fps.mp4
http://home.comcast.net/~nakospace/dustforce_panning_30fps.mkv
http://home.comcast.net/~nakospace/dustforce_panning_30fps_noaudio.mkv
Attached Files:
Notes
(0000550)
madshi   
2014-04-01 19:42   
Which display refresh rate did you test this on? FWIW, I see no problems here at all, as long as the sped up framerate does not exceed the display refresh rate. However, if you e.g. speed up the 60fps video by 2.0x, with 60Hz, then madVR has to drop a lot of frames, and currently it does not do this very well, resulting in stuttering. I consider this a bug, but I also don't consider it very important because you should always use a refresh rate which is higher than the (sped up) movie framerate. Or if you can't, then enable SmoothMotion FRC, and playback gets smooth again. Actually with SmoothMotion FRC is should be smoother than with EVR/VMR, if the sped up framerate exceeds the display refresh rate.

Can you confirm my test results?

I'll set the problem with non-smooth playback if the framerate exceeds the refresh rate with smooth motion FRC turned off to "acknowledged", which means that I'll fix that at some point, but it might take a while until I get to that.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
82 [madVR] bug minor random 2013-06-08 13:27 2014-04-01 19:32
Reporter: DarkSpace Platform: x64  
Assigned To: madshi OS: Windows 7  
Priority: normal OS Version: 6.1.7601  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.86.3
Media Player (with version info): MPC-HC 1.6.7.7114 (9eb64ec)
Splitter (with version info): LAV Splitter 0.57
Decoder (with version info): LAV Video 0.57
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: Off
Problem occurs with mode: all modes
GPU Manufacturer: AMD
GPU Model: Radeon HD 6970M
GPU Driver Version: 2D Driver 8.01.01.1162, Direct3D 7.14.10.0841, OpenGL 6.14.10.10834
Summary: Dropped frames at the beginning of playback and/or after seeking with Smooth Motion on
Description: When playing a file with Smooth Motion activated, madVR will occasionally drop some frames at the beginning of playback (especially noticeable when repeating the playback of a file) or when seeking to somewhere in the file. I think it happens outside of FSE mode as well, but I'm not sure about this.
Tags:
Steps To Reproduce: It doesn't happen always and also doesn't seem to be specific to a group of files. It may happen with one file now and then the next day, opening the same file may be fine, so it seems to be rather random. I attached a Debug Log where it happened only after seeking once (I think I did the seeking at around the three-second mark of the video).
My flush settings are the default flush / flush & wait (sleep) / don't flush / don't flush for both windowed and FSE mode.
Additional Information: I have madVR set to delay playback start until the render queue is full, both for normal playback and after seeking, and I use a separate device for presentation.
I found that the amount of dropped frames seems to depend on the GPU queue size: at my default value of 24, I got 22 dropped frames most of the time, sometimes also 21 or 23, while at the size of 16 (I only tested this briefly), I got 16 dropped frames on the first occurrence.
Attached Files: Log.rar (692,866 bytes) 2013-06-08 13:27
https://bugs.madshi.net/file_download.php?file_id=32&type=bug
Notes
(0000210)
madshi   
2013-06-15 21:11   
Yes, this is definitely an issue, have seen this myself. This will be on my short list of things to do. It will not make it into the very next build, though.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
106 [eac3to] bug minor always 2013-07-09 15:31 2013-07-09 15:31
Reporter: wavelet Platform: Intel i7  
Assigned To: OS: Win 7 Home Premium 32 bit  
Priority: normal OS Version: SP1  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
eac3to Version: 3.27
Summary: Bogus video gap warnings
Description: eac3to gives a large number of bogus "video gap" warnings when run on the following file: http://rapidshare.com/files/1415344562/DVB-T2_sample.ts

Here is the output of a "check" operation:

eac3to v3.27
command line: eac3to -check DVB-T2_sample.ts
------------------------------------------------------------------------------
M2TS, 1 video track, 2 audio tracks, 1 subtitle track, 0:00:19, 25i
1: h264/AVC, 1080i50 (16:9)
2: AAC, English, unknown parameters, -1043ms
3: AAC, English, unknown parameters, -709ms
4: Subtitle (DVB), English
[v01] The video bitstream framerate field doesn't seem to match the timestamps. <WARNING>
Bitstream parsing for tracks 2 and 3 failed. <WARNING>
Demuxing these tracks may still produce correct results - or not. <WARNING>
[v01] Extracting video track number 1...
[v01] Video has a gap of 7 frames at playtime 0:00:00. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:00. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:00. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:00. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:00. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:00. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:00. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:00. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:00. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:01. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 15 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:02. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 15 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:03. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 8 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:04. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 8 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:05. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 14 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 8 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:06. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 8 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 22 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 7 frames at playtime 0:00:07. <WARNING>
[v01] Video has a gap of 21 frames at playtime 0:00:07. <WARNING>
Video track 1 contains 475 fields.
eac3to processing took 1 second.
Done.
Tags:
Steps To Reproduce: eac3to -check DVB-T2_sample.ts
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12 [madVR] bug tweak always 2013-02-16 17:10 2013-02-16 20:59
Reporter: mark007 Platform: x64  
Assigned To: madshi OS: Windows  
Priority: low OS Version: 8  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
madVR Version: 0.85.8
Media Player (with version info): mpc-be build 2080
Splitter (with version info): LAV 0.55.3
Decoder (with version info): LAV 0.55.3
Decoding: Software
Deinterlacing: none (progressive)
DXVA2 Scaling Active: no
Aero / Desktop Composition: On
Problem occurs with mode: all modes
GPU Manufacturer: NVidia
GPU Model: GTX 295
GPU Driver Version: 313.96
Summary: Windows -> Fullscreen
Description: During playback, switching from a small window (windowed mode) to fullscreen (exclusive mode). The transition from small to large happens in two phases instead of one, ie the image is first stretched horizontally to fill the width of the screen, then a few milliseconds later, vertically to fill the height. Its most noticeable on slower machines as it obviously happens much slower, and the user can think something has gone wrong temporarily as the image can look extremely badly out of proportion.

I put this as a tweak as it doesn't break anything, just visually looks wrong compared to other renderers that don't show this behavior. Maybe the transition can change width and height in one operation.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000033)
madshi   
2013-02-16 17:26   
Ok, bug report accepted, but extremely low priority. Not anytime soon.
(0000034)
mark007   
2013-02-16 20:59   
Thanks madshi. Thought it was best to mention it here in case you ever want to look at it in the future.