Gah! Why is anyone even uttering the word "RAID". Ugh. ZFS people. ZFS.
All the striped modes will (in effect) limit write rates to the bandwidth of a single disk, but ZFS is good about this: So long as the writes are reasonably large, as they'll likely be for a media server, you'll usually get the maximum streaming bandwidth of the disk. So, 150-200 MB/s. Reads are much faster.
It's not something you'd want to use in a DC, but for mostly-idle storage at home it's perfectly fine. Add in an SSD cache, and it'll be downright speedy.
That gives an effective capacity of 64 TB, given 8TB disks, and the chance of four disks dying before you can replace even a single one is pretty low. The usual limitation of ZFS applies, however: You have to decide the number of disks up-front, as you can't expand the size of a RAIDZ vdev later on.
(Well, you can, but only by replacing all the disks with larger versions.)
IOPS aren't cheap, and you will find out just how much that matters the moment you have to replace a disk in a pool with a lot of data in it. Resilver times of days can be pretty agonizing in a home setting.
I won't build a pool without at least double redundancy per rotating-drive vdev, meaning at least 3-way mirrors (zpool create foo mirror disk0 disk1 disk2 mirror disk3 disk4 disk5) or raidz2, as I have had to go to backups for failures during resilvers of raidz (never again!) and 2-way mirrors.
3-way mirrors conveniently provide high read IOPS. OpenZFS does a good job aggregating and scheduling writes to the point that writes are mainly choked by random reads. (Very full pools induce quasi-random reads while hunting for space in metaslabs, which is the main reason writes to very full pools perform poorly).
2-way mirrors are only really fine for vdevs that have negligible random-access penalty (and thus likely high IOPS), or where rebuilding an entire pool from backups takes time comparable to resilver and scrub times when dealing with a replacement leaf device that might fail during resilvering (you cannot know the data on the replacment device is OK until you have read it, which generally means scrub-after-resilver), or errors reading the surviving leaf device(s).