1

I have been breaking my head for the pass 2 weeks, and I still can't figure it out. I'm trying to build a Server-Client based streaming player on Python (Ironpython for the wpf GUI) that streams video files. My problem is when the client requests to seek on a part that he did not load yet. When I try to send him just the middle of the .mp4 file, he cant seem to be able to play it.

Now I know such thing exists because every online player has it, and it uses the HTTP 206 Partial Content request, where the client just requests the byte range that he desires and the server sends it to him.

My question is - how is the client able to play the video with a gap in bytes in his .mp4 file - how can he start watching for the middle of the file? When i seem to try it the player just wont open the file.

And more importantly: how can I implement this on my Server-Client program to enable free seeking?

I really tried to look for a simple explanation for this all over the internet... Please explain it thoroughly and in simple terms for a novice such as me, I would highly appreciate it.

Thanks in advance.

Omer Maimon
  • 31
  • 1
  • 3

1 Answers1

3

Before playing an MP4 file the client (e.g. browser) needs to read the header part of the file. An MP4 is broken into 'Atoms' and the Moov atom is the header or index atom for the file.

For MP4 files that will be streamed, a common optimisation is to move this Moov atom to the front of the file.

This allows the client to get the moov at the start and it will then have the information it needs to allow you jump to the offset you want in your case.

If you don't have the moov atom at the start the client needs to either download the whole file, or if it is a bit more sophisticated, jump around the file with range requests until it finds it.

Mick
  • 24,231
  • 1
  • 54
  • 120
  • But once I have the moov atom, how can i make it play the middle of the file? – Omer Maimon Jan 16 '17 at 20:32
  • 1
    The moov atom contains the byte offset of every frame in the file. Parse the atom, find a sync frame, find the chunk offset and download from that byte. – szatmary Jan 17 '17 at 04:55
  • Browsers are smarter than jumping around. If they don't see the MOOV atom in the beginning of the file, they download some amount of bytes from the end of the file (varies, don't know why). Now that they have the MOOV, they send a 3rd and final request to stream the file. – Greg Bell Dec 13 '20 at 00:29
  • @GregBell - that's very interesting - I'm guessing this is a recent development and it makes a lot of sense. Do you have any references as it would be great to look at it a little more? – Mick Dec 13 '20 at 20:55
  • @Mick I thought so too. I think the browser even aborts the stream when it doesn't see the MOOV, because the first request, size-wise, actually asks for the full video. https://stackoverflow.com/a/29013131/3713234 with a pointer there to even more details.. If you're interested, I can make available a video for you to point your browser to and see first hand. – Greg Bell Dec 14 '20 at 21:24
  • @GregBell - Thanks. The linked discussion in that answer, is something I had seen before . I think the comments ask some good questions also. It would be really great to have a definitive explanation, per browser, but I have not seen one to date. – Mick Dec 15 '20 at 08:52