Running DOS on the DASH - HTC Excalibur

Does anyone succed in getting PocketDOS running on the DASH ?
.exe launch said "not for this device".
help much appreciated !

So nobody have been able to run DOS on a Dash/S620 ??

This does work:
Download
http://www.pocketdos.com/PocketDOS/PocketDOS_111.exe
Unzip (do not execute!) PocketDOS_111.exe
Go into the Smartphone Directory of the unzipped PocketDOS_111.exe
copy DR-DOS_703.CAB and PocketDOS.arm_400sp.CAB on the phone.
Run and install both CAB files on the DASH.
Once done, get the Landscape mode update here:
http://www.pocketdos.com/PocketDOS/PocketDOS_111_SPL_Beta5.zip
Unzip & update the pocketdos.exe file to the DASH.
P.S: the Landscape mode beta seems a bit buggy with the keyboard.
In order to fix the issue you have to assign the numbers key to their corresponding letter using the CUSTOM menu.
List of apps that have been tested w/ PocketDOS v1.11 :
OS:
====
Working:
========
Windows 3.0 : VGA / 186 / EMS (0Mb) or EMM286.EXE (available from our website)
OpenGEM 5.0 : VGA
Games:
======
Working:
========
Another World : VGA
Civilization 1 : VGA / Retrace enabled
Colonization : VGA / HD
Commander Keen 1 : VGA
Commander Keen 4 : VGA
Corruption : VGA
DeathTrack USA : VGA / EGA BIOS
Duke Nukum 1 : VGA
Dune : VGA
Elite : VGA
FlashBack : VGA
Flight Simulator 4.0 : VGA
HeroQuest : VGA
Hugo's House of Horrors : VGA
Indiana Jones & The Last Crusade : VGA
Jones in the Fast Lane : VGA / HD
Kings Quest 1 : VGA
Leisure Suit Larry 1 : VGA / EGA BIOS
Leisure Suit Larry 2 : VGA / HD
Leisure Suit Larry 3 : VGA / HD
Master of Magic : VGA / HD / EMS (3Mb)
Master of Orion : VGA / EMS (1Mb)
Paganitzu : VGA
Police Quest : VGA / EGA BIOS
Police Quest III : VGA
Prince of Persia : VGA
Railroad Tycoon : VGA
Secret of Monkey Island : VGA
Space Quest 1 : VGA / EGA BIOS
Space Quest 1 (VGA) : VGA / HD
Space Quest 2 : VGA / EGA BIOS
Stunt Driver : VGA
Stunts : VGA
Test Drive 2 : VGA / HD
Ultima VI : VGA
Wizardry - Crusaders of the Dark Savant : VGA / EMS (0Mb)
Wolfenstein 3D : VGA / 286 / Retrace disabled

Its working fine per the install instructions above, however the keyboard support is a problem. I'm unable to get it configured to work well enough to be useful, but I haven't spent too much time on it.

It does partially work if you switch between the CUSTOM mode & the others one.

There are two further test (beta) versions available from:
http://www.pocketdos.com/PocketDOS/PocketDOS_111_SPL_Beta7.zip
http://www.pocketdos.com/PocketDOS/PocketDOS_111_SPL_Beta8.zip
These versions specifically address the numeric/alpha key issue.

Related

[REF][11.11.09] CFC - THE Manila/TF3D Image Editor - Tech Reference (Q)(W)VGA

Update November 11, 2009
CFC and CFC GUI have been updated to 0.60 and 0.60.35 respectively. CFC runtime files have been updated. This thread has also been update to add information about the new file formats.
Changes:
- (CFC GUI) Support for new filenames (and categories) used in TF3D v2.5+
- Support for new file formats (read only, "replace" write is always in old format) used in TF3D v2.5+
- Support for new compressed formats that correspond to the new formats mentioned above
- (CFC GUI) If you are using this with 2.5, please do read the 2.5 specific notes (in the CFC GUI thread).
- At this time I STRONLY recommend patching Manila files manually instead of using the auto-patching! See the tech thread referenced below.
Update June 5, 2009
CFC and CFC GUI have been updated to 0.55 and 0.55.25 respectively. The CFC runtime files have not been updated. Changes:
- Better compression ratio (backwards compatible with old runtime)
- UltraHQ en/de-coding support (CFC)
- "Patch Manila on device" function has been improved to work-around the issue of Manila no longer starting that some people have (CFC-GUI)
Update April 20, 2009
CFC and CFC GUI have been updated. Many changes! For the changelog see the CFC GUI thead. The CFC runtime has also been updated to v0.50, so there is a new libgles_mn file required. See the cfc-support-dll zip attached a few posts down.
Update Feb 26, 2009
CFC and CFC GUI have been updated to 0.46.15. Fixed an issue with PNGs without alpha channel.
Update Jan 15, 2009
CFC Live Patch 0.45.01 has been released. You can run this tool on your phone to make your current Manila installation compatible with CFC compression.
See this post.
Update Jan 14, 2009
CFC GUI 0.45.15 released. No changes to CFC core, only GUI stuff. Attached download updated.
CFC GUI thread: http://forum.xda-developers.com/showthread.php?t=470798
Changelog: http://forum.xda-developers.com/showpost.php?p=3164604&postcount=3
Update Jan 13, 2009
CFC 0.45 and CFC GUI 0.45.12 released.
CFC (core) changes:
- Heavily modified encoding algorithm. It is often slower but the quality should be much better. Please read this post!
CFC GUI changes:
- No longer freaks out if the wrong file attributes are set on some files
- Added background color selection
- Added tool to patch a complete Manila package for CFC compatibility and optimization
Also, non-technical discussion of CFC GUI (only) should go to this thread:
http://forum.xda-developers.com/showthread.php?t=470798
Update Jan 12, 2009
Yes I know, too many updates today!
CFC 0.42 attached. Was something weird going on with the encoding sometimes. Furthermore it seems like the encoding works great on the original files, but it drops the ball here and there with other files. Going to look into that ASAP and finetune the encoding algorithm!
Most important about this update is, CFC now also comes with a GUI!
Update Jan 12, 2009
CFC has been updated to version 0.4. Added features are:
- QTC -> PNG (+- 30% faster than 0.4b2)
- PNG -> QTC
- CFC -> QTC (finally)
- QTC padding
- QTC trimming
With QTC <-> PNG conversion now available from CFC, it seems the Compressonator is no longer needed!
Further EDIT: All posts updated.
Further EDIT: 0.41 added... There was a small bug in CFC compression in 0.4, it didn't always set PayloadSize correctly, which could create errors with padding/trimming.
Update Jan 8, 2009
CFC has been updated to version 0.3. It can now fully handle the RGB format as well. CFC compression has been slightly optimized. QTC and ATC headers are now completely written correctly.
This now also allows for larger than original images
Also lots of info in the first 6 posts has been updated to reflect these changes and add information.
Update Jan 7, 2009
Thanks to myself and D-MAN666, it seems the QTC format is now completely known!
Also today brings CFC compression for (W)VGA devices, if chefs choose to implement it. The needed stuff is here.
The CFC tool itself still needs an update (0.3 ?) to handle QTC/ATC_RGB conversion to ATC/ATC_RGB conversion (and back) and to decompress the CFC files. Donor headers won't be needed anymore then either in some cases (but they will remain handy in others!), and with that some parts of the first 5 posts will have to be rewritten as well (sigh...)
Note that some other parts of the first few posts are marked with changes. Look for the red letters.
- end of updates -
Intro
As some of you may have seen, me, djboo, pcarvalho, "he who shall not be named" and several other enthousiasts have ported TouchFlo3D (to be specific, the version that came on my Raphael) to QVGA. A large part of this effort involved hacking into Manila/Mode9 and even OpenGL ES itself to get it operating decently, but after that, a lot of effort went into optimizing, which was largely done by scaling the images. While working on this, I encovered a lot of information and wrote quite a bit of code to 'get it done'. As always, a lot of it ultimately redundant, but we did pull it off! (barring some issues that are driver related).
Acknowledgements
Before continuing, people need to be acknowledged for their parts in this. I could hardly have done it alone. A lot of these credits go out to people involved in the TF3D QVGA porting, but also drivers porting, they all had a hand in this information being 'discovered', and hence are mentioned here.
- djboo Keeping all this stuff going. I looked at this stuff once when herg did an attempt, never really got involved, but because of him did get involved this time around. As he seems to be forgotten in the credits here and there, he's #1 in this thread!
- pcarvalho A bit of competition that led to great stuff. In the end, our intended methods of porting complement eachother nicely - 'my' part got it going, but the QVGA port didn't really shine 'til we did the other things 'his way' as well.
- "he who shall not be named" The anonymous HTC-CA hacker, about whom probably everybody knows who he is (it aint me ) Did some cracking work on this too.
- The P3D Team A bunch of them did a lot of testing
- D-MAN666 Mentioned last but certiainly not least! Cracked the file format first, and generally found out and published a hell of a lot of information. Also the author of Manila Editor.
Requirements
For all this, you will need and/or want the following:
- "The Compressonator", image conversion/compression/viewer tool by ATI/AMD. You may need to sign up at the AMD website, but it is free of charge and I haven't received any spam from them yet. Update: The version of Compressonator on AMD's site is no longer able to do ATC. The correct version of Compressonator is attached to this post. Update: The Compressonator is now no longer strictly needed due to CFC being able to do the QTC en/decoding.
- "Manila Editor", Manila image editor. You will not be using this for the actual good stuff, but you may be using this for testing things quickly, and you will definitely want to use it for finding the files you actually want to replace. Update: no longer needed, use the CFC GUI instead!
- CFC, (attached), tool by yours truely to convert between QTC, ATC, CFC and PNG formats
- Knowledge of the Windows command line - Though CFC now comes with a GUI as well, yay!
- The files attached to this post. These are all the images from Manila (the version that came with my Raphael) converted to PNG by "The Compressonator". It's kind of a ***** to do, so if you want to save yourself some trouble, just see that post. VGA as well as (rescaled using Lanczos3) QVGA images are attached to that post. Update: this image packs need to be updated, will do some time
CFC download
Notice: you do not need the compressonator files to use CFC. They are just here in case you want to do things the old-school way
( < 0.60 : 3408 downloads )
Textures, ATC, CTES, QTC, CFC (tech background)
The imageon 3D chip in our devices support texture compression, and Manila (Mode9) uses this. The format used is a special format created by AMD/ATI for low size and lower power use on mobile devices, called ATC (ATI Texture Compression).
There are three ATC formats:
- ATC_RGB: 4 bits per pixel (4 bits RGB)
- ATC_RGBA_EXPLICIT_ALPHA: 8 bits per pixel (4 bits RGB + 4 bits Alpha)
- ATC_RGBA_INTERPOLATED_ALPHA: 8 bits per pixel (not sure on the format)
Almost all images used in Manila are of the 'ATC_RBGA_EXPLICIT_ALPHA' variant, and this article will focus on these. ATC_RGB is also used for a small number of images, though I have not further investigated its format.
The image data for these formats are stored in one of the following file formats:
- ATC: The file format generally used by AMD/ATI
- CTES: ATC related, some weirdness, see below. Seems to be forward compatible with ATC, but not backwards.
- QTC: Qualcomm adapted version of ATC, used by Manila/Mode9
The formats are very similar, though we will focus only on ATC/QTC, that's all we need.
Image data (ATC_RGBA_EXPLICIT_ALPHA) - Updated January 12, 2009
A lot of the original information comes from D-MAN666's posts here.
I will skip over the headers (32 bytes), they are listed below for ATC and QTC specifically. This is about the actual image.
The image is divided into blocks of 4x4 pixels. An 8x8 image would be stored like this: (A, B, C and D are 'pixel blocks')
AAAABBBB
AAAABBBB
AAAABBBB
AAAABBBB
CCCCDDDD
CCCCDDDD
CCCCDDDD
CCCCDDDD
A 4x4 pixel block is 16 pixels and 16 bytes. So in effect, you can see it as 8 bits per pixel. An image is always stored using these 4x4 pixel blocks. A 5x5 images would thus use 4 blocks!
bytes 0-7 are alpha values for each pixel, 4 bits per pixel (4 bits * 16 = 64 bits = 8 bytes) - this is not present for the ATC_RGB format. Scale these to the 0..255 range by multiplying each alpha value by 17.
bytes 8-11 are color keys, there are two keys of 16 bits (2 bytes). The keys are stored like this:
word 1: XRRRRRGG GGGBBBBB (1-bit method, 5-bit R, G, B)
word 2: RRRRRGGG GGGBBBBB (5-bit R, 6-bit G, 5-bit B)
Where X is the decoding method to use, there are two.
bytes 12-15 are mixdown values, 2 bits per pixel (2 bits * 16 = 32 bits = 4 bytes). The per-pixel mixdown value, combined with the color keys mentioned above determine the actual color that is outputted. You must scale the scolor keys to the 0..255 range and apply a formula to them.
Code:
if HasAlpha then begin // skip for ATC_RGB
sIn.Read(dw, 4); // read dword
for i := 0 to 7 do begin
alpha[i] := (dw and $F) * 17;
dw := dw shr 4;
end;
sIn.Read(dw, 4); // read dword
for i := 8 to 15 do begin
alpha[i] := (dw and $F) * 17;
dw := dw shr 4;
end;
// alpha[0..15] now contain the scaled 4x4 pixel block alpha values
end;
sIn.Read(w, 2); // read a word, key1
Method := (w shr 15);
Keys[iR, 0] := ((w and $7C00) shr 10) * (255/31);
Keys[iG, 0] := ((w and $03E0) shr 5) * (255/31);
Keys[iB, 0] := (w and $001F) * (255/31);
sIn.Read(w, 2); // read a word, key2
Keys[iR, 1] := ((w and $F800) shr 11) * (255/31);
Keys[iG, 1] := ((w and $07E0) shr 5) * (255/63);
Keys[iB, 1] := (w and $001F) * (255/31);
sIn.Read(mixdown, 4); // read a dword, mixdown values
for i := 0 to 15 do begin
pixels[i] := (mixdown and $3);
mixdown := mixdown shr 2;
end;
// pixels[0..15] now contain the still-encoded 4x4 pixel block mixdown values
When thinking about the color keys and mixdown values, think of the keys as a color-range start and end value. The mixdown values decide which value to pick inside the range. (for each R,G,B)
For example, let's take a key1 of 10 and a key2 of 40 for Green. Then the decoded Green values would be:
Code:
mixdown 00 01 02 03
value 10 20 30 40
This is only true, however, when the 'method' bit (X) is 0. Full decoding of both methods:
Code:
for i := 0 to 15 do begin
a := alpha[i];
if (method = 0) then begin
r := Round( Keys[iR, 0] + ((pixels[i] / 3) * (Keys[iR, 1] - Keys[iR, 0])) );
g := Round( Keys[iG, 0] + ((pixels[i] / 3) * (Keys[iG, 1] - Keys[iG, 0])) );
b := Round( Keys[iB, 0] + ((pixels[i] / 3) * (Keys[iB, 1] - Keys[iB, 0])) );
end else begin
case pixels[i] of
0: begin
r := 0;
g := 0;
b := 0;
end;
1: begin
r := Round( Keys[iR, 0] - ((1/4) * Keys[iR, 1]) );
g := Round( Keys[iG, 0] - ((1/4) * Keys[iG, 1]) );
b := Round( Keys[iB, 0] - ((1/4) * Keys[iB, 1]) );
end;
2: begin
r := Round( Keys[iR, 0] );
g := Round( Keys[iG, 0] );
b := Round( Keys[iB, 0] );
end;
3: begin
r := Round( Keys[iR, 1] );
g := Round( Keys[iG, 1] );
b := Round( Keys[iB, 1] );
end;
end;
end;
end;
Both methods have various way of formulating them. I thought the ways I have chosen here are clearest for how it works.
Update Jan 7, 2009
Image data (ATC_RGB)
The image data here is exactly the same as ATC_RGBA_EXPLICIT_ALPHA, except that the alpha bits aren't includes. So, each 16-pixel block becomes 8 bytes instead of 16, as bytes 0-7 from ATC_RGBA_EXPLICIT_ALPHA are not there. This means 4 bits per pixel.
- end of update -
ATC, CTES, QTC
This image data seems to be the same across all formats - and it should be, as this data is sent directly to the 3D chip. You would not want to have to process it first.
Let's first pick out CTES, as I have very little to say about it. It seems to be nearly the same as ATC and QTC, however, for some reason, "The Compressonator" will output CTES files we can use as ATC, but will not read our own Manila-based ATC's in CTES mode (only in ATC mode). What's up with that? I don't know. Perhaps one of you will figure it out.
QTC header
Code:
Magic: DWORD; // 0x31435451 : "QTC1"
Magic2: DWORD; // always 1 ?
Width: DWORD;
Height: DWORD;
Format: DWORD; // 0x14, 0x15
Dummy1: DWORD; // formerly known as Unknown1, may be 0 - Jan 7, 2009
PayloadSize: DWORD; // formerly known as Unknown2 - Jan 7, 2009
Dummy3: DWORD; // formerly known as Unknown3, may be 0 - Jan 7, 2009
The meaning of the unknowns has not been deciphered yet. Setting them to weird values does muck-up the decoding of the images, however, they do not seem to be actually sent to the 3D chip. Or perhaps I just have not found where and when!
For format, 0x14 is used for ATC_RGB_EXPLICIT_ALPHA. The small number of images that use 0x15, I suspect, are ATC_RGB. Either way, they do not decode using the ATC_RGB_EXPLICIT_ALPHA method and I know ATC_RGB is used some places, so it would make some sense to make this assumption.
Update Jan 7, 2009
Unknown2 has been replaced by PayloadSize, thanks to myself, D-MAN666 and eidolen.
The PayloadSize is the number of bytes after the header that contain content.
For images of type 0x14 (ATC_RGB_EXPLICIT_ALPHA) this is: Width * Height, where both Width and Height are multiples of 4, due to how the format itself works, in other words: (RoundUp(Width / 4) * 4) * (RoundUp(Height / 4) * 4).
For images of type 0x15 (ATC_RGB) this is half of type 0x14, because ATC_RGB uses 4 bits per pixel instead of 8. The multiples of 4 rule still stands, so the PayloadSize is: Round(((RoundUp(Width / 4) * 4) * (RoundUp(Height / 4) * 4)) / 2)
Note that all Manila image files (at least the ones I have) are padded to be a multiple of 512 bytes in size. This is probably a speed optimization for when these files are cooked into a ROM.
Dummy1 and Dummy3 (aptly renamed from Unknown1 and Unknown3) seem to be irrelevant. After we figured out how PayloadSize (Unknown2) was relevant, we tried blanking out Dummy1 and Dummy3 with 0's, and TF3D still works without a hitch. The original values do not seem to be related to the dimensions nor the payload size, and they are not sent to the graphics chip either.
- end of update -
Update November 6, 2009
Manila 2.5 uses 4 additional file formats:
0x01 - 8888 RGBA, 32bpp
0x02 - 888 RGB, 24bpp (I have not encountered an actual image in this format, so processing may be faulty by CFC and CFC GUI)
0x03 - 565 RGB, 16bpp
0x05 - 4444 RGBA, 16bpp
- end of update -
ATC header
Updated 08/Jan/2009
Code:
Magic: DWORD; // 0xCCC40002
Width: DWORD;
Height: DWORD;
Format: DWORD; // ATC_FORMAT, 0x01 for RGB, 0x02 for RGBA_EXPLICIT_ALPHA, 08/Jan/2009
Magic3: DWORD; // 0x20 ... mucks up colors... not clear?
Magic4: DWORD; // 0x01, 08/Jan/2009
Magic5: DWORD; // 0x01, 08/Jan/2009
FormatMagic: DWORD; // 0x8C92 for RGB, 0x8C93 for RGBA_EXPLICIT_ALPHA, 08/Jan/2009
- end of updated content -
CFC format + historic Compressonator editing
CFC format
I use the CFC format (yes, that's why the tool is called CFC) for the Manila QVGA port. It saves a lot of space and even seems to improve performance a bit. It uses standard gzip/zlib compression on the QTC image data (which compresses to about 20% on average) and hides the compressed data inside the QTC file itself. Decompression of this is over 5 MB/s on our devices, but images are only a few KB each. The proxy libgles_cm is what actually decodes this and sends the decompressed data to the 3D chip.
CFC adjusts the QTC header to the proper values. Beware when doing this yourself that Mode9 uses these values internally as well). The image data ('payload') is replaced as follows:
Code:
Magic: DWORD; // 0x31434643 : 'CFC1'
Format: DWORD; // CFC_FORMAT...
Width: DWORD;
Height: DWORD;
CompressedSize: DWORD;
UnCompressedSize: DWORD;
... compressed data ...
Format can be one of the following:
Code:
CFC_FORMAT_COMPRESSED_QTC_RGBA_EXPLICIT_ALPHA = 0x3001; // 0x14 from QTC
CFC_FORMAT_COMPRESSED_QTC_RGB = 0x3002; // 0x15 from QTC - used since CFC 0.3
CFC_FORMAT_COMPRESSED_RGBA = 0x3101; // April 20, 2009 - RGBA format - used since CFC 0.5
CFC_FORMAT_COMPRESSED_RGB = 0x3102; // April 20, 2009 - RGB format - used since CFC 0.5
Width and height are included for historic reasons, and it also opens up the possibility to do some weird mods. RGBA format is included for possibly allowing use of uncompressed textures for Manila support on non-HTC/Qualcomm/ATI/AMD based devices.
Update April 20, 2009
(A)RGB formats are gzip/zlib compressed just as QTC/CFC variants and require the CFC 0.50 runtime files. The uncompressed data is actually stored as (height x width x) BGR(A) (from x86 viewpoint) as this is the format the graphics chip can handle.
Update November 6, 2009
The following formats have been added to CFC. Note that the QTC header always says RGB or RGBA_EXPLICIT_ALPHA. This actually allows the new formats to be used on older Manila versions that do not directly support them, if you are using CFC 0.60 runtimes.
Code:
// CFC 0.60 additional formats
CFC_FORMAT_COMPRESSED_QTC_8_8_8_8 = 0x3003;
CFC_FORMAT_COMPRESSED_QTC_X_8_8_8 = 0x3004;
CFC_FORMAT_COMPRESSED_QTC_5_6_5 = 0x3005;
CFC_FORMAT_COMPRESSED_QTC_4_4_4_4 = 0x3007;
Notice: the text below in this post is here for historic reasons. It is no longer completely relevant
Right, well I did tell you to get "The Compressonator" from AMD's site, right? You should have done this by now. You should also have the CFC tool attached to the first post of this thread.
Say we want to manipulate an image from Manila. First we need to find out which image it is. Easiest way to find them is to use Manila Editor (also linked in first post), so you get the 'magic' filename.
You may want to ask why we dont simply use Manila Editor for doing these things, simply put, the image quality from The Compressonator is better than the current version of Manila Editor. Also, we can do stuff in batch in The Compressonator.
Manila to PNG (single)
Now, say this image is 7d3f1247_manila (the globe on the internet page), we use the CFC tool to convert it to ATC format:
Code:
cfc -qa 7d3f1247_manila 7d3f1247_manila.atc
You can open this file in The Compressonator. It may look a bit weird, because alpha is not displayed. Right click on the image and select "Show RGBA", there, that looks better.
Something you will not directly notice with the globe image, but you will with other images, is that the image is UPSIDE DOWN. You will need to flip the image over if you want to put it back into Manila. For some reason I haven't figured out yet, decoding goes upside down, but encoding needs to be the correct side up.
Now we may wish to edit this file, so we save it as PNG: File -> Save Original.
Open it in photoshop, flip it vertically, and save it.
Manila to PNG (batch)
We will need to use batch mode to convert back to Manila anyways, so lets just start using it for converting it to PNG as well (for some reason doing it non-batch doesn't work right).
This will assume you have a bunch of .atc files in a directory. Batch converting Manila (QTC) files to ATC files is also possible with CFC:
Code:
cfc -qaf orgfiles atcfiles
Assuming you have your original Manila files in the folder 'orgfiles' and created a new empty directory 'atcfiles'.
Open The Compressonator, and go to File -> Batch Compress (or press F4). Navigate to your folder containing all the ATC files, set the "Files of type" box to "ATC Textures (*.ATC...)". set the "Output File Format" to PNG and "Output Format" to "ARGB8888". Punch the "Compress All" button and wait a bit.
Note that some files will not decompress correctly and crash The Compressonator. You will have to look at the crash dump to find out which file was the culprit and remove it from your batch directory. IIRC, there are about 10 files that have this issue, so be prepared for 10 minutes of infuriating work.
You MUST set "Output directory" to "Use Input Directory", or you will not be able to decompress more than one file!
In the end, you will have a large bunch of PNG files. Note that these PNG files are also available already done for you, see the link in the first post of this thread.
Files known to crash The Compressonator: 08/Jan/2009
Code:
00ad7edb_manila.atc
056e5c7f_manila.atc
063f5858_manila.atc
0c175082_manila.atc
2255b55f_manila.atc
24720929_manila.atc
39064485_manila.atc
4a209508_manila.atc
PNG to Manila (single + batch)
Even for single files, we are using the batch function, as there seems to be an issue with doing this in The Compressonator normally.
The operation is exactly the same, but for single you select the file and press "Compress", and for many files you do not select a file and press "Compress All".
Note that as previously mentioned, decoding ATC to PNG files results in the PNG's being upside down, but to make ATC files from PNG files the correct side needs to be up!
This time around we set "Files of type" to "PNG Textures" (duh) and "Output File Format" to "CTES Textures". As previously mentioned CTES is compatible with ATC, but ATC is not compatible with CTES. You won't notice this though.
The magic is the "Output Format" setting. Set it to "CTES Texture Compression" and hit the "Options" button. In the "Compress Texture" dialog that pops up, select "ATC RGBA Explicit Alpha (8 bits per pixel)", or "ATC RGB (4 bits per pixel)", depending on which format you want, hit OK, and you're there. Hit "Compress" or "Compress All", and wait 'til it's done.
You MUST set "Output directory" to "Use Input Directory", or you will not be able to decompress more than one file!
Now we want to convert these CTES/ATC files back to Manila files, and for this, again, we use the CFC tool:
Code:
cfc -aqf atcfolder qtcfolder orgfolder
You can also use -aq instead of -aqf for a single file. Note that the CFC tool does NOT change filenames, so you have some renaming to do.
Update 08/Jan/2009
With CFC 0.3, donor headers are not longer necessary, and have become an optional parameter.
- end of update -
Rescaling to QVGA
Converting Manila images to QVGA is pretty simple. Just use the techniques described above.
What you want to do is scale ONLY images 32x32 and larger, and you will want to divide the width and height exactly by two. That's all there is to it.
If you have a bunch of PNG files you want to scale, the CFC tool can even do this for you, including the needed vertical flip:
Code:
cfc -nsf vgapngfolder qvgapngfolder
This will rescale using the Lanczos3 algorithm.
CFC Compression
The QVGA port supports the CFC format as mentioned above. This can save a lot of space and is the preferred way of using textures for the QVGA port.
To compress your QVGA QTC files to CFC:
Code:
cfc -cf qvgaqtcfolder qvgacfcfolder
CFC tool (commandline)
As CFC offers a lot of options, many of them related to the pre-0.4 way of converting images, I'll take a very short time to explain the most relevant CFC options, what they do, and when/why you should use them. Most of these are available in the GUI as well.
Convert QTCs to PNGs
Code:
cfc -qp in-filename out-filename
cfc -qpf in-folder out-folder
Since CFC 0.4 this should be the preferred way to convert Manila's QTC files to PNG's (it's pretty fast and saves a lot of steps and trouble compared to using other CFC options and the Compressonator). These images come out with correct side up, so no longer is there a need to flip them manually with CFC or Photoshop or whatever.
Note: This does not handle CFC compressed QTC's, you will have to decompress those first!
Convert PNGs to QTCs
Code:
cfc -pq in-filename out-filename
cfc -pqf in-folder out-folder
Obviously if you want to convert QTCs to PNGs there's a good chance you also wish to do the reverse. Introduced in CFC 0.4b2. CFC will automatically detect if RGBA_EXPLICIT_ALPHA or RGB is the most optimal QTC format to use.
Quality rivals the Compressonator, but CFC is quite a bit slower (though the saved number of steps save you more time).
Note: The output are not CFC compressed, you will have to do that manually.
Compress QTCs to CFCs
Code:
cfc -c in-filename out-filename
cfc -cf in-folder out-folder
Compressed QTCs (CFCs) are usually much smaller than the original QTCs, and provide a performance boost as well. However, you will need a patched Manila to be able to use CFCs. The QVGA port is patched to do this, and instructions on how to other Manila versions can be patched are included a few posts below this one.
Decompress CFCs to QTCs
Code:
cfc -d in-filename out-filename
cfc -df in-folder out-folder
This should speak for itself
Trim QTCs
Code:
cfc -t in-filename out-filename
cfc -tf in-folder out-folder
Saves some space on your hard-disk, removes unnecessary data from the QTC files (also works on CFCs).
Pad QTCs
Code:
cfc -p in-filename out-filename
cfc -pf in-folder out-folder
This makes the QTCs (and CFCs) a multiple of 512 in bytes in size. HTC originally did this with all their images. It seems to improve performance when Manila is cooked in.
Scale PNGs VGA->QVGA
Code:
cfc -ps in-filename out-filename
cfc -psf in-folder out-folder
For the theme and Manila porters. Note that Manila in QVGA can handle VGA textures (and vice versa) just fine, however, using the correct image size for the Manila resolution does improve performance quite a bit.
Complete QVGA port example
Updated 13/Jan/2009
You can now do this whole thing with a single push of a button in the CFC GUI: Tools, Scale QVGA -> VGA
- end of update -
Updated 12/Jan/2009
The text below has been updated to reflect changes with CFC 0.4
- end of update -
This is the complete rundown of how I converted all the VGA images from Manila to QVGA images, the same method can be applied to themes and what not.
First, create a directory somewhere, and put the CFC.exe in it. Then go to the command line and change directory to this new directory.
We will want to create a bunch of directories:
1) Setup
Code:
mkdir org png pngscale qtc cfc out
Dump all your original manila files in org (in this case, the entire manila, but you could just dump your theme in there instead)
2) Convert QTC to PNG
Code:
cfc -qpf org png
3) Scale PNG images from VGA to QVGA
Because CFC will not scale very small images, we need to make sure the output folder (pngscale) has all the images we want first. The ones that are scaled will be overwritten by CFC:
Code:
copy png\*.png pngscale\*.png /y
Do the scaling:
Code:
cfc -psf png pngscale
4) Convert PNG back to QTC
Code:
cfc -pqf pngscale qtc
5) Convert QTC to CFC (optional)
Code:
cfc -cf qtc cfc
6) Pad QTC/CFC (optional, for cooking)
Code:
cfc -pf cfc out
2-6 in one go:
Note that this does not include making the directory and placing your Manila in the org folder.
Code:
cfc -qpf org png
copy png\*.png pngscale\*.png /y
cfc -psf png pngscale
cfc -pqf pngscale qtc
cfc -cf qtc cfc
cfc -pf cfc out
--
Et voila, most of our images have now been rescaled to QVGA, are compressed for optimum filesize, and located in the qtc, cfc, or out folder, depending on which steps you skipped.
Also note we retouched some images by hand for the QVGA version.
CFC for VGA and WVGA
!IMPORTANT! Updated 11.11.2009: CFC GUI updated. Support DLLs updated to CFC 0.60!
!IMPORTANT! Updated April 20, 2009: CFC Live Patch discontinued!
I have recompiled the libgles proxy file originally made for QVGA to a version that only handles the CFC compression, and should work on any 'normal' Manila 3D version, like the ones found on the Touch Diamond, Pro and HD.
If you cooks/chefs/whomever implement this, you can reduce TF3D's size footprint by half (7 mb smaller in my test). This also makes a positive performance difference, as the on-the-fly decompression of the images is actually faster than the flashdisk access.
Patching TF3D to be able to use CFC compression also allows theme makers to make faster and smaller themes.
Instructions to modify TF3D VGA/WVGA - for users NEW!:
FOR v2.5 AND NEWER PATCH MANUALLY!
- Get CFC GUI, attached to the first post of this topic.
- Connect your device using ActiveSync
- Use the "Device->Patch Manila on device" feature
Instructions to modify TF3D VGA/WVGA - for chefs:
FOR v2.5 AND NEWER PATCH MANUALLY!
- Get CFC GUI, attached to the first post of this topic.
- Run CFC GUI and select the folder where your Manila package is stored
- Make sure you got a backup of said folder
- Go to Tools -> Patch Manila
The following things will be done to your Manila package:
- All image files will be CFC compressed (lossless, faster)
- All image files will be padded to be a multiple of 512 bytes in size (faster)
- All image files will be set to System/Hidden/Archive file attributes
- Manila.exe will be patched to use libgles_mn.dll
- Manil2.exe will be patched to use libgles_mn.dll (depending on Manila version)
- Mode9.dll will be patched to use libgles_mn.dll
- libgles_mn.dll will be placed in the package
- zlib_mn.dll will be placed in the package
If no errors occur, there is nothing else you need to do, aside from cooking the package
Instructions to modify TF3D VGA/WVGA - by hand
Attached is a zip file (cfc-support-dlls) with the two DLLs you need: libgles_mn.dll and zlib_mn.dll . These must be placed in your \Windows folder.
Next, hex edit Manila.exe, Manil2.exe and Mode9.dll to use libgles_mn.dll instead of libgles_cm.dll. Just search for "libgles_cm.dll" in the files and replace it with "libgles_mn.dll". These values may appear multiple times in the file! Make sure to search and replace for both ANSI and UNICODE variants! Your Manila version may not have both Manila and Manil2, or only one of them may contain the "libgles_cm.dll" string. This is normal.
You should also modify HKLM\Software\OEM\MASD\Manila and append _CFC to the version string. This so people can recognize if their installation supports CFC.
This will only add support for CFC to your Manila install, it will not make images and such actually use CFC. But you can now support themes that do use CFC.
Note to people who used an older version of this patch
You don't have to do it again, but the automated tool makes sure everything is done right. If you still have zlib1.dll from the old patch on your device, do not remove it unless you want to break the "Teeter" game.
You can run the automated tool over a package you used the older patch on - it will clean it up.
Wow. I can't wait. So is it possible then to run TF3D on an older VGA device? Or is this to help us decode the themes. Isn't james making a image converter from vga to qvga?
Kraize92 said:
Wow. I can't wait. So is it possible then to run TF3D on an older VGA device? Or is this to help us decode the themes. Isn't james making a image converter from vga to qvga?
Click to expand...
Click to collapse
everything has been converted to qvga
CraZyLiLbOy said:
everything has been converted to qvga
Click to expand...
Click to collapse
True, but a tool would still be nice because the skins of tf3d are all in vga. If we had a converter, I could apply the theme and everything, and then convert it to qvga.
Kraize92 said:
True, but a tool would still be nice because the skins of tf3d are all in vga. If we had a converter, I could apply the theme and everything, and then convert it to qvga.
Click to expand...
Click to collapse
You don't have to convert anything to qvga. All touchflo 3d themes work on our qvga devices. You are using touchflo 3d interface from the diamond. You can apply any themes you want for the touchflo 3d. I know the diamond is a vga device but it still works. I'm saying this because I've tried it and it works, mark my words
The QVGA port was made specifically in mind with that VGA stuff will just work - and they will. However, when I finish this guide and you have read it, you will understand exactly how you can significantly optimize the QVGA version - and make the VGA version better
I don't know man but I think I fall in love with the touchflo 3d. Thanks to Chainfire and djboo.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Great TUT very interesting. thanks for sharing your tools
yesssss thank you for your great tuto,
2Chainfire
Didn't understand how to convert single PNG to manila's VGA file
Could u give me more examples?
any progress???
Any progress... on what? This tutorial is finished. TF3D-QVGA is finished. All we're waiting for is a new driver release that fixes the power issues.
i dont mean to sound like a complete idiot, but will this ever be in cab form?
i have no idea what most of what you are talking about means in this tutorial, I am just legitimately curious if it is even possible.
also if that is not possible, wouldnt the old touchflo3d porting-to-qvga cab be necessary along with this tutorial? maybe i am just seriously confused and have no idea what is going on
disregard if this is too much ignorance in one post!
thanks
htctoucher
htctoucher said:
i dont mean to sound like a complete idiot, but will this ever be in cab form?
i have no idea what most of what you are talking about means in this tutorial, I am just legitimately curious if it is even possible.
also if that is not possible, wouldnt the old touchflo3d porting-to-qvga cab be necessary along with this tutorial? maybe i am just seriously confused and have no idea what is going on
disregard if this is too much ignorance in one post!
thanks
htctoucher
Click to expand...
Click to collapse
I'm not quite sure what you are after with this CAB you ask for. If you are looking for TF3D for QVGA, a CAB is available (but there are still some issues with the required 3D drivers for the QVGA devices).
The modifed TF3D executable files work fine on QVGA with the original graphics. This thread however explains the method to do pixel-perfect TF3D image manipulation (for themers, porters, etc) in general, which was up until the documentation of this thread impossible (read: unknown). Methods like using Manila Editor work, but degrade image quality significantly more than the method described here.
However, this thread also documents converting the (originally) VGA TF3D images to the corresponding QVGA sizes, and even adding an extra 5x compression to them. This is not necessary to do if you have the modified TF3D executables for QVGA (it will use the VGA graphics files just fine), however, it certainly makes TF3D a hell of a lot faster and significantly reduces the size it requires on disk and the memory use (both of which are more limited on the QVGA devices compared to the VGA ones). It includes this information because this method was 'discovered' in the process of porting TF3D to run on QVGA devices. Similarly, porting existing TF3D VGA themes to QVGA resolutions will increase the speed of TF3D on QVGA devices over using the original theme's VGA graphics files.
Note that the TF3D-QVGA CAB ( http://www.htcclassaction.org/download/TF3D-QVGA.cab ) already includes the optimized QVGA graphics, and some of them were even retouched by hand (not mentioned in this threaD).
I hope this explains what you want to know
Hi I have managed to convert a manila file to ATC format using cfc.exe but now I cant open it using The Compressonator. If I go to open (there is no ATC file type listed in 'Files of type' drop down menu), select All Files (*.*) and try to open the converted .atc file, it does not load. I am using The Compressonator 1.50 which seems to have been updated recently (18-12-08) so it might be an issue with the new version. If it is that can you please upload or direct me to the old version or else if I am doing something wrong, please help.
Thank you
AF241

I can't see the Tv Live with Orange France

Hi all,
I install this new Rom :
Oops black : http://forum.xda-developers.com/showthread.php?t=401062
I install Manilla :
http://forum.xda-developers.com/showthread.php?t=398173
I install 2 patchs ( 1 by 1) for the Orange TV:
http://www.ftp-win-mobile.com/Cab Operateurs/FR_Orange_TV.cab
and
http://rapidshare.com/files/61052683/Patch_TV_Vid_o_Orange_by_Seiya.CAB
And this 2 patch doesn't work for that IE look my p3300 seems like a SPV M650
Can comeone Help me ?
I find the solution :
You go to :
[HKEY_LOCAL_MACHINE\Security\Internet Explorer\User Agent]
You make a new Key String Value
Key Name : Custom
Key description : HTC-P3450-orange/PPC; 240×320; OpVer 23.114.2.741
Source : http://win-mobile.forumpro.fr/htc-p...-orange-tv-video-t12853.htm?highlight=clavier
If a admin or a modo can lock the topic , thx

Data connection problem after hard reset

Hi i currently using HTC Trinity p3600i(black) as my pda. I frequently search for useful software but that habit is causing me more problem because i'm a newbies and stil learning in this forum & PDA world.
My PDA won't connect when my 3G simcard voice & data provider(Maxis).
I downloaded anvanced configuration tools & Resco Explorer Spb Suite(comes in pack with encryptor). What happen is, I had to hard reset my device cos it has gone haywired & hanged ( using ctrl+alt+del 3button push ) last week.
After that, I can't connect to any data connection whatsoever & it keep saying "the remote party has ended this connection". But however unlikely, when i use another ISP simcard (Celcom ) it worked just fine. Please help & advise me what to do. I'm totally blurred.
-My current ROM & Device Information-
About-Windows Mobile R 6 Professional
CE OS 5.2.1437 ( BUILD 17944.0.3.1 )
Processor : SC32442B-500MHz
Memory : 49.22 MB
Device Info
ROM VERSION : 3.00.707.17
ROM DATE : 06/29/07
RADIO VERSION : 1.46.00.11
PROTOCOL VERSION : 32.79.7020.19H
CPU : SAMSUNG (R) 2442
SPEED : 500MHz
RAM : 64MB
FLASH : 256 MB
DATA BUS : 32 BITS
STORAGE SIZE : 179.14MB
DISPLAY : 240 X 320
COLORS : 65536
TO ALL THE SIFU HERE, PLEASE HELP ME. PLS

[Q] HS video decoding problem... I'm about to give up.

Hello. My saga starts in this thread. I'm trying to run my 720p mkv video files smoothly in my Arc S (arconium 7.2, .64 baseband). Firstly I installed many video players from market (I even bought DicePlayer, which is great) but no one of them could run all mkv ok. A xda fellow told me about H264leveleditor, that I should use it to down my mkv file levels to 3.1, and it would resolve my problems. Well, in part, it worked. 30% of my video files began to run like a dream (in HW decoding mode) When the H264 level was in 4.1, the players worked only in SW mode, which was awful. The developer of DicePlayer told me that Qualcomm processors have a weak point in decoding mkv videos, but if it's true, why some videos run ok and some of only run laggy and out of sync?! Example: I run The.Big.Bang.Theory.S05E05.720p.HDTV.X264-DIMENSION perfectly (hw decode), but The.Big.Bang.Theory.S05E17.720p.HDTV.X264-DIMENSION run only in SW decoding mode. Isn't these mkv videos "identical"? Why one of them can run and the other one can't, if both of them is 720p mkv (3.1 H264 level)?
Sorry for the bad english but please, help =(
EDIT: Type mistake on the thread's title... it's HW video decoding problem...
I instaled MediaInfo and compared two videos... One of them run in HW mode (runs like a dream, even without overclock) and the other only in SW (runs awful).
The properties of the one that works:
General
Complete name : C:\Users\Israel\Desktop\The.Big.Bang.Theory.S05E05.720p.HDTV.x264-IMMERSE.mkv
Format : Matroska
Format version : Version 2
File size : 455 MiB
Duration : 21mn 1s
Overall bit rate : 3 026 Kbps
Writing application : x264.exe
Writing library : mkv2rls x264-tv version built on 2011. febr. 17
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 21mn 1s
Bit rate : 2 838 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.128
Stream size : 427 MiB (94%)
Writing library : x264 core 118 r2085 8a62835
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No
Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 21mn 1s
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 19.2 MiB (4%)
Language : English
Default : Yes
Forced : No
The one that doesn't run fine:
General
Unique ID : 187155380279623684204582013841221980954 (0x8CCCD0AB4515F47C91628E7A2295931A)
Complete name : C:\Users\Israel\Desktop\The.Big.Bang.Theory.S05E17.720p.HDTV.X264-DIMENSION.mkv
Format : Matroska
Format version : Version 2
File size : 542 MiB
Duration : 21mn 28s
Overall bit rate : 3 526 Kbps
Encoded date : UTC 2012-02-16 14:26:19
Writing application : mkvmerge v3.1.0 ('Happy up here') built on Jan 19 2010 12:09:24
Writing library : libebml v0.7.9 + libmatroska v0.8.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 8 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 21mn 28s
Bit rate : 3 072 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.139
Stream size : 472 MiB (87%)
Writing library : x264 core 120 r2164 da19765
Encoding settings : cabac=1 / ref=8 / deblock=1:-2:-2 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=1 / 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=5 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : No
Forced : No
Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 21mn 28s
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 59.0 MiB (11%)
Default : Yes
Forced : No
Tried Rockplayer? I just watched an episode of Himym, and it ran great. Fps and quality all fine.
E: oh HW decoding? My mistake.
Yeah... HW decoding. Is it possible to edit the title of the thread?!
Anyway, the developer of DicePlayer answered my email and said:
"Hi,
I don't know exactly the difference. I guess that the main reason is the count of reference frames (5 vs 8), but I'm not sure. The HW codec of tegra2 sometimes takes some more time to decode some frames (may be b-frames) as expected.
Thanks."
I'll try to check it later...
And yes, I tried rockplayer. It can't run some mkv's in HW decoding mode
Like I said in the other thread, for me also any difference between videoas that works and do not works were re-frames. And you cant change it without re-encode whole video and this takes time. For me with amd phenom II 4x3.4ghz it takes about 15 min for 20 min video. Shame that re-frames cant be changed like profile level I think that newer releases o mkv videos are encoded with newer rules that scene must follow (like with profile level, that's required to be 4.1 at least for what I know) so less and less videos are gonna work on our arcs
I discovered a new method to resolve this problem... Later on I'll make a tutorial

[Q] Video Playback on Note 2 (GT-N7100)

I've been using MXPlayer to play video files on my phone and while it usually doesn't have a problem playing most of the files, there have been a few where it would only play the sound and not the video. I never had problems of the video not playing at all, though. And also, there are some files which play both sound and video but the video is quite laggy.
I'm not familiar with how phones and codecs and whatnot work (when I still had a desktop, I would watch my videos there and when the videos didn't play right, all I had to do was download and install codec packs but I'm not sure if you could do that with a phone...). Anyway, to make things a bit simpler (I think), I've posted below the media info of the video files that only played sound and no video, and the laggy one.
NO VIDEO, JUST SOUND (Also, these won't show subs)
Code:
General
Unique ID : 182338066429087365776864735620848566423 (0x892D08C23B632384A297E5F4018E4097)
Complete name : H:\# Unsorted Downloads\[Anime-Koi] Karneval - 01 [h264-720p][E619A01C].mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 373 MiB
Duration : 23mn 39s
Overall bit rate : 2 202 Kbps
Encoded date : UTC 2013-04-05 02:25:56
Writing application : mkvmerge v6.0.0 ('Coming Up For Air') built on Jan 20 2013 09:52:00
Writing library : libebml v1.3.0 + libmatroska v1.4.0
Attachment : Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Codec ID : V_MPEG4/ISO/AVC
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Original frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Scan type : Progressive
Title : H.264 720p HDTV [10bit]
Writing library : x264 core 125 r2200+677M 3a754e7
Encoding settings : cabac=1 / ref=9 / deblock=1:1:1 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / fade_compensate=1.00 / psy_rd=0.70:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=70 / rc=crf / mbtree=1 / crf=17.0000 / qcomp=0.70 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=3:0.70
Language : Japanese
Default : Yes
Forced : Yes
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 23mn 39s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Title : AAC LC 2.0 192Kbps
Language : Japanese
Default : Yes
Forced : Yes
Text
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : Main Track [Softsub Karaoke]
Language : English
Default : Yes
Forced : Yes
Menu
00:00:00.000 : en:Prologue
00:00:37.787 : en:Part A
00:02:49.043 : en:Part B
00:11:13.839 : en:Part C
00:19:46.852 : en:Part D
00:21:54.604 : en:Ending Song
00:23:24.569 : en:Preview
00:23:39.376 : en:End
Code:
General
Unique ID : 195443306720641913050768616422467911184 (0x930902FDBE99D920B101FA2128E33E10)
Complete name : H:\# Unsorted Downloads\Persona 4 The Animation [Dual Audio] [Blu Ray]\Persona 4 The Animation Ep.01 - You're myself, I'm yourself.mkv
Format : Matroska
Format version : Version 2
File size : 386 MiB
Duration : 29mn 56s
Overall bit rate : 1 803 Kbps
Movie name : You're myself, I'm yourself
Encoded date : UTC 2012-12-10 08:40:38
Writing application : mkvmerge v5.5.0 ('Healer') built on Apr 6 2012 21:43:24
Writing library : libebml v1.2.3 + libmatroska v1.3.0
Attachment : Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 29mn 56s
Width : 1 280 pixels
Height : 720 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
Title : Episode 1 - You're myself, I'm yourself
Writing library : x264 core 124 r2197 69a0443
Encoding settings : cabac=1 / ref=9 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=9 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No
Audio #1
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 29mn 56s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 9ms
Title : English 2.0 AAC
Language : English
Default : Yes
Forced : No
Audio #2
ID : 3
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 29mn 56s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 945ms
Title : Japanese 2.0 AAC
Language : Japanese
Default : No
Forced : No
Text #1
ID : 4
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : English Lyrics/Signs
Language : English
Default : Yes
Forced : No
Text #2
ID : 5
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : English Subtitles
Language : Japanese
Default : No
Forced : No
Menu
00:00:00.000 : en:Prologue
00:01:27.963 : en:eek:pening
00:02:58.136 : en:Part 1
00:18:34.113 : en:Part 2
00:26:53.695 : en:Ending
00:28:08.687 : en:Preview
00:28:24.703 : en:Ending Credits
Code:
General
Unique ID : 238416833271108914671198131772825344211 (0xB35D696EA074F0DF82BF62388C5518D3)
Complete name : H:\Anime\Brave 10\[Final8]Brave 10 - 01 (BD 10-bit 1280x720 x264 AAC)[114F9F2D].mkv
Format : Matroska
Format version : Version 2
File size : 365 MiB
Duration : 23mn 41s
Overall bit rate : 2 154 Kbps
Encoded date : UTC 2012-09-20 16:22:54
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
Attachment : Yes / Yes / Yes / Yes / Yes / Yes / Yes
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 41s
Width : 1 280 pixels
Height : 720 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=16.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 : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 23mn 41s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 9ms
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:23.000 : :eek:P
00:01:52.500 : :Part A
00:10:24.000 : :Part B
00:21:42.000 : :ED
00:23:11.000 : :Preview
PLAYS VIDEO AND SOUND, BUT VIDEO IS LAGGY
Code:
General
Unique ID : 226338877801338539278156801268788804665 (0xAA47484077141735ACDFD3C191F4BC39)
Complete name : H:\Anime\Durarara!!\[Coalgirls]_Durarara!!_01_(1280x720_Blu-ray_FLAC)_[537A4BA3] [8bit].mkv
Format : Matroska
Format version : Version 2
File size : 440 MiB
Duration : 24mn 30s
Overall bit rate mode : Variable
Overall bit rate : 2 510 Kbps
Movie name : Durarara!! 01
Encoded date : UTC 2012-10-21 15:36:55
Writing application : mkvmerge v5.8.0 ('No Sleep / Pillow') built on Sep 2 2012 15:37:04
Writing library : libebml v1.2.3 + libmatroska v1.3.0
Attachment : Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes / Yes
Video
ID : 5
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 24mn 30s
Width : 1 280 pixels
Height : 720 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 : 8 bits
Scan type : Progressive
Writing library : x264 core 128 r2216 198a7ea
Encoding settings : cabac=1 / ref=1 / deblock=1:1:1 / analyse=0x3:0x113 / me=hex / subme=2 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:0.60
Language : English
Default : Yes
Forced : No
Audio #1
ID : 1
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 24mn 30s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Title : [FLAC 2.0]
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : Japanese
Default : Yes
Forced : No
Audio #2
ID : 2
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 24mn 30s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Title : [FLAC 2.0]
Writing library : libFLAC 1.2.1 (UTC 2007-09-17)
Language : English
Default : No
Forced : No
Text #1
ID : 3
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : [ASS]
Language : English
Default : Yes
Forced : No
Text #2
ID : 4
Format : ASS
Codec ID : S_TEXT/ASS
Codec ID/Info : Advanced Sub Station Alpha
Compression mode : Lossless
Title : [ASS] [FOR DUB]
Language : English
Default : No
Forced : No
Menu
00:00:00.000 : en:eek:pening
00:01:30.048 : en:Part A
00:11:58.551 : en:Part B
00:22:46.532 : en:Ending
00:24:15.476 : en:Preview
I wanna know if there's something I can do so that I can watch these files on my phone (coz my media player can't play most of these files, either). Can I download codecs or may be a specific player off the market or do I have to do some video conversions?

Categories

Resources