[MrMC]

This issue is exactly why MrMC fork kept VDA codec and did not move to VTB. The move to VTB only was premature, and now depends on upstream working on fixing issues. Which means that usage in Kodi v17 is broke except for newer devices.

As for a 9400M not being powerful enough. seems someone does not understand that VDA is just a light API wrapper around VTB. If VDA can do it, so can VTB. In fact, VTB can handle much more than VDA which is why the move to VTB is good idea, but that assumes that the VTB implementation actually works as well as VDA

[tripkip]

I found that using NFS instead of SMB there was a big improvement with HW VTB acceleration on.
This has to do with Kodi using Apple's SMB implementation, the same issues occur for some users (including myself) using VLC:
https://forum.videolan.org/viewtopic.php?t=115152
https://trac.videolan.org/vlc/ticket/9885

Using libdsm on all (but win) platforms might be the solution? http://videolabs.github.io/libdsm/

I will do some more tests and report back:
- play local file in Kodi
- debug log - local file with VTB enabled
- debug log - local file causing audio stutter (yesterday without VTB audio started to stutter)

[tripkip]

OK here it goes:
- SMB with VTB: unwatchable lag + out of sync
- NFS with VTB: unwatchable lag + out of sync
- SMB without VTB: playback OK, CPU usage 70-100%
- NFS without VTB: playback OK, CPU usage 65-80%

So I'm definitively going to use path substitution on my Macbook to swap SMB for NFS, but still I would really like to see VTB working properly on OS X.

[Memphiz]

It is working properly on osx - just not for all hardware (sorry but i hate generic statements when they are not true...)

And we all would like to see that it works for more hardware. (Would like seeing just doesn't get anything rolling sadly)

[Waltman]

It is working properly on osx - just not for all hardware (sorry but i hate generic statements when they are not true...)

And we all would like to see that it works for more hardware. (Would like seeing just doesn't get anything rolling sadly)

Memphiz. And again your response isnt encouraging. It seems at this moment like older (< x year) Apple hardware is going to be left behind for Kodi 17. You sound unhappy with the situation. What can we users do to help ?

[Memphiz]

It is simply not my area of knowledge. We have 2 developers which are technically able to develop for osx (including me). I have only intel hd 4000 hardware (macmini + hackbook). And fernetmenta has hd4000 and one nvidia 320 or so IIRC. All this hardware doesnt show the problems mentioned here in the forum.

Also its completly normal to me that not all releases of kodi support all devices in the same way. (Thats one difference to companies)

So if i have the choice of allowing the overall architecture of Kodis video player to improve (by letting the videoplayer developer go for a generic video decoding approach via ffmpeg/vtb) or to stick with the own video decoder we had (that worked on more hardware but no-one on the team maintains it anymore) and leaving osx behind in the video player stuff. Well you know my decision.

There will be improvement over time because ffmpegs devs are maintaining vtb. And yes it might be that kodi 17 will not have the same playback experience for all osx harware. But in the end the video decoder code we have now is better because we have someone maintaining it on both sides (kodi and ffmpeg).

And i am prepared for the shitstorm once osx users switch to 17 (well at least i hope i am prepared). Along with the shitstorm because we dropped ios5 support and ios6 has non working vtb decoder.

[tripkip]

Completely understand. Can we help to improve by doing ffmp get specific debug tests and send them to ffmpeg or are they already aware of the issue(s)?


Verzonden vanaf mijn iPhone met Tapatalk

[Memphiz]

I am not so familiar with ffmpeg. I guess they have a test tool which can play videos standalone? Would be interesting if it chokes on the same movies/hardware.

Also your tapatalk signature is on (strange - this happens often these days - did they re-enable it with the latest update?

What also might be helpfull is a debug log (wiki) with jarvis (kodi 16) where the playback with hardware decoding is fine.

[tripkip]

They do have a player 'ffplay'. I'm trying to figure out how to test it with VTB decoding, but no luck so far.
ffmpeg knows VDA and VTB are supported on OS X:

Code:

/ffmpeg -hwaccels
ffmpeg version 3.1.2-tessus Copyright (c) 2000-2016 the FFmpeg developers
  built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
  configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --as=yasm --extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzmq --enable-version3 --disable-ffplay --disable-indev=qtkit --disable-indev=x11grab_xcb
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 48.101 / 57. 48.101
  libavformat    57. 41.100 / 57. 41.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 47.100 /  6. 47.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
Hardware acceleration methods:
vda
videotoolbox

Yet when I query ffplay to see if VTB is available as a decoder, nope:

Code:

➜  Downloads ./ffplay -codecs | grep 264
ffplay version 3.1.2-tessus Copyright (c) 2003-2016 the FFmpeg developers
  built with Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
  configuration: --cc=/usr/bin/clang --prefix=/opt/ffmpeg --as=yasm --extra-version=tessus --enable-avisynth --enable-fontconfig --enable-gpl --enable-libass --enable-libbluray --enable-libfreetype --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libschroedinger --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzmq --enable-version3 --enable-librtmp --enable-ffplay --disable-ffmpeg --disable-ffprobe --disable-ffserver --disable-indev=qtkit --disable-indev=x11grab_xcb
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 48.101 / 57. 48.101
  libavformat    57. 41.100 / 57. 41.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 47.100 /  6. 47.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100
DEV.LS h264                 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vda ) (encoders: libx264 libx264rgb h264_videotoolbox )

I'm now reaching out to ffmpeg on IRC. Will update with any progress.
Meanwhile if anyone knows how to play using ffplay with vtb, please let me know.

[Memphiz]

I have done some blind backports from the former vda decoder. Well basically i only touched rendering because i don't think the issues have something to do with hw decoding, but with rendering the videocore buffer afterwards.

Here are 3 test versions which should be tested and reported back.

1. Change decoder and render format from to kCVPixelFormatType_422YpCbCr8 - as this was the format the VDA decoder used before

http://mirrors.kodi.tv/test-builds/osx/x...x86_64.dmg

2. Don't use the zerocopy rendering (which should be the fastest we have normally due to no need to copy the decoded frame from gpu to cpu and back to gpu) - instead convert the decoded buffer into Y420P and let our glsl or arb software/shader renderer do the work (thats what vda did before for some GPUs that won't do proper zerocopy). This change makes the rendermethod effective in settings->videoplayer->Rendering - so please test GLSL and ARB with this.

http://mirrors.kodi.tv/test-builds/osx/x...x86_64.dmg

3. Don't convert the frame to Y420P but just assign the buffers and render in RENDER_FMT_UYVY422 directly. This should be faster as 2. but its not for me. Its really crappy on my tests. Once again - ARB and GLSL rendering are effective here and should both be tested.

http://mirrors.kodi.tv/test-builds/osx/x...x86_64.dmg

[Waltman]

What also might be helpfull is a debug log (wiki) with jarvis (kodi 16) where the playback with hardware decoding is fine.

hardware and OSX
Mac mini 2011 with intel HD3000 and 16GB RAM
OSX 10.11.6

first log kodi 16 with vda enabled
http://pastebin.com/x95GFnwq

second log kodi 16 with via disabled
http://pastebin.com/3FYwCJ7C

[Waltman]

[quote='Memphiz' pid='2398236' dateline='1471788561']
I have done some blind backports from the former vda decoder. Well basically i only touched rendering because i don't think the issues have something to do with hw decoding, but with rendering the videocore buffer afterwards.

@Memphiz: i did the best i could and i hope i understood everything (i am not sure, so please explain if i got something wrong)
@Memphiz: I had no playback issues with al these builds, no problems at all.

hardware and OSX
Mac mini 2011 with intel HD3000 and 16GB RAM
OSX 10.11.6


Test one
1.1 VTB enabled http://pastebin.com/DLWmRBae
1.2 VTB disabled http://pastebin.com/HrRnHGDy

Test two
2.1 ARB http://pastebin.com/1tBAjBga
2.2 GSLS http://pastebin.com/UDDRYxZL

Test three
3.1 ARB http://pastebin.com/svVi2uKS
3.2 GSLS http://pastebin.com/gUuKvqm0

[Memphiz]

Yes you got it right (logs look as expected - thx). Question is - do you have problems with normal nightly builds? So did my testbuilds improve anything for you?

[tripkip]

Jarvis (perfect playback and CPU 10% lower than test build 1): http://pastebin.com/8cMcb9gE
Test build 1 (little lag every second or so): http://pastebin.com/Pab4gKTv
Test build 2 - ARB (choppy as master VTB): http://pastebin.com/xWGgANe5
Test build 2 - GLSL (choppy worse as master VTB): http://pastebin.com/n3MFi25b
Test build 3 - ARB (choppy as master VTB): http://pastebin.com/aPUKLiwm
Test build 3 - GLSL (choppy worse as master VTB): http://pastebin.com/yzVAx3dW

[Waltman]

Yes you got it right (logs look as expected - thx). Question is - do you have problems with normal nightly builds? So did my testbuilds improve anything for you?

@Memphiz, yeah the test build improved the world. All three test build word perfect in my case. Normal highly builds can't be used with VTB ON

hardware
mac mini 2011 HD3000 16GG RAM
OSX 10.11.6

kodi
kodi nightly kodi-20160821-59efbe3-master-x86_64

first test
VTB on, choppy unwatchable picture. http://pastebin.com/wCVxFtYy
ARB, VTb on, terrible choppy picture http://pastebin.com/1ThzQNRy
GLSL VTb ON, terrible choppy picture http://pastebin.com/Wm6ZZQEG

second test
VTb OFF, normal picture http://pastebin.com/fFhghXgC

conclusion
so all three test builsd performed perfect at my machine with the VDA ON and the default, ARB and GLSL render methods
However: the current kodi highly mentioned above is creating an unwatchable picture with VDA ON with all render methods