I am having problems recording audio in FIMS 3.5. About 20% of the videos recorded appear to fast forward part way through the video. I understand this occurs when there is lag between the audio and video that is sent from the client to the FIMS server. I have tried setting the parameters in the <RecBuffer> section of the Server.xml file to sufficiently high values to offset the lag but the problem is still occurring. Are there any other areas I should be looking at to solve this issue?
Heh, well apparently the forum has some email response bugs too - oh well - my response went like this.
> Cut
Interesting. Can you share the scenario that you're experiencing this in?
You're recording with the Flash Player I assume? If not then with what?
How large is the stream and how large is the bandwidth pipe for recording it? Are you using a buffer on your publish?
What are the settings that you employed to try and correct this?
Is there a commonality to the 20% that expose this issue? Bandwidth? OS?
Where does the issue happen in the stream, everwhere - just at one point, only if they've been going on for a while?
Does this occur if you record to an mp4: format instead?
Asa
>You're recording with the Flash Player I assume? If not then with what?
Yes, recording is done with Flash Player. It is just a basic recording application that allows users to record up to 10 mins. of audio/video. No other bells or whistles.
>How large is the stream and how large is the bandwidth pipe for recording it?
The steam is up to about 500 Kbps and our pipe is 1 gb.
>Are you using a buffer on your publish?
Yes, I’m using quite a large buffer on the client side, almost enough to buffer the entire video. When recording is stopped the contents of the buffer is flushed to the server before the stream is closed. This may take several minutes for people with slow connections.
>What are the settings that you employed to try and correct this?
<RecBuffer>
<MaxFlushTime>300</MaxFlushTime>
<MaxFlushSize>10240</MaxFlushSize>
<AllowedVideoLag>300</AllowedVideoLag>
<MaxSize>10240</MaxSize>
<MaxTimestampSkew>-1</MaxTimestampSkew>
</RecBuffer>
>Is there a commonality to the 20% that expose this issue? Bandwidth? OS?
No commonalities that I have noticed so far. I am not currently recording bandwidth or OS stats but I should look into this.
>Where does the issue happen in the stream, everwhere - just at one point, only if they've been going on for a while?
It happens in videos of all lengths. Never at the very beginning or end but can occur anywhere in between.
>Does this occur if you record to an mp4: format instead?
I have not tried recording in mp4 format.
Hey Spykke,
Can you try two things here
Dunno if you had this before on FMS 3.5.2 - but the AllowedVideoLag is auto tuned from that build to be the buffer size of the player. That's what it needs to be to prevent this out of order recording happening. That wasn't true in old builds. However, it's treating your setting like an override to 5 mins. So please try
1. Removing the AllowedVideoLag setting
2. If that doesn't work try changing it to 1200 as that represents twice the 10 min buffer you allow clients to have and should help the situation.
Asa
Spykke,
I'm just curious how you're flushing the rest of the buffer to the server when you stop recording? Currently when the user presses the "Stop Recording" button, i just close the netstream (netstream.close()). Does closing the netstream flush the buffer before it actually closes? Is there another way to do this? I also tried to set netstream.attachCamera(null), netstream.attachAudio(null) but I never received the NetStream.Record.Stop event.
I don't have any custom FMS code for the recordings. I simply call netStream.publish(fileName, "record"). How do you handle this?
Thanks,
Wes
North America
Europe, Middle East and Africa
Asia Pacific