Database Develop

CoolCamera for Alpine

CoolCamera - the program to take pictures and video on HTC Magician and HTC Alpine.
key features:
High frame rate (up to 25 fps) and smooth video. Efficient encoding algorithm utilize your XScale processor at maximum!
Easy camera control. All actions can be performed using hardware buttons only.
Camera adjustment without leaving view-finder mode.
Interval picture capturing.
High resolution (up to 1280x960) video in Motion Jpeg AVI format.
Pause/resume video recording process.
Available video resolutions and frame rates (with sound):
160x120 - 25 fps
320x240 - 20 fps
320x480 - 14-15 fps
640x240 - 16 fps
640x480 - 10 fps
1280x960 - 1-2 fps
For more details and download current version see official web-site.
www.ateksoft.com.

it will be cool if with unlock key..... :lol:

Anybody test this program? Does it work om Alpine?

Yes it does work, not a bad little app really.

Really nice app, thanks a lot!
Does anybody know which are the best
settings in order to capture fine photos?
Thanks!

first of all how do you get it to run ....do you just copy into windows as my file is a .php is that right

It is vey nice application....How can I map the default camera key so to use with this application?

To run CoolCamera instead of the standard camera software change the shortcut in \Windows\Start Menu\Programs. Edit the camera shortcut to point to \Programs\ATEKsoft\CoolCamera\CoolCamera.exe

got many software that can remap your hardware button. just search it.....

Yes I know that, I mean inside the program it has not such a setting...

Re: CoolCamera
Ran it on mine, had problems with the menu system and then it freezes, I don't think I#ll bother with that until it hs been developed alot more.

atek coolcamera
Thank you very much for coolcamera. it look nice and pro. I just test it and think it is bester than camera soft on my o2i. especially when take a video.

I set my coolcamera setting like this:6-5-4-5-3

Dynamic Over-Clocking Solution!!!

Alright, I've been really upset with the performance of the video camera & playback on my Tilt. In desperation I installed an HTC Application for the Apache which allows you to overclock to 520 or 624. I've been playing with this for a full 10 days now & have to say that aty the 520mhz video is bettyer than bearable, I've had no freezes & my battery draw is roughly the same as before I installed HTC Performance. This does not scale with steps like other over/under-clocking programs, so I just activate it when I need video cam or with TCPMP. It's working Great for me.
The original OEM app it was extracted from has helmi's name on it. I can't figure out what it does, but there is a significant diference for me when running at 520mhz especially in Video Cam mode.
If you want it, get it here: http://rapidshare.com/files/72529266/HTC_Performance__with_shortcut_.cab

GSLEON3 said:
Alright, I've been really upset with the performance of the video camera & playback on my Tilt. In desperation I installed an HTC Application for the Apache which allows you to overclock to 520 or 624. I've been playing with this for a full 10 days now & have to say that aty the 520mhz video is bettyer than bearable, I've had no freezes & my battery draw is roughly the same as before I installed HTC Performance. This does not scale with steps like other over/under-clocking programs, so I just activate it when I need video cam or with TCPMP. It's working Great for me.
The original OEM app it was extracted from has helmi's name on it. I can't figure out what it does, but there is a significant diference for me when running at 520mhz especially in Video Cam mode.
If you want it, get it here: http://rapidshare.com/files/72529266/HTC_Performance__with_shortcut_.cab
Click to expand...
Click to collapse
I installed - I enabled - I checked my Device Info (still 400). I ran sk benchmark with it on and off and results almost exactly the same. On what are you basing your info?

Tried it here to, doesn't seem to do anything for me either

sugar pill
I tried it too and noticed no difference LOL, I think its one of those times when someone thinks there running faster due to there special shoes

what's really interesting is that this program isn't even working writing the registry entries correctly. Under HKLM/Software/HTC/ this app writes a key called HTC_Misc. In that key are 2 sub-keys regarding the overclock. With the option to overclock turned off in the application, if you look at the registry you'll find that the ovefclocking is turned on. When you select 500mhz it turns off the overclocking registry. If you set it to 624 mhz, the keys are both set to 1 (on). I think this app needs some more work as it's not working correctly.

Maybe it's a sugar pill...
Yeah, I know fast shoes & all that. The funny thing is that almost all the Apache users found that the benchmarks were simillar to not using this app. but the majority of them also said that their unit was much more responsive. If it's a Placebo effect, it's a good one & I'll take it because my video cam actually captures things that are moving now, not just a blur. I'll reset & see if Tracker picks up any other changes anywhere else in the registry.
As far as what I'm currently basing my oppinion on, it's just that my camera is capturing moving people & items clearly.

GSLEON3 said:
Yeah, I know fast shoes & all that. The funny thing is that almost all the Apache users found that the benchmarks were simillar to not using this app. but the majority of them also said that their unit was much more responsive. If it's a Placebo effect, it's a good one & I'll take it because my video cam actually captures things that are moving now, not just a blur. I'll reset & see if Tracker picks up any other changes anywhere else in the registry.
As far as what I'm currently basing my oppinion on, it's just that my camera is capturing moving people & items clearly.
Click to expand...
Click to collapse
what speed are you using?

smittyofdhs said:
what speed are you using?
Click to expand...
Click to collapse
Funny enough, the 520 setting feels faster & camera works better for me. Strange though.

a faster processor isnt going to reduce the required exposure time

I understand that, & I'm strictly talking about overall sys. response & the Video Cam. Before when people were moving it as horrible, they appeared as just a blur of motion. Now it records movements much more clearly. The only other thing I've done is installed TomTOm6 w/ a few maps.
I'll tell you what, I'll make a screen recording of video with & with out this applied & you will see what I mean.

Are you sure you're not just taking photos in better light conditions at the moment? The kaiser automatically switches to night mode when the light is poor, and then the camera becomes unusable.

also please review the post I meade eralier about registry keys. When this app is set to 520, the actual registry entries show that overclocking is turned off.

This is DEFINITELY Placebo effect.

dang, this got me pretty excited...

Just as a final nail I tested corecodec benchmark of the spiderman3 movie I have on storage.
Non Over - 97.43% playback rate
520 - 96.62
640 - 96.00
So all in all I think we can call this one dead.
PS: Yes it does piss me off the playback isnt 100%+ but thats the drivers thread not this one.

Frame rate option in camera?

I've tried recording videos with both "normal" and "high" frame rate options, it doesn't seem to do anything, any ideas why it's there?
The info button says it's the rate at which videos are captured, so would that indicate if it works you'd get slow motion video?

i've been wonderin about that option myself....and changin it really doesnt seem to do anything at all...

There is a pretty clear difference.
However, the X1i is the only phone that has the difference.
It's not completely noticable on the Xperia, but if you play the video on the computer,
there will be a noticable difference in the framerate. Give it a shot!

just open files on advanced player and press PROPERTIES
Frame Rate: > 10fps or 24 fps

the problem is that the framerate goes down when the brightness is low..then the camera gets laggy in recording mode...so there has to be a setting that we can change the minimum frame rate
please developers HELP
[HKEY_LOCAL_MACHINE\Software\SonyEricsson\Camera]
"PROPERTY_MAX_MMS_LENGTH" = dword:0
"PROPERTY_MAX_MMS_SIZE" = dword:95D97
"PROPERTY_MMS_RESTRICT_RESOLUTION" = dword:1
"PROPERTY_VIDEO_QVGA_KBYTE_RATE" = dword:14
"PROPERTY_VIDEO_VGA_KBYTE_RATE" = dword:1
"PROPERTY_EXTERNAL_CAMERA_DIRECTORY" = "DCIM"
"VersionInfo" = "R19"
"ApplicationName" = "\\XperiaCamera\\CameraRunner.exe"

bummler said:
the problem is that the framerate goes down when the brightness is low..then the camera gets laggy in recording mode...so there has to be a setting that we can change the minimum frame rate
please developers HELP
Click to expand...
Click to collapse
Try BsB tweaks 1.6 it has an option to increase video bitrate. If this post helped press thanks.

ok,does it works on windows 6.1? and is it good to change to mpeg4 recording? what settings you used? would you please upload a video to see the difference?

bummler said:
ok,does it works on windows 6.1? and is it good to change to mpeg4 recording? what settings you used? would you please upload a video to see the difference?
Click to expand...
Click to collapse
I have no idea if it works on 6.1 because I don't use 6.1. The settings I used are the ones that improved camera and video quality to me they seemed like they worked I hardly use my camera and video anyway , I don't think the OP would put it improves camera and video quality if didn't. I'm not a bout to upload videos that's way to much of my time and effort when this is not my problem. Go ahead and install the cab and find out for yourself .

does i have to be carefull with this tweak,which settings i should change there?
my x1 quality is not that good...yours?
http://www.youtube.com/watch?v=xDZqi3PBqLI
http://www.youtube.com/watch?v=M5Kb9Wmr5_Y
http://www.youtube.com/watch?v=F912UyxU2hs
http://www.youtube.com/watch?v=dSRY99p7y6M

hm ok i installed it on the storage card but i cant see a difference,when i do a soft reset
its recording in vga not mpeg4 and i cant see any hidden camera modes..what does i have to do that the tweaks settings are visible

bummler said:
hm ok i installed it on the storage card but i cant see a difference,when i do a soft reset
its recording in vga not mpeg4 and i cant see any hidden camera modes..what does i have to do that the tweaks settings are visible
Click to expand...
Click to collapse
To start off if you are installing tweaks you always want to install them in the main phone memory unless the app says otherwise. I looked into what you were saying and made an interesting discovery the tweaks are not meant for the X1's camera. In the rom I'm using now I went to my multimedia folder and found separate camera and video software( most likely HD2 or rhodiums or HTC camera and video). I went into the software and found all the options the tweaks are supposed to unlock. The hidden video formats are H.263 and 4, 3GPP2, MPEG 4, and Motion JPEG. To my suprise the highest resolution is CIF(352x288). I tried all the video formats and all are very laggy the X1's video camera is way better. I only use BsB tweaks for the Power saving, Policies, SMS Wake Up, Gyph Cache and TCIP/IP Cache. The videos you posted look actually pretty good and the one where you were riding on the bike and past the man be pushed in a wagon made me laugh so hard

hehe these videos are just samples for good quality xperia x1 videos,i found on youtube. i dont made them. my quality is not that good i think. i installed the bsb tweak now on the main memory but really no changes (
highest resolution is CIF(352x288) i would like to see a video in that quality on xperia x1...is there any other good solution? at the moment i use vga,wide screen and endless focus
thx for help

bummler said:
hehe these videos are just samples for good quality xperia x1 videos,i found on youtube. i dont made them. my quality is not that good i think. i installed the bsb tweak now on the main memory but really no changes (
highest resolution is CIF(352x288) i would like to see a video in that quality on xperia x1...is there any other good solution? at the moment i use vga,wide screen and endless focus
thx for help
Click to expand...
Click to collapse
Ya I seen a couple of your posts in different threads saying they are sample videos lol. Believe me when I say this it is very bad with CIF and it is not in fullscreen view mode, very laggy/ blurry when you move it's not even worth uploading a video to show it's that bad. Try macro focus instead of endless see if that improves anything. Also maybe overclocking your phone with more speed might give a better framerate also idk.

ok,i installed wimospeed..how much does i can push up the mhz that it doesnt influence the battery life

bummler said:
ok,i installed wimospeed..how much does i can push up the mhz that it doesnt influence the battery life
Click to expand...
Click to collapse
Your battery life is going to be the same regardless of the increase of mhz. Every Xperia is different so the results of how high you can push it is going to be different. Try 652 to start.

it doesnt influence the battery life?
Thats a pretty good tool...652,8mhz and its mainly faster but the frame rate in video recording seems to be the same or?
if you have some more usefull tools,let me know.
p.s. my homescreen etc.
http://forum.xda-developers.com/showthread.php?t=656584&page=122

bummler said:
it doesnt influence the battery life?
Thats a pretty good tool...652,8mhz and its mainly faster but the frame rate in video recording seems to be the same or?
if you have some more usefull tools,let me know.
p.s. my homescreen etc.
http://forum.xda-developers.com/showthread.php?t=656584&page=122
Click to expand...
Click to collapse
I Pm you some good apps, Thank this post if you found them useful .

[HKEY_LOCAL_MACHINE\Software\SonyEricsson\Camera]
"PROPERTY_MAX_MMS_LENGTH" = dword:0
"PROPERTY_MAX_MMS_SIZE" = dword:95D97
"PROPERTY_MMS_RESTRICT_RESOLUTION" = dword:1
"PROPERTY_VIDEO_QVGA_KBYTE_RATE" = dword:14
"PROPERTY_VIDEO_VGA_KBYTE_RATE" = dword:1
"PROPERTY_EXTERNAL_CAMERA_DIRECTORY" = "DCIM"
"VersionInfo" = "R19"
"ApplicationName" = "\\XperiaCamera\\CameraRunner.exe"
is there a chance to change the framerate???
when the light is bad,the framerate goes down :0(,maybe the developers have a solution

the same here
I have the same issue, it is a shame... nice phone, though

True high-res 1024x600 video on Nook Color may be possible.

M-JPEG/MJPEG provides the possibility for relatively low-resource software decoding. If the Nook Color is up to the task at 800 MHz or even 1.1 GHz of decoding 24 fps and/or 30 fps M-JPEG streams at 1024x600 with relatively good compression quantizers, this could be one way of getting super-sharp, native-resolution playback working.
Does anyone know if any of the presently available media-players which run well on the Nook under any of the available OS flavors supports M-JPEG or could be modified to do so?
Obviously, this potential means of getting true 1024x600, even if it works, won't be for everyone. The files and raw bitrates will be massive compared to the 848x480 AVC files that many seem to be encoding so as to make use of the hardware decode ability. Depending on the speed of the flash-RAM being read from, there may also potentially be a bottleneck/buffer under-run issue there as well. But for those who are willing to go through the trouble of encoding to such a seldom-used codec and, if necessary, purchasing a microSD card with a confirmed high read-speed*, the benefits may outweigh the drawbacks.
Any discussion, ideas, information, and especially testing of these ideas would be much appreciated.
*be aware that SD Class ratings apply to sustained write and don't necessarily have a direct impact upon sustained read speed.
Full discloseure: I don't yet own a Nook Color, but am incredibly excited about purchasing one.

Sample clip to try out
Here's a sample clip to try, if anyone would be so kind. This is not the greatest or sharpest source material ever, it's intended more as proof of concept, but it should give an idea of the feasibility of this. The first half of the video is letterboxed, but the second half is full-screen 16:9 @ 1024x600, 29.97 fps.
Thanks in advance!
Skyrim Trailer: http://www.slingfile.com/file/2T6bd1yuXF
Encoded to M-JPEG .avi using XviD4PSP 6.0.3 Portable.
MediaInfo:Video
ID : 0
Format : JPEG
Codec ID : MJPG
Duration : 2mn 53s
Bit rate : 19.1 Mbps
Width : 1 024 pixels
Height : 600 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 1.035
Stream size : 394 MiB (99%)
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 2mn 53s
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 2.65 MiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (0.72 video frame)
Writing library : LAME3.98.2

We just need some extremely skilled assembly programmer to come along and write a NEON optimized software decoder. The CPU is pretty powerful if that aspect is leveraged. Unfortunately that is a non trivial task lol
I've read that the DSP is actually more powerful than meets the eye but the docs necessary aren't available. That could be incorrect though... But considering its a somewhat flexible DSP it is a shame that they don't release the details becausewho knows what it could be used for if our wacky community went at it.

Yeah, it seems to me, though I'm a complete noob regarding this device/platform and don't even own one yet, that the people behind the scenes enabling all this stuff are pretty talented and enthusiastic, and will continue to uncover much hidden potential in the device.
As for native 1024x600 video via M-JPEG, though, even just as a proof-of-concept, I'd really love to hear from someone who's willing to give playback of it a shot, as I think it has potential (not necessarily my test file though) to blow the up-scaled 854x480 AVC video most people are encoding out of the water. Do you have an NC you could try it on?

I gave the video a try. It plays very smooth but there is an occasional stutter. It's very close. Looks excellent in quality.
I used QQplayer and am at 1100mhz.

Excellent! Thank you very much for trying it. Does your system generally play hardware-decoded videos with no issues at all?
If you're interested, keep an eye on this thread, eventually I'll post something with super-sharp pic quality and the audio lowered to 44.1 KHz and a bit lower bitrate, so we'll see if that helps at all.
Thanks again for taking the time to download, try it, and report back.

swaaye said:
We just need some extremely skilled assembly programmer to come along and write a NEON optimized software decoder. The CPU is pretty powerful if that aspect is leveraged. Unfortunately that is a non trivial task lol
I've read that the DSP is actually more powerful than meets the eye but the docs necessary aren't available. That could be incorrect though... But considering its a somewhat flexible DSP it is a shame that they don't release the details becausewho knows what it could be used for if our wacky community went at it.
Click to expand...
Click to collapse
I'm sure Android coders of VisualOn have already put their VOME Engine (http://visualon.com/english/Android/vome.htm, see also some descriptions and even a demo in older posts of my blog fineoils.blogspot.com) into their NookColors. At some point in this January, they even promised to donate their (compiled) code to AOSP 2.3 repos. However, nobody has seen it though, and the VisualOn is completely mum of that slip of their tongue.
In other words, yes, our ARM's CPU is powerful enough to make so-called "software" decoding which hardly ever missing a beat compared to a dedicated hardware decoder. Then I argue that what is missing in our NEON/2D/3D framework is hardware (shaders of SGX) overlay. Yet YouTube apk knows how to utilize it, Flash 10.0...10.1...10.2, lots of players don't.
Then, the new TI OMAP SGX code is presented for kernels 2.6.36+, we don't have such a luxury yet in our CM7. CM Team are perfectionists, they supposedly aiming for a clean stable build of 2.6.32 capable to be used on all and every 30+ smartphones too many of which aren't even based on TI OMAP chips.
As for assembly, it might be useful to squeeze some 3...5...10 additional fps when optimizing memory/cache I/O operations and/or something else operating on the low level. We might discover that with the new kernel everything of 720p/2Mbit/sec will start playing as per specs automagically, or some clever tweaks of video/audio buffers, cache could bring serious improvements to video playback even with the "old" 2.6.29 kernel.

Very sharp test file ready to download & test
Here's a test file that, if it plays well, might show the potential for really sharp video playback. It's 1024x600 @ 23.976, down-scaled from a Blu-ray rip that was full-screen (or maybe 1.85:1) 1920x1080. I adjusted the audio to be 96 Kbps, 44.1 KHz MP3 (I can't seem to get AAC to work in an .AVI container). It's the first minute of the Just Say Yes music video from Get Him To The Greek, prior to any NSFW language or anatomy.
Encoded with XviD4PSP v.6.0.3 beta full-install, M-JPEG quantizer of 1.
Audio encoded with Lame via VLC.
download:
http://www.slingfile.com/file/NfqRe61AWl
MediaInfo:
Video
ID : 0
Format : JPEG
Codec ID : MJPG
Duration : 59s 935ms
Bit rate : 17.4 Mbps
Width : 1 024 pixels
Height : 600 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 1.184
Stream size : 125 MiB (99%)
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 59s 716ms
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 700 KiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 26 ms (0.63 video frame)
Interleave, preload duration : 26 ms
Writing library : LAME3.98.4

a.fenderson said:
Here's a test file that, if it plays well, might show the potential for really sharp video playback. It's 1024x600 @ 23.976, down-scaled from a Blu-ray rip that was full-screen (or maybe 1.85:1) 1920x1080. I adjusted the audio to be 96 Kbps, 44.1 KHz MP3 (I can't seem to get AAC to work in an .AVI container). It's the first minute of the Just Say Yes music video from Get Him To The Greek, prior to any NSFW language or anatomy.
Encoded with XviD4PSP v.6.0.3 beta full-install, M-JPEG quantizer of 1.
Audio encoded with Lame via VLC.
Click to expand...
Click to collapse
Tested. No issues, playback is perfect.
CM7 Stable, OC kernel @ 1.1GHz, Moboplayer 1.1.139 (V7-Neon which is ARMv7 optimized)

a.fenderson said:
Here's a test file that, if it plays well, might show the potential for really sharp video playback. It's 1024x600 @ 23.976, down-scaled from a Blu-ray rip that was full-screen (or maybe 1.85:1) 1920x1080. I adjusted the audio to be 96 Kbps, 44.1 KHz MP3 (I can't seem to get AAC to work in an .AVI container). It's the first minute of the Just Say Yes music video from Get Him To The Greek, prior to any NSFW language or anatomy.
Encoded with XviD4PSP v.6.0.3 beta full-install, M-JPEG quantizer of 1.
Audio encoded with Lame via VLC.
download:
http://www.slingfile.com/file/NfqRe61AWl
MediaInfo:
Video
ID : 0
Format : JPEG
Codec ID : MJPG
Duration : 59s 935ms
Bit rate : 17.4 Mbps
Width : 1 024 pixels
Height : 600 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 1.184
Stream size : 125 MiB (99%)
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 59s 716ms
Bit rate mode : Constant
Bit rate : 96.0 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 700 KiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 26 ms (0.63 video frame)
Interleave, preload duration : 26 ms
Writing library : LAME3.98.4
Click to expand...
Click to collapse
wow this clip looks so amazing. how big of a file would the whole movie be? also would u be intrested in doing a small youtube video on how to acheve this?

Wow.. Mobo player playes that perfectly, where vital player (my previous favorite) chokes hard.....
And holy hell.. it even plays a 1280x720 recording i made from my Incredible, that no other player would play. Man, forget motion JPEG, its all about this player!!

thanks for testing, all!
daedelus82 said:
Tested. No issues, playback is perfect.
CM7 Stable, OC kernel @ 1.1GHz, Moboplayer 1.1.139 (V7-Neon which is ARMv7 optimized)
Click to expand...
Click to collapse
Awesome, thanks for testing!
cowballz69 said:
wow this clip looks so amazing. how big of a file would the whole movie be? also would u be intrested in doing a small youtube video on how to acheve this?
Click to expand...
Click to collapse
Therein lies the issue. This is relatively ineffecient codec, space-wise, because it's intra-only: MediaInfo reports the video bitrate as 17.4 Mbps, which is comparable to Blu-ray bitrates of 1920x1080 material. This clip is exactly one minute @ 125 MB, so at 90 minutes this would be (depending on how you define 1 GB) between 10 and 11.25 GB. For a 2-hour, 120-minute film, you're looking at around 15 GB. There may be further refinements to the bitrate possible, through lowering the quanitzer a bit during encode, but you'll likely lose quality quickly and end up being better off with up-scaled, hardware-decoded AVC @ 854x480.
As for the YouTube how-to, I'm not very good on camera, and I'm quite sure that the method I used was very inefficient--I just had to use the apps I'm familiar with, apart from XviD4PSP, so for now I'll give a brief workflow, to be followed by a detailed written step-by-step, and then I'll let someone smarter than me boil that down to an easier process.
This assumes a non-branching disc with one single .M2TS file comprising the entire feature:
1. Decrypt & rip BD to HDD via AnyDVD-HD--for content you own, IF this is legal in your location, some restrictions apply.
2. Demux the video and audio streams of the feature .M2TS file into their raw components using tsMuxeRGui 1.10.6.
3. Use VLC's Convert/Save function to convert the audio to raw MP3, down-sampled to 44.1 KHz at 96 Kbps, stereo/2-channel.
4. Remux the original demuxed video and the new MP3 audio track to .TS via tsMuxeR
5. Drop the file into XviD4PSP (link warning: although this program is great, the site is one huge monolithic Silverlight monstrosity--it is composed of slow and fail), and convert to container .AVI, video M-JPEG scaled to 1024x600, compression quantizer 1; leave audio intact via "copy".
6. Enjoy near-HD goodness.
Divine_Madcat said:
Wow.. Mobo player playes that perfectly, where vital player (my previous favorite) chokes hard.....
And holy hell.. it even plays a 1280x720 recording i made from my Incredible, that no other player would play. Man, forget motion JPEG, its all about this player!!
Click to expand...
Click to collapse
Now THAT is good news! But please give details on the clip: codec, bitrate, encode-options if known, and is it actually high-detail that ends up looking comparable or better than the "Just Say Yes" M-JPEG clip, with no stuttering or other issues? Would it be possible to share a segment of it so others can try to reproduce the playback?

I may have spoken too fast, as the audio comes across as a loud hiss... but the video is flawless. If you want to try it:
http://dl.dropbox.com/u/19844443/VIDEO0021.3gp
The video plays with hardware decoding mode on BTW.. its just the audio that isn't playing right.. bummer..

a.fenderson said:
Here's a test file that...
download:
http://www.slingfile.com/file/NfqRe61AWl
Click to expand...
Click to collapse
OMG I tested your video clip and WOW. It looked freaking amazing. It is by far the best quality I have seen yet on my nook. I think proof of concept is confirmed.
Audio works fine for me as well

I wonder if a profile for Xvid could be made that would have low enough CPU usage on playback. There are a number of settings that reduce playback complexity.
For example,
http://forum.doom9.org/showthread.php?p=398214
I'm not a big fan of encoding videos to a specific device because said device will be obsolete within a year anyway. We are really close to having handheld devices that will play anything.
I think most of our software players are using a port of FFMPEG and I'm not sure how optimized that is for ARM NEON. A Google search does show some talk about NEON optimizations though. But I'm thinking that it could go a lot farther given some time...
http://www.google.com/search?hl=en&...official&q=ffmpeg+neon&aq=f&aqi=g10&aql=f&oq=
Be thankful for the popularity of ARM cpus. It helps make things happen.

just to let u guys know the audio and video was PERFECT , no audio stuttering and im sure its due to the newest test kernel and alsa patch. so if u have audio issues with his clip he uploaded def flash new test kernel and alsa

Divine_Madcat said:
I may have spoken too fast, as the audio comes across as a loud hiss... but the video is flawless. If you want to try it:
http://dl.dropbox.com/u/19844443/VIDEO0021.3gp
The video plays with hardware decoding mode on BTW.. its just the audio that isn't playing right.. bummer..
Click to expand...
Click to collapse
Thanks. I've remuxed your 720p MP4-ASP file to an AVI, with the original video intact, and the audio converted to mp3 @ 64 Kbps (you're not losing much quality here, subjectively), and the sampling rate was already super low. Try it now, if you want, maybe this will play: http://www.slingfile.com/file/wC8Wczp3d6
Excerpts from MediaInfo on your original file's video (it must have lost lots of this header info in the remux):
Format : MPEG-4 Visual
Format profile : [email protected]
Format settings, BVOP : Yes
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : 20
Duration : 18s 234ms
Bit rate mode : Constant
Bit rate : 8 000 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.527 fps
Minimum frame rate : 5.000 fps
Maximum frame rate : 33.333 fps
Color space : YUV
Bit depth : 8 bits
Scan type : Progressive
Excerpts from MediaInfo on the reencoded audio:
Audio
Codec ID/Hint : MP3
Bit rate mode : Constant
Bit rate : 64.0 Kbps
Channel(s) : 1 channel
Sampling rate : 8 000 Hz
colbur87 said:
OMG I tested your video clip and WOW. It looked freaking amazing. It is by far the best quality I have seen yet on my nook. I think proof of concept is confirmed.
Audio works fine for me as well
Click to expand...
Click to collapse
Great, thanks! I actually hated having to lower the quality of the audio as per recommendations in this thread (props to dalingrin et al), because at this bitrate I can hear compression artifacts really easily, but if I could find a way to stick M-JPEG and AAC in a workable container, maybe the increased quality will help negate the low bitrate. Or, maybe the lower sampling rate has more impact than the lower bitrate and we could bump the audio Kbps back up--more experimentation needed, but I don't have access to the rip until I get home.
swaaye said:
I wonder if a profile for Xvid could be made that would have low enough CPU usage on playback. There are a number of settings that reduce playback complexity.
Click to expand...
Click to collapse
See above--Divine_Madcat was playing 720p MP4-ASP/XviD-encoded material, with only slight audio problems. See if the remux I posted works on yours with audio intact.
For example,
http://forum.doom9.org/showthread.php?p=398214
I'm not a big fan of encoding videos to a specific device because said device will be obsolete within a year anyway. We are really close to having handheld devices that will play anything.
Click to expand...
Click to collapse
On the one hand, I completely agree--this is a lot of work to produce some really huge files that don't necessarily have much use elsewhere (apart from iPads, from which specs I actually got the initial idea), but on the other hand, even if it's only for having one super high-quality sample clip that plays absolutely perfectly so I can show it off to my geek friends and family and leave them stunned at the quality, it'll be worth it.
I think most of our software players are using a port of FFMPEG and I'm not sure how optimized that is for ARM NEON. A Google search does show some talk about NEON optimizations though. But I'm thinking that it could go a lot farther given some time...
http://www.google.com/search?hl=en&...official&q=ffmpeg+neon&aq=f&aqi=g10&aql=f&oq=
Be thankful for the popularity of ARM cpus. It helps make things happen.
Click to expand...
Click to collapse
Bring on the optimizations!

a.fenderson said:
Great, thanks! I actually hated having to lower the quality of the audio as per recommendations in this thread (props to dalingrin et al), because at this bitrate I can hear compression artifacts really easily, but if I could find a way to stick M-JPEG and AAC in a workable container, maybe the increased quality will help negate the low bitrate. Or, maybe the lower sampling rate has more impact than the lower bitrate and we could bump the audio Kbps back up--more experimentation needed, but I don't have access to the rip until I get home.
Click to expand...
Click to collapse
I never said anything about lowering the bitrate. If you can tell a difference between 48K and 44.1K on the horrible nook audio then props to you =P
Any audio issues related to sample rate are fixed now anyway

dalingrin said:
I never said anything about lowering the bitrate. If you can tell a difference between 48K and 44.1K on the horrible nook audio then props to you =P
Any audio issues related to sample rate are fixed now anyway
Click to expand...
Click to collapse
Thanks for the info, and I'm sorry--I didn't mean to misquote you. Lowering sampling rate to 44.1K and bitrate was the overall plan I came away with after reading through that entire thread. It's great to know that the audio sampling rates can be high enough to maintain near-transparency. And no, I can't tell a difference between 48K and 44.1K sampling rate, all other things being equal, even on half-way decent equipment. No golden ears here.
Edit: when I said "maybe the lower sampling rate has more impact than the lower bitrate" I meant on playability, not on audio quality. My bad.

a.fenderson said:
Thanks for the info, and I'm sorry--I didn't mean to misquote you. Lowering sampling rate to 44.1K and bitrate was the overall plan I came away with after reading through that entire thread. It's great to know that the audio sampling rates can be high enough to maintain near-transparency. And no, I can't tell a difference between 48K and 44.1K sampling rate, all other things being equal, even on half-way decent equipment. No golden ears here.
Edit: when I said "maybe the lower sampling rate has more impact than the lower bitrate" I meant on playability, not on audio quality. My bad.
Click to expand...
Click to collapse
No worries, i just wanted to make it clear.

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.