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]
_______________________________________________
