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
