I have to know how many clients can stream movies from the SD card
through a HTTP request.
You don't want to know.
Using WiFi for such a setup (assuming that you have many WiFi clients to serve) will be cumbersome to start with, because Wifi does not lend itself for one-to-many simultaneous data flows (see both Ron's answer and comment).
It's already difficult when the sender is on the wired part of the network, and needs to serve multiple Wifi clients, but it gets hilarious when both sender and even just one receiver are on the same shared medium (same radio interface of the same AccessPoint) - achievable throughput is crippled to less than 25% of the nominal rate, because "airtime" is wasted for the sender to send data to the AP, then the AP to ACK that, then for the AP to send to the receiver and the receiver to ACK to the AP. The effect may be not quite be as bad on modern multiband APs where sender and receiver are not on the same frequency band or radio channel.
In short: when serving many (video) clients simultaneously with a continuous data stream, restrict the WiFi part of the overall network to the absolute minimum: Camera or Video server ("sender/source") to its nearest AP (if it needs to be wireless, prefer wired by all means), and serve the clients from other APs. Size the AP-to-client ratio accordingly.
Consider adding a "stream replicating server" in the wired part of the network, taking only a single unicast stream from the source, then handling the stream replication to the many unicast clients with its CPU/GPU and NIC power (we'll forego the options of transcoding and multicasting for today).
On top of that, there's the question of video codec and software used, and how sensitive they are to an ill-formed data stream (packet loss and out-of-order delivery). Packet loss and retransmissions is what you will get in WiFi networks.
There was that case of a ~10-11Mbit/s HD stream (over HTTP), from a surveillance camera to a server, encoded with MPEG2. Occasionally, video quality suffered somewhat, but was generally acceptable; but a constant/sustained 10+ Mbit/s stream was considered a waste of costly bandwidth for the WAN. Therefore, the customer wanted to save some bandwidth and use a more bandwidth efficient MPEG-4 codec.
Curiously, on the same network, from the same camera streaming the same scene at the same resolution to the same server, the 2.5-3Mbit/s MPEG-4 encoded stream would just not work at all. Eventually, it turned out that an utterly wrong QoS configuration on the camera's switch port had impacted all video streams with massive out-of-order delivery effects and quite some packet loss when the WAN link was just a bit saturated. The given software's MPEG-2 implementation had been able to cope with it, but the MPEG-4 codecs in the same software didn't. Correcting the QoS config made things work again.