WebM is in essence a container format for carrying VP-8 video and Vorbis audio. Its description clearly mentions:
One of the major goals is to allow content creators to have advanced playback capabilities, such as fast seeking and fast start using only an HTTP server. To achieve this, the WebM file format guidelines below should be followed when creating content
This just describes how a WebM file should be created so that when a client (e.g. browser) downloads the raw file from a server, it can start playing the video. This is, in essence, a process of "streaming" but has little to do with high-level streaming concepts such as RTMP and HTTP Live Streaming.
Let's talk about those "real" streaming applications first.
In RTMP streaming (Real Time Messaging Protocol), video will be delivered live to the clients. The process is explained in this JWPlayer support document. You need to run an RTMP server like Adobe Flash Media Server or Wowza, which will stream supported file formats (MP4, FLV) to the client. Don't confuse this with the next one …
In RTSP streaming (Real Time Streaming Protocol), is a control protocol for streaming servers such as the QuickTime Streaming Server or Helix Server. The client and server will exchange control messages through this protocol, while the data is transmitted through RTP (Real-time Transport Protocol) payload.
As alreaydy mentioned, WebM video is VP-8 encoded. There is an appropriate IETF draft on an RTP payload format for VP-8, which explains how to pack video into RTP packets and send them to a client. So, you can stream WebM through RTP.
In HTTP Live streaming (Wikipedia article), the client requests "chunks" of a video from a server through simple HTTP requests. The server parses the request and tries to access the corresponding part of a video file to read and deliver to the user.
In order to do so, the server has to know where in a video file which part is stored and makes use of a so-called playlist file for that.
The server MUST divide the stream into individual media segments
whose duration is less than or equal to a constant target duration.
The server SHOULD attempt to divide the stream at points that support
effective decode of individual media segments, e.g. on packet and key
However, for technical reasons, HTTP live streaming requires that "Each media segment MUST be formatted as an MPEG-2 Transport Stream". By design, HLS therefore does not support the WebM video container since the video must be stored in MPEG-2 TS instead.
HLS is relatively new and not widely supported – it also needs special server software to run. It is similar to, but shouldn't be confused with HTTP Pseudostreaming.
HTTP Pseudostreaming is explained very well in this JWPlayer support document. It makes use of the same principle as HTTP Live Streaming. Clients request parts of a video from a server through HTTP requests, but in this case, there is no playlist file, but an index in the video file itself.
So, while through a normal HTTP download, your browser or plugin should be able to play a video file from the beginning, you normally couldn't seek in it. HTTP Pseudostreaming allows you to seek any non-downloaded part of the video, and the server takes control of delivering the correct video segment.
The streaming server needs to have modules for parsing available video files and delivering the right chunks at the right time. MP4 and FLV containers are already supported by Apache and LightHTTPd as well as other servers. The MP4 container will also need to store information about the video itself in the so-called MOOV atom, which should be saved at the beginning of the file in order to be parsed by the server and/or receiving client.
WebM plugins for HTTP Pseudostreaming are not yet available – at least not that I know of.
So, as you can see, there exist various concepts for streaming that go beyond just downloading the file and playing it. WebM supports the latter pretty easily — and this is what HTML5 video will require: You embed the link to the raw video file in a website and the client (browser) will just play it. There's no need for any of the above technologies here, although they do have their merits in other applications.