Evaluation of HEVC decoders (SW, Hybrid and HW)

[NikosD]

No, not people.

It's actually you and a few others writing here.

And I'm wondering, where are they ?

[huhn]

if you think everyone here is a troll.
and you still have nothing to bring on the table`i wonder what people call that... kind of sad isn't it?

[NikosD]

You make me repeat myself and that it's kind of sad actually.

It's only you and a few others.

I know that you live for commenting me whatever I write wherever I write here in doom9 but after a while it's not funny...

It could be scary actually.

[huhn]

so that how you avoid your own started topic of broken nvdia drivers.
you can block people on this forum just a reminder.

[NikosD]

Thank you for the last one, a good reminder.

[CruNcher]

By far better drivers from AMD this year compared to Nvidia which had a lot, lot of problems.

Crimson Relive are extraordinary good, as I read to technical sites/ reviews.

This afternoon I will get a Sapphire Nitro+ RX 470/8GB and test the Polaris HW decoder in the next few days, even in VP9 (hybrid) after Crimson's Relive activation.

Stay tuned ;)

Nvidia was famous, once upon a time, for its drivers.

Actually Nvidia is a software company more than a HW company.

As the whole Internet says all over the planet, besides people here in this thread :) , this year was one bad or probably the worst year ever for Nvidia regarding drivers.

But, what the Internet and the technical sites know when we have so wise and skilled people around this thread...

Nope you see it very wrong also totally unscientifically at all you don't understand how Nvidias Driver is optimized they only have major problems under Windows 10 nothing else the other WDDM work overly perfect and you can see maybe some problems in rather useless stuff like 3D Vision and G-sync but the core Driver HEART is rock solid overall.

Especially Nvidias Shader Compiler is still the best of the best ;)

And this has very understandable reasons Nvidia invested a lot in going above normal Driver optimization since NT 6 (and they circumvented Microsoft Decisions partly to give users a better overall experience) , but lot of things changed and Windows 10 is a more massive WDDM change that overall AMD was better prepared for also because of different other business related things around a very well known Gaming Console.

In terms of optimization the Arbitrator is very well optimized and tested inside Nvidias driver, they're only very specific situations when it gets problematic and that is when Compute (CUDA) and 3D tasks (OpenGL/D3D/Vulkan) pre emptively hit each other (you need shader power all brute forced trys to get performance will fail, this is how Nvidia scales Gameworks) ;)


Windows 10 is a Driver Minefield in Flux who ever uses that as a work System should be aware that some time will still go by with a lot of problems, there are also a lot of new Security stuff playing a role nobody will really tell you about and problems with different System configurations ;)

Im testing Nvidias Driver codebase on my own and im very picky changing it once im happy with it unless it really gives me a measurable benefit in my workloads.


So if you really want to compare Windows GFX Driver in a correct way please compare them over the whole WDDM timeline since VISTA NT 6 introduction, thank you.


You all speaking about Windows 10 WDDM 2.0/2.1 and don't understand the difference.


i can only lough about the driver issues shown for Nivida here as problematic issues ;)

Really Problematic it was in times of the Arbitrator tuning or introduction of G-sync though some stuff needs certainly adaption to WDDM 2.0/2.1 and new use cases such as Low Latency VR.

VR is also the part where it could get overly problematic for Nvidia old Card user at least pre Paxwell in the future and where AMD will definitely shine at lower cost continuously without user getting headaches, especially in a complete AMD HSA driven Platform like ZEN/VEGA combination in 2017 when the Fusion becomes full reality in the PC mass market after Consoles ;)

Nvidia will heavily need Volta first to be able to recover the loss so Paxwell is a pretty dead investment choice currently.

And Nvidia knows that very very well that's also why their current Paxwell release was the most panic driven ever.



The whole ReLive thing Hype is crazy nothing is really new it's just nice progress for AMDs Driver but it's nothing to go Crazy about other then Marketing if Reviewer really need that kind of advice that AMD is giving them how to test things in that leaked document they should better not review anything anymore ;)

[CruNcher]

Newest Mainconcept SDK Result on Sandy Bridge I5-2400

It survives this Broadcast scene as Cyberlink the only Decoder currently pretty nice resilience decoding result.

their error correction works pretty well in this high bandwith loss situations keeping a very nice smooth motion playback result overall.

http://i1.sendpic.org/t/fV/fVME0iSCTPAFHy8K2Y2wZO1JD34.jpg (http://sendpic.org/view/1/i/ksK0MwQJXxuNsEZLA5kMof9DFuC.png)
http://i1.sendpic.org/t/rw/rwZMs0XshniaaumGCDrsS2d04GC.jpg (http://sendpic.org/view/1/i/cbaknCphv6zOUHWBBxlNSwtqLir.png)

Psy and Decoding Performance wise a great Broadcast Decoding result.

And the non 4K Cameras (Good,Bad Signal results) are still clearly detectable.

Awefull Camera input Signal in the 4K Playout Mix

http://i1.sendpic.org/t/4s/4s4xpCiBu06vwCvqVhuQj5j8PGB.jpg (http://sendpic.org/view/1/i/gVwGOuxtOu7SkrJLxJXLLkOYbTY.png)

[NikosD]

The Nvidia's driver team is clearly in shock, but I don't know the reason.

The whole year almost every release had problems that they were trying to fix in the next release, not always with great success.

That kind of rush has no clear reason and looks amateurish, something that has never happened before for Nvidia.

AMD clearly won the race of 2016 drivers with Crimson.

[CruNcher]

I would agree for Windows 10 only yes but it's everywhere problematic from all points of views for everyone the anniversary update was a bigger core change like a SP back in times and that needed adaption again, especially on the rendering side ;)
Therfore we reached a very low latency OSD Desktop Layer rendering now via Aero since VISTA/WIN7 times :)


Cyberlink does still really well when we get to Low Latency Broadcast Decoding Efficiency :)

Can't wait for their VP9/AV1 results :)

Cyberlink

http://i1.sendpic.org/t/oI/oIcqkyxxIywqY6aJmmd5HQfSNsI.jpg (http://sendpic.org/view/1/i/dDXRHOJF4CAamEm1hlvgzqDsHMN.png)

Mainconcept

http://i1.sendpic.org/t/TN/TNXNWYcTZ0BEHN8R1vomBRptvG.jpg (http://sendpic.org/view/1/i/bYeEGpXQfdv4RFDNn5AsRwTB4CL.png)

I guess you can see the chroma difference very well in the optimized decoding mode ;)

[NikosD]

Hello again.

I used for a few hours a Sapphire Nitro+ RX 470 with 8GB VRAM testing video decoding performance and compatibility issues.

My test system is Core i5-2400 - Win 10 x64 14393.479 - RX 470 - Crimson 16.12.1 (ReLive).

Latest LAV Video 0.68.1-53 (actually I just saw there is LAV Video v0.69 released today, but with no difference than v0.68.1-53) and DXVA Checker v3.14

I also used MPC-HC v1.7.10.269 but with latest LAV Video v0.68.1-53 for playback.

The screenshot of DXVA Checker v3.14 is this:
https://s30.postimg.org/kycts049t/RX_470.png

Now, first of all, as you can see there is no VP9 device decoder yet, so there is no HW acceleration for VP9 using DXVA2 decoders.

Also, Chrome can't use VP9 acceleration for Youtube as of today with a Polaris card.
I don't think we are far away from this day, though.

You can also see that there is DivX (MPEG4-ASP) HW acceleration and MJPEG.
For DivX it's pure fixed-function HW acceleration for MJPEG is GPU based (shaders)

They are not particularly useful nowadays, especially DivX, but it is interesting that AMD provides MFT HW decoders for both, that can be used with DXVA Checker in order to accelerate in HW those codecs.

Regarding H.264/H.265 HW decoding, unfortunately I will not provide specific numbers for specific clips because I found out a very strange behavior of the benchmarking process.

1) The video engine seems to act completely independently from the rest of the chip, regarding monitoring tools.

So, during decode mode benchmarking, the GPU clock most of the times stays at idle clock (!) at 300MHz and the power consumption of the card at ~8W which is the same like idle (!!)

2) Most of the times in decode benchmark mode the performance was lower than in playback benchmark mode.

This is unreasonable and more obvious in codecs like DivX or VC-1 or MPEG-2 where you can have a difference of playback being 3 times faster than decode mode.

Regarding monitoring tools, there is a new (?) GPU utilization parameter exposed by the driver, different than GPU D3D usage, which I haven't seen in Intel iGPUs and it goes from 0% to 100% during benchmarking and playback, fluctuating a lot.

Firstly, I thought that AMD maybe for the first time exposed Video Engine utilization, but this is not the case.

I made a contact with DXVA Checker's developer (actually a lot!) and I'm waiting for an answer if there is a way to benchmark Polaris cards differently, maybe to find another way to put the video engine in a more accurate benchmark mode.

Also, I find out a very strange behaviour for clips that are corner cases for this decoder, like the Ducks 2160p H.264 clip with 375Mbps bandwidth and 50fps, that in realtime playback mode using MPC-HC it could reach ~43 fps dropping frames, but if you repeat the playback procedure could reach 50fps with no dropped frames.

But not all the times.
There is no consistent behavior for those corner cases.

So, after a lot of testing I decided to load my "monster" clip collection of H.264/ H.265 clips with bandwidths up to 1000Mbps and 50fps and these are my results:
(the H.265 clips have been encoded by x265 from uncompressed sources and the H.264 clips by HW H.264 encoder from uncompressed sources)

Decode mode (same or lower than Playback mode) using LAV for H.264 and MS MFT for H.265

2160p H.264

600Mbps at ~30fps

2160p H.265 8bit

600Mbps at ~42fps

2160p H.265 10bit

600Mbps at ~42fps

Please note that for H.264, LAV Video and Microsoft's DirectShow H.264 decoder were very close to performance, but for H.265 8bit/10bit, MS MFT (no DS H.265 decoder at least for my system) was clearly faster than LAV Video.

LAV Video H.265 decoder, after a few runs, could reach the performance of MS MFT but not from the beginning.

Also, it's clear that H.265 decoder is faster than H.264 and HEVC 8bit has no difference than 10bit regarding performance at least on the specific clips.

It is clear from the results above that Polaris HW decoder shouldn't have any problems decoding in realtime Blu-ray UHD.

Regarding compatibility issues, I had no problem at all decoding in HW progressive material of MPEG2, VC-1, WMV3, H.264, H.265 (8bit/10bit).

Also for interlaced content MPEG2, VC-1 were perfect.

The only problem is still for some H.264 interlaced clips, but it will be fixed soon as long as it is mentioned in the drivers to do list.

I will try PotPlayer too and if I find out differences, I will come back on the subject.

Waiting for your comments, after you read carefully this post.

[CruNcher]

Can it decode that TRT4K Euro 2016 Broadcast stream without any latency issues and motion brakeups ?
What about the Channel4K stream and Sony 4K (L)HDR Camp ?

[NikosD]

Which one ?

Do you have a link ?

I don't remember downloading that sample.

[CruNcher]

http://demo-uhd3d.com/fiche.php?cat=uhd&id=54
http://demo-uhd3d.com/fiche.php?cat=uhd&id=143
http://demo-uhd3d.com/fiche.php?cat=uhd&id=144
http://demo-uhd3d.com/fiche.php?cat=uhd&id=146

[NikosD]

From the description I can't see where is the difficulty on decoding those specific clips.

I have started to download the last one, as it is the smallest, but the server is painfully slow.

It gives me only ~140KB/s and unfortunately I have to go.

But I can guarantee that there is no reason of not playing back those clips easily, unless they hide a secret weapon.

[CruNcher]

Good stable Decoding hasn't only todo with how much bitrate i can move around :D

for fixed function decoder the problems lie generally in other parts than that surely Blu-Ray and UHD Blu-Ray should be no problem (and decoder core performance counts only) but Broadcasting is another beast to tame ;)

And AMD from my own point of view has bad credits there in the past in UVD development.

And they where the once that lost back then the whole opportunity to get feedback on Doom9 to begin with and Nvidia/Intel got massive feedback also on their CUDA/OpenCL Decoders from here and improved continuously.

[NikosD]

I have to admit that I'm not easily impressed by SW.

But that ReLive thing is amazing for the easiness and user friendly approach, so i gave it a try and recorded my desktop during real-time playback of the UEFA_Euro_2016_Opening_Ceremony.ts clip.

So, what you see is a real-time HEVC decoded file and at the same time encoded real-time in HEVC!

I couldn't find any issue during playback, but I don't know how you measure latency.
With Jitter ? Sync ?

I used MPC-HC with EVR-CP and statitistics on-screen (Ctrl-J) and below the file.

I have activated all of my monitoring tools at the right of the screen in order to pay attention to those too.

If you find any issues, tell me.

Here it is:
https://www.sendspace.com/file/fkm017

P.S

I used relatively low bitrate for HEVC encoding at 5Mbps and a resolution of 1080p and 60fps.
It's low for that type of HW encoding.

Any issues found out regarding the picture of the encoded file have nothing to do with the real decoded image.

I just wanted to keep the final video small.

Also, I noticed something like tearing in the video, which of course is not present in the real-time decoded file.

The video is just for watching figures, not the quality of the HEVC encoded video ;)

[CruNcher]

Do this please with the Channel 4K sample it pushes the CPU Multithread Decoding to it's maximum EDGE for 4/8 Cores :)

thank you for that realtime insight into the current UVD this kind of video are very rare in such quality also with our comparable system specs pretty nice :)

You would mostly only believe to see this for some heavy 3D computation or encoding but here its sliced 4K 10 bit HDR 60 FPS decoding at the CPUs maximum ;)

http://i1.sendpic.org/t/kB/kBbbRgFpYfROM6nIqH1SOpUSOV0.jpg (http://sendpic.org/view/1/i/eRxASbaKq6NDWBHH2fkQGUUUXUU.png)


Also nice to get a first view on their RePlay Encoder use, looks problematic that intra pulsing isn't so nice :)

Higher bitrate needed if the gop stays that way


Draw time isn't that nice overall but you have the whole timers running and using the MPC-HC fail implementation of the OSD Rendering.

So overall it has to fight heavier :D

[NikosD]

Too easy clip I think.

I captured only 3 and a half minutes from the beginning with some jumps too.

The recording is at 8Mbps this time.

Tell me if you want another part of the clip around 5 minutes max, in order for sendspace to accept it.

https://www.sendspace.com/file/0vgvcu

[CruNcher]

Could you try the same with VSR and MPC-BE

the Clocks looks decent also the RPM :)

I hope though not some Pascal user says now what above 1v my bla bla does 0,8v and 7xx mhz pretty constant which they should achieve with the more powerful VPX core indeed ;)

the Data is pretty comparable to my GTX 970 @ 4K H.264 60 FPS except heat conditions they obviously differ very heavy also RPM

[NikosD]

My native display resolution is only 1680 x 1050.

It's an old display for my backup system.

Using VSR what resolution you want the test to be done ?

[CruNcher]

UHD what else but you really have to higher the RePlay bitrate somehow :)

and don't forget changing to MPC-BE and using the 2nd statistics display mode to reduce overhead you get to much sync offset with all that timers running and overall jitter.

GPU Fan is really impressive :)

i see you almost at the stock clock config for the CPU hardly jumping at all though from the minimum power saving mode

hmm 2 GPU clocks that irritates a little though 2nd seems to react to the complexity try to overlay Afterburner on the EVR CP output this way you also reduce overall timer stress further and you can higher the timer resolution then without to much interception :)

Latency overall feels perfect sound is still pretty much in sync and that from a DXVA Native recording :D

there is only one part in the decoding result im not yet sure about one specific camera movement result but with all this current encoding noise it's rather crazy to make such assumptions anyway, also playing with 50 and recording the DWM surface with 60 is not so optimal.

http://i1.sendpic.org/t/wp/wp4xcyfl8wmAs21PyR5Zz1jdB9n.jpg (http://sendpic.org/view/1/i/pAJdXge8XW3EzFZi4XFtTbTMdpX.png)

Encoder/Decoder evaluation at once remotely :D

Interesting it keeped the 8:5 ratio alive :D

Breite : 1 920 Pixel
Width_Original/String : 1 680 Pixel
Höhe : 1 080 Pixel
Height_Original/String : 1 050 Pixel

That pulsing in the top area that also destroys the video isn't really nice at all but bitrate is seriously way to low for this Low Latency Encoder @ 60 FPS

My guess would be 15-20 MBps at least in that current configuration with the 60 fps target and we could talk about some decent visual result :)

but that 5-6 mbps is way to low for our 60 fps DWM Capture target here in it's current configuration.

Cant wait to see the 8mbps 4K Channel result :)

Saw it nice the Encoder though still cant hold it stable pulsing like crazy as i thought still bitrate way to low though now it goes up to 15 mbps actually :)

Fan is now slowly taking on :) 16xx rpm seems reasonable


Could you run some Vulkan/D12/OpenGL application while recording the playback with VSR at 4K :D ?

But please use MPC-BE on it's 2nd statistics display

So it looks like this

http://i1.sendpic.org/t/aP/aPg9K2qOSA8gT5KLjRg9S7UCenh.jpg (http://sendpic.org/view/1/i/23ktAA4W8r4bonqzDRx5P004HLE.png)

http://www.ozone3d.net/gpu_caps_viewer/

[NikosD]

Also, I find out a very strange behaviour for clips that are corner cases for this decoder, like the Ducks 2160p H.264 clip with 375Mbps bandwidth and 50fps, that in realtime playback mode using MPC-HC it could reach ~43 fps dropping frames, but if you repeat the playback procedure could reach 50fps with no dropped frames.

But not all the times.
There is no consistent behavior for those corner cases.

I will try PotPlayer too and if I find out differences, I will come back on the subject.



OK, there is an update about this.

It seems that most of the decoders have problems with that file and also a bigger problem with this file:
https://www.sendspace.com/file/en6bnw

It's a VFR at 120fps 2160p H.264 clip which both MPC-HC with latest LAV and MPC-BE v1.5.0 can't play fast enough using the Polaris decoder.

MPC-HC (LAV) can reach about ~80fps and MPC-BE it's worse at ~62fps using default EVR-CP renderer.

PotPlayer latest stable x64 1.6.63856 can reach 120fps without any problems using EVR-CP and can play that Ducks clip with 375Mbps with no problem at 50fps steadily.

As always, it's kind of magic what the developers of PotPlayer do and although they use DXVA from ffmpeg (LAV) they have different results.

To the Polaris owners I suggest to test the above 120fps VFR file with various players.



the Clocks looks decent also the RPM :)

the Data is pretty comparable to my GTX 970 @ 4K H.264 60 FPS except heat conditions they obviously differ very heavy also RPM



GPU Fan is really impressive :)

Fan is now slowly taking on :) 16xx rpm seems reasonable


Don't look at the RPM, the monitoring tool can't display 0 RPM which is the default most of the times and just stays at an arbitrary number or the last actual number.
Because Sapphire by default pauses fans if temperature is below 56 Celsius.

The monitoring tool displays real fan speed after >56 C and it's usually <700RPM

I have never seen anything above 900 RPM actually, not even in games (!)

The Nitro series has dual huge fans of 95mm each, so the noise and temperatures are low and can be customized by playing around with the fan speed.

They have an optimized airflow and hot air is pushed out through the vents on the backplate.

Take a look here:
http://sapphirenitro.sapphiretech.com/en/470-8.html#cooling


i see you almost at the stock clock config for the CPU hardly jumping at all though from the minimum power saving mode


Yes, it stays at minimum clock with minimum CPU utilization, like using any other HW accelerator actually :)

Later I'll try MPC-BE with its statistics.

[NikosD]

Really Problematic it was in times of the Arbitrator tuning or introduction of G-sync though some stuff needs certainly adaption to WDDM 2.0/2.1 and new use cases such as Low Latency VR.

VR is also the part where it could get overly problematic for Nvidia old Card user at least pre Paxwell in the future and where AMD will definitely shine at lower cost continuously without user getting headaches, especially in a complete AMD HSA driven Platform like ZEN/VEGA combination in 2017 when the Fusion becomes full reality in the PC mass market after Consoles ;)

Nvidia will heavily need Volta first to be able to recover the loss so Paxwell is a pretty dead investment choice currently.


Things are getting worse for Nvidia.

Microsoft's Win 10 Creators Update on March, introduces new WDDM 2.2

https://s27.postimg.org/m8gc2yzub/WDDM_2_2.jpg

[Yups]

https://community.amd.com/thread/203197

Is Interlaced decoding really broken on Polaris?

[aufkrawall]

In NikosD's world, surely not.

[NikosD]

https://community.amd.com/thread/203197

Is Interlaced decoding really broken on Polaris?

In NikosD's world, surely not.

In my yesterday's post I wrote:



Regarding compatibility issues, I had no problem at all decoding in HW progressive material of MPEG2, VC-1, WMV3, H.264, H.265 (8bit/10bit).

Also for interlaced content MPEG2, VC-1 were perfect.

The only problem is still for some H.264 interlaced clips, but it will be fixed soon as long as it is mentioned in the drivers to do list.


And my last phrase was:


Waiting for your comments, after you read carefully this post.

So, do you have some issues with your life or you are just trolling ?

There is no reason at all to pollute my thread with garbage!

Get a life!

[el Filou]

https://community.amd.com/thread/203197

Is Interlaced decoding really broken on Polaris?
This is just unbelievable. The lack of fixed function VP9 and general lower video decode performance is what made me lose interest in the RX460, but this issue still not being fixed after 6 months is much worse, it's like we're back ten years ago with the obvious video decoding bugs that take months to get taken care of. :(

[NikosD]

90% percent of potential buyers/users of a graphics card, don't even know what interlaced content is and you think someone cares about your "opinion" ?

This is more interesting news:
http://www.guru3d.com/news-story/amd-rx-460-unlocked-with-bios-update-offers-1024-instead-of-896-shaders.html

and of course this one too:
http://www.anandtech.com/show/10905/amd-announces-radeon-instinct-deep-learning-2017/2

VEGA is faster even than Titan X Pascal.

[el Filou]

90% percent of potential buyers/users of a graphics card, don't even know what interlaced content is and you think someone cares about your "opinion" ?
Oh, I'm sorry, I thought this was a video forum, but I seem to have lost my way and somehow ended up in the firmware hacking and machine learning section?

My "opinion" on this is relevant as some people who are interested in a graphics card for the particular task of video playback (which includes a lot of HTPC users) may want to be aware that it cannot reliably decode a decade-old format used in e.g. Blu-ray documentaries or broadcast TV, and this would make the point of how fast it is decoding HEVC (the topic of this thread) a bit moot if some other standard stuff plainly doesn't work, don't you think?
Or do you mean hacking firmware to get 14% more shader power or having a multi-hundred watt GPU being faster at machine learning are more relevant to video playback somehow?

[Yups]

This is just unbelievable. The lack of fixed function VP9 and general lower video decode performance is what made me lose interest in the RX460, but this issue still not being fixed after 6 months is much worse, it's like we're back ten years ago with the obvious video decoding bugs that take months to get taken care of. :(


I couldn't believe after reading numerous times here that AMD drivers were so great this year and Nvidia just garbage. But it seems this is still not fixed. Funy enough, this is called trolling. I wonder what NikosD does here, he is mainly bashing Nvidia with some offtopic nonsense. And he only accepts Nvidia bashing in his thread.

[huhn]

https://community.amd.com/thread/203197

Is Interlaced decoding really broken on Polaris?

i will try it again when and if i get my 480 back.
but there are reports with broken interlaced streams on NVIDIA and AMD and they all come down to stream error which are pretty normal in broadcast.

[VincAlastor]

Please note that for H.264, LAV Video and Microsoft's DirectShow H.264 decoder were very close to performance, but for H.265 8bit/10bit, MS MFT (no DS H.265 decoder at least for my system) was clearly faster than LAV Video.

LAV Video H.265 decoder, after a few runs, could reach the performance of MS MFT but not from the beginning.


Waiting for your comments, after you read carefully this post.

:thanks:

i would like to test MS MFT on a core m 5y71 tablet but i can't find it it directshow filters or Mshevcdec.dll in system. Could you tell us how to use MS MFT, pleae?

[NikosD]

The only way unfortunately is via DXVA Checker.

There are no Video Players (besides built-in Windows) that leverage MFT decoders and I haven't found any other tool besides DXVA Checker to test MFT decoders.

For Polaris owners right now I would suggest definitely PotPlayer with built-in decoders for HW decoding, because MPC-HC and MPC-BE don't look so optimized yet.

Probably the developers of those two popular players should buy a Polaris card some time ;)

[Aleksoid1978]

For Polaris owners right now I would suggest definitely PotPlayer with built-in decoders for HW decoding, because MPC-HC and MPC-BE don't look so optimized yet.

Probably the developers of those two popular players should buy a Polaris card some time ;)

MPC-BE is all be ok with Polaris.

[NikosD]

MPC-BE is all be ok with Polaris.

Not all actually.

As I wrote to my previous post, using MPC-BE v1.5.0 (build 2235) I can't reach 120fps (VFR) with this clip:
https://www.sendspace.com/file/en6bnw

MPC-BE manages to decode around ~62 fps and MPC-HC ~80 fps.

PotPlayer does 120 fps.

[CruNcher]

H.264 resilience MBAFF Decoding is no easy task at all and AMD had allways more problems with Broadcast Decoding since the beginning in UVD so i wouldn't be surprised from my own experience with it.

About Potplayer

lot of care are gone actually especially into Broadcast Decoding after picking up MPC-HC core and restructure and refactoring it

Potplayers DXVA is very nicely integrated into as a whole

Such a stream though is highly not related to consumer reality :D

though MPC-BE surely has no problem to reach 120 fps you can test that easily with the fast forward on DXVA and a fixed function decoder i already did speedups up to 120 fps with DXVA on it fixed function ;)

Not sure how you test it but it could have many reasons but overall it would be way to complex doing cross OS compares so i wont say anything being under Windows 7 still and WDDM 1.1 ;)

i only know that many things in MPC-BE are very nicely and sanely done and i like it for that in normal playback consumer scenarios, it also has rather nice analyzing capabilities especially the sync graph is pretty unique also compared to MPC-HCs because of the better OSD integration that is better layerd without impacting so much on the overall render performance, still waiting for Sync Graph only Statistics Mode though :)


here is some crazy experiment i tried lately with it ;)

http://forum.doom9.org/showpost.php?p=1789431&postcount=21459


Avg consumer doesn't benchmark how fast his player can render things he want's efficiency and a bug free undisturbed Playback (a clean Multithreaded base) experience with OSD (for efficient subtitle display functionality) without braking or impacting the Video Rendering to much :D

He want's performance in scenarios like stream switching lowest delays possible he want's stability in every situation, he wants a easy to understand user interface with fast interaction times and lowest task times, he just want's to enjoy his content as undisturbed as possible.


And he want all that with starting it and playing at best doing no crazy configuration for optimal Performance on his System base.



with 120 FPS you calling not the very AVG (more Gamer then anything else) users but that goes into another future direction of course Performance is important here as well but not yet widely needed for now, it doesn't really surprises me though that the Koreans (Daum) tries to reach that state fast because it also plays a Role for VR Playback Performance and such.

And that is they key of course if you have a 8K Decoder Monster at your back like Nvidia now you can really be more efficient in every case and if Shdaer Power will be able to compensate that is a nice question HEVC was better Designed with this Decoding Scenarios though in mind already VP9 not really and it will be interesting to see AMDs R&D results here on the VP9 OpenCL Decoding part via GCN vs Nvidias HEVC Cuda Decoder.

Of course you not gonna reach the Power Efficiency that way not in the distant future and that anyway cries for the FPGA move first, though more interesting will be if Intel can beat both AMD and Nvidia with Kabylake which im pretty sure they will hands down like always every year kill the Discrete results of both again (and once again their manufacturing leap will be the master key), but more important will be how it looks on the Mobile side of things ;)


I would never really build a HTPC where i make myself entirely dependent on a Discrete solution IP Core no matter from whom ;)

[el Filou]

i will try it again when and if i get my 480 back.
but there are reports with broken interlaced streams on NVIDIA and AMD and they all come down to stream error which are pretty normal in broadcast.
Some broadcast streams may have errors, but the particular sample posted in that forum thread to illustrate the issue on RX series (meteo.ts) decodes and deinterlaces just fine on my old HD 4650 with LAV in DXVA2 Native, and TS Doctor doesn't detect any errors on the video stream, so in this case it's really either the cards and/or the drivers.

[huhn]

not sure if ts doctor is able to detect small decoding problems and it doesn't matter broadcast has to work.

and my r9 270 works fine too.

[nussman]

not sure if ts doctor is able to detect small decoding problems and it doesn't matter broadcast has to work.

and my r9 270 works fine too.
Interlaced .ts files/Streams without errors (ts doctor) works just fine with "every" other hardware (dxva native).
Its clearly an issue with AMD Polaris cards or drivers ...

We need a new thread about media playback @doom9 without this NVIDIA vs AMD nonsense ... :rolleyes:

[NikosD]

There is a certain number of members of this forum that are trully writing non sense in this thread and believe it or not you are one of them.

As I have said in the past, I have to apologise to the normal people reading this thread that I don't have the power to just block those kind of people in order to write their crap in another thread or nowhere.

But please go ahead, open a new thread regarding playback and take with you the army of trolls who are so heavily grabbed by this thread and can't live without writing their crap here.

[Aleksoid1978]

Not all actually.

As I wrote to my previous post, using MPC-BE v1.5.0 (build 2235) I can't reach 120fps (VFR) with this clip:
https://www.sendspace.com/file/en6bnw

MPC-BE manages to decode around ~62 fps and MPC-HC ~80 fps.

PotPlayer does 120 fps.

I understand what's wrong. All because file have VFR. Video decoder can't correct calculate time stamp. That's all. If you make such file but with CBR 120fps - all be perfect.

[NikosD]

The OSD of MPC-HC and MPC-BE and the statistics below the playback, report those numbers which are both over 60 fps during playback.

It's 62 fps for MPC-BE and 80 fps for MPC-HC.

The OSD of PotPlayer reports 120 fps and you can figure out immediately that is faster just by looking at it.

Also, the Ducks 50fps file at 375Mbps is reported as 43fps during playback by MPCs.

PotPlayer of course plays that file at 50fps.

You can test that file which is 50fps < 60fps

[Aleksoid1978]

The OSD of MPC-HC and MPC-BE and the statistics below the playback, report those numbers which are both over 60 fps during playback.

It's 62 fps for MPC-BE and 80 fps for MPC-HC.

The OSD of PotPlayer reports 120 fps and you can figure out immediately that is faster just by looking at it.

Also, the Ducks 50fps file at 375Mbps is reported as 43fps during playback by MPCs.

PotPlayer of course plays that file at 50fps.

You can test that file which is 50fps < 60fps

Need a file with CBR for compare.

P.S. Here http://120hz.net/hypermatrix/120fpsvideo/bf.mp4 1080@120fps, play perfect.

[Aleksoid1978]

I check in DXVAChecker - Microsoft DTV-DVD Video Decoder, Microsoft H264 MFT, LAV Video, MPC Video Decoder.
Decoding - all decoder ~110-120fps.
Playback - all decoder ~130-150fps

So - "bug" not in decoder. Tested LAV/MPC Video decoders in Pot - play perfect. Maybe it's bug in MPC's video renderers, i don't know what's wrong.

[NikosD]

Need a file with CBR for compare.



You make me write the same thing two times or three in a row.

OK, so this is a CFR file at 50fps.

ftp://helpedia.com/pub/multimedia/x264/testvideos/2012%20-%2001%20-%20QuickSync%20vs%20UVD%202.2%20vs%20VP4/9.Ducks.Take.Off.1080p30fpsRef5-108Mbps.mkv

Can you play it flawlessly using MPCs at 50 fps and a Polaris card ?

Because with MPCs I get ~43fps while PotPlayer gives me always 50fps using EVR-CP and Polaris card.

[Aleksoid1978]

I write about it - not decoder issue, possible video-renderer.

[NikosD]

You wrote about a 120 fps VFR and I give you also a 50 fps CFR.

Don't you think it woths to take a deeper look ?

It looks like a more general issue for the MPCs, than just two cases.

Also DXVA Checker doesn't reach those figures you wrote with LAV but lower - haven't tried MPC-BE DS decoder.

How can I recommend MPCs for Polaris owners when PotPlayer is perfect for all my samples and MPCs obviously not ?

[Aleksoid1978]

You wrote about a 120 fps VFR and I give you also a 50 fps CFR.

Don't you think it woths to take a deeper look ?

It looks like a more general issue for the MPCs, than just two cases.

Also DXVA Checker doesn't reach those figures you wrote with LAV but lower - haven't tried MPC-BE DS decoder.

How can I recommend MPCs for Polaris owners when PotPlayer is perfect for all my samples and MPCs obviously not ?

As i say - something wrong with MPC video renderers. This files bad playback also on Nvidia 960.

[Aleksoid1978]

You make me write the same thing two times or three in a row.

OK, so this is a CFR file at 50fps.

ftp://helpedia.com/pub/multimedia/x264/testvideos/2012%20-%2001%20-%20QuickSync%20vs%20UVD%202.2%20vs%20VP4/9.Ducks.Take.Off.1080p30fpsRef5-108Mbps.mkv

Can you play it flawlessly using MPCs at 50 fps and a Polaris card ?

Because with MPCs I get ~43fps while PotPlayer gives me always 50fps using EVR-CP and Polaris card.

1 - link to wrong file(30fps) :)
2 - i found there with 50fps and on my RX460 it's play stable 50fps.

[CruNcher]

Indeed something is strange in Render behavior with that High Framerate VFR on DXVA MPC-BE EVR-CP it fixes itself on exactly 80 FPS over here but resources on VPX are still left enough, that's strange.

Something seems to lock it

Input: LAV Splitter Source

Decoder:

LAV VIDEO avcodec (jitter upto 20 ms) 1 thread

http://i1.sendpic.org/t/kn/knQtndOeNQctAh1f60jmoSjKLpb.jpg (http://sendpic.org/view/1/i/7LgxUCs6S19rbllVLMviVfA9GCS.png)

LAV VIDEO avcodec (jitter upto 20 ms) 2 threads

http://i1.sendpic.org/t/15/15JuLJYnOfD86eBENK4IZKbQVJN.jpg (http://sendpic.org/view/1/i/xEHXVF0ZEMYHN1PouA0N2bBOQR0.png)

LAV VIDEO avcodec (jitter upto 20 ms) 3 threads

http://i1.sendpic.org/t/vu/vuIZI0GlSFFoc3oe0QEOmX0BU9e.jpg (http://sendpic.org/view/1/i/vZFLARRP8hjikLRDMljSSallmmF.png)

LAV VIDEO avcodec (jitter in range of 18 ms) 4 threads

http://i1.sendpic.org/t/qV/qVsBOY6EhCdHxPgRnS044X0NKLv.jpg (http://sendpic.org/view/1/i/cP1VZqwvxeeMNoOAhpkP33YHklr.png)

LAV VIDEO avcodec (jitter in range of 12 ms) 5 threads

http://i1.sendpic.org/t/uZ/uZP8lN4rX879bpxBoi0uGJ1as5T.jpg (http://sendpic.org/view/1/i/rYnCNFJawRlE3GmTMJRuEbJAKoN.png)

LAV VIDEO DXVA Native (jitter 8 ms)

http://i1.sendpic.org/t/5m/5mvmN53Wv7SdyagDj1nyoYyrv0.jpg (http://sendpic.org/view/1/i/mhNIKD024W7x9fD6e6HupSBWYiE.png)

LAV VIDEO DXVA Copy-Back (jitter 8 ms)

http://i1.sendpic.org/t/4a/4awxOS1KiZ75smLZID5Ngc5E7qz.jpg (http://sendpic.org/view/1/i/deX3nL9C2rXVb0hX4ux3gokvFUO.png)

LAV VIDEO CUVID (jitter 8 ms)

http://i1.sendpic.org/t/7n/7nXeVuEJoLgHBBoBxy04y4GywNh.jpg (http://sendpic.org/view/1/i/qtGQAThnFKaAS3O3AcjX66f435T.png)


CUVID has no issues it seems once again with VPX in that case, though jitter still around 8 ms on my system lot of data being pushed on the (copy) subsystem.


Maybe it's really time moving 1 WDDM up ;)


Cyberlinks HAM

Still a really interesting combination implementation, though you really wonder what it needs that additional Shader Power for in the VPX Decoding combination (and obviously you lose Shader PP headroom for the Renderer overall this way) :)

http://i1.sendpic.org/t/uF/uFdXRvB5uQmoeALQboG3ggnrax.jpg (http://sendpic.org/view/1/i/75oviVpy4le6tlGYbtpXysMbNaZ.png)

Overal CUVID is still more efficient using it's mysterious Node 6 Engine

http://i1.sendpic.org/t/r4/r44OH0SJnGoOq3Ip0W2Vw20II7g.jpg (http://sendpic.org/view/1/i/haRhUFOlnnBLGInpKap4Sn1mTf3.png)