Database Info

Poor video playback - solutions?

Hy guys,
Just to know, I'm coming from my trusty Eten M700. I bought the HTC Touch Pro about one week ago here, in Romania.
And I must say the video playback seems way too sluggish for a phone like this. On the M700, with same coreplayer version (latest), with raw frame buffer and medium quality and no other modification I could play every video I wanted. Including 720x576 xvid clips.
On this one...no matter what I set (QTV, raw frame buffer, direct draw), everything seems a little too sluggish compared to M700.
do you have the same impression, or is it just me?
I just read another thread here about video performance but it had too much dissipated info.

Gigs said:
Hy guys,
Just to know, I'm coming from my trusty Eten M700. I bought the HTC Touch Pro about one week ago here, in Romania.
And I must say the video playback seems way too sluggish for a phone like this. On the M700, with same coreplayer version (latest), with raw frame buffer and medium quality and no other modification I could play every video I wanted. Including 720x576 xvid clips.
On this one...no matter what I set (QTV, raw frame buffer, direct draw), everything seems a little too sluggish compared to M700.
do you have the same impression, or is it just me?
I just read another thread here about video performance but it had too much dissipated info.
Click to expand...
Click to collapse
Which is why it's great that you started a new thread to dissipate the info further. Read the other thread(s) again, this has already been answered and solved within coreplayer.

P0ll0L0c0 said:
Which is why it's great that you started a new thread to dissipate the info further. Read the other thread(s) again, this has already been answered and solved within coreplayer.
Click to expand...
Click to collapse
which topic is it? i have smilar issues

Untill now I have found that QTV with Medium acceleration, and dither on has the best performance, anyway less than m700. Setting the buffer to 8000 kb did not had any effect. Still want to hear from another pro owners what they think about this.

I agree, video playback just sucks! I hate Qualcomm processors, Xscale rulezzz!
However when I put QTv, my screen goes black and there's only sound.
How did you achieve to run it on QTv???

krabicka3 said:
I agree, video playback just sucks! I hate Qualcomm processors, Xscale rulezzz!
However when I put QTv, my screen goes black and there's only sound.
How did you achieve to run it on QTv???
Click to expand...
Click to collapse
It depends on what kind of file you want to play with it. On mine, some 3gp and some clips compressed for mobile devices don't show anything on screen. Try to switch to raw frame buffer, and restart core player, maybe it helps?

Unfortunately the HTC Touch Pro is not the mulitmedia phone you want if your looking to run your non-mobile encoded videos. However it still can be a awesome video player if you encode videos to the right dimension and specs.
I took this past Sunday to play around with finding just the right video format and encode settings to play video as close to vga as possible. Unfortunately the Touch Pro can't play videos in full-vga resolution. HOWEVER, it can perfectly play videos in 480x320 which when you compare to a 640x480 video on the touch pro's 2.5inch screen there is no difference in quality what so ever.
When you play small videos on such a small screen you wont notice the difference in the resolution, however comparing a qvga (320x240) to the half vga 480x320 resolution you can definitely see a difference.
I use two different encoders, one being pocket divx encoder and the other videora iphone converter.
I encoded a bunch of animes and movies using pocket divx set to 480x320, 2-Pass, vhq enabled, around 850 video bitrate and 128kb stereo bitrate and all my videos look crisp on the Touch Pro and plays smoothly.
I suggest others to try it out and benchmark the playback yourself and you'll see it'll run at a easy 135%+ which is perfect for 100% smooth playback.

Gigs said:
It depends on what kind of file you want to play with it. On mine, some 3gp and some clips compressed for mobile devices don't show anything on screen. Try to switch to raw frame buffer, and restart core player, maybe it helps?
Click to expand...
Click to collapse
1.) I suggest check two things, one be sure you are running the latest build which I assume you are,
2) under preferences and under the Qtv page look to make sure "Tytn 2 driver mode" is enabled.
3) some builds have a issue of zoomed in pictures to a an extreme amount that only a black screen shows when first installed, set the zoom to 50% and then reset to the normal or best fit.
Hopefully those changes should help you out
UPDATE: Also there is one bug I know of with Coreplayer. When coreplayer is launched and left running in the back (or if still active on screen) should the device go into sleep mode and then come back you will not be able to see any video playing when choosing to start. You'll have to close coreplayer and reopen again, I noticed this the other day and just came into mind when experiencing just now again.

I almost agree with you puerrican but I think it's such a burden to reencode....I managed to get easy after I saw that everything encoded with h264, mkv and encoders like this can't be played in the pro. However, everything I had in my computer encoded in divx, xvid, normal things works just fine with the settings I put in some posts above. I just tried 700 MB DVDrip(around 1000 kbit/s and 640x272) and some videoclip(624x352 vbr around 2300kbits) both xvid and they worked ok. 688x400 AVC1 (h264) killed the pro.It's not just the resolution but also the encoder used.
EDIT: just saw the update and I wanted to mention that I'm also using the 1.2.5 build 4506 with tytn 2 mode enabled and qtv on medium selected. And touchflo3d is disabled and I'm using the spb shell (or something like that with icons on screen).
IDEA: I think it would be interesting playing back xvid 640x480 and h264 640x480 to test this idea of mine

Definitely it is pain to go and do that. Plus reencoding speed relies heavily on your pc specs, on a high end specs your looking at around 4-5 mins for a 2-pass encoded video of 24 min length. While a movie length of 90 mins or so your looking at at least 16-22 mins.
So expect much longer wait on a lower end thats not even dual core or lower clock rate.
Until pdas start sporting dedicated gpus from nvidia or other names windows mobile wont ever benefit on being a media playback alternative which is a nice plus for those not looking to carry 2-3 devices for music, pmp, pda, and phone. Wish HTC would look into intel processors for their next unit and possibly throw in a nvidia mobile gpu like the 5500 with a decent amount of video memory. I mean at this point in the technology chain its not even remotely impossible to do so... so whats the hold up with companies???

yeah, i have no problem with mp4 at 640x480 (640x360 widescreen). mkv at high res (above 640x480) is a little juttery. my movies are usually 24fps, 1000kbps, 640x360
got same settings as gigs
coreplayer is working on fix for v1.3

I'm at a lost, I tried playing 640x480 videos on my touch pro and it stutters way too much, how are you guys managing to have to it playback flawlessly?

I dont really get whats good about watching movies on a 2.5 inch screen...do you do that on such a regular basis that this is so important ?
Regarding Video, i just watch some short youtube clips and stuff like that...
Ever tried to watch a full length movie on such a small screen ? I did that on holiday on my ipod and its really hurting the eyes to concetrate on such a small screen for 90+ minutes... not really anything you want to do regularly...besides not reencoded videos take up alot of space on your memorystick...
i dont have a problem with reencoding some videos and stuff, full length movies arent meant to be watched on a phone anyway

Well, a 2,5 inch screen is a bit too small, but our Touch Pros have a 2,8 inch screen

I have a zune and it has a 3 in screen and was perfect for watching tv videos or movies, and thats half the resolution then a TP. Cant wait to get my hand on the TP !!!

To each his own, some ppl like being able to watch videos whenever the call comes. Sometimes when I have to wait for something like a class to start or I'm away from my pc, or even on a airplane or public transportation I like to be able to watch few episodes easily and clearly. A full blown movie yea its gonna be a nuisance for a long time depending on the person. But some are accustomed to it, I for one can easily watch 4-6 episodes in a row without getting any kind of headahce.

yep, its quite convient. all in one device. it has tv out as well, so since it is simalar res to tv, it looks great
music + movies on phone, no ned for mp3 player. plus i can stream movies off my pc

yeah i see that there is room for this, but i dont think many people use this so regulary that converting a few movies is that much of a pain. You will save a lot of space on your memorystick as well.

I have modifying 2 regentries and the video is now much better.
Look here:
http://forum.xda-developers.com/showthread.php?t=438318
Using CorePlayer the benchmark was before 75-95%,now 145%. on same videofile - Uncompressed VGA XviD.
Edit... I am sorry. It wasn't working. I just forgot,that I set the video quality to medium before.

You have to chose Medium Quality on Video Settings (with Qtv selected), otherwise it lags so much ..
Even on medium on motion scenses some frame drops
Video used for tests: RL_XQ_640x480_1500_128.avi (found somewhere here on this forum.. can't remember the topic name )

Thinking through CM10 720p Video Recording

This first post from me is going to be short. I welcome additional thoughts, of course. Sorry if this isn't the best place to drop this, but it's not a question and it's not anything in development!
First, an observation: the problem with 720p in CM10 is not bright light, it's the camera's ability to adapt to bright light from low light. In other words, the problem seems to be related to the light sensor. Although this is not completely new, what I noticed from playing around with LGCamera is that if I turn UP the video bitrate, the flickering is not as sever. The flickering will stop and stabilize when filming in consistent light. Any change in light quality will produce more sticking. This makes sense since 720p requires finer adjustments to light and dark than 420p. The other part of the equation is the h264 encoder. I'm guessing that certain values in the light sensor need to match up with the h264 encoder...
Second, I was playing around with these settings today: http://forum.xda-developers.com/showpost.php?p=17791551&postcount=20 I haven't had enough time to verify what makes a difference and what doesn't. I believe that some settings have helped a bit. Also, I felt that changing the ISO to 800 in camera and then switching to video improved the video, but that could be totally imagined! Essentially, what we need is ISO800 for the vidcam... I think!

Suggested fix that was here didn't work. I'm editing to see if I can correct the "Invalid User ID" error I keep getting on my XDA app. Started right after I went to correct this message.

if you think you have found a fix i'd suggest bringing it to the developer's attention, such as indeed posting this in the official thread.
Also your second post got chopped off lol

threi_ said:
if you think you have found a fix i'd suggest bringing it to the developer's attention, such as indeed posting this in the official thread.
Also your second post got chopped off lol
Click to expand...
Click to collapse
I'm just messing around right now. I don't think I've found a fix. A few things I've found: I can't find a way, using the included camera, to film above 25 fps. It doesn't matter what the settings are in media_profiles.xml, 25 is the cap. The cap should be a little above 30. I also can't force the camera to film above a bit rate of 6 Mbits/sec. I averaged around 8 Mbits on the stock camera and 10 in LG camera on GB. These settings will affect light responsiveness! Perhaps the oddest thing I've noticed is that the recording streams are inverted in JB. Everything I've filmed in GB has audio in stream 1 and video in stream 2. JB's streams are the other way around. EDIT: In fact, in GB 480p recordings use Stream 1 (or 0, depending on your player) for video and stream 2 for audio, but 720p recordings use Stream 1 for audio and Stream 2 for video. So, perhaps it's worth looking into the ways in which 720p recording is being "sent" to the codec.
In the process of sorting these things out, it would help if we could find out what the AVC h263 and MPEG4 profiles and levels were in GB. I'm not completely convinced that they are configured optimally for our phone.

[To Forum Mod: Is it possible to move this thread elsewhere? Possibly the Q&A section?]
I've spent more time on this than I intended today, so this will be brief(ish). I don't know if I've found a fix, but I may have discovered a good lead. This is definitely for people who can put together and test out kernel changes faster and more accurately than I can! The other day I thought I'd found something of use, a v4l2 driver modification for Crespo. I sent my findings over to Scotthartbti. The modification may still be of use, but there was an unanswered question: why is vidioc_dqbuf unable to to clear the buffer queue? If it's the preview screen size, the fix I discovered wouldn't repair everything. SO, when I read this morning that the kernel is actually based on a Rogers ROM with limited capabilities, I decided to run another diff on the JB kernel and the GB kernel from Samsung. What I discovered was that certain drivers s3c_bc.c and s3c_bc.h are absent from the JB kernel. These two files (?) contain information that sets screen and buffer size that I couldn't find replicated anywhere in the JB kernel. I don't think it's not there... so, in the process of trying to find out why these files might not be in the JB kernel, I discovered something better: the android exynos 3.4 Git. And surprise surprise! What is it that devs are fixing over there? Quite a few issues to do with s3c buffer size, particularly in s3c-fb, and the problem of the system ignoring preview frame size!
I suspect that some lingering bugs are being addressed here: https://android.googlesource.com/kernel/exynos.git/+/android-exynos-3.4

keep it up.
Thanks for working at this. I just learned how to pull a logcat and I nabbed one while barcode scanner was on. I'm running CM10 now and I ran CM9 until July. I wish I could help, but alas I am merely a padawan.

Thanks, reynaim. Yours looks pretty much like mine. It's useful to have that confirmation!
So, I've been working on this for awhile now, spending much more time than I ever thought I would. I'm not a developer. I taught myself html, css, and php and it looks to be following a similar route with c++ and python! I've learned a fair bit about how our phone works and I have some ideas about the problems with our camera. I'll list what I can here:
1. Google updated their camera code several revisions ago, but it appears Samsung either relied on aging code or has not released the actual code for the camera hal. Several commands that bind the driver layer to software are not up to date in our camera hal and may be part of the cause of the flickering. The way the camera works is that it calls up a preview, then dumps that information before it starts recording. I suspect that the camera is not clearing the buffer queue at that moment as it should. I am attempting to rewrite this portion of the driver, but it's laborious.
2. Let's be clear about what the problems actually are: Flicker in any transition of light conditions. I can get 720p to work in bright light if there are no shadows. The light sensor is not working with the camera correctly. Actually, the problem is the framerate. At the moment, the 720p stream is going through the wrong channel, as if it is running on a PAL device. Hence, not only is the datastream throttled, but the framerate is wrong. I tinkered a bit with the light sensor drivers - changed a few values here and there - but I haven't noticed a difference.
To note here: PAL = 25 fps, NTSC =30fps. Also, PAL = 50Hz, NTSC = 60 Hz. The Infuse may use a mixed mode that runs 30fps and 50Hz.
What you will notice as a user in addition to the flicker and stuck frames is that:
The video stream is stream 1. It should be #2 (you can check this most reliably in VLC on your computer or MX Player on your phone - VLC refers to the streams as 0 and 1).
FPS, despite media_profiles.xml demanding otherwise, will not rise above 25 and may drop to around 15.
Bitrate won't rise above 6Mbits/sec (interestingly, Android sdk has the bitrate capped at 8Mbits/sec). GB would ordinarily record at 10 - 11 Mbits/sec (there is a way to up the bitrate in JB, but it doesn't improve vid quality).
3. Some minor irritations can be corrected by adding the firmware packages back into the system folder. Add a directory called "firmware" to your system folder (so it should look like /system/firmware/), give it the permissions 754 (RWX,R-X,R-X), and add RS_M5LS_OI.bin, RS_M5LS_SI.bin, RS_M5LS_TB.bin (which you may find in an old GB backup). Give those the permissions RWX, R,R (or R-X, R-X for the last two - I'm not sure which is better!). Reboot. This gets rid of that odd lag you've probably noticed when you open up 3rd party cameras and they search for storage and sometimes crash as a result.
4. I don't think - I could be wrong! - that the problem is actually in fimc. Fimc is behaving normally. There are some curiosities in the current camera hal that fimc doesn't like.
5. In fact, it seems the camera hal was not written for an 8MP camera. Why doesn't Samsung release the camera hal? Does anyone know this? My best lead came when I bricked my phone and decided to take a couple of video logcats so I could at least pinch a few values and processes.

Its seems very long since update on this thread
Whizzpopper said:
Thanks, reynaim. Yours looks pretty much like mine. It's useful to have that confirmation!
So, I've been working on this for awhile now, spending much more time than I ever thought I would. I'm not a developer. I taught myself html, css, and php and it looks to be following a similar route with c++ and python! I've learned a fair bit about how our phone works and I have some ideas about the problems with our camera. I'll list what I can here:
1. Google updated their camera code several revisions ago, but it appears Samsung either relied on aging code or has not released the actual code for the camera hal. Several commands that bind the driver layer to software are not up to date in our camera hal and may be part of the cause of the flickering. The way the camera works is that it calls up a preview, then dumps that information before it starts recording. I suspect that the camera is not clearing the buffer queue at that moment as it should. I am attempting to rewrite this portion of the driver, but it's laborious.
2. Let's be clear about what the problems actually are: Flicker in any transition of light conditions. I can get 720p to work in bright light if there are no shadows. The light sensor is not working with the camera correctly. Actually, the problem is the framerate. At the moment, the 720p stream is going through the wrong channel, as if it is running on a PAL device. Hence, not only is the datastream throttled, but the framerate is wrong. I tinkered a bit with the light sensor drivers - changed a few values here and there - but I haven't noticed a difference.
To note here: PAL = 25 fps, NTSC =30fps. Also, PAL = 50Hz, NTSC = 60 Hz. The Infuse may use a mixed mode that runs 30fps and 50Hz.
What you will notice as a user in addition to the flicker and stuck frames is that:
The video stream is stream 1. It should be #2 (you can check this most reliably in VLC on your computer or MX Player on your phone - VLC refers to the streams as 0 and 1).
FPS, despite media_profiles.xml demanding otherwise, will not rise above 25 and may drop to around 15.
Bitrate won't rise above 6Mbits/sec (interestingly, Android sdk has the bitrate capped at 8Mbits/sec). GB would ordinarily record at 10 - 11 Mbits/sec (there is a way to up the bitrate in JB, but it doesn't improve vid quality).
3. Some minor irritations can be corrected by adding the firmware packages back into the system folder. Add a directory called "firmware" to your system folder (so it should look like /system/firmware/), give it the permissions 754 (RWX,R-X,R-X), and add RS_M5LS_OI.bin, RS_M5LS_SI.bin, RS_M5LS_TB.bin (which you may find in an old GB backup). Give those the permissions RWX, R,R (or R-X, R-X for the last two - I'm not sure which is better!). Reboot. This gets rid of that odd lag you've probably noticed when you open up 3rd party cameras and they search for storage and sometimes crash as a result.
4. I don't think - I could be wrong! - that the problem is actually in fimc. Fimc is behaving normally. There are some curiosities in the current camera hal that fimc doesn't like.
5. In fact, it seems the camera hal was not written for an 8MP camera. Why doesn't Samsung release the camera hal? Does anyone know this? My best lead came when I bricked my phone and decided to take a couple of video logcats so I could at least pinch a few values and processes.
Click to expand...
Click to collapse
Hi @Whizzpopper,
I was searching on Google for infuse 4g 720p recording on JB custom ROMs and found your thread,
it seems you had been gone throught very deep on this.
Have you found anything that help us on resolving this issue afterwards ?

yogi.306 said:
Hi @Whizzpopper,
I was searching on Google for infuse 4g 720p recording on JB custom ROMs and found your thread,
it seems you had been gone throught very deep on this.
Have you found anything that help us on resolving this issue afterwards ?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?p=38355903
Sent from my Galaxy Nexus using xda premium

yogi.306 said:
Hi @Whizzpopper,
I was searching on Google for infuse 4g 720p recording on JB custom ROMs and found your thread,
it seems you had been gone throught very deep on this.
Have you found anything that help us on resolving this issue afterwards ?
Click to expand...
Click to collapse
Indeed, I did leave the Infuse. There are so many variables, it's hard to say. The problem could be in the codec or in the settings used to interact with the codec (the media_profiles.xml or media_codecs.xml) or it could be in the kernel as Scott Hart used to suspect (don't know what he thinks now!). As you know, Samsung did not provide an honest release of the source for the Infuse.
Sorry I couldn't be of more help!

Thanks
Whizzpopper said:
Indeed, I did leave the Infuse. There are so many variables, it's hard to say. The problem could be in the codec or in the settings used to interact with the codec (the media_profiles.xml or media_codecs.xml) or it could be in the kernel as Scott Hart used to suspect (don't know what he thinks now!). As you know, Samsung did not provide an honest release of the source for the Infuse.
Sorry I couldn't be of more help!
Click to expand...
Click to collapse
Thank you for your updates,
Now Scott made a lot of improvement and fixed all most all the bugs for the kernel we are using in infuse 4g,
the only 720p recording and HDMi are not resolved yet, and i guess its not possible due to samasung not provided the source.
Thanks for your efforts on infuse.

[Q] ICS 3Dvideo mods

Using a pc program "mediainfo" I noticed the 3D video encoding has changed from the codec used in gingerbread. The codec is now listed as iso which is common enough, but the codec also uses "frame tripling". The frame rate is 30fps so are we getting a 30fps with 3 frames making 1, effectively 90fps or 10fps with 3 frames duplicated to "make" 30fps.
The new 3D files cause windows explorer to continually try to analyse the mp4 files and will not automatically unmount the sd card as it is continually trying to recognize the file. The same problem also when the 3D videos are transferred to PC and the folder is viewed in explorer, cannot even re-name them with a different extension to stop the lock-ups.

Sorry to say, but 90 fps is not even true. The S3D hardware is limited to only TWO images, so it's basically split-image, either 30fps or 60fps, both left and right images. If you try 90fps, you will have image ghosting which the transparent ceramic plate is timed wrongly against video frames or worse - you will see flashing or wavy patterns which will cause you the headache. And, LCD is normally locked at 60 hertzs, as is the case with non-3D LCDs.
EDIT: The file is basically a MP4 file - with some capable media players, probably like VLC player, it will display two "squeezed" images as seen by two cameras on the 3D phone.
Sent from my LG-P920 using xda premium

I didn't have a problem moving or viewing the 3D files created in gingerbread. It seems the new codec used by ICS is causing windows problems as the codec is not recognized, windows just keeps trying to update the thumnails on the sd card when connected via usb or when removed and in a sd card reader.
Just wondered if anyone has found a way round this problem.
The "frame tripling" that is reported in the pc program {mediainfo} is a part of the codec description and cannot seem to find any mention of it in this forum.

Interesting... I have a modified ICS version of 3D camera, modified for CM10 - will try this. BTW, I don't like using thumbnail feature on Windows - nothing but a PITA.
Sent from my LG-P920 using xda premium

Hmmm. I have Nvidia 3d vision and drivers on my pc and I can watch video directly over hdmi and copy them, etc. Maybe you need the Nvidia drivers???

Or updated Catalyst for AMD Radeon HD 4k or later. I have Radeon 4670, BTW. It's still a great general-purpose video card.
However, I don't have a 3D monitor. Definitely outside of my budget.
Sent from my LG-P920 using xda premium

The "lockup" of file monitoring in widows7 for this new codec is not my main concern,annoying as it may be. I am worried about the mediainfo report of the frame mode is "frame tripling". my own research has been that 3D capture on a 3D camera by panasonic or philips or someone ACTUALLY records at 10fps and each frame is then repeated 3 times to give a 30fps video file This would give a poor motion quality video. I need to confirm that ALL o3D ICS updates have the same frame tripling video recording, as I have some "issues" with my upgrade in other software since upgrading to ICS .If the video recorded by the ICS upgrade is in fact 10fps and multiplied x3 then it is a novelty and not really persuing 3D by upgrading PC or TV to view real 3D.
Thanks for your reply's so far.

Still interesting, however. 10 fps seems slow but here, the first ever stereoscopic 3D camcorders have slower in-order processors, BTW - not as advanced as what's in our phones. So, in reality 90 fps is actually viewable as 30 fps when the 3D LCD timing is factored here.
Sent from my LG-P920 using xda premium

Sorry but don't understand the explanation or translation into english,

keith210350 said:
The "lockup" of file monitoring in widows7 for this new codec is not my main concern,annoying as it may be. I am worried about the mediainfo report of the frame mode is "frame tripling". my own research has been that 3D capture on a 3D camera by panasonic or philips or someone ACTUALLY records at 10fps and each frame is then repeated 3 times to give a 30fps video file This would give a poor motion quality video. I need to confirm that ALL o3D ICS updates have the same frame tripling video recording, as I have some "issues" with my upgrade in other software since upgrading to ICS .If the video recorded by the ICS upgrade is in fact 10fps and multiplied x3 then it is a novelty and not really persuing 3D by upgrading PC or TV to view real 3D.
Thanks for your reply's so far.
Click to expand...
Click to collapse
Indeed "TriDef Media Player" installed with my LG3D monitor can't play 3D movies from ICS but 2D is able to play.
"Stereo Movie Player" http://stereo.jpn.org/eng/index.html can't play 3D from ICS too.
Only "Stereoscopic Player" http://www.3dtv.at/Index_en.aspx can play that video.

Nvidia 3D Vision drivers work for me, but if you have an AMD GPU it may be different.

OK, works very well for me too.
After I uninstalled ffdshow

HTC OneM8 compatibility after latest update, H/W+ and H/W framerate issues, S/W OK

Hi,
I am not well acquainted with the forum's best way to report that kind of thing, so please excuse me if i am not doing it properly.
HTC dispatched earlier this week an update in my region for the stock HTC One M8 (europe).
I do not know what it was before, but now it is under android 4.4.3 and Sense 6.0 (2.22.401.5, kernel 3.4.0-ge224610)
I am using MX Player Pro 1.7.31 (activated, of course), and i don't believe it has updated at the same time as the HTC one.
Before the update, H/W+ and H/W was working very fine with my collection of videos (of various container types and encodings), be it high bitrate full HD 24fps (for broadcast ballet) or low bit rate more "standard" resolutions. It had a "hold" (were a frame is kept too much, creating a choppiness) every now and then (less than one per couple of minutes) but it was very subtle and not intrusive.
After the update, H/W+ and H/W are unusable for ballet, the hold is very noticeable and much more frequent (up to every other second sometimes), in fact it sometimes looks like the framerate is globally reduced as well, independently of framerate and resolution, every video has the fluidity issue even the ones that were playing flawlessly on my old legend.
My playback conditions are in the same conditions always, i use airplane mode, and it has been observed on the course of several days, with various uptimes (same after a fresh long OFF-ON or a 1 day uptime).
The system load oscillates between 8 and 20% before starting mxplayer (with the monitor using a good share of it )
S/W is much smoother, without hiccups.
Log files show no error message during playback... it is just choppy. Just for info i attached a report (i didn't play long runs this time around).
So, fellow HTC users, if it is not limited to my very phone (i'd be surprised), it's time to move on to S/W decoding for the time being, works very well with the platform... I hope it won't tax too much the battery when i am in a train.

Hmm, I'm interested to hear what's wrong as well. @bleu8888 please take a look!

BarfHappy said:
Hi,
I am not well acquainted with the forum's best way to report that kind of thing, so please excuse me if i am not doing it properly.
HTC dispatched earlier this week an update in my region for the stock HTC One M8 (europe).
I do not know what it was before, but now it is under android 4.4.3 and Sense 6.0 (2.22.401.5, kernel 3.4.0-ge224610)
I am using MX Player Pro 1.7.31 (activated, of course), and i don't believe it has updated at the same time as the HTC one.
Before the update, H/W+ and H/W was working very fine with my collection of videos (of various container types and encodings), be it high bitrate full HD 24fps (for broadcast ballet) or low bit rate more "standard" resolutions. It had a "hold" (were a frame is kept too much, creating a choppiness) every now and then (less than one per couple of minutes) but it was very subtle and not intrusive.
After the update, H/W+ and H/W are unusable for ballet, the hold is very noticeable and much more frequent (up to every other second sometimes), in fact it sometimes looks like the framerate is globally reduced as well, independently of framerate and resolution, every video has the fluidity issue even the ones that were playing flawlessly on my old legend.
My playback conditions are in the same conditions always, i use airplane mode, and it has been observed on the course of several days, with various uptimes (same after a fresh long OFF-ON or a 1 day uptime).
The system load oscillates between 8 and 20% before starting mxplayer (with the monitor using a good share of it )
S/W is much smoother, without hiccups.
Log files show no error message during playback... it is just choppy. Just for info i attached a report (i didn't play long runs this time around).
So, fellow HTC users, if it is not limited to my very phone (i'd be surprised), it's time to move on to S/W decoding for the time being, works very well with the platform... I hope it won't tax too much the battery when i am in a train.
Click to expand...
Click to collapse
If both hw and hw+ decoder have same problem, it is highly alike a firmware problem.
I will take a look at my HTC One.

BarfHappy said:
Hi,
I am not well acquainted with the forum's best way to report that kind of thing, so please excuse me if i am not doing it properly.
HTC dispatched earlier this week an update in my region for the stock HTC One M8 (europe).
I do not know what it was before, but now it is under android 4.4.3 and Sense 6.0 (2.22.401.5, kernel 3.4.0-ge224610)
I am using MX Player Pro 1.7.31 (activated, of course), and i don't believe it has updated at the same time as the HTC one.
Before the update, H/W+ and H/W was working very fine with my collection of videos (of various container types and encodings), be it high bitrate full HD 24fps (for broadcast ballet) or low bit rate more "standard" resolutions. It had a "hold" (were a frame is kept too much, creating a choppiness) every now and then (less than one per couple of minutes) but it was very subtle and not intrusive.
After the update, H/W+ and H/W are unusable for ballet, the hold is very noticeable and much more frequent (up to every other second sometimes), in fact it sometimes looks like the framerate is globally reduced as well, independently of framerate and resolution, every video has the fluidity issue even the ones that were playing flawlessly on my old legend.
My playback conditions are in the same conditions always, i use airplane mode, and it has been observed on the course of several days, with various uptimes (same after a fresh long OFF-ON or a 1 day uptime).
The system load oscillates between 8 and 20% before starting mxplayer (with the monitor using a good share of it )
S/W is much smoother, without hiccups.
Log files show no error message during playback... it is just choppy. Just for info i attached a report (i didn't play long runs this time around).
So, fellow HTC users, if it is not limited to my very phone (i'd be surprised), it's time to move on to S/W decoding for the time being, works very well with the platform... I hope it won't tax too much the battery when i am in a train.
Click to expand...
Click to collapse
Hi,
Would you send me a sample video clip having this issue? My HTC One m7 is also recently upgraded to 4.4.3 but cannot reproduce this issue with full HD videos. This issue may happen only on m8.
Thanks

High quality video has constant slowdowns

Hi Folks,
I got an mxiii 4k / k200c / 2g / 8g / arm-A9 / mali-450MP box that works rather well for moving around the box (very speedy) and works perfectly for streaming 1080p content over LAN with Kodi but for some reason, some apps struggle with high quality video. It's most apparent with the DirecTV app but it also happens with Youtube (although much less). It starts playback, works fine but then the video starts slowing down as if the CPU or GPU were overwhelmed. This condition lasts for 3-5 seconds and then it goes back to normal until it happens again a few seconds later. It can also manifest itself as lost frames with random skips.
Anything I can do to improve the performance?
Thanks

Sounds to me like a caching problem, but perhaps it's the codec

rhtizzy said:
Sounds to me like a caching problem, but perhaps it's the codec
Click to expand...
Click to collapse
Might be, it doesn't appear to happen with all videos. Any way to overclock de GPU, see if that helps?

I believe so, there are a number of apps in the playstore I once used but you'll have to search if they still exist, look for sysinfo apps
Sent from my Nexus 7 using Tapatalk