LOL! Let's calm down a bit and remember that we are discussing a cross-platform app that violates the Android User Interface compatibility standard with regard to the notification / status bar, & etc. The real problem is that Google requires each OEM to port the Android AOSP Nexus source code to their non-Nexus hardware, and stipulates that they must obtain any patent licences necessary to do so. You may not have noticed, but there have been many Android software patent lawsuits that have been filed against Google and its partners. So every non-Nexus device is using low-level OEM-written media codecs - and many of them either use their own patented technologiy or have to resort to patent workarounds to hold down unit costs. That's one of the reasons your Zidoo is less expensive than some comparable devices. Once again, it was team Kodi that created most of the problems you are complaining about here, when they discarded all of the OEM-specific low-level code from their archives; dropped support for the standard libstagefright.so; and started rendering their user interface at a lower resolution than the actual display or video playback resolution. That method is not in keeping with the published AOSP Android User Interface Compatibility guidelines, e.g. http://source.android.com/compatibility/android-cdd.pdf FYI, they only needed to do that because certain brands of UHD/4K devices (manufactured by XBMC Organization Gold and Silver sponsors) could not properly render the Kodi user interface elements at a high enough resolution. Furthermore you, yourself, are asking Zidoo to circumvent the relevant HDMI standards and continue development oF the so-called 'HDMI Deception' app. That item in your bug list is completely at odds with the relevant standards and your desire for X6 Google Play Movie app compatibility. Google doesn't list devices designed to circumvent DMCA copyright protection systems. The Zidoo product specs clearly state that the X6 is compatible with the HDMI 2.0 standard. If that's not acceptable, you shouldn't have bought one. FYI, Shenzhen Zidoo Technology Co, LTD is listed as a formal HDMI adopter by the relevant industry consortium: http://www.hdmi.org/learningcenter/adopters_founders.aspx#S Compliance with their HDCP standard is one of the requirements any Zidoo device will have to satisfy in order to become a Google Play Movie supported device. There will always be DRM'd apps that are deliberately incompatible and/or defective by design. They include any which only run on phones or tablets; those that refuse to function while a standards compliant HDMI/HDCP display is connected; or ones that won't work if the user is located in the wrong country or region. Those really aren't bugs in Zidoo's hardware or firmware and shouldn't be treated as such.
LOL for you. Custom Cyanogenmod build for Rockchip. No problems, no audio out of sync. You have no idea what are you talking about.
I know perfectly well that Cyanogenmod has not solved the horrendous audio latency problems that have always plagued the Android OS. I watched out-of-sync Netflix audio and video for years on Nexus, Samsung, and Sony Android devices - and Cyanogenmod wasn't offering any solutions. For a while the Netflix app incorporated a user audio offset setting, exactly like the one that is still employed by Team Kodi. Other apps, like Hulu, Amazon Video, Sling, and MX Player HW+ actually do handle decoding on the X6 without the audio sync bugs you reported. When I first got my X6, MXPlayer Pro could not do hardware accelerated rendering, like the native Zidoo Video player. But their developers got HW+ decoding working on the RK3368 in very short order. They also followed the AOSP User Interface standard. Team Kodi simply chose not to do something like that. FYI, Cyanogenmod is funded and silently partners with one of the biggest Android patent licensing trolls, Microsoft. But if Cyanogenmod has ported a better implenentation of the AOSP Level 16 Mediacodec API to the RK3368, why are you still here complaining? The bottom line is that there is a difference between bug reporting and flooding the forum with repetitious insults and opinions.
CM has not ported anything to Rockchip. I'm talking about unofficial builds (not available for Zidoo though). Also, please don't tell me about any licences etc. First, Zidoo sells his hardware and gets money. So they should also buy licences if needed. Second, audio out of sync and poor MediaCodec implementation have nothing to any licence. This is just a buggy software - either Zidoo or Rockchip (as a customer, I don't care which one should be blamed).
Re: Second, audio out of sync and poor MediaCodec implementation have nothing to any licence. This is just a buggy software - either Zidoo or Rockchip (as a customer, I don't care which one should be blamed). You keep babbling on about there being no need for the existence of the Rockchipcodec, despite the fact that I already gave you a link to the AOSP Android Compatibility Compliance Document, which introduces the subject of the Mediacodec API. It explains that each OEM is responsible for porting and implementing it on their own proprietary hardware by supplying the necessary low-level code and obtaining the necessary patent licenses. Google, Motorola Mobility, and many other OEMs have been forced to pay-off individual MPEG-LA members - including Microsoft, Mitsubishi, Philips, General Electric, Thomson Licensing, Panasonic, and Sony - over their use of unlicensed FOSS decoders. They were unable to strike a deal that would afford blanket protection to all other Android OEMs from similar demands. Readers of this forum have known for months how to workaround that problem in Kodi, while we wait on the new Zidoo API. In most cases, it doesn't even matter to end users if the video gets decoded by the Cortex A53 Octa-core CPU or the PowerVR G6110 GPU. Many apps that function pretty flawlessly on the X6 (without the need for workarounds) such as Hulu, Amazon Video, & etc., obviously don't rely upon Mediacodec's hardware acceleration in the first place.
Readers of this forums know workarkund for Kodi problems, because I gave them workaround. They know workaround from me - advancedsettings.xml. You don't need to teach me anything about workarounds in to get rid annoying audio out of sync. And Kodi problems are blame Zidoo. I'm really afraid new zidoo api. I have already seen enough. RockChip codec, which causes Kodi crash on stop playback.
Nonsense, you can buy a half dozen other brand name or generic RK3368 Kodi boxes with the very same problem. Zidoo has acknowledged the issue, provide a blog and this forum where the workaround techniques have been discussed, and have announced that they are working on bug fixes and new APIs. FYI, Stefan-ott explained to Spring and Cyber7 that turning-off Rockchip hardware acceleration would correct most of the problems back in November 2015 http://forum.zidoo.tv/index.php?thr...-ever-i-cant-watch-anything-on-my-x6-pro.642/ At that same time, Zidoo acknowledged these issues and said they hoped to have them fixed in their next firmware update. FYI, at the very same time (last November) Team Kodi was purging the necessary low-level Zidoo/Rockchip OEM/ODM code from their project source code archives and Koying was specifically promising to fix the Rockchip and other OEM issues by rewriting the Kodi Mediacodec rendering hacks. He claimed that would have made the problem - and his own SPMC fork - completely irrelevant. He promised to deliver the first build that weekend, but we all know that he subsequently changed his mind. http://freaktab.com/forum/tv-player-support/general-tv-player-dicussions/xbmc-talk/8752-spmc/page38 Many other users here and in the Kodi users forum have discussed the various methods of setting the default audio offset by either using the Kodi player's built-in sound and subtitles settings dialog or editing the advancedsettings.xml file.
It seems you have outdated info. Let's give most recent status of Kyoing and Rockchip: So, no he have not changed his mind. RK monkeys made any support impossible. Most likely, it's because they broke ffmpeg licence and they can't show their code now. This closes all discussion about Kodi on RK. Kodi will never work fine on RK. Zdmc/Rockchip codec is against all standards and it's poor. End of topic. Current status of RockchipCodec in zdmc - tragedy. Everybody are forced to disable it.
I know all about that. But he certainly did change his mind and the excuses he provided don't make a great deal of sense. He announced that he could fix the problem in a matter of days, and there was no mention of his need to obtain the source code for Rockchip's player app. The fact is that no lone developer, like Koying, can stop anyone else from rewriting the Kodi open source code rendering hack, so that its player will run correctly on Rockchip hardware. Zidoo has already done some work along those lines. The fact that Koying might not agree with the idea of software patents, trade secrets, non-disclosure agreements, and etc. doesn't mean that everyone else feels the very same way. The fact that Koying suspects that Rockchip may be violating FOSS software copyright licenses is ironic, since many patent owners have said they believe FOSS media encoders/decoders (including the ones in FFmpeg) violate their FRAND patent licensing rights. FYI, there are many software layers in the Android media system where a constant audio playback offset can be introduced, e.g. https://source.android.com/devices/audio/ The kernel Hardware Abstraction Layer (HAL) was deliberately designed to be agnostic about the use of closed-source proprietary hardware drivers from the likes of Kodi Foundation Gold Sponsor Nvidia. In fact, they have resisted demands from the relevant Linux kernel maintainers for years that they provide all of the source code for their hardware drivers that use GPL'd Linux kernel hooks. That situation makes it extremely odd for Koying to promise that he'll give their Android Shield hardware platform lots of love and attention.
I don't need to try any other to see bugs on zidoo. Also tested much android hardware (phone, tablet). For example , Pipo P1 running on unofficial Cyanogenmod build has no issues. Vanilla Kodi. Hardware is RK based (but older cpu). Technically, it does matter - Android box, tablet, phone. It's all about bugs in Android build for each device.
its not about the numbers of bugs. is about them trying to fix bugs. you can count on 1 hand the companies that sell boxes AND provide any sort of support to them. Zidoo is one of them. and it bothers me to see this whiny/bitch attitude from you in every post you make . p.s. my Samsung phone has bugs. haven't seen a update for it in 2 years
Xoxo Xiola, you're looking bad here. This argument is absolutely one sided, Harlan intelligently picks apart your ranting. Time to sell your Zidoo and troll somewhere else. Have an amazing day!
I have quoted Kyoing from official Kodi forum . This shows current thoughts Kodi team about Rockchip. Because of lack of RK sources, Kodi will never work fine on any RK hardware. Telling the truth is "trolling"? Good for you, Have Amazing Day for you too Harlan mentioned something without providing source of that, instead he posted some forum links with posts written a few years ago. LOL P.S. Kodi will be never supported, but ZDMC could be better. Unfortunately, it's not better. Shitty RockchipCodec is piece of sh*t (read my above posts) and the only we can do is to disable it, resulting to get the same as official Kodi (RockchipCodec is the only modification added by Zidoo)
I've never needed to disable Rockchipcodec acceleration or Mediacodec acceleration to watch movies on my X6 Pro. I used the advancedsettings.xml file to set a 250 millisecond offset and use the stock ZDMC with the TVAddons MC Edition "as-is" after running their Config Wizard Program. It works as intended for me, when I occasionally launch ZDMC to watch a Movie. If it bothers you soo much please try Mobdro or something better. And please stop feigning ignorance about the fact that Zidoo and other independent developers have made their Rockchip-specific source code fixes to the Kodi app available to the XBMC Foundation. If anyone is to blame for the fact they never made it into the main XBMC repository, it isn't Zidoo. See for example https://github.com/zidootech/zidoo-kodi-15.1 FYI, I'm not using "outdated" info or forum posts from several years ago. I was citing a conversation, that isn't even a year old yet, to illustrate that Koying had changed his mind about on-going Rockchip support and the relevance of his SPMC fork of Kodi. In case you don't remember here are some of the relevant facts: 1. Despite the disinformation propagated by some members of "Team Kodi", the "standard" native media player engine and framework of the Android Open Source Project is still Stagefright (including libstagefright.so, and all of the Stagefright APIs, not just Mediacodec). They specifically provide interface layer hooks for the incorporation of proprietary (closed source) OpenMAX hardware acceleration (aka OpenGL). See the subsections on satisfying OEM and SoC dependencies on the AOSP Stagefright documentation page: https://source.android.com/devices/media/soc.html So, the Rockchipcodec is not against the relevant Android Media, aka "Stagefright" standard at all. 2. Mediacodec is merely one of the newer-level public class APIs that are an integral part of that Stagefright media framework. They were introduced by Google in API Level 16 (Android 4.1), but weren't finalized until recently. See https://developer.android.com/reference/android/media/MediaCodec.html Google did NOT provide well-defined, final documented methods for OEMs to implement the new APIs, until after the release of the official Marshmallow (Android 6.0) Level 23 API Documentation. See for example the commentary about that situation here: http://bigflake.com/mediacodec/ Most Android devices are still running code based upon the Android OS version 4 or 5 documentation, and apps that target Android 4 + for backward compatibility, not code written after the release of Marshmallow. So you need to keep all of that in mind when Koying says preposterous things like "And libstagefright is a hack using private api's. Generally speaking, it's only needed on Android 4.0 ICS." http://forum.kodi.tv/showthread.php?tid=180872 Most developers still employed the older, standard, well-documented libstagefright.so APIs for backward compatibility. But Team Kodi decided NOT to do that in their Jarvis and later versions. That's why Kodi is still plagued with issues that most other Google media players never had in the first place. The only "official" TV box implementation of the fledgling "mediacodec standard" that other OEMs could imitate was the example of the X86 Google Nexus Android Player. Compared to that implementation, Rockchip actually did a semi-reasonable job implementing the new APIs, based upon the semi-complete nature of the documentation that was available to OEMs who were tasked with implementing them on Android 4 and 5 devices. 3. You can't always eliminate latencies that result from the concurrent use of software (e.g. audio) and graphics hardware video decoding methods. For example, here is an extract from the Intel X86 Nexus Android Mediacodec implementation guide. It recommends the use of a "workaround solution" (aka "a hack") on the decoder side to deal with their own occasional 200 millisecond blockage/offset problems: "Using the hardware decoder, we can get good performance, but the side effect is high latency due to the software decoder. ... If the encoder type is H.264, MediaCodec may have a delay of several frames (for IA platforms, it is 7 frames, while others are 3-5 frames on main or high profile). If the frame rate is 30 FPS, 7 frames will have a 200-millisecond delay. ... So, on IA-based Android platforms, the solution is to change the encoder to a baseline profile. If the encoder profile cannot be changed, a viable workaround solution is to change the configuration data on the decoder side." https://software.intel.com/en-us/android/articles/android-hardware-codec-mediacodec So, Mediacodec isn't exactly the panacea that you suggest. It's also no "tragedy" to find that Team Kodi, which relies on third-party Android codecs, might need to use an audio offset control in its "Audio and Subtitles" control dialog box . There's even a note in their Audio FAQ which explains that particular workaround solution is necessary, even on non-Android Kodi hardware platforms. - They also provide instructions on how to use that setting as the default Kodi video setting. http://kodi.wiki/view/Android_FAQ#Audio_sync.2Fdelay_issues 4. The overwhelming majority of Android devices still don't have a post-Marshmallow era implementation of mediacodec. In the meantime, XBMC programmers should be used to employing hacks. In fact, their original program couldn't even be installed on an MS Xbox without employing a root exploit or modchip. Similarly, the Android version of Kodi used to employ a hack to change the Android system file permissions to more directly access the device's hardware, e.g.: "Kodi doesn't try to manually fix the permissions anymore. Doing so was a hack that the devs didn't feel comfortable with, and vendors need to fix this on the firmware level, not the application level. Some hardware vendors are still unwilling to set the necessary permissions because of a misconception on "security", which ironically requires granting apps root-level access, which is far less secure. However, the mediacodec "path" to decoding doesn't require the permissions changes, and mediacodec support has improved both in Kodi and in most firmware (even in some of the flawed ones). So now when amcodec fails it falls back on mediacodec, which normally works. In that sense it is "fixed". Eventually mediacodec will be the single standard, and there won't be a need for amcodec, but the option is still there for some special situations." http://kodi.wiki/view/Android_FAQ Despite those Team Kodi assurances, there have been critical remote code execution security vulnerabilities discovered in the Nexus implementation of Media Codec. In any event, Hardware OEMs are constantly introducing new features to distinguish their products from their competitors. So special OEM codecs will always be required to handle bleeding edge tasks that aren't included in the existing Mediacodec API. Koying worked on SPMC and Kodi for years by employing calls to the libstagefright.so APIs, without the need to have source code access to Rockchip's (or anyone else's) low-level proprietary Android code. In fact, he started development of SPMC (Semper Media Center) as a Rockchip-optimized fork of Kodi/XBMC. It was first released a few years ago and contained fixes for Rockchip devices that were never included in the Kodi mainline source code. See for example the article about that here at CNXSoft News http://goo.gl/UhCNZF Here is the forum conversation between a Rockchip user and Koying last July 2015 that I cited above: "Sombra 07-11-2015, 11:42 OK now there is an RC2. Just wondering if SPMC is still being maintained or is KODI's stagefright implementation now good enough to work cleanly with rockchip? Koying 07-12-2015, 22:19 I'm working on an improved MediaCodec rendering system in Kodi that *should* make rkstf (and thus spmc) irrelevant. You'll have test builds next weekend." http://freaktab.com/forum/tv-player-support/general-tv-player-dicussions/xbmc-talk/8752-spmc/page38 4. The post you cited above, actually proves my point, i.e. that he changed his mind about the need to fix the problem in Kodi's source code and the on-going relevance of SPMC. The reasons that he gave afterward were somewhat illogical. There's nothing available from Nvidia's Github site, except a mix of patch files and binary-only low level drivers - and SPMC is still forced to do some rendering in software on the Shield TV. The source code situation is about the same on the Amazon Fire TV box. Nonetheless, he promised that those particular boxes and private hacks would be getting some "love" from SPMC going forward.
I don't see anything there that supports the idea of end-users spamming this or any other forum with repititious insults disguised as bug reports. I'm a retired programmer.and system integrater. So I know a thing or two about the realities of the software and the hardware industries. I see that he says: "God has decided that amlcodec does not fit his vision, so will disappear from Krypton altogether. It will be (maybe) replaced by a linux-only codec currently in development. Not that important, really, as only Windows (and maybe some Apple) users will be using stock Krypton" So he doesn't seem to mind the use of other codecs, beside mediacodec, and correctly notes that Android users aren't likely to be running stock versions of Kodi in the foreseeable future. He claims it's easy for OEMs to write the low-kevel code needed to implement mediacodec. If that's true, then it's bound to be much easier for OEMs/ODMs to write native apps that only have to make calls to those APIs and low-level code. They already have written their own derivative forks of Kodi and native mediacenter apps. So they really don't have to depend upon the whims or design philosophy of the XBMC Foundation leadership. In the long run, it only makes good business sense to do that. Once again, the majority of Android streaming apps, like Amazon Video, Netflix, Hulu, Sling TV, & etc. already do work on Rockchip SoCs, including the Zidoo X6, and they aren't written by committes of squabbling volunteers. For better or worse, there are still major OEMs who choose to employ Rockchip SoCs in commodity consumer devices, like the Asus Chromebit. I also know that about 20 percent of the worlds population lives in China; that Android is poised to be the dominant computing platform in the world today; and that Rockchip particpates in the ARM University Alliance Program in China. It provides some of the hardware, software, and development tools that students use to prepare for their own careers, e.g see http://www.businesswire.com/news/ho...l-Rockchip-Join-ARM-Global-University-Program So, the OEMs and ODMs in the Android TV sector in China don't have to gamble on the whims of a few indifferent volunteers/hobbyists at the non-profit XBMC/Kodi Organization. I've bought a Zidoo X9 and a Zidoo X6 because they were good overall commodity products. They do many things better, or just as well as my family's other Dell, Apple, Roku, Samsung, Google, and Amazon devices.
