Search options

Sorry I missed that I'm sure that will fix it! Thanks!

Chainik this is really interesting to me.
It must be something funny going on specifically with my setup.
Maybe the fact I'm using an eGPU.... Or maybe because I have an Intel CPU with Integrated Graphics it's doing something strange.
I have another AMD laptop I can try it on, but I'll have to remove one of the nvme ssd's and use one of those external pci riser cables to test it with an nvidia gpu to see if it works or not.
That probably won't happen for another month but i will report back here if I try it.
Your result does at least give me hope though that when/if I build my desktop PC with an AMD cpu and Nvidia GPU it may just work using 220706.
One last thing, can you just confirm was this with the portable version or the installed version?
Also if anyone else wants to try PotPlayer 220706 and report back if MVC decoding works it would be cool.
UPDATE: I just tried testing with VapourSynth instead of AVISynth and I can confirm it seems ot require a back ported version of vapoursynth_filter_64.ax . With the current version it shows the same green stretched distorted image as with the original avisynth_filter_64.ax before I added your patched version.
If you provide one I'll try to test that and at least confirm the vapoursynth pipeline can properly receive full resolution TAB 3d content with 220706 (I can test with regular interpolation still I just can't use my nvidia gpu with it for the reasons I said above).
Thanks agian for being willing to help me debug this!!!

Hey Chainik,

Thanks again for trying to help.
So it appears that using 220706 has some other bug that makes it unusable to decode MVC video on a PC with an nvidia gpu.

For some reason the Video Codec "OpenCodec(Intel Media SDK MVC Decoder)" is not being used by PotPlayer when I have the EGPU installed.
But this only happens on PotPlayer versions up until 230207, of which the version you suggested to use 220706 is below.

On any PotPlayer version prior to 230207 if I remove my NVidia GPU it will properly use the Intel Card as the Render Device, and that allows it to use the "OpenCodec(Intel Media SDK MVC Decoder)" to decode the MVC video.
If I put the nvidia card back in though it starts using the built in ffmpeg DXVA decoder by default and there is no way to force it back to use the "OpenCodec(Intel Media SDK MVC Decoder)" code. I spent like 3 hours trying.
If I upgrade to any version after 230207 it will properly use the "OpenCodec(Intel Media SDK MVC Decoder)" irregardless of what video card I have installed (assuming I tell it to).
So they must have fixed that bug with their  230207 release.

Unfortunately the 230207 release has the AVISynth issue where it drops the second frame when you do Full Side By Side or Full Top And Bottom. Presumably only the older release you suggested 220706 doesn't have this issue and they introduced the bug after.

If I connect my EGPU while the video is playing I can get it to keep using the correct "OpenCodec(Intel Media SDK MVC Decoder)" codec for decode whilst updating the render target to the Nvidia EGPU.
But it isn't practical to start playing a movie then plug in an EGPU every time I want to watch a movie, and make sure i don't stop the movie.

I think it's a catch-22 I can't have working AVISynth filters, or I can't have MVC decoding. Unless I remove my GPU, which is what i need to make SVP upscale with RIFE

All I can think is that perhaps there is some way to force the application not even know there is an nvidia gpu and try and use "220706".
I tried this by enabling powersaving mode for just that app, but I couldn't get it to work.

If anyone has any ideas or wants to try on their system to see if they hit the same issue I'de be curious what people fine.
Otherwise I'de say it's time to figure out how to get MPC-BE to render with page flipping output in a performance way.

I don't have that issue, I am able to play an MVC H264, specifically this one 3D_IMAX_Countdown.3D.MVC.mkv https://drive.google.com/file/d/1hGOmRT … ZBgZe/view
Is your MPC-BE having difficulty locating the Intel Media SDK with the H264 MVC decoder? It sounds like that may be whats happening if you are only getting one eye.
My SVP is properly receiving the full TAB video from MPC-BE and then splitting it (I presume) applying RIFE scaling then merging them again and MPC-BE is showing both eyes TAB format 1920x2160.

I found the relevant file and portion of code to modify it's here.
https://github.com/Aleksoid1978/MPC-BE/ … r.cpp#L582
I think the hard part will be setting up a build environment I will try in the coming weeks.
I looked into using HSLS shaders to achieve the same thing, but it won't work that way without losing quality due to downsampling and then upsampling again as the video resolution frame is 1920x2160 not 1920x2205 so you need to zoom out then use the shaders to add the black space then scale it back up. This means your going to lose quality (if I understand correctly, theres a chance it might not, but it seems that way to me).
Also I think there may be some issue with adding the 45 pixel gap prior to passing it to SVP, I will also need to modify hte SVP RIFE template vapoursynth script to strip out the 45 pixel gap before passing it to RIFE and then re-layout the frame interpolated output videos on the frame with 45 pixel gap.

"MPC-BE -> ShaderGlass -> WW" Does definitely work but it is very cumbersome as you need to have 3 windows open all with various settings to allow pass through of clicking and fullscreen vs not fullscreen. Also since MPC-BE determines the render surface size you might need to run it in fullscreen not to lose resolution, but I guess you'de have to make sure it was "windowed" fullscreen so as not to prevent WW running. If one could make a macro (AutoHotKey) or the like to launch it all that would be the way to go I guess.

Ok well I have some bad news, not only are they not going to fix it, they are planning to entirely remove 3d support from PotPlayer very soon ....
And this is why not having an open source package to fix it myself and not lose all this functionality blows.

My Inquiry:
```
Unfortunately there is an issue where when using the external version of VapourSynth or AVISynth as used by SVP, PotPlayer only works when "MVC 3D Transfer Mode" is set to "Synthesized View: TAB/SBS at half resolution". If one sets it to "Synthesized View: TAB/SBS at full resolution" only a single left or right frame is served up to the AVISynth or VapourSynth script.

This forum thread has images and discusses the intricacies of the issue.
https://www.svp-team.com/forum/viewtopi … 824#p86824

To be clear if one uses the built in location to supply an AVISynth or VapourSynth script the scripts there receive the correct dimension of 3840x1080 or 1920x2160.

But it fails to get the correct video frame (with both left and right eyes) when the script is loaded using "Filter Priority (Overall)"->"Add Registered Filter" as required by SVP and other tools externally as described here.
https://www.svp-team.com/wiki/SVP:Daum_PotPlayer

Setting the "MVC 3D Transfer Mode" to "Synthesized View: TAB/SBS at half resolution" means that the frame buffer exposed to external VapourSynth and AVISynth scripts correctly contains both the left and right eyes, but we lose half of the resolution.

If there is anyway to fix it I would very much appreciate it.

There is I believe a related issue which may cause this issue but can be witnessed without needing to use external AVISynth and VapourSynth filters.

Basically if one uses "MVC 3D Transfer Mode" set to "Synthesized View: TAB/SBS at full resolution", then one uses "Output Mode" "side-by-side" The default aspect ratio control over compensates for the side by side nature of the video and squishes it giving you two 32:9 image frames left and right side by side. Somewhat non intuitively, if you set a custom aspect ratio of 32:9 and enable it it causes it to squish them back to the correct aspect ratio. I think the auto determined aspect ratio you are using by default is being double multiplied by some compensation factor when "MVC 3D Transfer Mode" set to "Synthesized View: TAB/SBS at full resolution". The opposite issue happens when using top-and-bottom. The images are half width for some reason so you need to override and set an aspect ratio of "4:9" to cause it to correct them.

Hopefully you can fix the above issue I have mentioned if you have any questions please don't hesitate to ask!
```

PotPlayer Response:
```
That is unable~~

Please note that PotPlayer's 3D playback feature will be removed in the near future.
```

PotPlayer Second Response (after I told them I was very sad to hear they were removing 3d functionality).
```
The 3D feature is no longer being developed and will gradually be forgotten.
Also, the internal code is very messy due to the very complex implementation within PotPlayer, so it is no longer possible to improve it.
Therefore, it is difficult to maintain the issue any longer and it will be removed in the future.
```

I just realized MPC-BE was open source maybe I can try to add my required output format to it.

Hey Chainik,

Given PotPlayer is abandoning 3D support *apparently*, I will need to use an older version of PotPlayer with SVP anyways. Can you tell us the last working version of 64 bit PotPlayer you are aware of that doesn't have the issue myself and GregZone are encountering. You said you thought they had broken something. Are you aware if this ever worked in the past? Or perhaps it only worked from the beginning when the user selected "MVC 3D Transfer Mode" is set to "Synthesized View: TAB/SBS at half resolution". I'm more than happy to use an old version of the software if it will work.

Hey GeoFly,

I'm interested in playing 3D Blurays at 60hz. I'm curious if you can clarify your statement below.

1) Was this statement in regards to 24 to 48 fps conversions (frame doubling?)
2) Does this mean that 3840x1700 (black bars removed) is convertable from 24 to 48 fps with a 4080 super without issue using rife 4.16? (I'm guessing the <1700 pixel high 4k content you were playing was stuff with 2.39:1 aspect ratio as that comes out to about 3840x1607 with black bars.)

So based on the pixels you are processing (I won't bother to include padding to 32/64 pixel block sizes) 6528000 pixels.
For FHD 3D I'de need to process 3840x1080 which is 4147200 pixels.

I'm unsure how the load requirements change when you go from 24 to 48 vs 24 to 60 (aka 2x vs 2.5x).
It's unclear if the increased processing would be 1.5x or 2x what is required for regular doubling.
If it were 1.5x it's conceivable that a 4080 super might be able to process 3840x1080 from 24 to 60 fps.
If it's 2x though it's not going to be powerful enough....

Is there anyway you run a test to see what the max stable output for 24 to 60 hz at a frame width of 3840.

Downgrading to PotPlayer 64bit 1.7.22129 as per the ThreeDeeJay PotPlayer site didn't fix the issue.
I am able to get it working properly with PotPlayer VapourSynth script if I do the following.
Set the MVC 3D Transfer Mode to "Synthesized View: TAB/SBS at half resolution" followed by stopping restarting the video, then once the video is playing selecting Input Source "Full Resolution" twice (the first time it doesn't seem to work).
I don't like this solution because it means it's going to be generating a synthetic half resolution video before stretching it back (thus defeating the point).
But it just goes to show it works.
I looked into the vapuursynth script and I made some minor changes.
Irregardless of whether one selects half/full for "Synthesized View: SBS at half/full resolution" the "clip.width" seen by base.py is always 1920.
It should I believe be getting a clip.width of 3840 when Synthesized View: SBS at full resolution" is selected, but it is not....

I did the same test with avisynth and I get the same issue it shows 1920 as the width regardless of if Synthesized view is full or half width.
```
input2 = input.Subtitle("Width: " + String(input.Width()), size=60)  # Display the width
interpolate(input2)
```

Now for the interesting part.
For AVISynth If I disable the entries in "filter control" "custom filter manager".
And just add a simple subtitle to show the clip width in the inline avisynth logic it prints out the correct width 3840 for synthesized full width and 1920 for synthesized half width.
```
input = potplayer_source()
input2 = input.Subtitle("Width: " + String(input.Width()), size=60)  # Display the width
input2
```

And also for VapourSynth, same thing a custom added script properly shows the correct clip width and height for full and half transfer sizes.
```
import vapoursynth as vs

core = vs.core
clip = video_in
text = f"Width: {clip.width}"  # Get the width
clip = core.text.Text(clip, text, scale=6)  # Display the width with a larger font

clip.set_output()
```

Looking at the generated vapoursynth script the issue seems to be that.
```clip = VpsFilterSource.std.Trim(length=5000000)``` is getting a clip which always has 1920 irregardless of the transfer type half/full.
Meanwhile internal vapour_synth scripts to potplayer itself get a clip width that correctly matches the transfer type half/full.

I tried to load the script into potplayers varpoursynth plugin script location that change "clip = video_in". Then I proceeded to try and empty base.py in hopes that maybe it would work. But for whatever reason PotPlayer crashed, perhaps because SVP was still trying to load the second VapourSynth script and causing problems, or perhaps because the DLL cannot be loaded from within a VapourSynth script typed directly into PotPlayer..

At this point I'm at a bit of a loss. If the author of SVP wants to chime in and let me know why he thinks.
VpsFilterSource.std.Trim(length=5000000) is returning a different width from what the internal scripts get from "video_in"
I'm happy to try testing afew more things until my 30 day trial runs out.

Hey Greg,

One other update, regarding PotPlayer there is actually an installer script written by ThreeDeeJay
https://github.com/ThreeDeeJay/PotPlayer3D/releases
In his 1.2 release notes he said the following.
"""Updated PotPlayer to 240315(1.7.22128) (32-bit, as required by SVP) - ⚠️ Version 240509+ broke 3D SBS layout detection so SBS view looks quadrupled and manually changing it doesn't work, so avoid updating unless it was fixed, though you can always just run the script again to downgrade."""
This issue sounds similar to what you described as your problem with PotPlayer, you may want ot try downgrading to 240315(1.7.22128) (32-bit) and see if that fixes your issue (I havent tried it just yet).

Hey Greg,

I saw a post a month ago that detailed how to get "half 4k 3d" resolution on many 3d capable 4k projectors using a custom resolution with ToastyX CRU tool.
I can't find the original post I read, but I found a similar post that is pretty good.
You may want to check it out, getting the pixel clock and timings just right is difficult otherwise you can get tearing.
If I were buying a new 4k 3d capable projector I would definitely try that with SVP and see if you can get amazing results
half resolution 4k at 60 hz for 3D would be something special I have no doubt
https://www.avsforum.com/threads/setup- … r.3291217/
I didn't get a chance to try SVP just yet as I'm waiting for a period where I will have a few days to take full advantage of the 1 week trial to try and get it working right!
EDIT:
I think I found the original link I had read I'll post it here for completeness (it's by the same guy who would have guessed this guy is pretty rigorous in his documentation just like you).
https://www.avsforum.com/threads/playin … e.3289889/