Skip to main content
C
Crich18
Participating Frequently
June 23, 2010
Answered

Seeking in a Streaming H264 mp4 to unbuffered section.

  • June 23, 2010
  • 1 reply
  • 4667 views

Hi everyone. I'm working on a video player for my company, and I need to get H.264 videos streaming. I've gotten the mp4 file playing and buffering, which is great, but when I try to seek ahead to a part that isnt buffered, the video stops, goes to the start of the video, and will no longer play. FLV files behave exactly as I would like them to, meaning they go to selection position and start buffering and playing from there. Here is my progressiveSeek function:

public function progressiveSeek(pos:Number):void {
            log("progressiveSeek, pos: " + pos);
             if (!keyFramesSeconds) {
                return;
            }
            var index:Number = findMatchingKeyFrame(pos);
            offsetBytes = keyFramesBytes[index];
            offsetSeconds = keyFramesSeconds[index];
            inSeek = true;
            videoStream.stop();
            videoStream.close();
            videoStream = null;
            getVideoStream().setAutoPlay(true);
            getVideoStream().setTotalTime(totalTime);
            getVideoStream().setSourcePath(getStreamUrl(offsetBytes));

            }

keyFramesSeconds and keyFramesBytes are just arrays that hold the metadata for the seekpoints. This function, when called on the H264, goes to the beginning and stops the video, but when called on the FLV, does what I want. How can I do progressive seek for an H264? Can anyone help me?

Thanks,

Cyrus 

This topic has been closed for replies.
Correct answer Booya2nd

Hi there,

I'm quite familliar with waht you're doing - recently we had a couple of projects where we also used progressive video delivering with mod_h264 installed on the server side.

Regarding your question:

It is totally correct, that your video restarts from zero because you are getting a totally new file which is luckily a subpart of the whole video .

So It's up to you to keep the currentTime wihtin a variable to add it up and to keep track of the correct position of the scrubber.

Kind regards, Booya

1 reply

A
Andrei1-bKoviI
Inspiring
June 24, 2010

If this is a progressive playback - you cannot do that. For progressive videos seek() is available only for the parts of the video that is already loaded and you have no access to the parts of the video that are not loaded. With streaming videos you can do that though but you will need a streaming server like FMS.

C
Crich18Author
Participating Frequently
June 24, 2010

I'm streaming it, and I've figured out how to make the video jump to a specific point, it had to do with the fact that .FLV files take the offset in bytes, and .MP4 files take the offset in seconds (incase anyone else got hung up on that issue). Now my problem is that when I seek to an unloaded part of the .MP4, the "current time" of the video resets to 0. This throws off my seek handle and my timetextbox. I can reproduce any code, but to not bog down the discussion I'll leave it for requests only. Any ideas as to how to fix this one? I've been working on this project for 3 weeks, and I'm very close to wrapping it up, so any help would be GREATLY appreciated.

Thanks!

Thanks for the help Andre

C
Crich18Author
Participating Frequently
June 25, 2010

Hi there,

I'm quite familliar with waht you're doing - recently we had a couple of projects where we also used progressive video delivering with mod_h264 installed on the server side.

Regarding your question:

It is totally correct, that your video restarts from zero because you are getting a totally new file which is luckily a subpart of the whole video .

So It's up to you to keep the currentTime wihtin a variable to add it up and to keep track of the correct position of the scrubber.

Kind regards, Booya


Booya,

Thanks for the help. That's exactly the situation I'm in. I still don't know why, but when FLV files seek they dont restart, and the metadata remains the same, but with H264/mp4, the stream restarts given the offset (as expected), but the metadata truncates any keyframes before the chosen one to seek to. For example if you progressive seek to keyframe #20 out of 100, when you the stream restarts, the metadata only contains 80 keyframes. I've changed my code so it compensates for this, but I'm just a little curios. You've all been great help, and hopefully this will make someones life a lot easier by reading it. That's what helped me.

Cyrus

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices