For us, one of the big draws for streaming is mobile devices, and right now that means tablets that are almost all iPads, and smart phones where the majority are iPhones. So we need anything that we stream to be compatible with iOS. HTTP Live Streaming does that natively, so there are benefits to choosing that for at least as long as the tablet market is an iPad market. (I'm not bashing Android tablets here. They just haven't gotten much traction in the market yet.)
Last time I looked (and it has been a while), even the mobile devices that support Flash don't do it well, and Adobe is moving away from Flash on mobile, right? As you said, multiple streaming techniques may be required, at least until the various streaming options (HDS, HLS, etc.) converge. On Apr 20, 2012, at 7:56 AM, Ruediger Rolf wrote: > After one week I have to add 2 more findings to my H.264 experiments: > - When rescaling you should be aware that the dimensions of your video must > stay even numbers. If you use the ffmpeg option "-vf scale=200:-1" you might > be unlucky that your hight can get an odd number. > - streaming of h.264 files to mobile devices will require multiple streaming > techniques [4]. > > And now for me the interesting question would be, who has more experience > with these different streaming techniques: > - RTMP worked very reliable for us for several years now with FLV videos. > Additional to any desktop PC that has Flash installed it works in our Android > and iOS app [5]. Unfortunately it does not work with H.264 on iOS (but on > Android). > - HTTP Dynamic Streaming (HDS) is Adobes approach to http-streaming. I never > used it yet, and again it does not work on iOS. I have not tried it on other > plattforms yet. > - HTTP Live Streaming (HLS) is Apples approach on http-streaming. This now > works for iOS only and the latest Mac OS version. You cannot use it on > Windows, Linux, Android, Mac OS 10.6 (try it yourself [6]). So I'm wondering > why such a bad supported format is currently so highly requested. Does anyone > here have experience with HLS yet? > > I'm currently considering to switch back to FLV as everything seemed much > easier with this format. > > Regards > Rüdiger > > [4] http://forums.adobe.com/message/4100805 > [5] http://vm193.rz.uni-osnabrueck.de/matterhorn2go/index_en.html > [6] https://developer.apple.com/resources/http-streaming/examples/ > > On 16.04.2012 17:05, Ruediger Rolf wrote: >> Dear fellow Matterhorn users, >> >> as we start to use our Matterhorn 1.3 in these days, I wanted to improve our >> workflow definitions. I decided that I wanted to use H.264 only, as we >> luckly updated to a Wowza Media Server [1] that allows us to stream H.264 >> [2]. >> >> So I created some MP4 encoding profiles, updated the multi-quality workflow >> definition and created a HD-workflow definition based on multi-quality. >> These updates are documented here [3]. >> >> In creating the MP4 encodings I recognized that MP4 behaves quite different >> from FLV. I don't know how much I like these changes and I must say that FLV >> had some great features that I currently miss. So what has to be considered >> when encoding MP4: >> 1. If you want synchronous playback of two streams the two videos for >> presenter and presentation need to have the same framerate and GOP >> structure. If this is not given the videos can be out of sync for several >> seconds. >> 2. The Engage Player can only jump to key-frames. These are usually set >> every 300 frames. That means every 10s on NTSC, 12s on PAL. If you reduce >> the framerate to save bandwith the intervall may become even greater. You >> can try to set the key frame interval manually, but the presets may >> overwrite these changes. The consequence is that when you jump to a chapter >> in the Matterhorn engage player you will not jump to the exact second but to >> the last keyframe, that may be several seconds earlier. FLV did not have >> this problem as the format somehow stores the reference to the keyframes in >> the metadata. >> 3. At least in the engage player there seems to be a problem that the h.264 >> videos are not always lip sync, which means that the delay of audio and >> video is more than 80ms. >> 4. There are several "profiles" for H.264. I have not understood the >> differences between these profiles in depth. The advantage of baseline >> profile is that it should run on the most devices and is probably hardware >> accelerated. So at least one of you profiles should be a basline profile. >> From my subjective tests the lip-sync issues is not that recognizeable on >> main and high profiles somehow. >> 5. There are several encoding presets (from ultrafast to veryslow) for x264. >> There is a dublication of presets ffmpeg has its own which are called with >> the "-vpre" option and the presets from the x264 codec itself which can be >> called with the "-preset" option. The vpre-settings create a MP4 that is not >> playable in Flash, so I recommend to use the x264 presets that all seem to >> work fine. In my tests ultrafast was more than 10x faster than veryslow. >> From my test-encodings I decided to use the medium setting (2-3x the >> encoding time of ultrafast), as the video-quality seemed okay for me than, >> but I might adjust this with more test videos around. (In general the >> baseline profile encoded 30% in my examples than the other profiles). >> >> I hope my findings are helpful to others, as it seemed to me that there was >> quite a lot chatting on IRC about using H.264. >> >> Rüdiger >> >> >> [1] A guide on how to setup Wowza with Matterhorn can be found here: >> http://opencast.jira.com/wiki/display/MHDOC/Wowza+Media+Server+3+v1.3 >> [2] Red5 does not allow seeking in MP4 files somehow. >> [3] >> http://opencast.jira.com/wiki/display/MH/HD-Video+%28720p%29+with+H.264+encoding+only >> > > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
