Hi Max, I really should evolve beyond using Pine for my email - all those curly quotes and so forth seem to get lost. :)
In short, when you're using the ns.seek(seconds); to actively view a still image of that point in the video, you're only going to see the keyframe that is closest to that position. Anyway, to further respond to your two points: > It was a good shot in the dark: it solved my problem temporarily, but > it would appear that latest versions of red5 (after rc2) can only work > with files encoded in a special way so the seeking process works > properly -- is that correct? No, I don't think so. Regardless of what software you use to encode video into a FLV file, Red5 should be able to stream that back to a client. One bleeding-edge exception may be the latest version 7 of the On2 VP7 codec which presently requires a special player to view the FLV file. However, for our intents and purposes, if you're encoding video you have two choice of codecs: Sorenson Spark or On2 VP6. Your choice of which one to use depends mostly on which ever one you feel you get the best results from - most everyone these days has at least version 8 or 9 of the Flash Player, which handles both, while earlier versions will only handle the Sorenson codec. The "seeking" process appearing to work differently is due to the quantity or frequency of keyframes in the encoded video - since these are what the playhead is actually "seeking" to. Now your next point: > I’ve tried to change keyframe settings in Sorenson Squeeze to > reflect recommended value, set at every 6 seconds. Ironically, I > erroneously placed a keyframe every 6 frames (not 6 seconds!!!) and > the resulting huge flv file had no“ slider issue”. Placing > keyframes every 6 sec brought back the very same problem. I > didn’t have much time to actually experiment with different > keyframe settings, but the problem is definitely related to the > density of keyframes. Once again, rc2 had no such problem. It looks > like red5 forces everybody to use only specially prepared content with > certain density of keyframes, otherwise seeking process works in a > somewhat strange manner (as described in my previous email). If you re-read what I originally wrote about keyframes, and compare that with what you experienced, then perhaps your perceived problem about how the "seek" works will become more apparent. When you specify to add a keyframe every "Nth" frame, that means that if your video is, say PAL at 25 fps, or NTSC at 29.97 fps, then specifying a value of "6" will mean that you end up with about 4 or 5 keyframes per second - this is kind of overkill unless your intended audience is watching the video directly from their local hard disk or a CD. As you no doubt noticed, the size of the file that was produced was overly large. If you want to have a keyframe every six seconds, then what you'd do is multiply 6 by the framerate of your video. So it would be more like a keyframe every 150 frames, or every 180 frames. If you wanted a keyframe for at least every second of video, then choose a value that matches the frame rate - say 25. Although you're still going to end up with a quite larger file than if you let the keyframes be inserted automatically. More often than not, at least if you're using the Flash 8 Video Encoder, and you're working with files that are longer than a few minutes minutes, letting it automatically insert keyframes works fine - and I'd assume this holds true for any other encoding software (Sorenson Squeeze, ffmpeg, etc.). You have to decide how important it is for people to be able to seek to any exact spot in the video, or if it's okay to just get close. Here's the important thing to keep in mind - when you "seek" to a point in the stream, regardless of how precise you wish that to be - the playhead is only going to display the keyframe THAT IS CLOSEST to the timecode you're asking for. For instance, if there is a keyframe at 110 seconds into the video, and the ones around it are at 100 and 115 seconds, then if you seek to, say 117 seconds, you're going to get the keyframe at position 115 instead. If you seek to 106 seconds, you're going to see the keyframe at 110 seconds, and so on. Just because you expect to be able to smoothly seek to any arbitrary point in the video does not mean that you'll actually see what's there - what you will see is the keyframe CLOSEST to the point that you're trying to seek to. The reason for this is simply that the intervening "delta" frames do not contain all of the information necessary to give you a single still image - only a keyframe can do that. This, however, doesn't mean that you can't force playback to start or stop at any arbitrary number of seconds in the video - certainly that works. Hopefully this makes a bit more sense now. :) Yours, Nathan On Wed, 28 Mar 2007, Max Medvetsky wrote: > Hi, thank you for your help and advise. > > “ Just a shot in the dark, but two things come to mind.” > > It was a good shot in the dark: it solved my problem temporarily, but > it would appear that latest versions of red5 (after rc2) can only work > with files encoded in a special way so the seeking process works > properly -- is that correct? > > “ Second, the slider bar, when moved, is going to try to seek to > the closest keyframe in the video. Given that with most encoding > software, you only have the option of "automatic" keyframes (the > software will put them in when it determines one is needed to improve > the quality) or forcing the creation of a keyframe every N frames > (which increases the overall size of the FLV as N approaches 1 - most > guides recommend placing a keyframe every six seconds, and then > working around from there). So what you may be seeing with your > slider bar is just normal behavior.” > > I’ve tried to change keyframe settings in Sorenson Squeeze to > reflect recommended value, set at every 6 seconds. Ironically, I > erroneously placed a keyframe every 6 frames (not 6 seconds!!!) and > the resulting huge flv file had no“ slider issue”. Placing > keyframes every 6 sec brought back the very same problem. I > didn’t have much time to actually experiment with different > keyframe settings, but the problem is definitely related to the > density of keyframes. Once again, rc2 had no such problem. It looks > like red5 forces everybody to use only specially prepared content with > certain density of keyframes, otherwise seeking process works in a > somewhat strange manner (as described in my previous email). > > “ What were these examples that you didn't use the Flash 8 > Encoder to create made with?” > > I’m using Sorensen Squeeze to encode a DVD chapter. > > > > Nathan P. Johansen wrote: > > Hi, > Just a shot in the dark, but two things come to mind. > > You're using John's FLV player - so I'm not sure how it does a "rewind", > but if you're writing your own code, I'd suggest something simple like: > > ns.seek(0); > > To return the playhead to the beginning of the video. If you want to > pause it there, or force playback, then just do one of these next: > > ns.pause(); > ns.play(0); > > Second, the slider bar, when moved, is going to try to seek to the closest > keyframe in the video. Given that with most encoding software, you only > have the option of "automatic" keyframes (the software will put them in > when it determines one is needed to improve the quality) or forcing the > creation of a keyframe every N frames (which increases the overall size of > the FLV as N approaches 1 - most guides recommed placing a keyframe > every six seconds, and then working around from there). So what you may > be seeing with your slider bar is just normal behaviour. > > If you're capturing video from a web camera - I'm not entirely certain how > keyframes are (or perhaps are not) added to the FLV file. What were these > examples that you didn't use the Flash 8 Encoder to create made with? > > Nate > > > On Mon, 26 Mar 2007, Max Medvetsky wrote: > > > > Hello everyone!I'm using a trunk version (r1777) and I noticed that the > "rewind" > function now behaves somewhat differently from rc2's. I know that after > rc2 release a new .meta format was introduced to avoid the reparsing of > flv. I can no longer rewind to a particular place, or at least I cannot > do it 100% of the time. Sometimes the playback starts from the slider > point, and sometimes it just continues playing and it ignores a slider > being moved altogether. One little detail: this does not happen if I'm > using Flash 8 Encoder to produce flv file, but only if I'm using > Sorensen Squeeze 4.5 (VP6 2-pass VBR 256Kbit). So I'm wondering whether > there are any flv format variations that aren't fully supported by red5? > (like using progressive jpegs was not supported by Flash player some > time ago). Did anyone else come across this problem? The described > behavior was reproduced by using Flv Steram Player written by John Grden > and the latest trunk version (r1777), so I didn't write any code, and > it's not therefore my bug > > > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
