What you're proposing is called a stream cipher. Most stream ciphers take a key of one of a set of fixed sizes, usually with a non-secret value of fixed size called a nonce, and generate a very large key stream that can be used to encrypt large plaintexts securely.
In such a context, we usually don't use a key as large as 1 MiB because we presently believe that it will be computationally infeasible using all the resources of this planet to brute-force a 128-bit key. People who wish to hedge against additional cryptographic advances may choose to use a 256-bit key. Note that
/dev/urandom are generated using a 256-bit stream cipher on Linux and thus cannot have more security than that.
A scheme where you use a fixed key and a nonce and/or counter (what you refer to as a seed), passing them through a PRF, such as a cryptographically secure hash function, and then XOR it with the plaintext is, in the general case, referred to as counter mode, and is secure provided the PRF is secure. However, no stream cipher is perfectly secure in the way that a one-time pad is secure. That's not practically a problem because we have many good stream ciphers that are extremely fast and provide excellent security.
As a practical matter, you will also want to provide integrity verification for your plaintext using a message authentication code, or MAC, or by using an integrated design containing encryption and a MAC, called an AEAD. Instead of rolling your own algorithm, I'd recommend using AES with OCB mode or XChaCha20-Poly1305, both of which are extremely fast AEADs (4-11 GB/s) and provide excellent security guarantees.