[Red5] Recorded flvs can't be played from the start (Keyframe problem ?)

[Flossie]

Hello,

I've just upgraded our server from 0.7.0 to 0.9.1 and have encountered
a major problem recording incoming video streams. The problem is quite
strange, the file appears to record normally, but when I try to play
it back (either as a stream from Red5 or directly with VLC) it always
jumps forward by a number of seconds. The jump forward different for
every recorded video.

The really odd thing is that i've noticed a strange correlation
between the amount which the video jumps forward and the length of
time it takes me to click on the authorisation dialogue in flash
asking for permission to access the camera/mic. eg if I wait for 10
seconds, then the jump forward will be about 10 seconds. If I
deliberately wait longer and then record a video which is shorter than
the time I waited to click the 'allow' button, then the resulting
video file is unplayable.

I've also noticed when looking at the .meta files created when playing
back though the Red5 server, for videos recorded using 0.7.0, the
first keyframe always has a timestamp of 0, while for the videos
recorded with 0.9.x, the timestamp of the first keyframe is never 0
and always matches up with the point to which the video jumps when
played. My guess is that for some reason the initial keyframe is
either not being recorded or the meta data is being recorded
incorrectly so that the player thinks it is missing.

This problem is demonstrable with both my own software and the simple
recorder demo.

I did find the following older post, which seems to relate to a
similar problem :

http://old.nabble.com/Unable-to-get-a-keyframe-on-the-first-frame-when-recording--stream-to-server-td27463151.html

However, in my case i'm already using ns.publish(pubName, "record");
to send my video to the server, so the solution which worked in this
case won't help.

[Flossie]

One further piece of information when looking at the meta files, the
first entry will always be something like :

<KeyFrame position="126" timestamp="0" />

Followed by more entries in a reasonably regular increasing sequence.
For 0.9.x, the first timestamp will usually be a higher number than
those that follow. The following timestamps usually do then follow a
similar pattern to those in the files recorded in 0.7.0. For whatever
reason, 0.9.x is always recording the first timestamp with the wrong
value.

[Ignacio Lopez]

This problem came up a lot recently in the list...
Anybody knows if there is an issue im trac so devs can take notice?

2010/4/29, Flossie <flossi...@gmail.com>:

[Andy Shaules]

Not sure about the trac documentation, but yes, it is well known to those
who make a habbit of the list.

Red5 has been calculating the epoch of the flv stream from the moment of
creation rather than the first data packet.

The workaround, is to have a netstream waiting in the wings.

When you get permission from the user, fire off and use the new netstream so
there is no delay between the call to create a netstream and a call to
publish.

[Flossie]

> Red5 has been calculating the epoch of the flv stream from the moment  of
> creation rather than the first data packet.

Is this a deliberate change, or merely bug which hasn't been fixed
yet ?

> The workaround, is to have a netstream waiting in the wings.
>
> When you get permission from the user, fire off and use the new netstream so
> there is no delay between the call to create a netstream and a call to
> publish.

I think i'm going to stick with the 0.7.0 release for now rather than
to try and work around this. I would prefer to have a server which
behaves correctly verses changing my code to work around one that
doesn't..

[Octavian Naicu]

On the client side create the new stream/start publishing only when the user clicks the [Accept] button on the privacy dialog box. You can catch that event!

Octavian Naicu,
Founder of AVChat Software
http://avchat.net
http://twitter.com/avchathq

2010/4/29 Flossie <flossi...@gmail.com>

[Flossie]

> On the client side create the new stream/start publishing only when the user
> clicks the [Accept] button on the privacy dialog box. You can catch that
> event!

In my case the stream record isn't started until some time after the
accept button is pressed. The sequence of events is as follows :

Flash applet starts
Access to webcam is requested
Webcam preview is shown in the applet
User clicks record button
Stream is published to the server

I just tried creating the NetStream object at the point at where the
user clicks record (it was previously created it as part of the applet
start up), but this made no difference at all, the first key frame was
still offset in the meta data by the length of the pause between the
accept button being displayed and it being clicked.

Does anybody know what was changed in the Java code which embeds the
timestamps ? I'm a java programmer and i've been having a delve into
the Red5 backend to try and find the root cause of this, but any
helpful pointers as to where these timestamps are determined and set
would be useful.