That is not one requirement, but 4 requirements. One of the characteristics is of a good requirement is that it is cohesive: it addresses one, and only one, functional or non-functional characteristic of the system. I'd enumerate each of these as separate requirements or user stories to promote traceability and verification:
- Users can open content from local machines.
- Users can open content from remote servers.
- Users can open content via FTP.
- Users can open content via web streams.
Now that you have four user stories, you can treat them as four separate entities, with their own estimates, their own priorities, and so forth.
A release in which to deliver the feature is not a requirement of the system, but a measure of priority, so the story to be able to open content from local machines is placed ahead of the others in the product backlog (probably near the top, so it would be in an early sprint). The others can be prioritized where they fall with regards to other functionality.
The separation also promotes better relationship from the requirement/user story to the test cases that verify the functionality and gives the customer and user the ability to prioritize the four modes of operation in the event you can't deliver them all in the same sprint.