• 1
  • 7
  • 8
  • 9(current)
  • 10
  • 11
  • 21
Solved XVID/MPEG-4/MPEG-2 files in SD quality play in slow motion
(2018-11-29, 14:18)Lewpy Wrote: I will look to update my PC from Krypton to Leia, so its more comparable.
I have now upgraded my Media PC from 32bit Krypton 17.6 to 64bit Leia 18 RC1 .... and the software rendering with all deinterlacing settings [full/half/none] is now perfect, with no dropped/skipped frames  Blush
Does this prove anything? Or just muddy the water? I don't know.
Reply
(2018-11-15, 04:26)wrxtasy Wrote:
(2018-11-13, 11:50)wsnipex Wrote: if an A53 can't play mpeg2, then something is seriously wrong. Anyway, looks like there is no single 1 solution for those droid issues. Back to an expert setting? Wink

In Linux (AMLogic) Kodi settings under hardware acceleration, we still have mpeg2 and mpeg4 - HD and Up - user selectable options.
That should could be extended to Android Kodi IMHO and let the user decided what works for them.

Here is a quick and dirty Leia RC compile using those mpeg2 and mpeg4 options for Android Kodi Leia RC:

Settings > Player > Video > Accelerate MPEG2
Settings > Player > Video > Accelerate MPEG4

Never = disable hardware decoding for MPEG2 or MPEG4

kodiapp-armeabi-v7a-Leia_rc-DVD_VOB.apk

It's using a unique Signature so will not interfere with other installed Kodi Apps.

As already stated if you have not got the ARM ponies under the hood, then Software decoding of mpeg2 and mpeg4 is not going to help.
And yes Android Kodi vs Linux Kodi seems worse for software decode performance on low powered ARM chipsets.     
 @wrxtasy could you also provide the current RC2 with the two parameters as armeabi-v7a and also with the original name (org.xbmc.kodi), because the name you chose is already occupied by this program on my Android TV:

com.amazon.aiv.eu -->ATVBlastAndroidTVThinClient-eu

That would be great Wink
Reply
(2018-12-09, 03:03)rainman74 Wrote: That would be great Wink 

Would be really great also to have the source code. Thanks :-)
Reply
By the way, all XVIDs with these settings run absolutely smoothly with Kodi 18 again. Too bad that the developers don't activate this again. The solution would be so simple and would make thousands of Android users happy. As soon as Kodi 18 final is released, I'm afraid there will be a lot of problem messages because of that! Sad

My settings:
Settings > Player > Video > Accelerate MPEG2 - ALWAYS
Settings > Player > Video > Accelerate MPEG4 - ALWAYS
Reply
Too bad users don't give a fuck about solving these issues or bitching towards their idiots manufacturers that release absolute crap.

These settings we I'll not be added. period!
Now stop complaining or help solve it.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
(2018-12-11, 01:49)Martijn Wrote: Too bad users don't give a fuck about solving these issues or bitching towards their idiots manufacturers that release absolute crap.

These settings we I'll not be added. period!
Now stop complaining or help solve it.
 I don't need the settings in the official build anymore, I use the customized build of wrxtasy. Therefore this thread can be closed.
Reply
(2018-12-11, 01:49)Martijn Wrote: Too bad users don't give a fuck about solving these issues or bitching towards their idiots manufacturers that release absolute crap.

These settings we I'll not be added. period!
Now stop complaining or help solve it.
I have seen this in quite a few threads. Blaming the device manufacturers sure is the simplest thing to do. We know it's the manufacturers' fault and users are blaming them and trying to make them change. But as always things won't happen as you wish right? You kodi devs can make the situation better for users but you just don't care. Of coz I just use the free product and have no point to blame you. But yes I mean you don't have the passion to make kodi users happy any more. Kodi is now more like a responsibility out of your interests.
Reply
(2018-12-09, 19:56)Micromax Wrote: Would be really great also to have the source code. Thanks :-) 
I also compiled my own version to be able to enable these settings. You only have to modify three lines of code in settings.xml and eight in DVDVideoCodecAndroidMediaCodec.cpp. It is probably not the best way to do it, since it reuses the amcodec settings, but it's very easy to change and it works perfectly.

In my specific case I have enabled hardware acceleration for mpeg2 only when the video is HD in the settings and my problem is solved.

Here you have the changes that I have made regarding the official version (I did it between the rc1 and the rc2), really only the lines with the '-' or '+' matter:


kodi/system/settings/settings.xml  
Code:

@@ -119,13 +119,13 @@
           <updates>
             <update type="change" />
           </updates>
           <control type="toggle" />
         </setting>
         <setting id="videoplayer.useamcodecmpeg2" type="integer" label="39001" >
-          <requirement>HAVE_AMCODEC</requirement>
+          <requirement>HAS_MEDIACODEC</requirement>
           <level>2</level>
           <default>0</default>
           <constraints>
             <options>
               <option label="20420">9999</option>   <!-- Never -->
               <option label="39000">800</option>  <!-- HD -->
@@ -141,13 +141,13 @@
             </dependency>
           </dependencies>
           <control type="spinner" format="string" />
           <control type="edit" format="integer" />
         </setting>
         <setting id="videoplayer.useamcodecmpeg4" type="integer" label="39002">
-          <requirement>HAVE_AMCODEC</requirement>
+          <requirement>HAS_MEDIACODEC</requirement>
           <level>2</level>
           <default>800</default>
           <constraints>
             <options>
               <option label="20420">9999</option>   <!-- Never -->
               <option label="39000">800</option>  <!-- HD -->
@@ -163,13 +163,13 @@
             </dependency>
           </dependencies>
           <control type="spinner" format="string" />
           <control type="edit" format="integer" />
         </setting>
         <setting id="videoplayer.useamcodech264" type="integer" label="39003">
-          <requirement>HAVE_AMCODEC</requirement>
+          <requirement>HAS_MEDIACODEC</requirement>
           <level>2</level>
           <default>0</default>
           <constraints>
             <options>
               <option label="20420">9999</option>   <!-- Never -->
               <option label="39000">800</option>  <!-- HD -->


kodi/xbmc/cores/VideoPlayer/DVDCodecs/Video/DVDVideoCodecAndroidMediaCodec.cpp
Code:

@@ -426,23 +426,25 @@
   CLog::Log(LOGDEBUG, LOGVIDEO, "CDVDVideoCodecAndroidMediaCodec::Open hints: Tag %d \n", m_hints.codec_tag);
   CLog::Log(LOGDEBUG, LOGVIDEO, "CDVDVideoCodecAndroidMediaCodec::Open hints: %dx%d \n", m_hints.width,  m_hints.height);
 
   switch(m_hints.codec)
   {
     case AV_CODEC_ID_MPEG2VIDEO:
+      if (m_hints.width <= CServiceBroker::GetSettingsComponent()->GetSettings()->GetInt(CSettings::SETTING_VIDEOPLAYER_USEAMCODECMPEG2))
+        goto FAIL;        
       m_mime = "video/mpeg2";
       m_mpeg2_sequence = new mpeg2_sequence;
       m_mpeg2_sequence->width  = m_hints.width;
       m_mpeg2_sequence->height = m_hints.height;
       m_mpeg2_sequence->ratio  = m_hints.aspect;
       m_mpeg2_sequence->fps_scale = m_hints.fpsscale;
       m_mpeg2_sequence->fps_rate = m_hints.fpsrate;
       m_formatname = "amc-mpeg2";
       break;
     case AV_CODEC_ID_MPEG4:
-      if (hints.width <= 800)
+      if (m_hints.width <= CServiceBroker::GetSettingsComponent()->GetSettings()->GetInt(CSettings::SETTING_VIDEOPLAYER_USEAMCODECMPEG4))
         goto FAIL;
       m_mime = "video/mp4v-es";
       m_formatname = "amc-mpeg4";
       break;
     case AV_CODEC_ID_H263:
       m_mime = "video/3gpp";
@@ -477,12 +479,17 @@
       m_mime = "video/x-vnd.on2.vp9";
       m_formatname = "amc-vp9";
       break;
     case AV_CODEC_ID_AVS:
     case AV_CODEC_ID_CAVS:
     case AV_CODEC_ID_H264:
+      if (m_hints.width <= CServiceBroker::GetSettingsComponent()->GetSettings()->GetInt(CSettings::SETTING_VIDEOPLAYER_USEAMCODECH264))
+      {
+        CLog::Log(LOGDEBUG, "CDVDVideoCodecAmlogic::h264 size check failed %d",CServiceBroker::GetSettingsComponent()->GetSettings()->GetInt(CSettings::SETTING_VIDEOPLAYER_USEAMCODECH264));
+        goto FAIL;
+      }
       switch(hints.profile)
       {
         case FF_PROFILE_H264_HIGH_10:
           profile = CJNIMediaCodecInfoCodecProfileLevel::AVCProfileHigh10;
           break;
         case FF_PROFILE_H264_HIGH_10_INTRA:

Reply
(2018-12-11, 05:30)RuralHunter Wrote:
(2018-12-11, 01:49)Martijn Wrote: Too bad users don't give a fuck about solving these issues or bitching towards their idiots manufacturers that release absolute crap.

These settings we I'll not be added. period!
Now stop complaining or help solve it.
I have seen this in quite a few threads. Blaming the device manufacturers sure is the simplest thing to do. We know it's the manufacturers' fault and users are blaming them and trying to make them change. But as always things won't happen as you wish right? You kodi devs can make the situation better for users but you just don't care. Of coz I just use the free product and have no point to blame you. But yes I mean you don't have the passion to make kodi users happy any more. Kodi is now more like a responsibility out of your interests.

It's not fully like that. The only way we can do it would be to have many "special cases" in the codebase with work-arounds and other bodge sticking-plaster fixes to overcome the issues in the firmware of the specific manufacturers (or even specific devices in some cases).

Doing this would result in:

1) The manufacturers never actually fixing the problem.
2) Our code ending up being full of such crap which then becomes an absolute nightmare to maintain and upgrade.
3) An ever expanding need for such work-arounds as more and more boxes and firmwares are released.

So one or two versions ago it was decided to stop playing this game, to clean up the code and to put the onus to fix things back where it should be, with the manufacturers and their broken firmwares. It is indeed unfortunate that a certain proportion of the userbase who bought such defective boxes are forced to suffer, but in cold reality having the users move to a different manufacturer because the current one provides bad firmware is probably the only way to get them to actually fix the problems at source rather than relying on us to patch things up afterwards.

In the end we've got better things to do with our very limited pool of developer time than fixing stuff that others should be fixing but can't be bothered to, especially as we don't currently have any dedicated Android developers on the team.
|Banned add-ons (wiki)|Forum rules (wiki)|VPN policy (wiki)|First time user (wiki)|FAQs (wiki) Troubleshooting (wiki)|Add-ons (wiki)|Free content (wiki)|Debug Log (wiki)|

Kodi Blog Posts
Reply
(2018-12-11, 10:58)DarrenHill Wrote:
(2018-12-11, 05:30)RuralHunter Wrote:
(2018-12-11, 01:49)Martijn Wrote: Too bad users don't give a fuck about solving these issues or bitching towards their idiots manufacturers that release absolute crap.

These settings we I'll not be added. period!
Now stop complaining or help solve it.
I have seen this in quite a few threads. Blaming the device manufacturers sure is the simplest thing to do. We know it's the manufacturers' fault and users are blaming them and trying to make them change. But as always things won't happen as you wish right? You kodi devs can make the situation better for users but you just don't care. Of coz I just use the free product and have no point to blame you. But yes I mean you don't have the passion to make kodi users happy any more. Kodi is now more like a responsibility out of your interests. 

It's not fully like that. The only way we can do it would be to have many "special cases" in the codebase with work-arounds and other bodge sticking-plaster fixes to overcome the issues in the firmware of the specific manufacturers (or even specific devices in some cases).

Doing this would result in:

1) The manufacturers never actually fixing the problem.
2) Our code ending up being full of such crap which then becomes an absolute nightmare to maintain and upgrade.
3) An ever expanding need for such work-arounds as more and more boxes and firmwares are released.

So one or two versions ago it was decided to stop playing this game, to clean up the code and to put the onus to fix things back where it should be, with the manufacturers and their broken firmwares. It is indeed unfortunate that a certain proportion of the userbase who bought such defective boxes are forced to suffer, but in cold reality having the users move to a different manufacturer because the current one provides bad firmware is probably the only way to get them to actually fix the problems at source rather than relying on us to patch things up afterwards.

In the end we've got better things to do with our very limited pool of developer time than fixing stuff that others should be fixing but can't be bothered to, especially as we don't currently have any dedicated Android developers on the team. 
 I understand these arguments. But here are my points:
1. No work-around may force the manufacturers to fix their problem. But in my understanding, most likely the manufacturers don't care if kodi supports them or not. They will just advise users to install another software and say that's not their problem since other software might work.
2. Even manufacturers fix the problem by firmware updating or producing new devices, there will be still many devices out there which might not be in the support scope.
3. Users can not always abandon the device they bought. Firstly it's losing money. Secondly, it's very hard for users to turn to another device only because Kodi is not working. They may have other considerations.
4. I agree implementing device specific fixes increases the burden of kodi. I don't think Kodi should implement every device specific work-arounds either. It should be evaluated case by case. Specifically for this case, I don't think there is any problem by providing an option for uses to choose for their own device, with the default value kodi wants to have.
Reply
There are older versions of Kodi which have all of these bodges and patches in place which people can use on such devices. Plus sometimes there are versions and branches that may accomodate them, either semi-officially or entirely 3rd party.

They may miss out on some of the newest features, but they will still operate as media players for those who cannot or will not update their device and move away from defective firmware.

In the end we don't have the manpower to overcome issues that others should be fixing. That's not to mention the fact that those manufacturers have been paid for the hardware through the purchase, compared to our open source status.
|Banned add-ons (wiki)|Forum rules (wiki)|VPN policy (wiki)|First time user (wiki)|FAQs (wiki) Troubleshooting (wiki)|Add-ons (wiki)|Free content (wiki)|Debug Log (wiki)|

Kodi Blog Posts
Reply
Wink 
@Mochilote : Thank you very much!! Really appreciated.  Smile
Reply
(2018-12-11, 12:17)DarrenHill Wrote: In the end we don't have the manpower to overcome issues that others should be fixing. That's not to mention the fact that those manufacturers have been paid for the hardware through the purchase, compared to our open source status.

It's not only the manpower, but as @peak3d saw with AMLogic LibreELEC Kodi Krypton development, patches would be required for the underlying old 3.x Android/Linux Kernel as well for legacy support when hardware decoding of mpeg2, mpeg4 and VC-1.

And for Android Kodi devices, that is virtually impossible because 98% of the Android device manufacturers could not care less, even if you could contact them in the first place.
They only care about correct playback of video compression methods used by mainstream video Apps.

Moral of the story is pick the correct hardware in the first place.
Open source everything is usually the best like you see with LibreELEC devices. Or you use powerful hardware from Apple or Intel and just throw CPU horsepower at the issue and software decode old problematic video files.

Reply
I can perfectly understand the reasons why you do not want to put these options as they are failures of the manufacturers and specific devices and it's supposed to affect a few users (It is not clear how many users it really affects), and that the source code has to be clear and without strange patches to fix specific cases.

So I think it's right for Android to use hardware acceleration for all codecs by default and also can be disabled in the settings, so what I can not understand is that MPEG4 SD videos are forced to decode by software (always, regardless of the settings) which is also the problem that made this forum thread by @rainman74 and it is not explained either that until the rc1 the DVDs were also decoded by software always. ignoring again the settings.

Should it always be applied according to the settings, right? By default everything accelerated by hardware and if it is disabled in the settings then everything decoded by software.
Reply
We are mixing up several issues here...

- DVD has been software decoded because of missing/buggy(?) drain in Kodi's MediaCodec implementation which AFAIK is needed for proper menu handling (workaround for Kodi issue which hasn't been addressed)
- MPEG-4 ASP SD has been software decoded because of non-standards-compliant encodes, e.g. too many ref. frames (workaround for bad encodes)

Those workarounds have nothing to do with the device manufacturers. It has been done that way based on the assumption that SW decoding is a solved problem due to sufficient processing power of today's devices which is not true for most of them based on Android TV. Most of them are based on Amlogic S905X (streaming boxes) or MediaTek MT5890/MT5891 (TVs) which both feature a quad-core ARM Cortex A53 and fail to real-time decode MPEG-2/4 SD in software (especially interlaced stuff which requires Yadif as well).

MPEG-2 (apart from DVD) has always been decoded in hardware which @Mochilote's box seems to have problems with (most likely because of the HW deinterlacing). This is probably the only HW related issue we are facing in this thread.
Reply
  • 1
  • 7
  • 8
  • 9(current)
  • 10
  • 11
  • 21

Logout Mark Read Team Forum Stats Members Help
XVID/MPEG-4/MPEG-2 files in SD quality play in slow motion1