(2015-09-14, 13:06)Roby77 Wrote: [ -> ]In my case motion compensated is not selectable for all sd content
i tried several sd content in my library before find one to set motion compensated
Hm, might be that it requires interlaced content. I will check with live tv and see. And the logs will perhaps tell us more.
The second one is _not_ accelerated with VAAPI (DIVX5 or something). A
Debug Log is sufficient for such issues .... VAAPI-MCDI is only available when VAAPI is used for the video.
This clears things up. I guess I checked with SD content and both were encoded using xvid (old tv shows). I have 720p shows and movies that are x264, but not SD, will get an SD content encoded with h264.
In case of LiveTV, if I remember correctly, my provider broadcasts SD content encoded with mpeg2 and HD with h264.
I can't use kodi log uploader cause with last two jarvis build it doesn't work anymore
it's the same log that is located in log folder and is zipped ?
i remember a film that with isengard build vaapi motion was available...now not
edit: ok read fritsch post
I have rechecked for the av sync issues with 1080/24p content and are there. Am sorry fritsch but the debug log link is not working so i cant provide you with one
After I got the 50th email with:
- My skin does not work with jarvis builds
- I don't like to use experimental software
- My whatever piracy addon stopped working
- My whatever 3rd party personal audio streamer
- ...
I decided to update the Technological Preview based on Isengard.
Changelog:
- Rebased on OpenELEC master
- Added ffmpeg 2.8 + hevc fix
- Added vaapi hevc
- Mesa 11.0.0
In the future you are welcome to compile my isengard branch your self. From dev pov - Isengard is totally not interesting at all anymore ... especially as fernet's master has a lot of goodies that will help us all in the future.
And something else: I don't know how you do that in real life. I am not "the bro" ... at least it made me laugh.
Isengard builds:
http://fritsch.fruehberger.net/openelec/...f7773d.tar (update)
http://fritsch.fruehberger.net/openelec/...73d.img.gz (Image)
(2015-09-14, 14:19)ggp759 Wrote: [ -> ]I have rechecked for the av sync issues with 1080/24p content and are there. Am sorry fritsch but the debug log link is not working so i cant provide you with one
Yeah - no log, no issue. ssh in and do cat .kodi/temp/kodi.log | pastebinit in debugging mode please ...
(2015-09-14, 14:21)fritsch Wrote: [ -> ] (2015-09-14, 14:19)ggp759 Wrote: [ -> ]I have rechecked for the av sync issues with 1080/24p content and are there. Am sorry fritsch but the debug log link is not working so i cant provide you with one
Yeah - no log, no issue. ssh in and do cat .kodi/temp/kodi.log | pastebinit in debugging mode please ...
Did the above. Result in osx terminal is
http://sprunge.us/JeIB
Edit: Sorry i just saw the debugging mode in your comment. I enabled debug logging from the menu and i got this:
http://sprunge.us/PWDD
Now enable debug logging, reproduce and after that the same command again, please.
Is the offset constant? E.g. always the same?
Cause with fernet's rework of the AE doing the sync itself - the default OpenELEC 150ms offset for 24p could interact there ... Log looks good - all fine.
(2015-09-14, 14:34)fritsch Wrote: [ -> ]Is the offset constant? E.g. always the same?
Cause with fernet's rework of the AE doing the sync itself - the default OpenELEC 150ms offset for 24p could interact there ... Log looks good - all fine.
The offset in not always constant but its there. I have no delay or automatic delay enabled on avr. Its weird because previous builds where fine. Will a hard reset within openelec change anything or its a waste of time?
Also audio offset when playing is 0.000. Its always been like that.
(2015-09-13, 21:01)fritsch Wrote: [ -> ]Some short extract:
- Dual Channel matters :-)
With these integrated GPUs it does seem to make a significant difference. Coincidentally I was playing last night with the Broadwell i5 NUC (which sucks at HEVC decoding of course). I tried 1x4 GB and 2x2 GB setups and for example in the Cinebench R15 OpenGL test the results improved some 45% when having the dual channel setup in use (all this in Windows of course).