LAV Filters - DirectShow Media Splitter and Decoders

[huhn]

CUVID and DXVA use the same decoder so clearly no.

[VictorLS]

My video card based on GM107 :angry:
I suppose GK107 (Kepler core, not even Maxwell 1-st generation with hybrid h265 decoder). I was hunting for GTX750v2 for a long time - even nVIDIA's support didn't know about GTX750 on GM206 even this year when GPU out on stock!
Can theoretically simultaneously CUDA and DXVA2 push to decode?
I havn't downloaded hotfuzz.vc1 yet, but for h265 huhn right: clearly no.

[nevcairiel]

Please refrain from pointing people at wrong "solutions". Clearly your H264 problem is entirely unrelated to any VC-1 decode issues.
I'll have a look at that vc-1 clip later.

[VictorLS]

nevcairiel
I think h264 and VC1 almost the same, especially with hardware acceleration. Will see.

[nevcairiel]

nevcairiel
I think h264 and VC1 almost the same, especially with hardware acceleration. Will see.

They are entirely different, and the corruption seen in the movie is also nothing like that in your H264 clips.
Also, it works with CUVID with DXVA processing enabled.

Like I said, please refrain from making baseless claims.

[CruNcher]

VictorLS
My video card based on GM107 :angry:
Can theoretically simultaneously CUDA and DXVA2 push to decode?

Yes you can use both API simultaneously they don't exclude each other it seems but performance isn't really holding steady on both the same way if mixed but here we get now more into scheduling and who wins what were when and why no good compare base.

Though no idea why someone would even try todo something like this in Realtime running both at the same time except yeah maybe for problematic side by side stream analysis that runs on CUVID but fails on DXVA2 for certain filter/demux chain reasons.

I already found edge cases where CUVID does better in Playback stability but these where more problematic done bitstreams so far that CUVID can handle a little bit better doing different decisions mostly on the Playback chain side, that finally result in a better playback experience of these mostly weird done streams with Nvidias Decoder :)

http://i1.sendpic.org/t/im/imWfl6e1OEZCapsQDo78cnk9eiP.jpg (http://sendpic.org/view/1/i/dK6uApWnCn2PU5RmIXImYdknoAq.png)

[Gravitator]

CUDA - is a basic calculator. DXVA2 - separate computing unit in the GPU (Mini auxiliary processor for video).
Can a CUDA software engaged decoding 10bit or down 10bit to 8bit? Then feed DXVA2 :) Though somehow relieve the load on weak Core2duo.

[CruNcher]

CUVID is Nvidias own API to either a CUDA Based Hybrid Decoder/Encoder (NVCUVID/NVCUVENC) or a Fixed Function one (NVDEC/NVENC) and it shows that it works partly better with the Hybrid Decoder/Encoder especially :)

Latency in combination with the Hybrid Decoder is mostly very bad via DXVA2n CUVID fixes that with a higher default Frequency you can workaround this problem using dxva2 copy back (which automaticly switches to a higher frequency) but it's not optimal and you lose optimal results for both decoding/encoding cases switching to DXVA2n with Nvidias Driver.
CUVID is optimized for both Scenarios while DXVA2 is not really optimal for Nvidias CUDA Hybrid case and you have to switch manualy and you still will have inferior performance results with Nvidias Dynamic Arbitrator (Power Management).

Nvidia optimized CUVID to Perform the best for both Scenarios no matter what with their Driver it's in it's base a Compute/3D balance thing ;)

Compute requires higher Frequencies you have to manage that for both Scenarios efficiently on Nvidias Architecture or else you run preemption wise (running both at the same time) into problems affecting your overall latency heavily.

Paxwell has a Software Async Optimization which cleverly used can further reduce these issues.

On AMDs GCN if used right there are not such issues because both can run virtually in parallel (Hardware supported) without affecting each others Performance.

[drew_afx]

I'm currently using intel iGPU as DXVA2 Copy-Back by connecting both HDMI and DP cables to same monitor (only using discrete gpu as source on the monitor of course) and have windows 10 extend the desktop.

Is it not possible to use QuickSync as DXVA2 CB without connecting the iGPU to monitor with a cable? Or, does selecting QuickSync as HW decoding option have the same effect?

I've been using my discrete gpu for DXVA2 CB and madvr, but wanted to see if adding iGPU would bring any improvement.

[VictorLS]

This file is played with a scattering of squares through DXVA2 (CUDA normally). hotfuzz.vc1 (before playing it is desirable to pack the file through mkvtoolnix to .mkv).
Win10x64, Core2duo 3GHz, GTX750v1, driver 375.95, LAVx64 v0.68.1.36.
I couldn't repeat "scattering of squares" while playing hotfuzz.vc1 muxed with some mp3 (without audio it isn't playing) in either XP or 7x64 or 10x64. What player do you use in 10x64 and what renderer in it and what DXVA2 mode in LAV (native or copy-back) to see squares?
But I'm agree - file some strange - in XP with commercial Cyberlink and ArcSoft Decoders it stutters with DXVA1. With MPC decoder plays well with DXVA1. With LAV CUVID well too, of course.
They are entirely different, and the corruption seen in the movie is also nothing like that in your H264 clips.
Because, VC1 is progressive? I think you are right.

Anybody see "scattering of squares" in hotfuzz?

[CruNcher]

Latency Render Issue DXVA2 Native Nvidia Hybrid CUDA Decoder
Low Complex HEVC Main 8 Bit
EVR CP D3D9E
GTX 970 Windows 7 SP1 Platform Update WDDM 1.1

Lav CUVID 0.3xx ms

http://i1.sendpic.org/t/73/73hokcx1v5gY4IoZLdkBkAQ6UiI.jpg (http://sendpic.org/view/1/i/rcw7H2m9PKCyBk8BDBGbQ60VoHU.png)
http://i1.sendpic.org/t/Mt/Mt3zHbW9k3qWEmBwgg3Mhi90gR.jpg (http://sendpic.org/view/1/i/xnvQb2wUrHfSkt2JRYkIqHwQJAa.png)



Lav DXVA2 Native 9 ms (heavy render fluctuations throughout)

http://i1.sendpic.org/t/7B/7BcHJA0yW4BOgJbIstmbUwMzMDk.jpg (http://sendpic.org/view/1/i/iY2gH2i5hSABb1bhfVu3FHzotMa.png)
http://i1.sendpic.org/t/sF/sFblaLRHXQdt81oAGNnAgYLqZ27.jpg (http://sendpic.org/view/1/i/c28YAzmjc7xOh7VeEfbzYn1hMY2.png)


So you can guess until this issue is fixed once and for all im personally no fan of removing CUVID like nevcariel seems to be thinking of now.


PS: Though it becomes rather interesting now Frequency behaviour seems to be since some driver perform very close to each other and still the render latency issues occur with DVXA2 Native/Copy-Back even with lower Memory Frequency Decission for CUVID, the whole thing needs another evaluation.

So CUVID by now overall more efficient under WDDM 1.1 EVR-CP (at least) then DXVA2 natively ?

And if you look at that example that is no small gain here we talking about Windows 7 DXVA2 would be beaten by Nvidia CUVID by now from the Driver side look at the frame drops of DXVA2n and the heavy jitter compared to CUVID for merely a very few amount of more resources ;)

Lav DXVA2 has absulutely no chance here i need to evaluate with more DXVA2 implementations but it could be the case :)

[sneaker_ger]

I'm currently using intel iGPU as DXVA2 Copy-Back by connecting both HDMI and DP cables to same monitor (only using discrete gpu as source on the monitor of course) and have windows 10 extend the desktop.

Is it not possible to use QuickSync as DXVA2 CB without connecting the iGPU to monitor with a cable? Or, does selecting QuickSync as HW decoding option have the same effect?

I've been using my discrete gpu for DXVA2 CB and madvr, but wanted to see if adding iGPU would bring any improvement.
LAV does not support "headless" mode for DXVA2.

[jkauff]

LAV does not support "headless" mode.
Headless mode requires Win 8.1 or greater, which would leave out a lot of users. Not to mention what I would guess would be a substantial coding effort.

The "fake display" trick still works, though.

[nevcairiel]

Actually it should work with the QuickSync decoder as long as the GPU is enabled and a driver installed (and Win 8.1 or newer). It can use D3D11 to access it. I haven't tested it in ages though, as my current primary system doesn't have a Intel iGPU.

[CruNcher]

Some nice optimizations took place on the Driver side with CUDA and CUVID everything got more render efficient and latency improved through the bank :)

Makes the Hybrid Decoder more stable to use with Lav CUVID :)

Love the overall Perf Characteristics of that Driver branch of 375.63 [r375_45-10]

http://i1.sendpic.org/t/lW/lWSAvFjCLtPzZGZb1GYwxxL3Cf5.jpg (http://sendpic.org/view/1/i/3La2f5szcDRu84nW750x2GJ43AT.png)

[sneaker_ger]

Is the latest nightly (.37) supposed to work with HDR from Matroska/WebM? Doesn't seem to be triggering madVR's HDR mode for me.

[nevcairiel]

Is the latest nightly (.37) supposed to work with HDR from Matroska/WebM? Doesn't seem to be triggering madVR's HDR mode for me.

No, it is not.

[Gravitator]

What player do you use in 10x64 and what renderer in it and what DXVA2 mode in LAV (native or copy-back) to see squares?
Native and copy-back.
___________________________________________________________________________________________________
Win10x64, Core2duo 3GHz, DDR3 8GB, GTX750v1 2GB d375.95, MPC-HC-x64 v1.7.10, madVR v0.91, LAVx64 v0.68.1.36.

[VictorLS]

Gravitator
It's a pity I can't see your attachment (anybody can?) but you can ask your question about "squares" here http://forum.ixbt.com/topic.cgi?id=10:56858 or here http://forum.ixbt.com/topic.cgi?id=10:60902 - may be someone repeat "squares" and answer you.

[Nintendo Maniac 64]

It's a pity Nintendo Maniac 64 not answered my questions: Can you provide hardware (model of laptop, CPU, GPU if present) and software (OS and player with renderer you use or tried) configuration?

The main reason I have not is because I want to gather more data points first and therefore my initial concerns may or may not turn out to even be all that accurate depending on the results.

[TheShadowRunner]

Nev, another issue with LAV Splitter that baffles me ^^;
It has to do with matroska and aspect ratio.
Sample: http://videoff7.free.fr/wrongAR_sample.mkv
Display width of the video track is set to: 704x528 (4/3)
With Haali Splitter, it displays properly at 4/3.
With LAV, it's wrong (16/9) and video resolution is reported as 704x400.
It seems LAV Splitter isn't taking into account the display width that was set for the video track?
Again for this test, only the splitter is altered in the whole decoding chain.

[LigH]

There is a difference between two aspect ratio values reported by MediaInfo:

Width : 704
Width : 704 pixels
Height : 400
Height : 400 pixels
Sampled_Width : 704
Sampled_Height : 400
Pixel aspect ratio : 0.758
Original pixel aspect ratio : 1.000
Display aspect ratio : 1.333
Display aspect ratio : 4:3
Original display aspect ratio : 1.760
Original display aspect ratio : 16:9

Respecting the "Original ..." flags is not desired here, correct?

Just to check all possible reasons: Is your LAV Filters set up to prefer container or content AR flags? – But the container has no AR flag reported in MediaInfo. So the content AR should be the only relevant.

[nevcairiel]

Works fine for me, plays as 704x528. Note that ultimately its up to the video decoder to use an aspect ratio, and if you use other decoders then LAV Video, there is no telling what aspect ratio information they use, so if anything you would have to ask them. LAV Video prefers the container AR when its set and valid.
Haali does some evil hackery and actually overwrites the aspect ratio inside the h264 bitstream so it may work with more video decoders - but i'm not in the business of evil hackery.

[TheShadowRunner]

There is a difference between two aspect ratio values reported by MediaInfo:

Width : 704
Width : 704 pixels
Height : 400
Height : 400 pixels
Sampled_Width : 704
Sampled_Height : 400
Pixel aspect ratio : 0.758
Original pixel aspect ratio : 1.000
Display aspect ratio : 1.333
Display aspect ratio : 4:3
Original display aspect ratio : 1.760
Original display aspect ratio : 16:9

Respecting the "Original ..." flags is not desired here, correct?

Just to check all possible reasons: Is your LAV Filters set up to prefer container or content AR flags? – But the container has no AR flag reported in MediaInfo. So the content AR should be the only relevant.

Yes, the original (encode) ratio isn't desired here.
And I don't see any AR setting in LAV Splitter 0.68.1..
With Haali, the video AR source is reported as 704x528, with LAV it's 704x400..
I'm using ffdshow to decode the video stream (but that shouldn't make any difference?)

[TheShadowRunner]

Works fine for me, plays as 704x528. Note that ultimately its up to the video decoder to use an aspect ratio, and if you use other decoders then LAV Video, there is no telling what aspect ratio information they use, so if anything you would have to ask them. LAV Video prefers the container AR when its set and valid.
Haali does some evil hackery and actually overwrites the aspect ratio inside the h264 bitstream so it may work with more video decoders - but i'm not in the business of evil hackery.
Ah yes, with LAV Video dec, the AR is correct.
It's still strange, with Haali + ffdshow, ffdshow is indeed using the container AR.
But with LAV + ffdshow, ffdshow doesn't..?
(the stream is divx5 so i don't think Haali does anything evil ^^;)

[nevcairiel]

Use LAV Video and everything works fine. Or fix ffdshow. Its the decoders job to pick an appropriate aspect ratio, my decoder does so. There is nothing else to do. And Yes, Haali does quite a bunch of evil things to work around broken things like ffdshow, which was one of the key ideas I started on - not to repeat those.

[nevcairiel]

Is the latest nightly (.37) supposed to work with HDR from Matroska/WebM? Doesn't seem to be triggering madVR's HDR mode for me.

The next nightly (ie. tomorrows) should support those streams.

[sneaker_ger]

Great, thank you. Will it prefer container or bitstream (e.g. HEVC) or are both passed on and the renderer decides?

[TheShadowRunner]

Or fix ffdshow. Its the decoders job to pick an appropriate aspect ratio, my decoder does so.
And so does ffdshow when used with Haali :rolleyes:
Haali split + ffdshow: OK
Haali split + LAV dec: OK
LAV split + LAV dec: OK
LAV split + ffdshow: NG
this is.. unexpected, just saying.

And Yes, Haali does quite a bunch of evil things to work around broken things like ffdshow, which was one of the key ideas I started on - not to repeat those.
Indeed a wise choice, though I'm not sure it applies here since Haali split + LAV dec is OK.

[nevcairiel]

Great, thank you. Will it prefer container or bitstream (e.g. HEVC) or are both passed on and the renderer decides?

For basic color info, like colorspace/primaries/range/etc, it will prefer the container, and for HDR info it'll use the bitstream if present, otherwise the container.

I could probably add some more checks if the bitstream only has partial info to switch to the container HDR info, or something, but noone ever specifies how two conflicting sets of information are meant to be interpreted.

[nevcairiel]

this is.. unexpected, just saying

No, this is exactly what one would expect to happen. Haali Splitter hacks the new AR into the bitstream so it works with all decoders (including LAV), LAV Splitter relies on the decoder to be smart and do the right thing.
Nothing else about it.


Indeed a wise choice, though I'm not sure it applies here since Haali split + LAV dec is OK.

If you would want to codec AR to be used instead of the stream AR, then you would be screwed with Haali, since it gives you no choice.

LAV Splitter + LAV Video gives you all the choices, and it takes the correct one by default. So thats all thats to it.

ffdshow is dumb and can't use the constainer AR, so Haali does something evil and changes the AR in the codec bitstream to match the container AR, and it magically works everywhere. But its still evil, and you should just use a smarter decoder if you care about this.
In any case, I do not support any usage with ffdshow or Haali anymore, both of those are entirely dead, so if you want to keep using them, you are on your own either way.

[sneaker_ger]

I could probably add some more checks if the bitstream only has partial info to switch to the container HDR info, or something, but noone ever specifies how two conflicting sets of information are meant to be interpreted.
For AR LAV prefers container over bitstream by default, right? I guess doing the same for HDR would at least be consistent. Plus editing MKV container info is easier done than editing the bitstream info. Muxing is last step of production anyways.

(Then again, we have Matroska default values. E.g. matrix must be "unspecified" if element is missing. :rolleyes: )

[nevcairiel]

For AR LAV prefers container over bitstream by default, right? I guess doing the same for HDR would at least be consistent. Plus editing MKV container info is easier done than editing the bitstream info. Muxing is last step of production anyways.


I suppose I can make it prefer container, one wouldn't put it in there if its not supposed to be used, right?


(Then again, we have Matroska default values. E.g. matrix must be "unspecified" if element is missing. :rolleyes: )

I treat unspecified as unset, and if bitstream is set it'll use that. Thats really the only way to handle those.

[sneaker_ger]

I suppose I can make it prefer container, one wouldn't put it in there if its not supposed to be used, right?
Yes, I guess so.

[TheShadowRunner]

Roger that, it makes sense now.
Indeed Haali shouldn't alter the codec bitstream AR as a workaround for ffdshow not using container AR, it's bad.
I'm moving slowly to everything LAV so excuse the late discoveries ^^

[Mercury_22]

Quick question : Why HDR it's not working for MPC-BE + madVR v0.91.3 + LAVFilters-0.68.1-37 but it's working for MPC-BE + madVR v0.91.3 + MPC-BE's internal filters ?
On the same (driver, os, madVR settings, ...) system no other changes (native & copy-back & SW tested )
Do I need to enable / disable something in LAV's default settings ?
Samples : VP9 Profile 2 HDR (http://kodi.wiki/view/Samples)

[har3inger]

I've done some testing to try and narrow down the problem with Dolby II matrix: Seems like the problem exists way back even in version 0.60.1. of LAV filters.

I'm now wondering if it's possible the source is simply strange. Maybe the channels are encoded in 90 degrees phase from each other, which somehow causes cancellation when Dolby combines and phase shifts the signals? Nevcairel, I've got a vid sample I could share with you if you'd be interested to see. For what it's worth, even when I put the down-mixed signal into my 5.1 system that expects to receive 2.0 Dolby Pro Logic II, the audio center is very much moved to the right.

[nevcairiel]

Quick question : Why HDR it's not working for MPC-BE + madVR v0.91.3 + LAVFilters-0.68.1-37 but it's working for MPC-BE + madVR v0.91.3 + MPC-BE's internal filters ?
On the same (driver, os, madVR settings, ...) system no other changes (native & copy-back & SW tested )
Do I need to enable / disable something in LAV's default settings ?
Samples : VP9 Profile 2 HDR (http://kodi.wiki/view/Samples)

If you would read the last couple posts, you would know that its not supported in -37 yet but will need the next nightly.

[Mercury_22]

If you would read the last couple posts, you would know that its not supported in -37 yet but will need the next nightly.

Ooooops Sorry !

[CruNcher]

@nevcairiel

Any idea how to improve this Nvidia Hybrid Decoder situation with Lav DXVA ?

every DXVA implementation shows the same latency problem with it and DXVA copy-back is still sub optimal CUVID Performs the most stable with it on EVR CP but CUVID is not the optimal at playback for the Fixed Function Decoder there DXVA is.

I guess a viable solution to this problem could be using CUVID for the Hybrid Decoder as preferred and DXVA for the Fixed Function Decoder.

The more complex the Bitstream the more problematic this issue becomes here on the GTX 970.


Nvidia Hybrid HEVC Decoder EVR-CP DXVA Native Latency issue

Lav DXVA

http://i1.sendpic.org/t/ha/haqPKrCDHz60YljJw3D3vSgm4H8.jpg (http://sendpic.org/view/1/i/fyUNDmGDHRu3dXvOh37JrH5KXij.png)

http://i1.sendpic.org/t/oy/oyD2iaXo20TZmuNn1uT1lgTWrlI.jpg (http://sendpic.org/view/1/i/gZAZCRrezMhuukElrMtjLu5SdlU.png)

Lav CUVID

http://i1.sendpic.org/t/36/36GrOaL7LwI4nrO7pMuQOAkqGOW.jpg (http://sendpic.org/view/1/i/f1kA0RVJ1DeLj4q7TqxqQJoG9FZ.png)

http://i1.sendpic.org/t/kl/kl1ekaXRwoC5M2USrS9KyqRTstk.jpg (http://sendpic.org/view/1/i/a8QkH14lxXUw7WiEQIl0C8g0sej.png)


you see their up to 20 ms render spikes with DXVA it stutters like crazy with CUVID the present is ultra smooth either Windowed or Fullscreen.

PS: i will close this case now as for me finally i can exactly reproduce it and i can be sure that this is the exact issue and have to reevaluate a lot now based on it (First testing different EVR-CP implementations and how they behave with the CUDA Decoder and DXVA).

Especially finding the exact reason now why the CUDA Decoder behaves like that with DXVA and EVR-CP (very unstable) on my System of course it would be rather nice if some LAV DXVA Nvidia Maxwell users could maybe try to reproduce it on their Systems under at least similar properties (Maxwell HEVC Cuda Decoder DXVA and EVR CP presumably on Windows 7) especially if they where surprised why Bitstreams that would rather fall absolutely in the Decoder Specs behave problematic like that with DXVA and spiking like crazy on the present render times.

The major difference is the Core Frequency with CUVID it stays with the sample test above constantly @ 1126 MHz CPU: 23% GPU 22%

DXVA Native want's to go down immediately to 7xx MHz rises up to 1126 but present latency doesn't improve.

And when DXVA Copy Back decides to go as low as Memory 747 MHz and Core 911 MHz it goes totally out of sync.

And becomes a mega present disaster

http://i1.sendpic.org/t/qw/qwTIsqvJcCFCH0hCLVKX1mS93Ft.jpg (http://sendpic.org/view/1/i/rHRRktakhW0BTKW2efyHkVz3Q3n.png)


It seems Nvidia never really tested the CUDA Decoder on something like EVR-CP and it's reliability their with DXVAs Dynamic Frequency Decisions.

It completely fails to understand how to get the playback stable it seems the Frequency decisions taken are totally wrong for the CUDA Decoders stability.

I guess there is really no other way to maintaining stability for the CUDA Decoder then to switch Dynamically to CUVID for this specific Playback Scenario.

[sneaker_ger]

The next nightly (ie. tomorrows) should support those streams.
Working good. (not that I expected any different)

[Kotik]

There is an issue with 3D subtitles, specifically in Life Of Pi, the 3D effects of the movie cut through the subtitles.

I am opening the proper .mpls file directly from the disc, using latest lav nightly and latest madvr.

The other issue is with my Avatar 3D disc, with this one if I open directly the .mpls then the 3D subtitles have the correct 3D depth but if I repack the movie with makemkv then the subtitles are not getting the correct 3D depth, I noticed that makemkv is picking up 00852.mpls as "Title 0" and if I play directly this .mpls then the subtitles have the proper depth, this could be a makemkv bug.

Regarding Life Of Pi though there is no makemkv involved so I tend to believe it is a splitter issue.

Thanx in advance.

PS. My tv is passive 3D and the movies themselves are playing fine.

[madshi]

@Kotik, sounds like 2 different issues:

1) MakeMKV created MKV files not working properly. Could be MakeMKV's or LAV's fault.

2) Life of Pi not working correctly, even when playing the .mpls file directly. This could be madVR's or LAV's fault. Can you create a Life of Pi sample? MakeMKV obviously isn't suitable for that. We'd need all the Blu-Ray supports files (like playlists etc), plus a small portion of the movie m2ts file.

[Kotik]

Can you create a Life of Pi sample? MakeMKV obviously isn't suitable for that. We'd need all the Blu-Ray supports files (like playlists etc), plus a small portion of the movie m2ts file.
Here (https://www.mediafire.com/?yvnt116d4u77aur) are the essential files from the Life Of Pi 3D bluray disc. Keep in mind i didn't include any video files cause i am not sure how am i supposed to cut a small sample of a .ssif fille.

[NikosD]

@Cruncher

If I understand correctly your final review on the subject is that on specific environment (Maxwell, Hybrid HEVC decoder, Win 7, EVR-CP) the CUVID (CUDA API on top of DXVA) hybrid HEVC decoder is better in playback difficult streams than DXVA native/ copy-back.

Did you try other decoders/ implementations for your specific environment, like Cyberlink's or PotPlayer ?

If I were you I wouldn't spend so much time testing HEVC hybrid decoder.

I would go to fixed-fuction HEVC decoder, buying new hardware of course.

[CruNcher]

Revisiting another test case issue (Scenecut Spikes)

Lav Video/MPC Video

http://i1.sendpic.org/t/6g/6gCgm0ENVDV8Gvy498CHKSk2ftu.jpg (http://sendpic.org/view/1/i/jcJLCef8cYKZBnRAsrGKQlSPPTL.png)

Lentoid

http://i1.sendpic.org/t/bi/biFgpiFLCvrRPx8rH8KOamqfl5x.jpg (http://sendpic.org/view/1/i/5hWRIE5eo5VJJywdT5YwY6nvbMO.png)

PTC works better for LAV Video but creates still 1 down spike at least per scenecut (perceptible stutter)

Really interesting how much more of the Samsung ATEME Kyrion Encoder Streams have this issue actually that Lentoid avoids very successful.


@NikosD

Yes i tried MPDN Renderer it works ok with DXVA Copy Back and Lav Video for the CUDA Decoder but it has major issues with stable Multithreaded CPU Playback with Lav Video (decoding queue stalls very fast) compared to EVR-CP in MPC-BE

Also Potplayer works rather ok with its D3D Renderer but jitters to much with DXVA Copy Back on EVR-CP compared to CUVID with the CUDA Decoder as well.

@Aleksoid1978 and VictorLS

3. Aleksoid1978's patches very great too, i.e. LAVFilters-0.68.1-35.exe (10МБ) https://yadi.sk/d/M5KOnw9YyoQWo with "hacky workarounds" - possibility to uncheck Use HQ DXVA processing - and with unchecked Enable Adaptive HW Deinterlacing I see same deinterlacing quality (can anyone check?) but RussiaHD.ts and such other files and SAT channels are playing without artifacts and with hardware acceleration in LAV Video Decoder in Win7. I haven't to install LAV CUVID Decoder anymore - one LAV Video Decoder with NVIDIA CUVID hardware acceleration quite enough for me now in all ocсasions.
There is a mjor problem with Aleksoids HQ DXVA Processing patch addition to Lav Video CUVID is not gonna work with every Stream that way if HQ DXVA Processing is disabled and is falling back to the CPU Decoder instead of CUVID.

I can play now your RussiaHD.ts without block distortions with Lav CUVID but LG_4K_View-the-Feeling.ts for example doesn't want to work anymore with CUVID with HQDXVA option disabled many other streams as well fail now and falling back to the CPU Decoder, the patch looks not that stable yet.

So this workaround practically is for now pretty much needed to be done fully manual on first sight of the Decoding issues and reverted back for other streams that might not interop with it at all ;)

[nevcairiel]

Here (https://www.mediafire.com/?yvnt116d4u77aur) are the essential files from the Life Of Pi 3D bluray disc. Keep in mind i didn't include any video files cause i am not sure how am i supposed to cut a small sample of a .ssif fille.

From the metadata files alone I can't see anything wrong. It marks the 5 PG streams with 5 different subtitle offsets, and LAV reads those fine.

For further samples - LAV doesn't read the .ssif file, it reads the two split m2ts files.
In this case, 01217.m2ts for the 2D view, and 01218.m2ts for the 3D extension.

You can split them with any binary file splitter, on Linux I would just use the "dd" tool for that... :)

[madshi]

@Kotik, at which runtime is the first subtitle (of any language) which has an incorrect 3D depth? If it's very early, you should be able to simply truncate the 2 m2ts files (mentioned by nevcairiel) after a couple hundreds MBs. If you need help how to do that, let me know, it's pretty easy with a decent (freeware) hexeditor.

[Kotik]

I am currently uploading a 1GB chunk for each .m2ts file, it is going to take some time since my line has slow upload speeds.

I believe i will be done in around 3 hours.

[madshi]

And the problem can be reproduced with these chunks? If so, that'd be great! Might make sense to send the link to nevcairiel and me via PM instead of posting them here in the forum, because we don't want to violate any copyright stuff. Just chasing bugs...