One of the problems you will encounter with this is that, because of the way video compression works, video files are not a consistent stream that can be arbitrarilly dipped into at random.

Greatly simplified, the majority of video encoding work something like this.

First, a full frame is transmitted. Then, a series of deltas -- subsets of full frames -- representing the changes from the previous full frame plus accumulated deltas is transmitted. At essentially arbitrary points dictated by some heuristic, a new full frame will be transmitted and the subsequent deltas will be applied to this new frame.

If you dip into the stream at some random point, it is very unlikely that you will do so at exactly the start of a new frame. The result is that the receiver will never have seen the full frame to which the deltas you send should be applied and the you'll see the familiar scrambled video. This will remain until the stream encounters a new full frame.

For active video -- where the camera is panning or zooming or both, this may only take a second or two.

But for more static video -- examples: the fixed position of video chat or surveillance CCTV -- it may take many seconds before the compression algorithm detects sufficient change in the original input to make it economic to transmit a new full frame.

This is why when trying to step back and forth through video streams, you can often only move in fairly course steps. Those that equate to new full frames.

In essence, unless your client has some intelligence about what byte ranges it requests, the results are likely to be very unsatisfactory.