I'm curious if the they support ext2 or ext3 or ntfs which all support much larger files. If so does the player handle files >> 4gb ?
Yes, a friend has a 32GB SDHC and has tried placing a ~25GB file on it, which parses and seeks perfectly under ext3. I do not know any of the specifics of the partition details.
I'm a linux user so it is fairly easy for me to format the card anything but fat32 (where I have to use a windows box).
To format an SD card to FAT32 in Linux, I've used mkdosfs -c -F 32 -n MyCard -s 64 -S 512 -v /dev/sdc1
Graphically, KDE Partition Manager seems perfect for the job, too. You can of course fiddle around with the block/cluster size (size 64 clusters facilitate higher performance with larger files but more wasted space when storing multiple tiny files), and obviously replace sdc1 with your hardware's SD read point.
Also why would folks encode to the full resolution of the screen ? On most ios/ android devices I've tinkered with the player places a border around the screen. Does the htc player play the video border-less if the resolution matches the screen ?
A border is used as needed to maintain correct aspect ratio. When the aspect ratio of the video doesn't match that of the screen, the Sense player has options to adjust the scaling -- clicking the 'screen' button in the player controls its behavior. Playing 16:9 videos on a 5:3 QVGA screen can result in one of the following AR-maintaining behaviors, according to what setting is selected:
- Resizing the video so as to ensure the aspect-limiting dimension of video fills the screen perfectly in that dimension; the other is simply 'out of bounds' and thus entirely cropped off. This is destructive in that you are losing (often significant) parts of the image entirely due to cropping. However, the portion of the remaining video area is allowed to fill the whole screen, resulting in greater size/detail in the remaining area.
- Resizing the video so as to ensure the non-limiting dimension fills the screen perfectly; the other is sized accordingly in tandem with the creation of the 'letterboxing' (black bars) effect. This is much less destructive to the visible area of the video, but more so to the detail within it (it no longer fills the whole screen).
- Native size (DHD/some builds only): Video is not resized if it is already large enough to fit within the display. Note that the above scaling methods will also leave the dimensions untouched when the video already perfectly occupies the screen area.
Scaling (like decoding, provided you are using an appropriate player like the Sense player) is done in hardware. I believe the resampling method is bicubic interpolation on the Adreno 20X series, given the GPU's realtime bicubic scaling ability, but I haven't run any tests -- it could very well be a primitive bilinear function depending on the parameters of the decoder/GPU/player.
It has been my experience that most people with whom I have regular contact prefer the area/aspect maintaining scaling (method 2) rather than overcropping (method 1), especially when loading a video with subtitles in which portions thereof would be cut off when the sides are cropped during the 16:9 -> 5:3 conversion. In the case of non-destructive scaling (with attendant letterboxing), 800x450 is the screen's maximum physical output after hardware resizing, for a total of 360K pixels. Things get even worse when playing 2.39:1 content, but let's ignore this for now. AMOLED displays like that of the Galaxy S, by some estimates, have an effective PenTile resolution of 653x392, causing 16:9 content to display as 653x367 (240K), which is especially jarring when viewing sharp edges (anime, text in seminars/slideshows, etc).
The 3VO, in contrast, has a natural aspect ratio of 16:9, which is ingenious on a portable multimedia device. 16:9 content would be scaled perfectly to the screen resolution of 960x540, for an output of 518.4K pixels. That's a
44% increase in resolution over QVGA on all 16:9 content that is isn't destructively cropped (or a whopping 116% more than a PenTile AMOLED display of the same). The usable screen area is also maximized in this case, obviously, so no letterboxing is present and the video can (again, non-destructively) occupy more physical screen area as well.
On the above topic I believe one of the issue with the galaxy s was that it was very slow with fat32 but very fast with ext3 (ext3 has a lot of nice features).
Samsung used RFS, its own heavily modified filesystem compatible with FAT16/32 (and a somewhat lacking implementation thereof, I daresay). FAT32 in and of itself shouldn't be significantly slower than other filesystems on solid state media, since its largest issue (fragmentation) is largely irrelevant read-side with random access capability on NAND flash, be it internal or within removable flash media. YAFFS, NTFS, journaling filesystems, btrfs and the like support more features, flash-specific tools, less propensity for fragmentation, enhanced delayed allocation, and higher read/write buffers by default, often resulting in greater performance for burst read/writes, higher data resilience, and FS compression (NFTS/btrfs) for additional space savings.
)
