yumeyao / android_platform_frameworks_av Goto Github PK

The issue has also been reported in AOSP issue tracker as:
https://code.google.com/p/android/issues/detail?id=81428

While discussing(arguing) with AOSP community which solution is right, I'll implement the one that follows the standard strictly here with this ticket created to track the implementation details (like what's in the standard for some format).

I have created a wiki page that is open to everyone for editing. It also serves as a checklist.
https://github.com/yumeyao/android_platform_frameworks_av/wiki/Text-encoding-of-tags-in-formats-reference-list

To help with the research of different formats, you can contribute by leaving a comment here and/or editing the wiki page above.

Commit 3c2151e has been submitted to address performance.

However. The current way used to find the extension (position and length) in a path is not optimal.
Now it gets the strlen, and scans backward from the end of the string.
The fail-case would be /dir1/dir2/dir3/dir4/dir5/veryveryveryverylonglonglonglonglonglonglonglongpath/without/dots/in/any/part/of/the/path

There're 2 ways to make it better:

Since we know the maximum length of extension we can handle is 5, stop backward scanning if it exceeds this length.

This should be the fastest way but the code is a bit ugly.

In both ARM & x86, it's possible to do both strlen and strrchr at the same time with almost no significant performance lose compared to doing only one. Because doing strrchr always moves the pointer to last (the NULL character), but the pointer is not returned. We can simply skip strlen by subtract the original pointer (points to start of the string) from the final pointer (points to the trailing NULL) to get the length.

ARM reference:
strchr: https://sourceware.org/ml/libc-ports/2011-12/msg00028.html
strrchr is just looping of strchr to find the last one.

Intel x86:
repnz scasb

In x86 the performance of the second way is as fast as the first way except for the cases that there are many dots in the path, like /dir1/a.dir2/b.dir3.dir4.dir5.dir6/a.lot.of.dots.are.fun
In ARM, however, the first way should always be faster.

So I'll go with the first way to implement it.