2016-03-25, 12:11
2016-03-25, 12:11
In the defense of the people who buy these shitty android-boxes... If you're not tech-savy, it's really hard to know what to look for. Then again, if you aren't tech-savy then you may be better off with an Apple TV or Chromecast.
They use it as a Raspberry Pi case
(2016-03-25, 12:11)Koying Wrote:(2016-03-25, 12:04)giaur Wrote: Not at all. I own RK hadrware and I'm really happy with it, then only bad thing are Kodi problems.
Out of curiosity, if Kodi is useless on your hardware, what do you use it for?
They use it as a Raspberry Pi case
2016-03-25, 12:18
(2016-03-25, 12:11)nooryani84 Wrote: In the defense of the people who buy these shitty android-boxes... If you're not tech-savy, it's really hard to know what to look for. Then again, if you aren't tech-savy then you may be better off with an Apple TV or Chromecast.
(2016-03-25, 12:11)Koying Wrote:(2016-03-25, 12:04)giaur Wrote: Not at all. I own RK hadrware and I'm really happy with it, then only bad thing are Kodi problems.
Out of curiosity, if Kodi is useless on your hardware, what do you use it for?
They use it as a Raspberry Pi case
Be nice to the people :-)
2016-03-25, 12:22
(2016-03-25, 12:11)Koying Wrote:(2016-03-25, 12:04)giaur Wrote: Not at all. I own RK hadrware and I'm really happy with it, then only bad thing are Kodi problems.
Out of curiosity, if Kodi is useless on your hardware, what do you use it for?
It's not useless. The only noticeable issue is 250 ms out of sync audio, which I solved by setting 250ms audio delay for all videos. Also, some specific cases like file I posted above will cause problems, but I even don't own 4k tv and I'm not watching 4k movies, full hd is max and it's works as should (except mentioned audio out of sync). Interesting, because 4k movies downloaded from YouTube will play with Kodi without any problems.
Also PVR with tvheadend backend (576i and 1080i) all ok.
What else? Not only Kodi. Maps, Internet, text editor (WPS Office) for simple tasks , etc. Physical wireless keyboard (on screen keyboard disabled) and wireless mouse. Also sometimes remote desktop connections to Windows PC, etc. So, some things that would be difficult or not possible on Android TV actually.
Andoid TV is good for Youtube and to add some VOD services eaisly, nothing more.
2016-03-25, 12:26
(2016-03-25, 12:18)fritsch Wrote:(2016-03-25, 12:11)nooryani84 Wrote: In the defense of the people who buy these shitty android-boxes... If you're not tech-savy, it's really hard to know what to look for. Then again, if you aren't tech-savy then you may be better off with an Apple TV or Chromecast.
(2016-03-25, 12:11)Koying Wrote: Out of curiosity, if Kodi is useless on your hardware, what do you use it for?
They use it as a Raspberry Pi case
Be nice to the people :-)
Yea, that was a bit in poor taste. Sorry
2016-03-25, 12:28
(2016-03-25, 12:22)giaur Wrote: It's not useless. The only noticeable issue is 250 ms out of sync audio, which I solved by setting 250ms audio delay for all videos. Also, some specific cases like file I posted above will cause problems, but I even don't own 4k tv and I'm not watching 4k movies, full hd is max and it's works as should (except mentioned audio out of sync).
Also PVR with tvheadend backend (576i and 1080i) all ok.
lol. I even less understand what you want, then
Basically, if I get you right, you have no issue...
2016-03-25, 12:33
(2016-03-25, 12:11)nooryani84 Wrote: In the defense of the people who buy these shitty android-boxes... If you're not tech-savy, it's really hard to know what to look for. Then again, if you aren't tech-savy then you may be better off with an Apple TV or Chromecast.I would not call Zidoo X6 "shitty Android box". It's rather high quality and runs very smoothly. Kodi also runs very smoothly too, except some problems already mentioned above. Also, look at (for example) at Amazon Fire Stick, it runs on poor Mediatek CPU (quad core, they didn;t tell exact model). How can it be smooth? Once you install more advanced app you will most likely notice lags
2016-03-25, 12:35
(2016-03-25, 12:28)Koying Wrote: lol. I even less understand what you want, then250 ms audio delay is annoying for me
Basically, if I get you right, you have no issue...
That's all currently. Also, aspect ratio issue for dvb-t streams, but this looks like general Android issue (SD dvb-t streams have incorrent aspect ratio by default).
2016-03-25, 12:40
2016-03-25, 12:48
It is definitely not useless on RK (if you are using the right version), and definitely still useable, but things such as auto refresh rate switching, HD audio passthrough, and various other issues are present.
In all honesty, AML does have better support for many aspects of their chipsets, however, the performance of AML chipsets is sub-par, when compared to RK.
Lets take the S812-H as the example. I can honestly say that an RK3188 from like 4 years ago has nearly the same performance, of this 'top of the range' AML chipset (putting aside .h264 chip support etc).
Put them side by side running Kodi or other general operations, and they will do the same job.
Put an RK3288 next to them, and you'll be like WOW, this is super snappy - literally like running a mini pc.
I have played with over 10 android boxes, with chipsets ranging from AML, RK and Allwinner - nothing is comparable when it comes to performance, to RK.
P.s, Koying, please check your PM
In all honesty, AML does have better support for many aspects of their chipsets, however, the performance of AML chipsets is sub-par, when compared to RK.
Lets take the S812-H as the example. I can honestly say that an RK3188 from like 4 years ago has nearly the same performance, of this 'top of the range' AML chipset (putting aside .h264 chip support etc).
Put them side by side running Kodi or other general operations, and they will do the same job.
Put an RK3288 next to them, and you'll be like WOW, this is super snappy - literally like running a mini pc.
I have played with over 10 android boxes, with chipsets ranging from AML, RK and Allwinner - nothing is comparable when it comes to performance, to RK.
P.s, Koying, please check your PM
2016-03-25, 13:18
MXPlayer is a video player on Google Play Store that is developed and sold to make a profit.
Rockchip sell SoC's to various Hardware vendors to make a profit.
Kodi is a labour of love done developed for free by volunteer devs. in their spare time.
Google / Android has published API's that every Hardware SoC vendor is free to support.
Rockchip (users) want the Kodi devs to write and support specific RK Kodi code for free so Rockchip can sell more SoC's to make a profit.
Now does anyone see a BIG problem with the way that Rockchip are conducting their business ?
Rockchip sell SoC's to various Hardware vendors to make a profit.
Kodi is a labour of love done developed for free by volunteer devs. in their spare time.
Google / Android has published API's that every Hardware SoC vendor is free to support.
Rockchip (users) want the Kodi devs to write and support specific RK Kodi code for free so Rockchip can sell more SoC's to make a profit.
Now does anyone see a BIG problem with the way that Rockchip are conducting their business ?
2016-03-25, 13:32
(2016-03-25, 12:26)nooryani84 Wrote:(2016-03-25, 12:18)fritsch Wrote:(2016-03-25, 12:11)nooryani84 Wrote: In the defense of the people who buy these shitty android-boxes... If you're not tech-savy, it's really hard to know what to look for. Then again, if you aren't tech-savy then you may be better off with an Apple TV or Chromecast.
They use it as a Raspberry Pi case
Be nice to the people :-)
Yea, that was a bit in poor taste. Sorry
See the :-) <- in fact i was rolling on the floor laughing.
2016-03-25, 16:06
History is a mighty bitch, pay attention to her
Here's the low down.
When I started android port, it was on AML SoC, M1 in fact. The only Google API present was MediaPlayer which is fine for local file or http sources but would never work with the xbmc/kodi internal vfs. The internal vfs is REQUIRED for hitting smb or nfs sources. So I looked around and figured out what AML was doing. Thus a full blown AMLPlayer was born which sat along side the internal DVDPlayer. We vectored things is could handle to AMLPlayer and life was good.
Fast forward a bit and I was getting tired of constantly fixing AMLPLayer every time AML touched the internals and changed the API. And AMLPlayer did not handle some subtitles that DVDPlayer could handle. So I went deeper and AMLCodec was born. A lower API that seemed more stable. Of course AML devs diddled it over time too. So more breakage and fixes.
Fast forward again, google comes out with MediaCodec and millions of developers cry out. At this time I realized AMLCodec was dead and MediaCodec was the way forward. But some SoC venders were slow at adopting or had very buggy implementations of MediaCodec. AML in particular. Factor in OpenElec and other embedded Linux running on AML SoCs and that is why AMLCodec is still present in the codebase.
A little time later, koying comes up with stagefright codec which reached deep into google private APIs to support other vender SoCs for hw decoder support. Now XBX/Kodi could support other SoCs than just AML. Life was good again but relying on private APIs that could change was not the best choice but hey, what can you do...
At this time, I had an internal version of MediaCodec up for Pivos (worked for them at the time). We decided to push it public as an alternative to the stagefright codec. Koying and I butt heads a bit Both eventually come into the codebase and AMLCodec was retained because AML devs were too busy changing APIs like underwear to work on a good MediCodec.
To the present, Stagefright is gone, and MediaCodec is THE preferred API for Android. Yet some SoC vendors are still lagging behind the power curve which amazes me today. Get with the program guys or get left behind. Plain and simple.
Here's the low down.
When I started android port, it was on AML SoC, M1 in fact. The only Google API present was MediaPlayer which is fine for local file or http sources but would never work with the xbmc/kodi internal vfs. The internal vfs is REQUIRED for hitting smb or nfs sources. So I looked around and figured out what AML was doing. Thus a full blown AMLPlayer was born which sat along side the internal DVDPlayer. We vectored things is could handle to AMLPlayer and life was good.
Fast forward a bit and I was getting tired of constantly fixing AMLPLayer every time AML touched the internals and changed the API. And AMLPlayer did not handle some subtitles that DVDPlayer could handle. So I went deeper and AMLCodec was born. A lower API that seemed more stable. Of course AML devs diddled it over time too. So more breakage and fixes.
Fast forward again, google comes out with MediaCodec and millions of developers cry out. At this time I realized AMLCodec was dead and MediaCodec was the way forward. But some SoC venders were slow at adopting or had very buggy implementations of MediaCodec. AML in particular. Factor in OpenElec and other embedded Linux running on AML SoCs and that is why AMLCodec is still present in the codebase.
A little time later, koying comes up with stagefright codec which reached deep into google private APIs to support other vender SoCs for hw decoder support. Now XBX/Kodi could support other SoCs than just AML. Life was good again but relying on private APIs that could change was not the best choice but hey, what can you do...
At this time, I had an internal version of MediaCodec up for Pivos (worked for them at the time). We decided to push it public as an alternative to the stagefright codec. Koying and I butt heads a bit
Both eventually come into the codebase and AMLCodec was retained because AML devs were too busy changing APIs like underwear to work on a good MediCodec.To the present, Stagefright is gone, and MediaCodec is THE preferred API for Android. Yet some SoC vendors are still lagging behind the power curve which amazes me today. Get with the program guys or get left behind. Plain and simple.
2016-03-25, 16:40
(2016-03-25, 16:06)MrMC Wrote: At this time, I had an internal version of MediaCodec up for Pivos (worked for them at the time). We decided to push it public as an alternative to the stagefright codec. Koying and I butt heads a bit
Nah, it was obvious from the start your MediaCodec was the way-to-go. Just a timing issue
2016-03-25, 19:40
(2016-03-25, 16:06)MrMC Wrote: History is a mighty bitch, pay attention to her
Here's the low down.
When I started android port, it was on AML SoC, M1 in fact. The only Google API present was MediaPlayer which is fine for local file or http sources but would never work with the xbmc/kodi internal vfs. The internal vfs is REQUIRED for hitting smb or nfs sources. So I looked around and figured out what AML was doing. Thus a full blown AMLPlayer was born which sat along side the internal DVDPlayer. We vectored things is could handle to AMLPlayer and life was good.
Fast forward a bit and I was getting tired of constantly fixing AMLPLayer every time AML touched the internals and changed the API. And AMLPlayer did not handle some subtitles that DVDPlayer could handle. So I went deeper and AMLCodec was born. A lower API that seemed more stable. Of course AML devs diddled it over time too. So more breakage and fixes.
Fast forward again, google comes out with MediaCodec and millions of developers cry out. At this time I realized AMLCodec was dead and MediaCodec was the way forward. But some SoC venders were slow at adopting or had very buggy implementations of MediaCodec. AML in particular. Factor in OpenElec and other embedded Linux running on AML SoCs and that is why AMLCodec is still present in the codebase.
A little time later, koying comes up with stagefright codec which reached deep into google private APIs to support other vender SoCs for hw decoder support. Now XBX/Kodi could support other SoCs than just AML. Life was good again but relying on private APIs that could change was not the best choice but hey, what can you do...
At this time, I had an internal version of MediaCodec up for Pivos (worked for them at the time). We decided to push it public as an alternative to the stagefright codec. Koying and I butt heads a bit
To the present, Stagefright is gone, and MediaCodec is THE preferred API for Android. Yet some SoC vendors are still lagging behind the power curve which amazes me today. Get with the program guys or get left behind. Plain and simple.
Interesting read. Any plans to share the backport of V17 audio engine you created with Koying to implement in SPMC?
