![]() **UP TO HD QUALITY** You can stream movies up to HD quality (1080p) over WiFi to your iPhone or iPad from most recent Macs and PCs. StreamToMe users can download ServeToMe for free from ServeToMe converts the files to an iPhone/iPad-friendly format *on-the-fly*, so a single touch will start playback on your device in as little as 5 seconds. StreamToMe's companion program *ServeToMe*, which runs on your Mac or PC, does that for you. iTunes library integration browse your iTunes files and playlists - iPhoto library integration - Play all your music, display album art - Play through folders or use your iTunes playlists - TV out via the Apple Component, Composite and VGA cables (iPhone4 or newer) - SRT, SSA and SUB files or embedded text or DVD_SUB subtitles - Play audio in background - AirPlay audio and video support **NO NEED TO CONVERT OR SYNC** Why bother converting your stuff to an iPhone/iPod size or iPad format before you can view it? Syncing files to your iOS device is a pain. Video up to HD quality 1080p - Continuous and random playlist modes or single file only mode. ** FEATURES ** - Huge number of video, music and image formats supported (MP4, MKV, AVI, MP3, AAC, FLAC, JPEG, PNG and many more). Play on your device or Apple TV via AirPlay or use TV out dock/lightning cables, turning your iPhone/iPod/iPad into a mobile media player for all your computer's files. No prior conversion or syncing required (huge number of formats supported) just tap the file and it plays. As we move forward, we are likely to reconsider the builtin segmenter.Use StreamToMe on your iPhone, iPod Touch or iPad to play *video*, *music* and *photo* files streamed over WiFi or Cellular from any Mac or Windows PC running the free ServeToMe server (download from ). Also, at the time we started development we were on ffmpeg 0.8.x transitioning on 1.x and the builtin segmenter support was not great. So far, our approach seems to work fine so we are happy with that. I want to warn the reader to be careful if you want to experiment this path because the standard poses some constraints on how fast you can change the segment duration. ![]() Specifically, having shorter segments at the beginning of the video allows the player to download less data before starting playout. Some are because of the way our pipeline works and the fact that with our tool we can create segments with variable lengths to minimize the startup latency. There are several reasons why we went with our own solution. I felt like this part of the explanation was a bit too technical for a general audience but I can comment here. Good point on the segmenter built in ffmpeg. 3) providing a high quality gratifies the users that are previewing content on a fast wifi network. 1) Apple requires a minimum supported rate of 64Kbps, 2) networks are really still incredibly spotty and providing multiple representations enables the player to act intelligently and switch according to the instantaneously measured throughput of the channel. Multiple bitrates is a must for a few of reasons. As other folks commented already, we did find the support to be much more stable on ICS and above. For instance, at some point we dag into the code and found that certain useful tags like the EXT-X-PLAYLIST-TYPE (see. Anecdotally, our code has quite a few conditional statements to deal with Android. Given our engineering resources, we need to pick our battles so a good solution (even if not perfect) is better than no solution. We try our best to build a solution that works as ubiquitously as possible and indeed it gets challenging on Android. Hello there, Pierpaolo from Dropbox here. Pre-transcoding the first few seconds is a really great approach that I had never considered before. I have not found this to be the case so long as you set the segment times individually and force new keyframes at given times (-force_key_frames and -segment_times flags, otherwise the segmenter ignores your segment time option and just creates TS chunks at whatever frequency it wants to). You mentioned the mpeg-ts segmenter in more recent versions of ffmpeg but also mentioned that it has unacceptably high latency. Or is it to compensate for potential bandwidth fluctuations? Why offer the multiple bitrates on the HLS stream at all? You know what the client's bandwidth is, why perform three separate live transcodes? Is this because you're delivering the stream to an iOS app and Apple requires that? In Safari or a UIWebkitView based app you probably wouldn't have to do that. Then again, there's not a great alternative. Do you mean in-app HLS support? The Android Chrome browser doesn't support it at all, and only a select few versions of the regular Android browser support it. HLS support on Android is incredibly spotty.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |