5/31/2023 0 Comments Makemkv remuxIt's called "multiplexing" because audio and video data are interleaved. The cake is still the same cake, just the box is different. It's like taking a cake out of one box and putting it into another box. Re-multiplexing is the process of taking the compressed (or not) audio and video (and possibly other streams) out of one file and putting them into another (the container may be the same type or not) without decompressing and re-compressing them. Of course a (re-)muxing process natively, has nothing to do with re-encoding, de-interlacing, etc. So again, IMO it's about how you (want to) look at it. Or, if one tries to resolve an issue by muxing a sourcefile only with added/other muxing-settings, I would call that a remux too. Suppose you import a mkv into mkvtoolnix, drop a source-subtitle and add another one, mux to mkv again. In my view, the word remux would not only be used when "keeping original source streams and mux into another container". It's subject to consideration indeed, as ron spencer stated. Pre-playback, software de-interlacing for me forcibly comes into play when I need to slow-down certain sped-up (24fps based) PAL music material to native speed (4% speed-change for music is awfully much and can completely devastate groove & rhythm and tonal experience).Īs for the "remux phrase" itself, it's how you want to look at it. As stated earlier, it often is better to leave it as-is. Due to a seek fixing the issue I'm doubtful that this would be NVidia's fault, but I can't be sure, it's still possible.Normally I let my player or tv take care of de-interlacing. I could imagine this to be a bug in either the NVidia GPU drivers, the Intel Media SDK, the LAV Video Decoder or the LAV what are you thoughts on the matter? Do you see a chance there could be a bug in LAV Splitter or Decoder which could cause a 1 frame desync between left and right eye? FWIW, it occurred 3 times for me, and a seek reliably fixed the issue all 3 times for me. Due to the way madVR handles stereo frames this is very unlikely to be my fault. I've played two full 3D movies now with the new glitch handling and I've found that in both movies while they start playing fine, at some point suddenly there appears to be a 1 frame (or more) delay between left and right eyes, which looks rather weird. However, the other issue is unlikely to be my fault: I was able to create a log for that myself, and it appears to be my fault, and I hope to have it fixed in the next build. One of these is the slide show after ~ 1 hour of playback. Ok, I've been able to reproduce two important issues with my Windows 10 HTPC. I hope that the new "use alternative glitch handling mode" will solve the 3D playback reliability issues you reported (movie starting to drop frames like crazy after 1 hour playback or so)? However, in windowed mode I have to dumb the scaling options down a lot to make it run really smoothly. On my PC at least with this option enabled I get reliably smooth playback in both fullscreen windowed (after switching in and out) and FSE mode. This option modifies the D3D11 presentation to behave much more similar to my D3D9 presentation logic. So in v0.90.13 I've now added a new D3D11 sub option called "use alternative glitch handling mode". I can say that this is *definitely* a driver issue, my own logs pretty clearly show that the GPU driver reports bad timing data, which screws up the whole glitch logic which Microsoft recommends to use for D3D11 presentation. So I'd really strongly recommend that you guys setup a profile for 3D which enables FSE mode just for 3D, if you absolutely don't want to use it for 2D.Īnother thing: I've found that the NVidia driver produces very weird and non-spec-conform D3D11 presentation statistics during 3D frame packed output, which caused all sorts of playback issues on my PC. I've also found that FSE mode runs with MUCH better reliability and lower rendering times in Windows 10 with NVidia, when playing 3D frame packed content. I suppose forcing initialization in non-fullscreen windowed mode and then switching to fullscreen windowed mode shortly afterwards might work, but I'm hesitant to add such a bad hack. I've tried several things to work around it (changes in the D3D11 initialization order etc), but nothing worked. From all I can see, it's an NVidia driver issue. This does not happen on my development PC (Windows 8.1), though, and it's a very weird behaviour. Ok, after upgrading my HTPC to Windows 10 and plugging an NVidia GPU in, I can reproduce the problems you guys reported with starting playback in non-FSE fullscreen mode.
0 Comments
Leave a Reply. |