Database Develop

Coreplayer 1.2.5 - QTV compliant again on TytnII

Good news from CoreCodec and just confirmed. Their optimization for TytnII video support through QTV encoding is up and running again.
Quality wise, it still plays better than the temp solutions as RawFrameBuffer , GDI etc.
Sadly, this is the last 1.2 version they will deliver as they look into a 1.3 version (Iphone you know )
Yes, I did a search and No, I did not find this information to share yet

OMG this has been posted a million times before!
Haha only joking, good find mate. Going to have to get hold of this app .

No more black screen, but playback is still very choppy compared to 6.0, and the earlier 6.1 builds. On a 6.0 based rom videos playback at a smooth 30fps, on QTV, high quality, with smoothing turned on. I get about 22fps on the official 6.1 rom, and Diamond V4.
I'd guess that it's becuase HTC is using the QTV to boost DirectDraw performance and speed up the entire system.

I just posted in another thread but we just released v1.2.5 with a QTv fix for WM 6.1.... Not sure what the issue is with the Diamond though but we'll track it.
See: http://www.corecodec.com/forums/index.php?topic=1071.0

beta_boy said:
I just posted in another thread but we just released v1.2.5 with a QTv fix for WM 6.1.... Not sure what the issue is with the Diamond though but we'll track it.
See: http://www.corecodec.com/forums/index.php?topic=1071.0
Click to expand...
Click to collapse
The Diamond seemingly has proper driver functionality, perhaps you just need to tap in to that functionality instead of going the QTv way around it?
(Not that I have any idea what I'm talking about )

BTW performance for me is good and even though DirectDraw performance is way up on the 6.1 ROMs it suffers from lack of Vsync, QTv does not so even if performance seems to have taken a toll lately it's still better than DirectDraw at least.
EDIT: nope, sorry, no vsync... my bad
I get 85 % speed on my usual test file (24 fps NTSC 640x352 with MP3 128 kbps CBR).
With WM6 and older CorePlayer revision I used to get slightly over 100 % with the same file and not nearly the same amount of tearing.

undac said:
BTW performance for me is good and even though DirectDraw performance is way up on the 6.1 ROMs it suffers from lack of Vsync, QTv does not so even if performance seems to have taken a toll lately it's still better than DirectDraw at least.
EDIT: nope, sorry, no vsync... my bad
I get 85 % speed on my usual test file (24 fps NTSC 640x352 with MP3 128 kbps CBR).
With WM6 and older CorePlayer revision I used to get slightly over 100 % with the same file and not nearly the same amount of tearing.
Click to expand...
Click to collapse
Slightly interesting find.
I'm getting virtually identical benchmarks using QTV and RawFrameBuffer on HQ, on my test file.

Did some more testing on a small clip:
Raw Framebuffer: 75,4 %
QTv: 74,5 %
GDI: 71,1 %
DirectDraw: 62 %
I also did some additional tests running a file in "windowed" mode and checking the performance with Media properties in the File menu.
Pretty interesting results in comparison to the ones above:
QTv: 88,9 %
Raw Framebuffer: 88,3 %
GDI: 83,3 %
DirectDraw: 54,2 %
Here's some image quality assesements too:
GDI: Somewhere in between Raw Framebuffer and QTv regarding sharpness and colors. (Slight hint of vsync issues. Slight hints of random stuttering. Slight artifacting.)
QTv: Great color reproduction and detail, suffers greatly from lack of vsync.
Raw Framebuffer: Suffers greatly from lack of vsync. (Slightly less color fidelity than QTv, not quite as sharp either.)
DirectDraw: Heavy posterization issues, soft/blurred image and slight artifacting. No vsync issues whatsoever.
Comments within parenthesis are to be regarded as very mild deviations from the other modes.
The tests were done on the official TyTN II Windows Mobile 6.1 ROM (Swedish) 3.29 (no tweaks applied) using CorePlayer 1.2.5 at stock settings. (No other active applications.)
The test file was a 640x352 XviD file running at 24 fps with a variable video bitrate of ~1,2 mbps with 128 kbps CBR MP3 audio.
Judging by these tests I think I'll just stick with GDI for now. Apparently something is screwed up with QTv in the newer ROMs and/or CorePlayer revisions and the vsync issues with raw ramebuffer and Qtv are too annoying to ignore when playing files in full screen.
@beta_boy: is the lack of vsync in Raw Framebuffer and QTv modes something that you can fix? (I imagine you can't do much about it in raw framebuffer mode?) And do you think you can do something to restore the speed of QTv that we experience in older ROMs?

undac said:
Did some more testing on a small clip:
Raw Framebuffer: 75,4 %
QTv: 74,5 %
GDI: 71,1 %
DirectDraw: 62 %
I also did some additional tests running a file in "windowed" mode and checking the performance with Media properties in the File menu.
Pretty interesting results in comparison to the ones above:
QTv: 88,9 %
Raw Framebuffer: 88,3 %
GDI: 83,3 %
DirectDraw: 54,2 %
Here's some image quality assesements too:
GDI: Somewhere in between Raw Framebuffer and QTv regarding sharpness and colors. (Slight hint of vsync issues. Slight hints of random stuttering. Slight artifacting.)
QTv: Great color reproduction and detail, suffers greatly from lack of vsync.
Raw Framebuffer: Suffers greatly from lack of vsync. (Slightly less color fidelity than QTv, not quite as sharp either.)
DirectDraw: Heavy posterization issues, soft/blurred image and slight artifacting. No vsync issues whatsoever.
Comments within parenthesis are to be regarded as very mild deviations from the other modes.
The tests were done on the official TyTN II Windows Mobile 6.1 ROM (Swedish) 3.29 (no tweaks applied) using CorePlayer 1.2.5 at stock settings. (No other active applications.)
The test file was a 640x352 XviD file running at 24 fps with a variable video bitrate of ~1,2 mbps with 128 kbps CBR MP3 audio.
Judging by these tests I think I'll just stick with GDI for now. Apparently something is screwed up with QTv in the newer ROMs and/or CorePlayer revisions and the vsync issues with raw ramebuffer and Qtv are too annoying to ignore when playing files in full screen.
@beta_boy: is the lack of vsync in Raw Framebuffer and QTv modes something that you can fix? (I imagine you can't do much about it in raw framebuffer mode?) And do you think you can do something to restore the speed of QTv that we experience in older ROMs?
Click to expand...
Click to collapse
My guess would be that HTC implemented QTV in the rom as a way to provide a general performance boost without providing real drivers, so when you're using RawFrameBuffer, you're utilizing their implementation instead of the CorePlayer one.

shocco said:
My guess would be that HTC implemented QTV in the rom as a way to provide a general performance boost without providing real drivers, so when you're using RawFrameBuffer, you're utilizing their implementation instead of the CorePlayer one.
Click to expand...
Click to collapse
From what I know Raw Framebuffer is pretty low level and would avoid any such manuevers.
The name basically implies what it does: it dumps raw images to the frame buffer without going through the regular APIs or system memory etc.
(Not that I'm 100 % sure about this, it's just what I've gathered by the terminology of the setting.)

undac said:
From what I know Raw Framebuffer is pretty low level and would avoid any such manuevers.
The name basically implies what it does: it dumps raw images to the frame buffer without going through the regular APIs or system memory etc.
(Not that I'm 100 % sure about this, it's just what I've gathered by the terminology of the setting.)
Click to expand...
Click to collapse
Ehhh, wouldn't any QTV implementation be relatively low level, since what you're doing is accessing a hardware overlay?

shocco said:
Ehhh, wouldn't any QTV implementation be relatively low level, since what you're doing is accessing a hardware overlay?
Click to expand...
Click to collapse
Doh.. I realize the error in my assumption. I just figured a raw framebuffer mode would be accessing a primary surface rather than an overlay surface. I guess it could be any of the two though.

shocco said:
No more black screen, but playback is still very choppy compared to 6.0, and the earlier 6.1 builds. .
Click to expand...
Click to collapse
Sadly enough, I have to agree
Not "very choppy" but my SPBMobileDVD converted movies played better on a 1.2.4 release on a 6.0 or early build 6.1 WM.

For me, I got better result from DirectDraw (190%) over Qtv (180%) on one of my 4 mins clips. Re-test multiple time and still behave the same.

jackleung said:
For me, I got better result from DirectDraw (190%) over Qtv (180%) on one of my 4 mins clips. Re-test multiple time and still behave the same.
Click to expand...
Click to collapse
With smaller clips I also get similair performance.
Though, that's basically useless information since anything beyond 100 % means nothing.
Comparison is only meaningful when we achive less than 100 %.

Bug?
I think I found a bug which will not be solved anymore as this is the last 1.x.x release.
When going to "select page" --> colors, settings for Light, contrast - satuaration can not be opened - accessed. Similar for you all ?

hmmmm, i'm with dutty throys Diamond v1 rom and 1.2.5 and i get 85% boost, but every video is perfectly, perfecly playing. the quality is good, very smooth playback, flv, mov, avi, mpeg, every format plays very well finaly, but in benchmark i get only 85%... hmmm

Preferences...
Hello, could someone post his preferences for his HTC Tytn II (with orig. WM 6.1) here? My Coreplayer 1.25 doesn`t play youtube video- or Audio-streamings...thanks for your help!
Lou

Video Conversion [HELP please]

Hi, I've search many place and unable to find any good guides for video conversion for the Acer liquid(Donut). And the User Manual don't even give full specs.
I've done many conversion of my own, however the video always lag...
~~ Please tell what is the max bitrate, best codec(mp4, h.263, etc), resolution, fps to make a video play hi quality NO frame skip/lag on the Acer Liquid(Donut)~~
Note: I understand the max quality is only as same as the video/clip you've inputed, and that the Acer only support up to 20 frame per section(at least that's what written in the user manual), and I have a good video converter btw, been using it for years...

Shalala
Alrite after playing with the video for a few more day.
I STILL don't get exactly what I wanted...and I notice alots of people viewing this thread, so I'll share what I have at the moment.
~~~Good Enough~~~
Right this moment, my best conversion is...
Video Quality Superb
File Format *.MP4
Video Codec mpeg4
Resolution original as input/ since no TV-out, it is suggest 640x480 up to 720x480.
Framrate Always try to maintain the same or near framerate as the original video clips. To see how many fram per second the original clip is...right click on the video clip and choose properties > Details > Frame Rate.
Aspect Ratio either Auto or 16:9.
Audio Quality 128 kbps
Audio Codec mpeg4aac
Channels 2 Channels Stereo
Sample Rate Varies/44100 Hz
NOTE: I can't be sure if its just my phone in particular, I've only gotten it for a week. I don't wanna think that it is my phone that don't play video perfectly. However, the setting above allow me to play full screen with no frame skips, hi quality, almost everything is perfect with 1 exception.
The frame don't skip but it seem to lagg a "LITTLE BIT"... an example, you won't see black strips or shifting from 1 scene to another, but rather.....crap i can't explain it lolz

Camcorder - Any way to change audio encoder/bitrate?

n00b here. Recording a video with the audio at only 8000 Hz sounds like your camera is in a toilet. Are there any 3rd party camera apps that can do 16000 Hz, or maybe a hack for the default app?
I can successfully change bitrate and resolution for video encoding in build.prop, but changing any values for the audio just causes the camera app to force close. Failing at that, I looked up the AMRNB codec and found that it doesn't support 16000 Hz at all anyway. My next misguided idea was to change the default codec stuff from this
Code:
ro.media.enc.hprof.codec.aud=amrnb
...
ro.media.enc.hprof.aud.bps=12200
ro.media.enc.hprof.aud.hz=8000
ro.media.enc.hprof.aud.ch=1
to AAC, like it is in the Droid/Milestone
Code:
ro.media.enc.hprof.codec.aud=aac
...
ro.media.enc.hprof.aud.bps=96000
ro.media.enc.hprof.aud.hz=16000
ro.media.enc.hprof.aud.ch=1
I realize they are different phones, but I figured it was worth a shot. Failed again, naturally.
Can anyone shed some light on this? Why did HTC give us DVD resolution video with only telephone quality audio? That's like having an HDTV with only a piezo buzzer for a sound system. I do not understand this decision at all.

+1
I have noticed this as well, but I assumed it was a hardware restriction.
If there can be any light shed on this let us know!

Really good idea. I was thinking of adjusting the frame rate so that it always remained at a constant 24 fps, rather than going down to 9 fps in indoor conditions. Any suggestions?
gsmsosv said:
n00b here. Recording a video with the audio at only 8000 Hz sounds like your camera is in a toilet. Are there any 3rd party camera apps that can do 16000 Hz, or maybe a hack for the default app?
I can successfully change bitrate and resolution for video encoding in build.prop, but changing any values for the audio just causes the camera app to force close. Failing at that, I looked up the AMRNB codec and found that it doesn't support 16000 Hz at all anyway. My next misguided idea was to change the default codec stuff from this
Code:
ro.media.enc.hprof.codec.aud=amrnb
...
ro.media.enc.hprof.aud.bps=12200
ro.media.enc.hprof.aud.hz=8000
ro.media.enc.hprof.aud.ch=1
to AAC, like it is in the Droid/Milestone
Code:
ro.media.enc.hprof.codec.aud=aac
...
ro.media.enc.hprof.aud.bps=96000
ro.media.enc.hprof.aud.hz=16000
ro.media.enc.hprof.aud.ch=1
I realize they are different phones, but I figured it was worth a shot. Failed again, naturally.
Can anyone shed some light on this? Why did HTC give us DVD resolution video with only telephone quality audio? That's like having an HDTV with only a piezo buzzer for a sound system. I do not understand this decision at all.
Click to expand...
Click to collapse

YES!
I agree 100%. Maybe the idea was to create a suitable MMS birate/container solution w/ no regard to ANYONE else... there has to be a way. in fact I'm excited that you were able to at least play w/ the video and adjust bitrate & res. Care to share how to a layman?
AMR sounds like garbage. In addition to the incredibly low samling frequency, the bitrate is ~ 12.5Kbps. I would say that's a cut below telephone SQ.
Can any people in here far smarter than me, tell us if one can hackney a difference audio codec (say mp3?) as AMR seems too limited to work with. Or maybe a 3rd party app... why are there NONE?
this seems to make it seem possible:
http://developer.android.com/reference/android/media/CamcorderProfile.html

I would really love this on my Desire. Currently both video and audio are crap, audio especially. Here's a little demonstration I made, where I went to see which encoding type is better, mpeg4 or H.264:
http://www.youtube.com/watch?v=CgW28VE0eOo

justin.tv app mitigates this for now, as the video uploaded to justin.tv in near realtime is markedly better than the abysmal quality of the native android app, which just goes to show how dysfunctional it really is.
for now, I'll use justin.tv whenever recording videos... it goes to show that many android phones (inc. my hero) are capable of so much more in the hardware, and the limiting factor is crappy software devs and/or requirements.

Question about 1080p Casting...

Whether it's Allcast, Localcast, Castaway, etc. None of these apps can do 1080p without stuttering. Is this a hardware limitation of the chromecast, or my phone?

The Chromecast is capable. As I write this, I am streaming Ender's Game in 1080p from Plex to my Chromecast. I have never had good results with AllCast however, and I'm guessing the case would be similar with other device-local content casting apps. My theory is that most Android devices aren't capable of the throughput necessary to support 1080p streaming locally. When uploading a test video from my Note 2 to my Plex server for testing, the best xfer rate I could get is just under 1MByte/sec, not really enough for 1080p streaming. Once uploaded, playing via Plex worked just fine.

siratfus said:
Whether it's Allcast, Localcast, Castaway, etc. None of these apps can do 1080p without stuttering. Is this a hardware limitation of the chromecast, or my phone?
Click to expand...
Click to collapse
The Chromecast itself is fully capable of 1080p playback. The issues lie in wireless bandwidth and video format (compression and container).
See WiFi Bandwidth and Router considerations and Supported Media for Google Cast

siratfus said:
Whether it's Allcast, Localcast, Castaway, etc. None of these apps can do 1080p without stuttering. Is this a hardware limitation of the chromecast, or my phone?
Click to expand...
Click to collapse
My way to figure out if a video will stream on my network is (this isn't a perfect science mind you, and this is as far as i know)
-Check my wireless connection by my chromecast (72 mbits/s with mine)
-Divide by 8 (that gives you mb/s)
-Check to make sure video source falls within that value
This would give me (in a perfect world) the ability to stream a 9mb/s video source. Don't forget to divide by 2 if the source of your content is wireless as well. In my case I have my netbook direct connected to the router so it's a non issue.
Someone please correct me if i'm wrong

sherdog16 said:
My way to figure out if a video will stream on my network is (this isn't a perfect science mind you, and this is as far as i know)
-Check my wireless connection by my chromecast (72 mbits/s with mine)
-Divide by 8 (that gives you mb/s)
-Check to make sure video source falls within that value
This would give me (in a perfect world) the ability to stream a 9mb/s video source. Don't forget to divide by 2 if the source of your content is wireless as well. In my case I have my netbook direct connected to the router so it's a non issue.
Click to expand...
Click to collapse
Sounds about right.
The only other limiting factors would be
your router's ability to sustain the wireless rate (lower-end routers sometimes only peak at advertised rates)
your device's ability to sustain the required rate
your device storage's ability to sustain the required read rate

Any video whose bitrate is higher than 5000 Kbits/s (that is: most 1080p videos) is likely to stutter due to not enough WiFi bandwidth available or too irregular. WiFi sucks compared to Ethernet.

For some reason I've noticed stuttering only on videos taken with my phone. I cautiously played 720p videos for a time because I thought the issue was that the vid was full hd. Turns out it wasn't as Thor 2 in 1080p played flawlessly for me. It helps to have the fastest speed your provider offers...in my case I have 30mb down which is reduced to around 20mb through my wall. I hope Google Fiber makes it's way to my town eventually.

I use serviio and avia. Don't have any stuttering on 1080p. I did have issues with AllCast and 1080.. but I tend to use AllCast with other software and do not have any issues as long as the video is below 1080.

For what it's worth "1080" isn't always the same "1080". It really comes down to the bitrate of a video. Native 1080p (ripped from a bluray) is something like 30MB/s. My s4 records at something like 15-20 MB/s. If you download a yify torrent that is "1080p" it'll tend to be around 4MB/s. As you can see there is a big difference (these are approximated numbers off the top of my head but you get the point). If you're having a problem with a video i would suggest a run through Handbrake and it'll play fine. My suggested settings are as follows:
High profile
Web optimized checked
Set Denoise under filter settings (more takes longer, I default to weak)
Choose your poison for encode speed and RF quality. (Over night I do very slow and usually a 19 if i'm looking for HD quality and a decent file size)
Under the audio tab make sure you're giving the result an AAC codec audio to work with. (I tend to bump the rate up to 256(
My guess is that this is the reason Google doesn't want to officially support local content. There are a lot of hurdles to jump and all content is not created equal. Someone streams an "HD" video on netflix and then thinks that they should be able to stream ANY "HD" content. Not the case as we're finding out

Speaking of yify (happy retirement), I get no stuttering from any of their mp4's but I do if I use bubble upnp. I don't think it's just limited to video bitrate, though that clearly does have an impact. I think the software used should also be considered as a possible chocking point. As I mentioned earlier, serviio has consistently given me the best results.

Great point. "1080" is just part of the story, "1080p" is a little more, but still not the full story. It's like calling a seamstress and asking them to make you a shirt, but only telling them "I'm male" or "I'm a tall male" - not unhelpful, but still not enough data.
A video file consists of:
Resolution
This is the stored or "captured" resolution, not necessarily the displayed size
Pixel aspect ratio (PAR)
The "shape" each data pixel should be displayed at. The combination of resolution and pixel aspect ratio determines the display aspect ratio (DAR), which is sometimes defined in place of PAR. Unfortunately pixel aspect ratio is not defined the same way in all formats. For MPEG and most containerless formats, it's defined by the CODEC itself. The AVI container does not have a place to store it, so AVIs will play assuming square pixels except Windows Media Player makes some assumptions about certain video frame sizes and tries to compensate (sometimes incorrectly).
Luckily, the HD and UHD resolutions use square pixels so there's less to worry about.
Field Order
Whether samples are full frames (progressive), or fields (interlaced) in upper/top field first (UFF/TFF) or lower/bottom field first (LFF/BFF) order. Sometimes you'll see field order referenced as "odd" or "even" field first, but this is ambiguous as some things label the upper field as field 0 (which would be even) while others label the upper field as field 1 (which would be odd)
Sampling rate
How many samples per second (ie, 50 Hz, 60 Hz)
Higher sampling rate = smoother motion. This is why 24 Hz content that isn't shot specifically for film rate (avoiding fast motion and fast pans/zooms) looks "jumpy" compared to "regular" video.
Bitrate
What the data rate is - usually stated in bits per second (bps), kilobits per second (Kbps) or megabits per second (Mbps)
This is what determines the size of the video portion, regardless of resolution, interlacing and sampling rate.
Bitrate and video quality go hand-in-hand. The more bits you have, the better each video frame will look.
Compression type (CODEC)
What format the video is compressed in, for example, MPEG-1, MPEG-2, MPEG-4, WMV, VP6, DivX, Lagarith, etc.
CODEC and bitrate go hand-in-hand as well. More-complex compression algorithms can provide better quality with a lower number of bits.
Container format
How the video is "wrapped" or packaged. Some formats like MPEG and Windows Media support multiplexing and can be self-contained, so they can exist outside of a container. Other formats usually exist in a QuickTime container (.mov file) or DirectShow/Video for Windows container (.avi file)
Elements from containers can be added and removed without impact to audio/video quality.
Audio compression type
Like video compression, what format the audio is compressed in, if any. Common formats include MPEG-1 Layer 3 (aka "MP3), AAC, Dolby Digital, etc. Audio can also be uncompressed LPCM, often referred to as just PCM.
Audio sampling rate
The number of audio samples per channel, per second - usually in kilohertz (KHz)
Audio sample depth aka bit depth
How large each audio sample is, usually stated in bits (8-bit, 16-bit, etc)
Audio bitrate
What the data rate is - usually stated in bits per second (bps), kilobits per second (Kbps) or megabits per second (Mbps)
This is what determines the size of the audio portion, regardless of channels, sampling rate and sample depth.
Bitrate and audio quality go hand-in-hand. The more bits you have, the closer the audio will sound to the source.
The overall size of the video portion is video bitrate x length of video in seconds
The overall size of the audio portion is audio bitrate x length of video in seconds
Add any additional metadata overhead and additional tracks (subtitles, etc) from the container (if applicable), and you have the total file size.
So "1080p" only says it's a 1920x1080 resolution, and progressive samples. It does not say what the bitrate is or display/sampling rate is.

This will be slightly off topic but worth noting...
sherdog16 said:
For what it's worth "1080" isn't always the same "1080". It really comes down to the bitrate of a video. Native 1080p (ripped from a bluray) is something like 30MB/s.
Click to expand...
Click to collapse
Your post is pretty spot on just wanted to note Full Native 1080P is actually a little more than 1Gb Bitrate over HD-SDI.
Almost no one but the production crew ever gets to see the full resolution, not even the Networks that will broadcast it unless you mail the tapes to them.
Everything else is compressed to hell including BluRay and 40Mb is about as high as you will ever see outside of the Master Tapes. And since most networks have decided NOT to support the HDCAM format in favor of XDCAM or digital storage (which are not much higher than BluRay quality and compressed) It's rare to ever see a full resolution 1080 signal in real life.
All these phones and such who claim to record in 1080P really only save in 1080P. Their CMOS doesn't have the resolution to properly capture 1080P Native at most it is 720 or 480 upconverted to a 1080 resolution file.
As for CCast and Wifi I would never go over 10MB on a source without transcoding. 4-8Mb is the sweet spot for WiFi transmission (IMO).
Unless your used to seeing full resolution 1080 signal your really not going to miss or gain much by going higher than that for your library. You wouldn't see a significant difference till you got up to 40MB which is a little higher than what your original source was. Going Higher than source does not bring back the resolution of the original so there is no point to it.
Most of my Library is encoded at 4-6Mbs in 1080P and I hardly ever have a problem streaming them to any device.

I think that you have a typo Asphyx.
Plenty of phones have CMOS sensors exceeding 2 MP (that's about all a single 1080p frame is), so it's not resolution holding that back, it's a chain of poor response times.

EarlyMon said:
I think that you have a typo Asphyx.
Plenty of phones have CMOS sensors exceeding 2 MP (that's about all a single 1080p frame is), so it's not resolution holding that back, it's a chain of poor response times.
Click to expand...
Click to collapse
Well yes and no...The CMOS may have 2MP (and some have higher than that) but two things are in play there....
1 - Some of those pixels are split between G, R and B so a 6 MP CMOS could be using 4MP for Green and 2MP each for Red and Blue. so a 2MP Camera is probably not really getting full HD. 6MP would be the minimum for full 1080P.The old 4:2;2 standard
But more importantly is:
2 - Most video capture is not using the entire CMOS to capture image due to the 16:9 ratio of HD capture.And thats not so much about the CMOS as it is the lensing system.
In broadcast we use Three 3/4" CCDs or CMOS chips one for each color with a prism to split and send the color to each chip. Each chip is full resolution so we get 4:4:4 and every color is captured at full resolution.
Because of the lensing and focal length, the image reflected on these chips is very large compared to what is reflected on a Phone CMOS so the image is a lot clearer. less fuzz and better pixel resolution. In broadcast we shoot higher than HD as we have an overscan sized signal and we cut out the HD bit we need when recorded.
So yes Phones have the Pixels needed but in most cases they are not in the right place for full HD resolution. And due to the short focal length they rarely ever use the entire chip.

Thanks, I'm very familiar with the RGBG Bayer filter, for those that aren't - http://en.wikipedia.org/wiki/Bayer_filter
As for the 2 MP thing - I didn't mean to imply that a 2 MP sensor would take 1080p vids and no one making a phone claiming 1080p uses such a low MP-count sensor.
Smallest I know of is the HTC One at 4 MP and that's 16:9 all of the time, most everything else is 5, 8, 12 or more MP.
So, on that basis, allowing for the Bayer filter, lower quality without oversampling, and 16:9 masking, I'll maintain that the problem on the top end phones claiming 1080p video isn't resolution - it's response time.
I'm familiar with 3-chip cameras, I used to own a Canon XL-1 (SD obviously), and I'm way too familiar with CMOS and CCDs at the silicon level.
The CMOS mobile sensors are noisy, not terribly sensitive and s.l.o.w. They're price effective but they're just not CCDs.
You can dial in a higher bit rate for many Androids, especially with root options, that's probably the darling camera app mod - but you won't get faster than the sensor response time + readoff time + binning time + processor time of attention (usually an image processor in the main SoC, but sometimes a CPU core) + the frame rate processing algorithm time + compression time + plus whatever else I forgot.
And that's why phone videos stutter. When the system can't keep up, it simply lowers the fps rate.
The new crop is promising higher frame rates. We'll see.
As for frame quality - that's affected by all of the things you mentioned (and let's toss in inaccurate color rendering and plastic lenses for those without an iPhone while we're at it).
1080p can be done, sufficient phone sensors exist in terms of MP, and you can wind up the Mbps - but you can't cure light sensitivity and noise and what most people shoot slows down an already slow subsystem.
Edit - posting this made me think - so I went and checked my video closet - I actually still have a 3CCD Canon GL1 that I completely forgot about. rotflmao - I'll have to dust it off and see what I get.

I agree with you that the speed is a problem as well...
But when push comes to shove at some point phones (and CMOS) will catch up and we won't have to wonder if a particular model is true HD or not.
A recently as a year or two ago HD Record was more of a Marketing pitch than a reality.
Phones (and their camera's) have improved a lot since then and we even have a few Cameras with phone being made where the Camera and lensing is prioritized to get better picture.
It's something I expect us to tell our kids about the good old days when HD cameras in phones weren't really HD! LOL
They won't believe us!

EarlyMon said:
I think that you have a typo Asphyx.
Plenty of phones have CMOS sensors exceeding 2 MP (that's about all a single 1080p frame is), so it's not resolution holding that back, it's a chain of poor response times.
Click to expand...
Click to collapse
EarlyMon, you do have too much knowledge for the human being.
I feel embarrassed.

Not even the Note4 can play a 1080p hi10 video without overheating

Now I'm disappointed, I thought that a 800€ device from 2014 would be able to play such an old format, yet MX Player is not able to play it in HW, and in SW it uses the CPU so hard that the phone overheats and throttles, making the episodes unwatchable.
Really disappointing considering that a 450€ 2011 quadcore laptop can play it with less than 20% CPU use.
Mediainfo:
Code:
General
Unique ID : 210113449615409968501807337670924119963 (0x9E1260E100E888EDA6534B79C5ED2F9B)
Complete name : D:\Video\Anime\Aestetica\[Final8]Hagure Yuusha no Aesthetica - 08 (BD 10-bit 1920x1080 x264 FLAC)[981044CC].mkv
Format : Matroska
Format version : Version 2
File size : 1.13 GiB
Duration : 23mn 42s
Overall bit rate mode : Variable
Overall bit rate : 6 837 Kbps
Encoded date : UTC 2013-02-12 20:02:11
Writing application : mkvmerge v4.9.1 ('Ich will') built on Jul 11 2011 23:53:15
Writing library : libebml v1.2.1 + libmatroska v1.1.1
Attachements : ArnoPro-Caption.otf / cacmoose.ttf / Flat Brush Bold.ttf / Franco Bold Italic.ttf / Franco Bold.ttf / GARABD.TTF / Happy_Hell.ttf / pala.ttf / Village.ttf
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 42s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Writing library : x264 core 122 r2184 5c85e0a
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=12 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=15.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 23mn 42s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Default : Yes
Forced : No
Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Default : Yes
Forced : No
Menu
00:00:00.000 : :Intro
00:00:59.000 : :eek:P
00:02:28.000 : :Part A
00:10:13.000 : :Part B
00:21:40.000 : :ED
00:23:10.000 : :Preview
Let's hope at least the Note5 can.

It's Android problem and how manages media files. If the Note 4 doesn't woks fine for you, the S6/HTC One M8/LG G4/Nexus 6 wouldn't either. If you are waiting to buy a Note 5 just to see 1080p anime videos on it without overheating then happy waiting, pal. Also, you can't compare a laptop which have a cooler, HDD and a dedicated Video Card and CPU with a device with a compact flash drive and a Mali GPU WITHOUT cooling. You should know that...
If you wan't my advice: Downscale your video to 720p. It's anime.. i mean, its cartoon it shouldn't look THAT bad in 720p. I would be rather dissapointed if my Breaking Bad episodies look pixelated in such a good screen.
Cheers.

Use the MKV Amp Player from Play Store. It will play the mkv files fine.
Sent from my SM-N910G

galaxynote2 said:
It's Android problem and how manages media files.
Click to expand...
Click to collapse
Can you provide more information and links about this, please?
galaxynote2 said:
If the Note 4 doesn't woks fine for you, the S6/HTC One M8/LG G4/Nexus 6 wouldn't either.
Click to expand...
Click to collapse
Possible, although I wonder about the S6, since it has that Exynos.
galaxynote2 said:
If you are waiting to buy a Note 5 just to see 1080p anime videos on it without overheating then happy waiting, pal.
Click to expand...
Click to collapse
I'm gonna buy a Note5 because I got a 200€ off it with the Note4 purchase, and because I have an extreme interest in GearVR with the rumored 4k screen, but it would be nice if it could play all the media I can throw at it, yeah.
galaxynote2 said:
Note 5 just to see 1080p anime videos on it without overheating then happy waiting, pal. Also, you can't compare a laptop which have a cooler, HDD and a dedicated Video Card and CPU with a device with a compact flash drive and a Mali GPU WITHOUT cooling. You should know that...
Click to expand...
Click to collapse
Sure I can, when the laptop is 4 years old, costs half the phone and doesn't use even 20% of it's power to play a video.
I'm not expecting the phone to play Crysis 1 at max settings (although some Android games actually get pretty close to that graphic quality), I'm expecting it to play a 1080p video without dying.
galaxynote2 said:
If you wan't my advice: Downscale your video to 720p. It's anime.. i mean, its cartoon it shouldn't look THAT bad in 720p. I would be rather dissapointed if my Breaking Bad episodies look pixelated in such a good screen.
Click to expand...
Click to collapse
Please don't insult anime.
galaxynote2 said:
Cheers.
Click to expand...
Click to collapse
GrippingSphere said:
Use the MKV Amp Player from Play Store. It will play the mkv files fine.
Sent from my SM-N910G
Click to expand...
Click to collapse
Will try, thanks.

I'm not insulting it, I'm just saying that they're cartoon drawings, they doesn't distort that much in 720p.
About your laptop, a 4 years old laptop is much more faster than yoru device. Doesn't matter if you Note have 3 gigs of ram and a Octa-Core cpu, it doesn't have the full performance of a conventional PC. The device and the OS uses a lot of resources to playback a full HD video, while a PC with dedicated video card and CPU could handle it in background without problem.
I'm using the Exynos variant which performs pretty much like the S6 and I don't have any problem. It gets a little hot but it doesn't overheat like you said.
You could even reduce the Bitrate of the video since it's Anime (dont misunderstand me I'm not insulting it). These shows have less movement than a normal recording so if you reduce it a bit you will not see much difference.
Also: Try other video players: MX Player, VLC or MKV Amp as said before are the best for watching long videos.

elevul said:
Now I'm disappointed, I thought that a 800€ device from 2014 would be able to play such an old format, yet MX Player is not able to play it in HW, and in SW it uses the CPU so hard that the phone overheats and throttles, making the episodes unwatchable.
Really disappointing considering that a 450€ 2011 quadcore laptop can play it with less than 20% CPU use.
Mediainfo:
Code:
General
Unique ID : 210113449615409968501807337670924119963 (0x9E1260E100E888EDA6534B79C5ED2F9B)
Complete name : D:\Video\Anime\Aestetica\[Final8]Hagure Yuusha no Aesthetica - 08 (BD 10-bit 1920x1080 x264 FLAC)[981044CC].mkv
Format : Matroska
Format version : Version 2
File size : 1.13 GiB
Duration : 23mn 42s
Overall bit rate mode : Variable
Overall bit rate : 6 837 Kbps
Encoded date : UTC 2013-02-12 20:02:11
Writing application : mkvmerge v4.9.1 ('Ich will') built on Jul 11 2011 23:53:15
Writing library : libebml v1.2.1 + libmatroska v1.1.1
Attachements : ArnoPro-Caption.otf / cacmoose.ttf / Flat Brush Bold.ttf / Franco Bold Italic.ttf / Franco Bold.ttf / GARABD.TTF / Happy_Hell.ttf / pala.ttf / Village.ttf
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 23mn 42s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Writing library : x264 core 122 r2184 5c85e0a
Encoding settings : cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=12 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=15.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
Audio
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 23mn 42s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Default : Yes
Forced : No
Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Default : Yes
Forced : No
Menu
00:00:00.000 : :Intro
00:00:59.000 : :eek:P
00:02:28.000 : :Part A
00:10:13.000 : :Part B
00:21:40.000 : :ED
00:23:10.000 : :Preview
Let's hope at least the Note5 can.
Click to expand...
Click to collapse
This is one of those posts where you read the subject and can work out where it is going...
you mentioned 1080 and hi10 in a NOTE 4 forum
Hi10 needs to use SW encode on Note 4 and will use high cpu utilization, your going to have problems running it until there is support for this.
MX Player developer is aware of this (if you pop on over to the MX player forum http://forum.xda-developers.com/apps/mx-player ) this discussion has been had many many times.
You can work out if it can play hi10 without even purchasing the device so no point in posting a thread to notify us all about it not working. So please no random remarks about trying different players etc.
only way is to re-encode

galaxynote2 said:
It's Android problem and how manages media files. If the Note 4 doesn't woks fine for you, the S6/HTC One M8/LG G4/Nexus 6 wouldn't either. If you are waiting to buy a Note 5 just to see 1080p anime videos on it without overheating then happy waiting, pal. Also, you can't compare a laptop which have a cooler, HDD and a dedicated Video Card and CPU with a device with a compact flash drive and a Mali GPU WITHOUT cooling. You should know that...
If you wan't my advice: Downscale your video to 720p. It's anime.. i mean, its cartoon it shouldn't look THAT bad in 720p. I would be rather dissapointed if my Breaking Bad episodies look pixelated in such a good screen.
Cheers.
Click to expand...
Click to collapse
I wish I had Tekkaman II in 720p xD I can't find it in any HD formats! ARG.

That video is only 1080p, Note 4 can handle 4K videos without problems. Make sure first that no other apps are causing the overheating.

Have you tried watching the file using the stock video player provide with your Note 4? I can play a 1080p video on my SGSII and my Note 8.0 WiFi Edition using any media player, they both run as cool as a kitten.

f4vr said:
That video is only 1080p, Note 4 can handle 4K videos without problems. Make sure first that no other apps are causing the overheating.
Click to expand...
Click to collapse
DarkGuyver said:
Have you tried watching the file using the stock video player provide with your Note 4? I can play a 1080p video on my SGSII and my Note 8.0 WiFi Edition using any media player, they both run as cool as a kitten.
Click to expand...
Click to collapse
You guys seem to have ignored the previous posts. it is hi10 video so your suggestions are irrelevant so unless the phone magically gets new hardware you are stuck in software encodes.

A|ex said:
You guys seem to have ignored the previous posts. it is hi10 video so your suggestions are irrelevant so unless the phone magically gets new hardware you are stuck in software encodes.
Click to expand...
Click to collapse
Even though it is hi10, it is still H.264. The GPU that comes with the Note 4 (Snapdragon) can decode a H.265 which is more intensive than H.264. But you still cannot expect that it will not get warm.

f4vr said:
Even though it is hi10, it is still H.264. The GPU that comes with the Note 4 (Snapdragon) can decode a H.265 which is more intensive than H.264. But you still cannot expect that it will not get warm.
Click to expand...
Click to collapse
still stuck HW vs SW
10 bits!!!!

http://forum.xda-developers.com/showthread.php?p=57674483