If you assume there's only one file you could probably skip it.
But the question was about using the zip file as a source for streaming, and that will work fine even if you have to spend an extra read to load the directory first.
I don't think you can safely assume random reads if you are streaming. Usually the point of a stream is you have to process the file in-order.
Regardless, if for some weird reason you really liked the zip compression algorithm (DEFLATE), you would probably just use gzip instead (same compression algorithm, no weird file format with critical metadata at the end). Its also the compression algo used by PNGs.
> I don't think you ca safely assume random reads if you are streaming.
I could interpret this a couple ways, so let me try to clarify.
If you're talking about the ability to seek around inside the video, it is correct that this will not work well.
If you're talking about seeking to the end of the zip file to read the directory, I don't think that was part of the scenario. My interpretation of the question is that the server has a zip file and has to output a video stream directly from the zip.
If the zip itself is being delivered as a single stream, start to end... I have no idea what kind of scenario this is. There's no zip-streaming protocol out there. Filesystems can give you the end of a zip. HTTP can give you the end of a zip.
> Regardless, if for some weird reason you really liked the zip compression algorithm (DEFLATE), you would probably just use gzip instead (same compression algorithm, no weird file format with critical metadata at the end). Its also the compression algo used by PNGs.
Maybe. You might want windows users to be able to easily extract the video.
the question in the OP was to have the avi file be zipped, and it would offer similar levels of compression.
But if you're streaming a zip file down the line, can you view the stream as it partially loads, which is possible with certain video formats (esp. if the player can handle missing key frames etc).
I was under the impression that a zip file cannot be partially read and reconstruct partially the contents.
The first distinction is between streaming from the start of a file, without needing any storage space, versus streaming from a random point in the middle of the file. With a zip you can do the former, but you cannot do the latter.
The second distinction is between streaming the zip itself, versus streaming from the zip without needing any storage space. If you stream the zip itself, and don't allow even a single extra read to get the directory, it will be trickier to extract the video on the fly but still probably possible. If you are streaming from the zip then you can read the end then jump to the start and begin streaming, and it will work fine.
If that's a confusing mess, then I guess be more specific. What data does the video player see, and from what protocol?
Let's imagine the scenario : you have a video file on a http server, and you want to serve the video to the end user.
The end user can buffer the entire video, but that takes too long. So ideally, the player can download the video partially, and start watching while buffering the remaining. (assume the video is in a format that's streamable).
So is it possible to zip the video on the server, and rewrite the http server to serve the zip file directly to the end user, and yet still have the end user be able to partially view the video as a stream, while the zip is still downloading?
> it will be trickier to extract the video on the fly but still probably possible
i think this is what i'm looking for - extract a partial video file from a partially downloaded zip file.
If the user is viewing the video from the start, then there's no problem. There are multiple ways to make this work.
If the user wants to jump into the middle of the video, it won't work.
That's the short answer.
The long answer goes into more detail on how to make it work:
It would be possible to have the http server unzip a megabyte at a time and send it to the client, but you said you want to send the zip to the user so we'll cross out this possibility.
That leaves two ways of doing things.
The easy way is to have the client make an HTTP Range request to get the last 100KB of the zip file, then make a second request to start at the beginning of the zip file. This will let the client act like a completely normal unzipper, and it can start playing immediately.
The hard way is to go into more detail about how a zip file is structured. We don't actually need the directory to start decompressing. A zip file is structured as [file header][file data][file header][file data][file header][file data][directory]. You can just start decompressing the first file in the zip and feeding it into your media decoder. It'll work.
For watching videos from the start, zipping is only be a problem if you put multiple videos into a single zip and use a web server that doesn't support Range requests.
