Java Mobile Application Support
|
|
J2ME and real-time media streaming?
|
|
Mime types and media formats
|
|
Media streaming and locked/unlocked phones
|
|
mWebPlayer's known issues
|
|
Debug mode and resolving issues
|
| |
 J2ME and real-time media streaming
|
|
| |
While using mWebPlayer
or our other media mobile products
keep in mind following restriction that must be applied for any JME streaming software application.
Built-in mobile J2ME-based player supports real-time streaming only for media stream broadcasted
via RTSP protocols. That is available now only in 3G network and for latest 3G phone models.
All other mobile devices works only with HTTP protocol via direct socket connection.
This way is used when mWebPlayer plays mp3 media from
any stream server like ShoutCast.
Using HTTP as a transport protocol in J2ME-player means that media data must be loaded
in full before playing. It is not a problem for a local audio file but it is impossible for
a web streaming radio.
To solve this problem mWebPlayer creates an own play buffer
and fills it up with next part of stream media in background while the player is playing previous media part.
When it finished playing the fisrt data the player loads from the buffer all available at this moment next media portion
and plays it. And so on.
Loading data into the player takes some time and that causes a small pause between
playing two following stream parts. It is not fault of the application,
it is the current implemenation of J2ME system player.
To decrease this gap mWebPlayer provides really smart
algorithm for internal buffering. Size of a media part (and its playing time)
is changed dynamicaly and depends on internet connection speed, bitrate of the selected channel,
available memory heap and CPU power of your mobile device. And the longer the application
plays the media stream, the more smoothy playing will be.
|
|
Mime types and playing media
|
|
| |
All our Java-mobile media applications do not provide any codecs for streaming media.
It depends only on J2ME implementation in a particular cellphone which stream media format is playable with
Java-mobile player.
To play MP3 stream media a phone must support one of following mime types:
- audio/mpeg
- audio/mp3
- audio/mpeg3
To play AAC+ stream media (which has much better quality) a phone must support one of following mime types:
Many phones can play AAC+ media even if they indicates support only for AAC media (audio/aac mime type).
But it depends only on phone's features, noy on our media applications.
If you use mWebPlayer or any other of our media application
you can easy check all mime types supported by your phone. Just go to Mime Types screen and check the list in
MIME TYPES category.
|
|
Media streaming and locked/unlocked phones
|
|
| |
mWebPlayer and our other media applications
use direct socket connection to get media data from Internet radio servers. Unfortunately many mobile providers
(especially in USA) block access to such sockets for third-part Java-mobile applications. Because of that locked phones cannot play
online stream media from http/socket links and they throws security connection error in this case.
To avoid the restriction you should use unlocked phone or the latest 3G phones
that allows to play stream broadcasted via rtsp protocol.
To check if you phone can support 3G links go to Mime Types screen and check if rtsp is in the list in
PROTOCOLS category.
|
|
mWebPlayer's known issues
|
|
| |
Special message for Motorola Razor V3/V3i users!
According to technical specifications provided by Motorola following MP3
encoding properties are available for Razor V3i platform:
| File Type |
Frequency |
Bit Depth |
Mono/Stereo |
Bit Rate |
| MP3 |
44 KHz |
16 |
Mono |
64 kbps |
| MP3 |
24 KHz |
16 |
Mono |
40 kbps |
| MP3 |
16 KHz |
16 |
Mono |
32 kbps |
Any mp3 stream that does not match specifications above can be not playable.
|
|
Debug mode and resolving issues
|
|
| |
mWebPlayer and our other media applications
has special Debug mode to provide developers helpfull information about problems with our applications.
Unfortunately in many cases users cannot use this mode properly and we receive lots of e-mails with empty log files.
When you got any error message while using our applications keep in mind that log information about the error is not saved in log file
until you turn on the Debug mode in Debug Settings screen. You should set "Debug Mode" in "On" state,
press OK button to save the setting, exit the application and restart it again. Only after this the application will keep detailed
data about its work in its log file. When you recreate situation with error you need to go to Email Log screen and send the message to us.
Starting from verion 2.00 your log file will be attached to your message automatically. There is also restriction that you cannot send the message if your log file is empty.
|
