[Platypus2]

Any more builds ?

Actually new build (with BT keyboard fix) has already been online for some days: https://github.com/linusyang/xbmc/releases I'm now just waiting for Gotham beta 1 for making a semi-stable build.

Hi,

I tested build 5. I was playing a WEB-DL TV show episode in 1080p, but the picture was all messed up. I tried some other movie files and they seem fine. This is with Hardware acceleration on and using VTB. The screenshot of the video I see is in the url:

http://imgur.com/H3gbamM

Noticed this as well, only on certain videos though.

Did anyone notice anything wrong in the log? I can provide more if necessary. Works fine on PC / 32 bit iDevices so definitely something to do with 64-bit

[Xryptic]

Hi,

Does anybody know if the latest Gotham RC1 includes the 64 bit build here?

[Memphiz]

This won't Hit Gotham at all ...

[linusyang]

@Platypus2 @Xryptic @TheTroll @unique904
I am not very sure about the corrupted playback issue, maybe related to the VTB API? @Xryptic, Could you please provide the media info or a sample of the video?

Hi,

Does anybody know if the latest Gotham RC1 includes the 64 bit build here?

The source code of latest XBMC ARM 64-bit build is here: https://github.com/linusyang/xbmc/tree/gotham-arm64

Changelog since last 5th revision:
* Update to latest final Gotham 13.0 version
* Backport more arm64 optimization from FFmpeg upstream
* PVR loading issue should be fixed (Please report if you still have issue with this)

I'll upload the built Debian package to the Github release page later.

[TheTroll]

Hi,

did you post the compiled .deb ?
I can't find it.

Thanks

[nabelo]

@Platypus2 @Xryptic @TheTroll @unique904
I am not very sure about the corrupted playback issue, maybe related to the VTB API? @Xryptic, Could you please provide the media info or a sample of the video?

Hi,

Does anybody know if the latest Gotham RC1 includes the 64 bit build here?

The source code of latest XBMC ARM 64-bit build is here: https://github.com/linusyang/xbmc/tree/gotham-arm64

Changelog since last 5th revision:
* Update to latest final Gotham 13.0 version
* Backport more arm64 optimization from FFmpeg upstream
* PVR loading issue should be fixed (Please report if you still have issue with this)

I'll upload the built Debian package to the Github release page later.

Hi,

thank you very much for your effort on the arm64 version of XMBC

Where can i find the .deb package? I just checked on your github page but i can't find it.

Best regards,
Manuel

[linusyang]

@TheTroll @nabelo Sorry for the delay.
Description and download are available here: https://github.com/linusyang/xbmc/releases

Please be aware that, the corrupted HW playback issue still exists in this version. I highly doubt it is related to the VideoToolBox API.
@Memphiz, could you please help me look into this?

Currently, you can just disable the HW decode and use the FFmpeg software decode to eliminate this issue:
In settings -> video, change your settings to "Advanced", then in the Acceleration section, disable the VTB decode.

Since I've backported some ARM64 specific asm optimization for FFmpeg,
the software decode is also very efficient (1080p costs ~50% cpu).

[nabelo]

@TheTroll @nabelo Sorry for the delay.
Description and download are available here: https://github.com/linusyang/xbmc/releases

Please be aware that, the corrupted HW playback issue still exists in this version. I highly doubt it is related to the VideoToolBox API.
@Memphiz, could you please help me look into this?

Currently, you can just disable the HW decode and use the FFmpeg software decode to eliminate this issue:
In settings -> video, change your settings to "Advanced", then in the Acceleration section, disable the VTB decode.

Since I've backported some ARM64 specific asm optimization for FFmpeg,
the software decode is also very efficient (1080p costs ~50% cpu).

Hi linusyang,

Thanks you so much for this release. So far HW Playback is working fine for me.
I didn't had a video so far which have corrupted playback. So I guess I'm lucky so far
Any chances you can fix this bug anyway ?

Best regards,
Manuel

[Xryptic]

@TheTroll @nabelo Sorry for the delay.
Description and download are available here: https://github.com/linusyang/xbmc/releases

Please be aware that, the corrupted HW playback issue still exists in this version. I highly doubt it is related to the VideoToolBox API.
@Memphiz, could you please help me look into this?

Currently, you can just disable the HW decode and use the FFmpeg software decode to eliminate this issue:
In settings -> video, change your settings to "Advanced", then in the Acceleration section, disable the VTB decode.

Since I've backported some ARM64 specific asm optimization for FFmpeg,
the software decode is also very efficient (1080p costs ~50% cpu).

Thanks this helps and videos still look reasonably good. However, hope you still do find a fix soon!

[nabelo]

This won't Hit Gotham at all ...

Hi Memphiz,

any infos on which version of XBMC this will be included?

Best regards,

Manuel

[Memphiz]

its not that easy as "including" - we need to setup the whole architecture in our automated build environment (similar what we needed to do for building android x86 and arm side by side) - it hasn't been decided yet if and how we want to provide arm64 builds of xbmc officially...

[nabelo]

its not that easy as "including" - we need to setup the whole architecture in our automated build environment (similar what we needed to do for building android x86 and arm side by side) - it hasn't been decided yet if and how we want to provide arm64 builds of xbmc officially...

I hope you will make the right decision :-)
An official iOS arm64 build would be awesome.
Because all future iOS devices will be arm64 i think its necessary :-P

Best regards,

Manuel

[Memphiz]

That doesn't make sense - it won't be really necessary on future devices - as they will be powerfull enough to handle software decode of hd content - there is no other benefit of using 64bit - but there is the burdon of supporting yet another architecture ...

Not to mention on telling users which version they need (grabbing the wrong version on older devices won't work of course).

[Platypus2]

It won't be really necessary on future devices - as they will be powerfull enough to handle software decode of hd content - there is no other benefit of using 64bit

I don't really want to get into it as I'm more than happy with linusyang build for now and never know what might happen in a few years... But;

Isn't software decoding everything going to have a pretty large impact on battery? :S

If a fix for the random corrupted playback of some h.264 videos could be found then linusyang build would be perfect. If it stays unofficial then that's fine, until he stops supporting it

[Memphiz]

Yes the burdon on battery might exist or not. But the burdon on x86_64 is a PAIN IN THE F**** ASS. We already learned that the hard way on osx 64bit. The support is just doubled because we not only need to poke for debug logs each time but also make the user try the other build aswell and report back (and in this case it is even harder because on a 64bit system the 32bit build won't do hw decode - and the other way around the build will crash or not even start).

As long as there are not more permanent ios devs in our boat (which is just not the case - we only have some short runners which already vanished in the background) it is a really tough decision.