Database Info

[SOLVED] Video performance issues

Am I being unrealistic in my expectations WRT playback of video on the Transformer? (NB After some of the replies below, I've added this comment to emphasise my point - I am NOT talking about high-def video here [e.g. 720p], just normal PAL or NTSC video taken from standard DVDs.)
I've ripped some DVDs using Handbrake on my Mac, using the default High Profile settings. The resulting h.264 files play smoothly and nicely on the Mac.
However, on the Transformer, the playback is juddery.
These are standard-resolution DVD rips, from TV shows and movies.
I wouldn't have been surprised for HD content to be a bit dodgy, but I was surprised not to be able to play SD content smoothly.
Has anyone else got good video playback (i.e. do I have a dodgy tablet) or is the Transformer with its Tegra 2 really not up to playing full-screen SD video?

Don't use high profile. Search before you post - there is many threads about video issues of Tegra2 devices here and in Xoom forum.

Why do people keep doing this, you have a Google tablet, Google this.
The Tegra 2 has a strange limitation, it doesn't play high profile. Before you make the mistake everyone else does, high profile is not a measure of quality, its the measure of compression. The bit rate is the quality.
Put it on high profile go to advanced, turn off 8x8 transform and Weighted P Frames and Subpixel ME to 6, use MP4.
Don't bother with other peoples presets, just use Moboplayer and you will be good with this setup.

Thanks
OK, thanks to you both for sorting me out with this. I did (contrary to appearances) try to find a thread on this topic but failed. Clearly I must brush up on my searching skills.

What about YouTube playback? Even this works terrible on my transformer. It keeps droping how of frames with latest firmware update.
Sent from my Transformer TF101 using Tapatalk

ivan.volosyuk said:
What about YouTube playback? Even this works terrible on my transformer. It keeps droping how of frames with latest firmware update.
Sent from my Transformer TF101 using Tapatalk
Click to expand...
Click to collapse
there will be an update for this, also the browser player works fine for me.

Settings that work
OK. After some testing with the first chapter of the Matrix DVD (because I have it to hand and it's got some nice pans and action to check the juddering against), I have found that the following settings in Handbrake give me acceptable performance on my Transformer with the h.264 codec. This is standard-definition video, please note, NOT high-def.
Note that sorting this out is far from as simple as "Google it" because there are a great many mutually contradictory sets of advice out there!
I took the Normal profile, then went to the Advanced tab and disabled CABAC and set the max B frames to 0.
This was the least dramatic setting that gave smooth playback on my Transformer. So I guess I should repeat my original question - given that my tablet appears to require much lower video settings than generally advised AFAICS in order to get smooth video playback (it's hard to measure this but this is my preception), should I worry? Or is this pretty much what everyone finds with the Transformer?
(The easiest way to get smooth video seems to be just to switch to the MPEG-4 codec and to increase the quality to about 3 to compensate. However, this gives files that are 40-50% larger, so I wanted to avoid that if possible.)

I usually use Handbrake for everything but I was in a hurry so I tried Freemake Video Converter. I converted a few downloaded x264 MMA videos. It has built in settings for Android. I was surprised how well it looked.
I'll still probably go back to Handbrake as soon as I have time to setup and test various suggested settings listed here and some other forums.

FtL1776 said:
Why do people keep doing this, you have a Google tablet, Google this.
The Tegra 2 has a strange limitation, it doesn't play high profile. Before you make the mistake everyone else does, high profile is not a measure of quality, its the measure of compression. The bit rate is the quality.
Put it on high profile go to advanced, turn off 8x8 transform and Weighted P Frames and Subpixel ME to 6, use MP4.
Don't bother with other peoples presets, just use Moboplayer and you will be good with this setup.
Click to expand...
Click to collapse
Thanks for the info.
Are you using handbrake? If so, are you using constant quality, bitrate or target size for your encode?

The Tegra 2 supports 720p High Profile Hardware Decoding, but Honeycomb can't utilize it yet. 3.1 or something later should address this.

frosty5689 said:
The Tegra 2 supports 720p High Profile Hardware Decoding, but Honeycomb can't utilize it yet. 3.1 or something later should address this.
Click to expand...
Click to collapse
Link please?

NOT about high-def content
Can I reiterate that my query is NOT about high-def content (e.g. 720p)? I'm talking here about being able to view simple SD content from a DVD I've bought, without juddering.
Can other folks view standard DVD rips on their Transformers using standard Handbrake settings, with no juddering during whole-screen update sections (e.g. pans or action sequences)?

I just used Adobe Media Encoder CS5 (part of the Creative Suite) to encode a file and it played flawlessly on my xformer. I used the Apple TV Preset as a base then modified the profile from main to baseline.
Sent from my Transformer TF101 using XDA Premium App

cd419 said:
I used the Apple TV Preset as a base then modified the profile from main to baseline.
Click to expand...
Click to collapse
Could you share which modifications you made? As I don't have access to CS5, I'd need to reproduce the settings on my software.
Thanks!

there's a handbrake profile for video encoding for the transformer. search for it.

seshmaru:
Unless you know something is there then you don't know to search for it. Now I know, I have searched and found that what I posted above is basically the situation - no B frames, no CABAC.
That being said, all the discussion I have seen has been based on 720p content rather than standard def so it's not clear to a newcomer to video issues that tthe same restrictions necessarily apply.
Anyhow, that seems to be the answer so thanks to all for the help.

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][Resolved] MX player and HEVC/H265 codec

when this app will support a 4K videos?
thanks:laugh:

The app can already play 4K video and HEVC. MX Player uses ffmpeg as a base decoder, so whatever ffmpeg can play, MX can play. Of course, 4K and HEVC support isn't optimal by anyone right now, so don't expect stellar results.

Expect hardware-decode of HEVC/X265
CDB-Man said:
The app can already play 4K video and HEVC. MX Player uses ffmpeg as a base decoder, so whatever ffmpeg can play, MX can play. Of course, 4K and HEVC support isn't optimal by anyone right now, so don't expect stellar results.
Click to expand...
Click to collapse
When I play a 1080p vedio of HEVC/X265 movie with mxplayer 1.7.32, the player just only can play it using software decode, and the playing is very slowly.
I try to enable hw/+ mode but it failed to play.
So, expect that hard-decode can implement quickly~~~~

Hardware and/or hardware+ decode is not possible until manufacturers make chipsets that support HEVC. Those won't come for at least another year.
You can find a planned production timetable by Qualcomm here: http://forum.xda-developers.com/showpost.php?p=57336946&postcount=119

Well, I have Qualcomm 801 that should support HEVC decoding (at 1080p), but it doesn't work. MX can't use HW(+) on HEVC videos, and it's not even in the list that I can get using Android API (MediaCodecList).
It seems that even if you have chipset with HEVC support you still may need to wait for manufacturer to get it supported. So player developers can't do anything about it.

Indeed, thank you vivan for the clarification!

Learned how to solve the slow film problem
you can solve the slow playing problem by going to this address on your phone : settings-developer settings - advanced settings - Enable OpenGL traces - systrace (graphics)
and its done , and your welcome

Leo_tm said:
you can solve the slow playing problem by going to this address on your phone : settings-developer settings - advanced settings - Enable OpenGL traces - systrace (graphics)
and its done , and your welcome
Click to expand...
Click to collapse
I tried this, but it made no difference. The video playback is still slow, and periodically the sound stops playing for a few seconds while the video catches up.

Mistake
RashaMatt said:
I tried this, but it made no difference. The video playback is still slow, and periodically the sound stops playing for a few seconds while the video catches up.
Click to expand...
Click to collapse
Yeah you're right it wasn't it
but i think it's supposed to be like this , i mean if you pay attention movies go slow when it's not that important , like when a conversation is going on it's good and when it ends and it shows for example "a house from a distance" it goes slow , you know what I meann ?!!!

Leo_tm said:
you can solve the slow playing problem by going to this address on your phone : settings-developer settings - advanced settings - Enable OpenGL traces - systrace (graphics)
and its done , and your welcome
Click to expand...
Click to collapse
Dumping or enabled trace, live log etc will slow down system. You must know what you are saying man!

warvevo said:
Dumping or enabled trace, live log etc will slow down system. You must know what you are saying man!
Click to expand...
Click to collapse
I just learned , thank you for telling me .

changed settings my Elephone P8000
phone : settings-developer settings - advanced settings - Enable OpenGL traces - systrace (graphics)
HEVC
now much smoother, but still slows

thank you very much

I found setting the number of cores to use (in MX player's settings) to match the number of cores in my device processor worked. Video was very jumpy and audio/video sync failed before, now 265 plays perfect. (Samsung Galaxy Tab S 8)

jlparsons2 said:
I found setting the number of cores to use (in MX player's settings) to match the number of cores in my device processor worked. Video was very jumpy and audio/video sync failed before, now 265 plays perfect. (Samsung Galaxy Tab S 8)
Click to expand...
Click to collapse
perfect... I change the number of core to use, so it finally work with H265 HVEC codec

If didnt work, try in MX player play with settings there, for example what works for me (lenovo tab yoga 3 pro) was: limit CPU core to 8, YUV colours, and use tricks for faster play -> any one from these not set = video playback fail, all of them = absolute superb (even in battery saving mode); so keep trying, the hope is there

I tried everything above mentioned. I have OnePlus 2 and a custom RR 6.0 ROM, version of Android is 8.1. HEVC (×265) lag in mxplayer or any other player in my phone. So please someone give me solution for this. My phone has a SD 810 and SD 810 support HEVC but mxplayer doesn't use HW or HW+ at all it only use SW. So any developer develop any app that use HW to play ×265 or just they use software decoder for that.

patelDarshan said:
I tried everything above mentioned. I have OnePlus 2 and a custom RR 6.0 ROM, version of Android is 8.1. HEVC (×265) lag in mxplayer or any other player in my phone. So please someone give me solution for this. My phone has a SD 810 and SD 810 support HEVC but mxplayer doesn't use HW or HW+ at all it only use SW. So any developer develop any app that use HW to play ×265 or just they use software decoder for that.
Click to expand...
Click to collapse
Please collect a bug report from the help menu right after playing the file that has issues & share with us here. It may help us to understand the issue better.

Thirumalai.K said:
Please collect a bug report from the help menu right after playing the file that has issues & share with us here. It may help us to understand the issue better.
Click to expand...
Click to collapse
I want to attach a zip file of bug report but it shows bad request, I tried with separate file too. But it shows bad request. What should I do?
I can't share drive link too.

patelDarshan said:
I want to attach a zip file of bug report but it shows bad request, I tried with separate file too. But it shows bad request. What should I do?
I can't share drive link too.
Click to expand...
Click to collapse
Looks it's due to the post count limitations. But, you can still share the drive link by simply masking to prevent the URL detection.
eg: use h**p://www.google.com instead of http://www.google.com

[Bug Report] Wrong colormatrix (BT.601) on HD videos

Theory:
Wiki -> YCbCr
Video is stored in yuv colorspace, and since displays are RGB you need to convert that yuv data into RGB. Colormatrix is a set of coefficients that are used in conversion process. To get correct colors you need to use a right colormatrix - colormatrix that was used to create that yuv data.
There're several standart colormatrixes: BT.601 ("SD"), BT.709 ("HD"), and new BT.2020 ("UHD", who cares about it). They are supposed to be used on corresponding sources (DVD - SD, BD - HD).
Border between SD and HD is not well defined, but "horizontal resolution <= 1024" is a common rule for defining SD (1024x576 is 16:9 PAL, while 1280x720 is a common HD resolution).
Ignoring the existence of colormatrixes (hardcoded BT.601) is a common problem of a lot of video-related software.
Issue: MX Player seems to be using BT.601 colormatrix for RGB conversion all the time, even on HD videos, which results in wrong colors.
Pics:
10-bit 720p:
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/noir/mvr.png (how it supposed to be, for reference)
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/noir/mvr_601.png (forced BT.601)
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/noir/sw_16.png (sw 16-bit)
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/noir/sw_32.png (sw 32-bit)
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/noir/sw_sp_32.png (sw 32-bit with speed-up tricks)
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/noir/sw_yuv.png (sw yuv)
8-bit 1080p:
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/tc/mvr.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/tc/mvr_601.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/tc/hw.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/tc/hw+.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/tc/sw_16.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/tc/sw_32.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/tc/sw_yuv.png
file
8-bit 720p (with matrix defined in stream):
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/rave/mvr.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/rave/mvr_601.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/rave/hw.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/rave/hw+.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/rave/sw_32.png
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/rave/sw_yuv.png
file
(not related to MX Player, I was just checking settings and was amused by how terrible "professionals" ideas of "improving" video are)
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/rave/xreality.png (X-reality)
https://dl.dropboxusercontent.com/u/16254258/android/mx/matrix/rave/super_vivid.png (Super-vivid)

Hmm, @bleu8888 should definitely take a look at this. I don't know enough about colourspaces to comment.
While we are at it, this tangentially relates to the filters request: http://forum.xda-developers.com/apps/mx-player/feature-request-debanding-filter-t2939323

CDB-Man said:
While we are at it, this tangentially relates to the filters request
Click to expand...
Click to collapse
While it's possible to fix this with filters, it's better to fix conversion code itself - since double conversion leads to banding (and extra processing time).

Indeed. I just brought it up as they are marginally related issues that bleu might want to look at together.

Question on UHD Video Recording Limitations

Hi All from Toronto, Canada!
I hope this is the right place to ask this. My question is as follows:
I have an Honor Note 8 with the Kirin 955 and the Mali T880. The camera on this phone is the Sony IMX278 RGBW sensor, which isn't the best as I hear, but is able to record 4k/UHD video.
From what I can gather, the Kirin 955 doesn't support hardware level UHD video encoding (only DECODING), and any phone with this SoC isn't able to record 4k/UHD video.
Would it be possible (albeit a lot of work) to record 4k/UHD video and either encode it at a software level (i gather this would be really slow), or even by using the GPU instead of the CPU to encode it? From what I can gather, the GPU is much more efficient as processing graphics and 2D video shouldn't be a problem at all for it. It seems like a solution to this would allow any user with this hardware configuration to be able to enjoy their phone cameras a lot more.
I know 4k/UHD video isn't really widespread yet, but I do have the necessary components at home including a 4k TV to be able to enjoy this resolution, so I am looking for a solution to this. Is it as simple as modifying the media_profiles.xml file and installing a different camera app?
I don't know a lot about android development, but I am making it a point to learn as much as I can, and I have put quite a lot of research into this idea before posting here, including searching on XDA. I work in Software Application Support for a small CRM, and I have years of experience doing mods and customization on android devices, so I am familiar with the landscape here and I should at least be able to understand any answer no matter how technical.
Thank you for your help!

jdantow said:
Hi All from Toronto, Canada!
I hope this is the right place to ask this. My question is as follows:
I have an Honor Note 8 with the Kirin 955 and the Mali T880. The camera on this phone is the Sony IMX278 RGBW sensor, which isn't the best as I hear, but is able to record 4k/UHD video.
From what I can gather, the Kirin 955 doesn't support hardware level UHD video encoding (only DECODING), and any phone with this SoC isn't able to record 4k/UHD video.
Would it be possible (albeit a lot of work) to record 4k/UHD video and either encode it at a software level (i gather this would be really slow), or even by using the GPU instead of the CPU to encode it? From what I can gather, the GPU is much more efficient as processing graphics and 2D video shouldn't be a problem at all for it. It seems like a solution to this would allow any user with this hardware configuration to be able to enjoy their phone cameras a lot more.
I know 4k/UHD video isn't really widespread yet, but I do have the necessary components at home including a 4k TV to be able to enjoy this resolution, so I am looking for a solution to this. Is it as simple as modifying the media_profiles.xml file and installing a different camera app?
I don't know a lot about android development, but I am making it a point to learn as much as I can, and I have put quite a lot of research into this idea before posting here, including searching on XDA. I work in Software Application Support for a small CRM, and I have years of experience doing mods and customization on android devices, so I am familiar with the landscape here and I should at least be able to understand any answer no matter how technical.
Thank you for your help!
Click to expand...
Click to collapse
I don't know much about Kirin SOC but with say QCOM to be able to encode via software using say FFMPEG the ISP would have to return preview frame with UHD Dimensions.
Its probably Capable of Encoding 4K maybe can check if it can be modded by understanding how everything works .
1st Check in /system/vendor/lib /system/lib/ lib64 for any file containing the word camera zip them attach them to your post
2nd download freedcam from play store in the menu scroll down and save camera parameters attach the file outputted to /DCIM/FreeDCam
Sent from my NX503A using XDA Free mobile app